molily: Sinn und Zweck des "target"-Attributs

Beitrag lesen

Hallo,

Es gibt jedoch auch Momente, wo man ganz gerne ein neues Fenster hätte und dem besucher - im Gegensatz zu anderen Webseiten (natürlich nicht von mir), wo er gerade so mit einem Fensterjungel konfrontiert wird - lediglich die Möglichkeit gibt, eine intelligente "Fensteraufteilung" vorweg vorzunehmen

Dann lautet die Technik, die du suchst, »Frames«, nicht target="_blank".

Nein, ich meinte das eher in Verbindung mit "mehrere Fenster in bezug auf mehrere webseiten" - ich würde nie im Leben ein frameset für eine Linkliste erstellen und den Surfer zwingen, eine neue Seite in einem hässlichen Frame zu öffnen´...

Ich verstehe nicht, was am Öffnen immer neuer Fenster sonderlich übersichtlich und somit »intelligent« ist. Das läuft ebenso auf einen Fensterdschungel heraus.

Während es bei target="_blank" in der Regel ein aktuelles, unabhängiges Fenster gibt, welches letztlich geschlossen wird, wenn zum Ursprungsfenster zurückgekehrt wird,...

was afaik definitiv falsch ist, denn ein mittels _blank geöffnetes Fenster öffnet ein unabhängiges Fenster (diesmal nicht afaik), und du kannst nicht einfach sagen, der Surfer würde es schließen, um zum Ursprungsfenster zurückzukehren.

Es ging darum, dass die gewünschte und »in der Regel« zu erwartende Wechsel zum Ursprungsfenster davon begleitet wird, dass der Benutzer aus welchen Gründen auch immer seine Aktivitäten dort - zumindest zeitweise - als beendet ansieht. Dies wären die Motive, aus denen bei einer Einfensterlösung die zurücknavigiert wird. Das Fenster kann dann geschlossen werden oder unbeachtet in den Hintergrund wandern, auf jeden Fall hat es mit der Ursprungsseite nichts mehr zu tun und die Ursprungsseite greift nicht mehr darauf zu. So entstünden mitunter viele von diesen Fenstern, je mehr target="_blank"-Links gefolgt werden. Daher wird in den meisten Fällen durch das Schließen des neuen Fensters zum Ursprungsfenster zurückgekehrt bzw. wird das vom Benutzer verlangt, denn sonst sammeln sich unzählige Fenster an, in denen der Benutzer mehr oder weniger parallel surfen müsste.

Zurück zum Beispiel Linkliste: Ich finde einen guten Link, klicke drauf, im neuen Fenster, schön, schließe die Ursprungsseite weil sie für mich keinen Sinn mehr hat (ich habe ja das schöne neue fenster), und weiter geht's...

Wenn dieses Szenario tatsächlich relevant ist, spräche es aus Sicht des Benutzers gegen eine Mehrfensterlösung, weil es viel einfacher ist, eine Seite über einen direkten Link ohne neues Fenster zu verlassen. Sie stört nicht als Fenster im Hintergrund und ist immer komfortabel über die Browserhistory zugänglich.

wäre ein solches zur selben Seite gehörendes Zweitfenster gleichzeitig abhängig/verbunden und unabhängig, weil es offenbar nebenher existiert und beim Zurückkehren zum Ursprungsfenster absichtlich offen bleibt.

Ja und? Du kannst genau diese art von fenstern auch mit window.open() erstellen

Mein Posting erläutert eben, warum es unsinnig ist, bewusst mit Zweitfenstern zu arbeiten, welche im Hintergrund offen bleiben sollen, um dann mit target ohne JavaScript angesprochen zu werden - insofern wäre *nur* die Variante mit window.open() sinnig.

<a href="#" onclick="window.open('http://www.irgendwo.de');">
Und dieses Fenster ist afaik genauso wie <a href="http://www.irgendwo.de" target="_blank">.

Abgesehen davon, dass solche Popup-Fenster auch zugänglich gelöst werden können, ist es schwer, damit alle Merkmale eines target="_blank"-Fensters interoperabel nachzuahmen (z.B. dass die Fensterkonfiguration eins zu eins übernommen wird).

(In welchen Fällen hat so etwas überhaupt Sinn, wozu solche Konstruktionen verwenden?)

Wieso komplizierte JavaScript-Dinge, wenn es letztenendes mit target sooo einfach geht?

Ich habe Gründe in meinem Posting genannt.

Wenn nur mehrfach target="zweitfenster" ohne window.open() verwendet wird, ergäbe sich das bekannte Problem, dass das Zweifenster nicht in den Vordergrund geholt wird, sofern es schon geöffnet ist.

