Hallo,

Also: Rechter Mausklick, "Copy Link Address", Klick in die URL-Zeile, Strg-V, Return - und ich krieg die Seite dann doch im gleichen Fenster. Nerviger Umweg, Minuspunkte für die gerade verlassene Seite.

Rechter Mausklick, "Copy Link Address", [STRG]+[D]

Opera 6.

Das Umgehen von target-Attributen funktionierte im Opera schon immer ohne große Zwischenablageumwege mit »Open link« im Kontextmenü des Links. Zusammen mit der Kennzeichnung solcher Links über eine entsprechende CSS-Regel im Benutzerstylesheet lässt sich mit target="_blank" gut leben.

Mathias

Hallo,

der zweite parameter der open-methode ist _nicht_ optional ;-)

sdhd (Scheiß der hund drauf) ;-)

nein, nicht ganz. das zweite auf diese weise "geöffnete" fenster wird das erste zum anzeigen des inhaltes nutzen, sofern dieses noch offen und der fenstername gleich ist.

du meinst für die einstellungen oder so was? Ja, da handhaben die browser afaik recht unterschiedlich - während der ie bei target="_blank" die fenstereinstellungen des alten übernimmt, gibt's bei opera bspw. nicht viel zu übernehmen ;-)

wieso überhaupt in die gewohnheiten des surfers eingreifen wollen, wenn man ohne jeglichen schnickschnack dieser art dem surfer die kontrolle über art und anzahl seiner fenster überlassen kann?

gute frage - dann wäre diese gesamte diskussion hier sinnlos, und unzählige Kilobyte bei allen möglichen servern, bei denen diese zeilen, die ich hier tippe, mal über den arbeitsspeicher flutschen werde, sinnlos.

aus den gründen, die du nennst, target="_blank" einzusetzen heisst für mich, dass du den besucher deiner seiten schlicht für "zu doof" hältst, um selber links in neuen fenstern zu öffnen.

Wieso ihm nicht etwas "hilfe" geben *bg* ?

wenn du deine zielgruppe so definierst, meinetwegen - aber dazu möchte ich dann bitte nicht gehören.

Sagen wir es mal so: Nein, ich definiere meine "Zielgruppe" nicht so.

schaffe ich bei der ergebnisliste einer SuMa auch ohne das diese mir dieses "feature" anbietet.

ich auch, aber anscheinend die selfhtml-suche nicht *ggg*

wie schon gesagt, ist wieder mal die frage des "dem surfer das nicht selber zutrauens" ...

->Selfhtml->surfer nicht selbstzutrauen....  und du willst nicht zu dieser zielgruppe gehören? Daraus würde ich schließen, dass du auch selfhtml entsprechend "verabscheust", dann wären jedoch deine aktivitäten in diesem forum unbegründet, was letztenendes zur folge hätte, dass auch deine aussage hier in sich nicht mehr notwendig wären....

... Ein Kreter behauptete, dass alle Kreter lügen...-Verhängnis in irgendeiner art und weise.

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

Hi,

Ach so!? Das heißt, die "strengen" XHTML-Regelungen (nicht-überschneidene Tags, leere elemente als <element /> oder <element></element>...) gibt es also erst ab XHTML, und wenn ich in HTML <br /> schreibe, ist das offiziell syntaxtechnisch falsch?

Nein, es ist nicht syntaktisch falsch.
HTML 4.01 hat SHORTTAG = YES gesetzt (damit können Syntaxregeln benutzt werden, die aber [so gut wie] kein Browser richtig umsetzt) - siehe http://www.w3.org/TR/html401/sgml/sgmldecl.html#didx-SGML

Nach diesen Regeln schließt der / das tag, das > ist normaler Text, der eigentlich auch angezeigt werden müßte - aber wie gesagt, die Browser setzen diese SHORTTAG-Regeln nicht wirklich um.

Machst Du das bei Elementen, in deren Elternelementen kein freier Text erlaubt ist (z.B. bei Meta), wird Dir der Validator zum > anmerken, daß Text hier nicht erlaubt ist.

