Sinn und Zweck des "target"-Attributs

[WauWau]

Hallo molily,

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

es kann, muss aber nicht - hierbei spielt das verhalten des surfers natürlich eine rolle.

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.

Wer zwingt ihn parallel zu surfen? Aber Ok, ich habe mir das mal recht überlegt und schreibe jetzt mal für die "usuability" demnächst keine traget-Attribute mehr, dann müsste mein XHTML-Tansitional-Code doch ohne Probleme XHTML-Strict werden, oder? Warum gibt es überhaupt bei XHTML noch so einen Transitional/strict-zeugs, xhtml soll doch so "rein" und tóll sein, dann könnte man doch das dreckige kleine HTML (*scnr*) im letzten jahrtausend zurücklassen...

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.

vielleicht...

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 h a (!?)

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).

genau - daher wäre bei einem unbedingten Wunsch der funktionen des links bei dem Attribut das attribut unerlässlich (logischerweise), was dazu führen würde, dass der autor nur noch transitionalen code schreiben kann, damit seine seiten nicht so toll sind, er in seinen "referenzen" auf schlechte seiten verweist, er damit als beruf "ich-kreire-ihre-homepage" nicht viel geld bekommen würde, dann unter der brücke leben würde und letztenendes elends von ratten zerfressen, drogenabhängig und alkoholsüchtig vom lkw überfahren werden würde.

UND DARAN ist dann nur W3C schuld!!! MÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖRDER!

[weitere interpretationsmöglichkeiten meiner wunderbaren geschichte, wie sie jeden tag vorkommen könnte und auch millionenfach vorkommt, sind natürlich ohne rechtliche bedenken freigegeben]

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.

...natürlich finde ich so ein zweitfenster-gefrimel und dann vor allem noch mit einem dicken fetten javascript absolut übertrieben. traget="_blank" öffnet ein vom browser-selbsteingestelltes fenster, welches automatisch den fokus erhält und alle sind glücklich.

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.

Weißt du was? Ich habe vor kurzem bei einem "Webbasierten Chat" (PHP,Mysql,Xhtml,css[;-)],javascript[;-)]) die "hässlichen" open(), confirm() und prompt()-Funktionen, die ja bekanntlich das window-objekt zur allgemeinen verfügung bereitstellt, durch eigene kreationen ersetzt. Herausgekommen ist eine komplexe klasse mit hin-und-zurück-datentransport (zum aufrufen geht dass dann so ähnlich wie diese Alterboxen in VB(S), du kannst also eingenen Typ definieren (Alert,prompt,confirm,goodalert,pwd,pwdout,...), und entsprechend die richtige seite wird in einem neuen window.open geöffnet [mit richtigen icons & styles...]. Dort gibt dann ein formular die eingegebenen daten per "callback"-Funktion [;-) -  der name klingt nur ímmer so lustig] mit speziell eingebbaren Parametern an das ursprungsfenster zurück (das sonderbare problem dabei ist noch, dass das Chat-fenster in ein 4-teiliges, verschachteltes frameset aufgeteilt ist und man somit mehrere scripte in unterschiedlichen frames braucht, genaugenommen brauche ich 5 JavaScript-Dateien sowie eine PHP-Datei für die realisierung; welches dann die Daten verarbeiten kann.

Das nun resultierende Problem ist, dass das die window-methoden ersetztende fenster (Ich habe das gesamte system "window-tools" getauft) sich irgendwie nicht schließen lassen will, und auch sein vater oder dessen kinder es nicht hinbekommen wollen. Es verschwindet also immer nach getaner arbeit in den Hintergrund, dass ist ein dummer, dummer fehler in dem programmablauf. Ich verstehe jedoch dummerweise nicht, wo er steckt, ich sollte dieses forum noch ein nettes thread dazu eröffnen *bg*

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

s.o. - der script ist eine sinnvolle seiteniniterne zweifenster-anwendung und funktioniert übrigens sogar in ns4.

WauWau