eigentlich, ja. Aber es gibt dann wohl auch Suchmaschineneinstellungen (mir fällt gerade google und die Selfhtml-Suche ein), wo man einstellen kann: Suchergebnisseiten in zweitfenster öffnen. > target="irgendeinzweitfenstername"...

Dann ist das kurzsichtig, weil sich scheinbar nichts tut, wenn der Benutzer auf einen Link klickt, weil sich die Zielseite im Fenster im Hintergrund öffnet, was er vielleicht nicht einmal durch die Fenstertitel-Änderung in der Taskleiste bemerkt. Nach anfänglicher Irritation mag der Benutzer das System zwar durchblickt haben, zumal er es ja bewusst in den Einstellungen eingeschaltet hat, aber intuitiver wäre es trotzdem, wenn das Zweitfenster auf jeden Fall beim Aktivieren eines Links in den Vordergrund geholt würde. Das Mittel dazu ist JavaScript.

Für interne Zweitfenster wäre also höchstens target="_blank" bzw. eleganter window.open() mit Autofokus und - je nach Inhalten - Fokussperre (sodass wie bei GUI-Dialogen nur ein Fenster fokussiert sein kann, in dem Fall das Zweitfenster, welches geschlossen werden muss, um zum Ursprungsfenster zurückzukehren) effektiv.

Wieso will man dem User aufzwingen, dass das neue Fenster im Vordergrund bleiben soll?

Weil manche Seiten so aufgebaut sind, dass in den Popup-Fenstern gewisse Formularinterfaces oder ähnliches enthalten sind, welche eine bestimmte Aktion vom Benutzer verlangen (eben wie bei den verschachtelten Dialogen einer Anwendung). Oft wird beim Abschluss dieser per JavaScript das Ursprungsfenster geändert. Durch diese Abhängigkeit ist es notwendig, dass das Zweitfenster nicht den Kontext zum Inhalt des Erstfensters verlieren darf. Es wäre unsinnig, wenn es als Zweitfenster im Hintergrund verbliebe und der Benutzer im Ursprungsfenster weiterarbeiten würde.

Ich habe mit meinem Ursüprünglichen "_blank"-Beispiel ein ganz unabhängiges zweitfenster angesprochen, nichts komisches javascript-gefrimeltes, was sich aggresiv in den Vordergrund drängt.

Das komische JavaScript-Gefriemelte ist ein Beispiel für eine der wenigen sinnvollen und zuverlässigen seiteninternen Zweitfenster-Anwendungen.

Mathias

0 55

W3C-Validator ... Das groooooße *ggg* zum Wochenende

WauWau
  • sonstiges
  1. 0
    Thomas J.S.
    1. 0
      WauWau
      1. 0
        rainer groth
        1. 0
          WauWau
          1. 0
            rainer groth
            1. 0

              W3C-Validator ... Doch ein lokaler Webserver...

              WauWau
      2. 0
        Thomas J.S.
        1. 0
          WauWau
  2. 0
    Tobias Kloth
    1. 0
      WauWau
  3. 0

    W3C-Validator - Das große "Wie poste ich unbrauchbar" zum WE

    MudGuard
    1. 0
      WauWau
      1. 0
        MudGuard
        1. 0
          WauWau
  4. 0
    Avalon
    1. 0
      WauWau
      1. 0
        wahsaga
        1. 0

          Sinn und Zweck des "target"-Attributs

          WauWau
          • html
          1. 0
            wahsaga
            1. 0
              WauWau
          2. 0
            Sven Rautenberg
            1. 0
              wahsaga
              1. 0
                Sven Rautenberg
                1. 0
                  molily
                  1. 0
                    WauWau
          3. 0
            molily
            1. 0
              WauWau
              1. 0
                wahsaga
                1. 0
                  WauWau
                  1. 0
                    wahsaga
                    1. 0
                      WauWau
              2. 0
                molily
                1. 0
                  WauWau
                  1. 0
                    wahsaga
                    1. 0
                      WauWau
  5. 0

    W3C-Validator die 2: (nur)1völlig unverständlicher Fehler?

    WauWau
    1. 0
      MudGuard
    2. 0
      Ingo Turski
      1. 0
        MudGuard
        1. 0

          W3C revolutioniert seine HTML-(XML?)-Spezifikationen !?

          WauWau
          • zur info
          1. 0
            Sven Rautenberg
            1. 0
              WauWau
              1. 0
                MudGuard
                1. 0
                  WauWau
                  1. 0
                    Thomas J.S.
              2. 0
                Sven Rautenberg
                1. 0
                  MudGuard
                  1. 0
                    WauWau
                    1. 0
                      Thomas J.S.
                2. 0
                  WauWau
                  1. 0
                    Daniel Thoma
      2. 0
        WauWau
        1. 0
          wahsaga
          1. 0
            WauWau