Bei XHTML ist SHORTTAG auf NO gesetzt.

ach so, klar.

WauWau

Hi,

Der Validator ignoriert in HTML solche Schrägstriche in Tags übrigens nicht! Der meckert sie an.

Aber nur an Stellen, an denen kein Text erlaubt ist (siehe anderes Posting, wg. SHORTTAG=YES bei HTML und SHORTTAG=NO bei XHTML)

cu,
Andreas

Hi,

Ach so!? Das heißt, die "strengen" XHTML-Regelungen (nicht-überschneidene Tags, leere elemente als <element /> oder <element></element>...) gibt es also erst ab XHTML, und wenn ich in HTML <br /> schreibe, ist das offiziell syntaxtechnisch falsch?

Auch HTML hat strenge Regeln. Korrekte Verschachtelung war immer schon Pflicht. <a><b></a></b> ist falsch, <a><b></b></a> müßte es heißen.

gutgut - nur schade, dass <a><a></a></a> dann wieder falsch ist *bg* ;-)

Bei XHTML gibt es keine optionalen Tags mehr. Jedes Element hat immer ein Start- und ein Ende-Tag. Und wenn das Element keinen Inhalt hat, kann Start- und Endtag in einem Tag zusammengefaßt werden.

Die "Regelung" ist auch ganz gut :-)

<b>irgendein Text</b> insgesamt ist ein Element, ein B-Element, bestehens aus Start- und End-Tag sowie Inhalt dazwischen.

Hm - DOM sieht das dann als 2 knoten an, oder? einmal der tag an sich mit attributen, und dann der inhalt als knoten. Endtag wird afaik nicht als knoten angesehen, oder?

Weil bei <br>, <meta>, <link> und <img> kein Inhalt zwischen Start- und End-Tag kommt, schreibt man diese in XHTML <br/>, <meta/>, <link/> und <img/>.

genau.

Damit diese Schreibweise kompatibel zu Browsern ist, die nur HTML können, fügt man vor dem / noch ein Leerzeichen ein. Dann interpretiert der HTML-Browser diesen Schrägstrich als Attribut, das er nicht kennt und gemäß HTML-Standard dann ignoriert - und allen ist geholfen.

wie schön dass ich immer gleich allen helfe - und dann sag noch mal, man könnte es nicht allen recht machen ;-)

Ein direkt anschließende Ende-Tag <br></br> wäre zumindest nach XHTML-Standard auch möglich, aber da rasten HTML-Browser dann unter Umständen aus, weil solche Tags nie vorgesehen waren.

Hm - und zwar ganz drastisch.... NS4 hat bei mir mal bei <hr></hr> 2mal eine Linie gezeichnet !? aber die <leereselementtag></leereselementtag>-Regelung finde ich sowieso dumm.

Aber bei XHTML muss dann wieder <link /> geschrieben werden, oder?
Was heißt "wieder"? Erstmalig.

Ich komme nunmal gerade von einer XHTML-Seite und habe jetzt alle meine tags xhtml-kompatibel gemacht, die seite als html-4-strict gespeichert (der doctype war schon mal drin, dann wollen wir also mal nix verändern *g*), und mich nun extrem gewundert, was er bei mir an den <link>- und <meta>-Tags rummeckert! Aber wenn

Der Validator ignoriert in HTML solche Schrägstriche in Tags übrigens nicht! Der meckert sie an. Deshalb macht es keinen Sinn, in HTML-Dokumenten XHTML-artige Tags zu setzen.

macht das ganze natürlich wieder sinn (irgendwie habe ich anscheinend nicht dran gedacht, dass <tag /> ja XML ist!!), und ich denke, ich werde mein dokument mal mit doctype xhtml-strict abspeichern, dann habe ich eine xhtml-valide strict-seite, und dass ist w3c-nach gesehen sowieso das beste, was man momentan produzieren kann *bggg* ;-)

WauWau