nicht angemeldet
Wer hat Recht?
Hallo,
ich habe gerade ein Verständnisproblem. Ich habe in einer html Datei,
die als 4.01 strict gekennzeichnet ist geschrieben:
Internet: <a href="http://www.url.de" target="_top">
und die Datei unter http://validator.w3.org/check geprüft. Dabei erhielt ich unter anderem folgende Meldung:
Error: there is no attribute "TARGET" for this element (in this HTML
version)
In SelfHTML wurde dieses Attribut aber gelistet. Was gilt denn nun?
Gruss, Lars
-
hi!
Internet: <a href="http://www.url.de" target="_top">
und die Datei unter http://validator.w3.org/check geprüft. Dabei
erhielt ich unter anderem folgende Meldung:
Error: there is no attribute "TARGET" for this element (in this
HTML version)
In SelfHTML wurde dieses Attribut aber gelistet. Was gilt denn nun?Aus der HTML 4.01 Spec[1]:
=== cut ===
By assigning a name to a frame via the name attribute, authors can
refer to it as the "target" of links defined by other elements. The
target attribute may be set for elements that create links (A, LINK),
image maps (AREA), and forms (FORM).
=== cut ===Wenn der Validator das also wirklich anmeckert, hat er Unrecht. Kann
man sich die Ausgabe und das angemeckerte Dokument vielleicht mal
irgendwo anschauen?bye, Frank!
[1] http://www.w3.org/TR/html401/present/frames.html#adef-target
-
Aus der HTML 4.01 Spec[1]:
=== cut ===
By assigning a name to a frame via the name attribute, authors can
refer to it as the "target" of links defined by other elements. The
target attribute may be set for elements that create links (A,
LINK), image maps (AREA), and forms (FORM).
=== cut ===Wenn der Validator das also wirklich anmeckert, hat er Unrecht. Kann
man sich die Ausgabe und das angemeckerte Dokument vielleicht mal
irgendwo anschauen?Online ist die Datei nicht, aber ich schicke sie gerne mal per Mail.
Es handelt sich dabei nämlich um ein Offline CD Projekt. Frames kommen hier zur Navigation zum Einsatz und bilden Elemente die immer sichtbar sein sollen, damit der Benutzer schnell zu den einzelnen Fachthemen wechseln kann. Gleichzeitig gibt es aber auch ein übergeordnetes Menü, das halt immer zu einem der Framesets springt.
Wenn ich mal die ganzen Kommentare gelesen habe, dann muss ich sagen das es keine Alternative zu Frames in diesem Fall gibt, da mit Tabellen oder DHTML der Verwaltungsaufwand bei Änderungen viel zu hoch wäre.Gruss, Lars
-
-
Hi!
ich habe gerade ein Verständnisproblem. Ich habe in einer html Datei,
die als 4.01 strict gekennzeichnet ist geschrieben:Internet: <a href="http://www.url.de" target="_top">
Schau mal hier: http://selfhtml.teamone.de/html/referenz/varianten.htm
Da keine Framesets erlaubt sind, wird target wahrscheinlich auch nicht erlaubt sein. Schätz ich mal. Man wird mich eines besseren belehren, wenn ich irre...
Gruß,
Pascal -
Hallo Lars,
Error: there is no attribute "TARGET" for this element (in this HTML
version)
In SelfHTML wurde dieses Attribut aber gelistet. Was gilt denn nun?In der Attributreferenz von SELFHTML wird irrtuemlich behauptet, das target-Attribut gelte fuer alle drei HTML-Varianten. Es gilt aber offiziell nur fuer die Frameset-Variante. Wenn du es also in einer Datei verwendest, die du in der DOCTYPE-Deklaration mit strict ausgewiesen hast, dann ist das tatsaechlich verkehrt.
Mal abgesehen davon, dass es ein Fehler in SELFHTML ist, halte ich es aber auch fuer einen Fehler von W3C, target nur bei Framesets zu erlauben. Denn die Wertzuweisung "_blank" oder die Adressierung eines mit JavaScript geoeffneten Fensters hat ja nicht unbedingt was mit Frames zu tun. Das target-Attribut gehoert deshalb finde ich durchaus auch in die strict-Variante uebernommen.
viele Gruesse
Stefan Muenz-
Hi Stefan!
Mal abgesehen davon, dass es ein Fehler in SELFHTML ist, halte ich es aber auch fuer einen Fehler von W3C, target nur bei Framesets zu erlauben. Denn die Wertzuweisung "_blank" oder die Adressierung eines mit JavaScript geoeffneten Fensters hat ja nicht unbedingt was mit Frames zu tun. Das target-Attribut gehoert deshalb finde ich durchaus auch in die strict-Variante uebernommen.
Dem kann man nur beipflichten. Deshalb bin ich auch etwas unsicher geworden, als ich meine bescheidene Vermutung formuliert habe. Die "ge_blankten" Anzeigebeispiele in 8.0 sind ja eine sinnvolle Anwendung.
Und da man sich ja eh etwas schwer tut, Textgrenzen bei Hypertexten zu definieren, ist _blank auch ein wunderbares Mittel, dem Benutzer deulich zu machen, dass er eine externe Seite aufgerufen hat (wenn das nicht eh schon durch das Layout deutlich wird).
Gruß,
Pascal-
Hi,
Dem kann man nur beipflichten.
ich auch.
Die "ge_blankten" Anzeigebeispiele in 8.0 sind ja eine sinnvolle Anwendung.
Noch sinnvoller ist m.E., Links mit target="_top" auszustatten - selbst wenn irgendein Hansel meine Site in sein Frameset presst, muss ich das "meinen" Links nicht auch antun.
Ich nehme übrigens an, das W3C wollte auf diese Weise eine Meinung über das Öffnen neuer Fenster an den Mann bringen.
Cheatah
-
Hallo Pascal & Stefan,
Mal abgesehen davon, dass es ein Fehler in SELFHTML ist, halte ich es aber auch fuer einen Fehler von W3C, target nur bei Framesets zu erlauben. Denn die Wertzuweisung "_blank" oder die Adressierung eines mit JavaScript geoeffneten Fensters hat ja nicht unbedingt was mit Frames zu tun. Das target-Attribut gehoert deshalb finde ich durchaus auch in die strict-Variante uebernommen.
strict.dtd zeichnet sich durch einen gewissen Minimalismus aus,
dazu gehört der Verzicht auf Frames, aber auch der Verzicht auf
etliche Attribut, wie eben target.Sobald Frames wegfallen, bleiben genau vier Werte für den Inhalt
des target-Attributes übrig:
_parent -> erübrigt sich, wenn keine Frames vorhanden
_blank
_self -> erübrigt sich, wenn keine Frames vorhanden
_top -> erübrigt sich, wenn keine Frames vorhandenErgo wäre da nur noch target="_blank" und dies wiederum bewirkt,
dass beim Benutzer immer neue Fenster geöffnet werden, was nicht
unbedingt sinnvoll sein muß. Ergo kann man es besser in der and.
DTD (loose.dtd) unterbringen, die solche "Extras" berücksichtigt.Das target-Attribut wird btw vom W3C explizit in Zusammenhang mit
Frames eingeführt, d.h. es ist genau für diesen Zweck überhaupt
vorhanden:
http://www.w3.org/TR/html401/present/frames.html#adef-targetDie Möglichkeit, target="_blank" auch ohne Frames zu nutzen, ist
nur eine Art Abfallprodukt, so etwa wie die Teflon-beschichteten
Bratpfannen ;-)Dem kann man nur beipflichten. Deshalb bin ich auch etwas unsicher geworden, als ich meine bescheidene Vermutung formuliert habe. Die "ge_blankten" Anzeigebeispiele in 8.0 sind ja eine sinnvolle Anwendung.
genau dies halte ich persönlich für Unfug, weil ich gern und viel
mit der Maus navigiere (Opera) und da ist es weitaus einfach, ein
Stück nach links als erst nach unten und dann nach rechts die Maus
zu rücken (damit sind die mousegestures von Opera gemeint).
Wenn ich das Verlangen habe, ein Beispiel in einem Extrafenster zu
betrachten, dann öffne ich mir ein solches ;-)Um auf die eigentliche Sache zurückzukommen, wenn man hier dieses
Attribut verwenden will, dann *muß* man loose.dtd referenzieren.
Es wäre völlig sinnfrei, wenn die beiden DTD's nahezu den gleichen
Inhalt hätte, dann würde ja auch eine DTD ausreichen.Und da man sich ja eh etwas schwer tut, Textgrenzen bei Hypertexten zu definieren, ist _blank auch ein wunderbares Mittel, dem Benutzer deulich zu machen, dass er eine externe Seite aufgerufen hat (wenn das nicht eh schon durch das Layout deutlich wird).
In einem Großteil der Fälle wird das Layout ein anderes sein. In
*allen* Fällen, wo target="_blank" verwendet wird, zwingt man dem
Besucher ein neues Fenster auf, egal ob er dies (nicht) möchte.
Es ist doch Unfug, wenn jemand die Seiten verlassen möchte, dann
darf er dies gern tun und wenn er anschließend zurückkehren will,
dann benutzt er eben den Back-Button seines Browsers. Durch die
Verwendung von target="_blank" verhindert man in vielen Fällen
eine sinnvolle und vom Nutzer so gewünschte Navigation durch
das WWW.
Oder besteht Surfen aus dem Anklicken von Links, die in neuen
Fenstern geöffnet werden und dem anschließenden Schließen der
vorhergehenden Browserfenster?Ich denke nicht, dass sich die Benutzerfreundlichkeit einer Web-
site idR durch die Verwendung von target="_blank" erhöht.Viele Grüße,
StefanPS: *Ausnahmen* bestätigen die Regel.
-
Moin!
strict.dtd zeichnet sich durch einen gewissen Minimalismus aus,
dazu gehört der Verzicht auf Frames, aber auch der Verzicht auf
etliche Attribut, wie eben target.was auch duraus so sinnvoll ist.
Sobald Frames wegfallen, bleiben genau vier Werte für den Inhalt
des target-Attributes übrig:
_parent -> erübrigt sich, wenn keine Frames vorhanden
_blank
_self -> erübrigt sich, wenn keine Frames vorhanden
_top -> erübrigt sich, wenn keine Frames vorhandenNun ja, nicht ganz. Es fehlt noch das Oeffnen eines neuen Fensters ueber einen bisher nicht benutzten Fensternamen und die Steuerung dessen Fensterinhalts aus dem andern Fenster heraus.
Die Möglichkeit, target="_blank" auch ohne Frames zu nutzen, ist
nur eine Art Abfallprodukt, so etwa wie die Teflon-beschichteten
Bratpfannen ;-)Die zweifelsohne auch sehr praktisch sein kann ;-) Aber ernsthaft - ich sehe es genauso wie stefan - strict soll so wenig wie moeglich eingriffe in die Darstellung auf dem Bildschirm nehmen, und wer bestimmte 2-Fenster-DHTML-Sachen braucht, der kann ja auf Transitional umstellen.
ich gern und viel mit der Maus navigiere (Opera) und da ist es weitaus einfach, ein Stück nach links als erst nach unten und dann nach rechts die Maus zu rücken (damit sind die mousegestures von Opera gemeint).
Hmm... Keine Schleichwerbung hier, ja? ;-)
Mit Mozilla und seinen Tabs ist _blank uebrigens auch recht nervig - Wenn ich einen Link in einem andern Tab aufmachen will, dann kenn ich meine Maus gut genug, um ihr auch mal an die mittlere Taste zu fassen ;-)
Wenn ich das Verlangen habe, ein Beispiel in einem Extrafenster zu
betrachten, dann öffne ich mir ein solches ;-)Genau das - Externe Links kann man IMHO eh besser kennzeichnen als mit _blank - SelfAktuell/HTML zeigt auch schon, wie das geht.
Es wäre völlig sinnfrei, wenn die beiden DTD's nahezu den gleichen
Inhalt hätte, dann würde ja auch eine DTD ausreichen.Full ACK.
Es ist doch Unfug, wenn jemand die Seiten verlassen möchte, dann
darf er dies gern tun und wenn er anschließend zurückkehren will,
dann benutzt er eben den Back-Button seines Browsers.Again, Full ACK.
Ich denke nicht, dass sich die Benutzerfreundlichkeit einer Website idR durch die Verwendung von target="_blank" erhöht.
idR wuerd ich jetzt hier schon fast streichen - Ich persoenlich kenne keinen Fall, wo es so waere.
PS: *Ausnahmen* bestätigen die Regel.
Und die waeren?
viele Gruesse,
Einbecker
-
Hallo Einbecker,
na, wieder nuechtern von den Genuessen der Lounge? *g*
Die zweifelsohne auch sehr praktisch sein kann ;-) Aber ernsthaft - ich sehe es genauso wie stefan - strict soll so wenig wie moeglich eingriffe in die Darstellung auf dem Bildschirm nehmen, und wer bestimmte 2-Fenster-DHTML-Sachen braucht, der kann ja auf Transitional umstellen.
Ja. Allerdings ist target kein Attribut, das die Darstellung betrifft, sondern eines, das hypertextuelle Organisation unterstuetzen kann. Die Entscheidung, ob ein Verweisziel in einem anderen Fenster angezeigt werden soll, ist schliesslich was anderes als Schriftgroessen und Hintergrundfarben. target ist also ein Attribut mit logischen Aufgaben. Im uebrigen gilt das auch fuer Frames. Ich bin selber kein grosser Freund von Frames, aber die Art, wie W3C diese immer noch ausklammern will, finde ich idiotisch. Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde, waere begruendbar und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der Fall ist. Und der Unterschied zu Transitional waere dann auch nachvollziehbarer. So aber - dieses ganze Schlamassel mit Transitional und Frameset und loose.dtd - das ist doch reiner Hirngeburten- und Inginieuren-Quatsch (hach, tut das gut, mal wieder so herzhaft ueber heilige Kuehe zu schimpfen *g*).
Mit Mozilla und seinen Tabs ist _blank uebrigens auch recht nervig - Wenn ich einen Link in einem andern Tab aufmachen will, dann kenn ich meine Maus gut genug, um ihr auch mal an die mittlere Taste zu fassen ;-)
Das stimmt. Allerdings hat der Mozilla sehr wohl in seinen Preferences die Moeglichkeit einzustellen, dass Seiten, die von Webseiten in neuen Fenstern geoeffnet werden, stattdessen in einem neuen Tag geoeffnet werden sollen. Das hab ich auch brav eingestellt. Leider funktionierts nur nicht ;-)
viele Gruesse
Stefan Muenz-
Hi,
Ich bin selber kein grosser Freund von Frames, aber die Art, wie W3C diese immer noch ausklammern will, finde ich idiotisch.
ACK.
Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde, waere begruendbar und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der Fall ist. Und der Unterschied zu Transitional waere dann auch nachvollziehbarer.
Nun... der Unterschied wäre dann kaum noch zu unterscheiden vom Unterschied zwischen HTML und XHTML... :-)
Ernsthaft: Es wäre auch meiner Meinung nach nicht sooo schwer, von <!ELEMENT HTML o o (HEAD, BODY)> auf <!ELEMENT HTML o o (HEAD, (BODY|FRAMESET))> umzustellen. Eine komplette Trennung in "ent- oder weder" geht ohnehin nicht, weil die einzelnen Frames ihrerseits wieder HTML-Dokumente beinhalten (meistens jedenfalls). Ich nehme aber an, dass genau hier die Abneigung des W3C gegenüber Frames begründet ist: Wenn man _nur_ die Frameset-Datei nimmt, hat man _nichts_. Bei nur einer "normalen" HTML-Datei hat man zumindest dessen Inhalt, auch wenn vom "HT" nicht viel zu merken ist.
So aber - dieses ganze Schlamassel mit Transitional und Frameset und loose.dtd - das ist doch reiner Hirngeburten- und Inginieuren-Quatsch (hach, tut das gut, mal wieder so herzhaft ueber heilige Kuehe zu schimpfen *g*).
*lol* :-)
Das stimmt. Allerdings hat der Mozilla sehr wohl in seinen Preferences die Moeglichkeit einzustellen, dass Seiten, die von Webseiten in neuen Fenstern geoeffnet werden, stattdessen in einem neuen Tag geoeffnet werden sollen. Das hab ich auch brav eingestellt. Leider funktionierts nur nicht ;-)
Es heißt nicht "_in_ einem neuen Tag", sondern "_an_ einem neuen Tag", und Du musst daraufhin ein Weilchen warten. Deswegen funktioniert's auch nicht... *ggg*
Cheatah
-
Moin!
na, wieder nuechtern von den Genuessen der Lounge? *g*
*g* - Nun ja, ist ja noch nicht abend, von daher eher: noch ;-)
Die zweifelsohne auch sehr praktisch sein kann ;-) Aber ernsthaft - ich sehe es genauso wie stefan - strict soll so wenig wie moeglich eingriffe in die Darstellung auf dem Bildschirm nehmen, und wer bestimmte 2-Fenster-DHTML-Sachen braucht, der kann ja auf Transitional umstellen.
Ja. Allerdings ist target kein Attribut, das die Darstellung betrifft, sondern eines, das hypertextuelle Organisation unterstuetzen kann. Die Entscheidung, ob ein Verweisziel in einem anderen Fenster angezeigt werden soll, ist schliesslich was anderes als Schriftgroessen und Hintergrundfarben.
Nun gut - Ein unterschied besteht. Aber ich wuerde target keinenfalls nur logische aufgaben zuordnen. Wenn es ein attribut geben wuerde, dass Links in logische Gruppen zusammenfassen koennte, dann waere das sicher der Fall. Im Moment hat target jedoch die alleinigen Aufgaben,
1. Frames anzusprechen
2. Neue Browserinstanzen zu oeffnen
a) mit Namen
b) ohne Namen
3. Framesets zu sprengenund diese sind imho nicht rein logischer Natur, denn es hat immer Auswirkungen auf das GUI (gut, dass haben eigentlich alle logischen Elemente. Ich merke grad, dass meine Argumentation etwas in eine Sackgasse laeuft. Ich hoffe mal, dass am Ende doch ein Ausgang ist ;-) ). Also, was fuer mich der Unterschied zwischen physischen Elementen/Attributen und ebensolchen logischen ist, ist der folgende: logische Auszeichnung beschreibt, _was_ es ist, und das UI bestimmt, wie es dargestellt wird. Physische Auszeichnung hingegen beschreibt, wie es _dargestellt_ wird und kuemmert sich einfach nicht um den logischen Zusammenhang. Daher ist target imho ein physisches Element - allein schon die Angabe _blank zeigt an, dass eine neue, leere UI-Instanz erzeugt werden soll. Logische Auszeichnung waere fuer mich in diesem Zusammenhang, wenn ein Attribut sagen wuerde "hey, dass hier ist ein neuer Themenbereich" - und die UI dann sagt, "OK, dann oeffne ich dich in einem neuen Tab oder Fenster" oder aber "mein User sagt, dass auch andere Themenbereiche ins gleiche Fenster sollen, also rein mit dir". Ich hoffe, durch die bildhafte Sprache wird klar, was ich darunter verstehe.
Im uebrigen gilt das auch fuer Frames.
Auch dies wuerde ich gern mit obiger Argumentation von "logisch" und "physisch" verneinen. ;-)
Ich bin selber kein grosser Freund von Frames, aber die Art, wie W3C diese immer noch ausklammern will, finde ich idiotisch. Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde, waere begruendbar und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der Fall ist. Und der Unterschied zu Transitional waere dann auch nachvollziehbarer.
Das sehe ich - auch wieder nach der obigen Argumentation - nicht so. Frames sind imho etwas, dass zwar auf den ersten Blick einfacher, logischer usw aussieht, aber im Nachhinein nur Probleme mit sich bringt. Ich habe - bis heute - keine Verwendung von Frames gesehen, die mich davon ueberzeugen konnte, dass ein besseres oder zumindest gleichwertiges Ergebnis ohne Frames moeglich gewesen waere ;-)
So aber - dieses ganze Schlamassel mit Transitional und Frameset und loose.dtd - das ist doch reiner Hirngeburten- und Inginieuren-Quatsch (hach, tut das gut, mal wieder so herzhaft ueber heilige Kuehe zu schimpfen *g*).
*g* - Tob dich ruhig aus, ich bleib trotdem bei meinem Standpunkt ;-)
Das stimmt. Allerdings hat der Mozilla sehr wohl in seinen Preferences die Moeglichkeit einzustellen, dass Seiten, die von Webseiten in neuen Fenstern geoeffnet werden, stattdessen in einem neuen Tag geoeffnet werden sollen. Das hab ich auch brav eingestellt. Leider funktionierts nur nicht ;-)
Genau das ist ja das eigentliche Problem ;-)
Viele Gruesse,
Einbecker
-
Hallo Stefan!
reiner Hirngeburten- und Inginieuren-Quatsch (hach, tut das gut, mal wieder so herzhaft ueber heilige Kuehe zu schimpfen *g*).
Endlich einer, der mir aus der Seele spricht! Abgesehen davon, dass die W3C-Seiten völlig unübersichtlich sind, deren Suche in die Mülltonne gehört [1] und dass man merkt, dass sie etwas "deutsche Gründlichkeit" (kann ich als Franzmann ohne Patriotismus sagen, *ätsch*) bräuchten, bin ich der Meinung, man sollte diesen Haufen "Kopf-in-den-Wolken-janz-weit-weg-von-der-Realität-Theoretikern" vor die Aufgabe stellen, innerhalb 3 oder 4 Stunden eine Seite nur nach Screenshot nachzubauen (also ohne einen Blick in den Quelltext). Vielleicht würden sie dann etwas anders denken.
[1] Ich schaute vorhin in den Specs und stellte fest, dass align=right (beim img-Tag zum Beispiel) deprecated sei. Es ist sehr gut, dass man darüber informiert wird, ja. Aber ein Link zum entsprechenden CSS-Ersatz? Fehlanzeige, obwohl die ansonsten auch nicht an irgendwelche Links sparen. Nein, ich musste noch CSS 1 öffnen, und mühsam suchen, bis ich endlich float: right; fand.
Es gäbe mit Sicherheit viel mehr valide Seiten auf Webs Erde, wenn das W3C etwas von Übersichtlichkeit verstünde.
Grüße,
Patrick-
Hallo Patrick,
deren Suche in die Mülltonne gehört
Du weißt, dass auf der W3C-Website seit geraumer Zeit Google als
Suchmaschine benutzt wird [1]? Diese Suchmaschine liefert die
meiner Meinung nach mit Abstand qualitativ hochwertigsten Ergeb-
nisse, insofern kann ich Deine Kritik nicht so recht verstehen.man sollte diesen Haufen "Kopf-in-den-Wolken-janz-weit-weg-von-der-Realität-Theoretikern" vor die Aufgabe stellen, innerhalb 3 oder 4 Stunden eine Seite nur nach Screenshot nachzubauen (also ohne einen Blick in den Quelltext). Vielleicht würden sie dann etwas anders denken.
in nahezu jedem, zumindest aber wohl in jedem technischen Bereich
unseres Lebens gibt es entsprechende Spezifikation, die idR recht
trocken formuliert sind, was durchaus sinnvoll ist. Eine Spezifi-
kation soll den Leser nicht unterhalten, sondern deutlich und so
unmissverständlich wie nur irgendwie möglich die darin behandelten
Inhalte rüberbringen. Unnötiges "Gelabber" und oft auch Dinge, die
es *allgemein*verständlicher machen, sind da fehl am Platze. Der
Sinn von technischen Spezifikation ist es nicht, alle möglichen
Leser zu unterhalten, sondern den Fachleuten auf diesem Gebiet die
relevanten Informationen darzulegen.Als Beispiel lassen sich problemlos Dinge wie RFC's, DIN oder ISO
nennen, alle diese Sachen sind ganz sicher nicht unterhaltend [2]
oder mit zahlreichen Praxisbeispielen versehen.Aber ein Link zum entsprechenden CSS-Ersatz? Fehlanzeige, obwohl die ansonsten auch nicht an irgendwelche Links sparen. Nein, ich musste noch CSS 1 öffnen, und mühsam suchen, bis ich endlich float: right; fand.
Die W3C-Specs sind sicher aufeinander abgestimmt, aber sie werden
letztendlich als eigenständige Publikationen veröffenlicht und be-
handelt, d.h. ständige Querverweise, insbesonders solche wie von
Dir angesprochen, wären nur schwer möglich oder nicht sinnvoll,
weil es durchaus passieren kann, dass dann z.Bsp. in HTML 4(.01)
noch zahlreiche Verweise zu der veralteten CSS1-Spec wären.
Insofern ist es richtig, auf die betreffenden Sachen nur soweit
zu verweisen [3], wie es *unbedingt* notwendig ist. Erklärenden,
praxisnahen Charakter sollen diese Spezifikationen nicht vorder-
gründig haben, sie dienen lediglich zur Dokumentation eines fest-
gelegten Standards, s.o.Es gäbe mit Sicherheit viel mehr valide Seiten auf Webs Erde, wenn das W3C etwas von Übersichtlichkeit verstünde.
Sinnvoller fände ich es, wenn es mehr *Dokumentationen* wie SELFHTML
gäbe (für die entsprechenden Gebiete, mit Beispielen etc.), die es
anschaulich erklären und praxisnahe Beispiele enthalten, zu den in
den *Spezifikationen* behandelten Themengebieten.Letztendlich können wir dankbar sein, dass wir SELFHTML haben und
gleichzeitig auch die Möglichkeit, im Zweifelsfall in der dazuge-
hörigen Spezifikation nachzuschauen, Dinge wie ISO- oder DIN-Specs
muß (?) man käuflich erwerben [4].Zusammengefasst bleibt folgender Unterschied:
W3C-Spec -> HTML-Spezifikation [5]
SELFHTML -> HTML-Dokumentation [6]Es ist meiner Meinung nach kam möglich, nur mit einer Spezifikation
etwas zu lernen, allerdings sind sie in den meisten Fällen nicht
unverzichtbar, weil sie letztendlich entscheidend sind.
Selbstverständlich sollte eine Dokumentation fachlich der dazuge-
hörigen Spezifikation entsprechen, SELFHTML 8.0 ist da schon sehr
weit gekommen, mit einer zweiten Errata [7] wird da kaum noch eine
nennenswerte Anzahl von Unzulänglichkeiten vorhanden sein.Viele Grüße,
Stefan[1] siehe Hinweis auf http://search.w3.org/ und Suchfeld direkt
auf der Homepage des W3C (http://www.w3.org/)
[2] http://rfcs.net/ - http://www.din.de/ - http://www.iso.org
mit einigen wenigen Ausnahmen wie http://rfc.net/rfc2324.html
[3] in der HTML 4.01 Spezifikation auch nochmal zusammengefasst:
http://www.w3.org/TR/html401/references.html (nur als Beispiel)
[4] http://www.iso.ch/iso/en/prods-services/ISOstore/store.html
http://www.beuth.de/ und http://www.din-katalog.de/ (DIN)
[5] Einzelaufzählung, spezifiziertes Verzeichnis, spezifizierte
Aufstellung, Liste
[6] Zusammenstellung, Ordnung u. Nutzbarmachung von Dokumenten u.
[Sprach]materialien jeder Art (z. B. Urkunden, Akten, Zeit-
schriftenaufsätze zur Information über den neuesten
Erfahrungsstand)
[7] die afaik bereits von Stefan Muenz angedeutet/angekündigt ist
-
-
Hi Stefan,
Ich bin selber kein grosser Freund von Frames, aber die Art,
wie W3C diese immer noch ausklammern will, finde ich idiotisch.Ich bin ein Freund von Frames - aber andererseits bin ich durchaus der
Meinung, daß ein Frameset-Dokument etwas substantiell Anderes ist als
ein 'normales' Dokument.
Ich finde die Idee, dafür zwei getrennte DTDs zu verwenden, naheliegend.
Daß ein Frameset im <noframes>-Bereich ein /fast) normales Dokument ent-
halten kann, halte ich für keinen Widerspruch zu meiner Aussage.
Ich fände es aber sinnvoll, wenn diese Trennung zwischen Dokument und
Frameset konsequenter durchgezogen würde.Was ich an dieser Stelle schon mal andiskutiert hätte, wäre ein Konzept
(RFC?) zur Definition eines "Uniform Frameset Locators", also der
Codierung eines gesamten Frameset-Baums in linearer Form (und damit als
potentiellen Subset von URLs!).
Das, was ein Browser bei der Entstehungsgeschichte seines Fenster-Inhalts
durchgeführt hat, um einen beliebig tief geschachtelten Frameset-Baum zu
erzeugen, resultiert in einer Datenstruktur, die strukturell gesehen
nicht komplexer ist als ein HTML-Dokument selbst.
Wenn dann aber ein HTML-Dokument letztlich ein byte stream ist, wieso
kann das ein UFL nicht auch sein, und damit als URL (Bookmark, Link, ...)
verwendbar?
Gäbe es Ideen in dieser Hinsicht (und eine Umsetzung in einem der experi-
mentellen Browser, i. e. Opera / Mozilla), dann wären die bestehenden
Usability-Probleme von Frames zumindest deutlich reduzierbar.Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde,
waere begruendbarJa. Das Gegenteil ist es m. E. aber ebenfalls.
(Man kann alles beweisen, solange man von den richtigen Axiomen ausgeht. ;-)und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der
Fall ist.Bei wem?
Ich halte eine wie auch immer geartete ästhetische DTD für Framesets nicht
für den Weg, deren Akzeptanz spürbar zu erhöhen.Eine verbesserte Usability dagegen könnte helfen.
Viele Grüße
Michael -
Hallo, Stefan, Forumsgenossinnen und -genossen,
Ja. Allerdings ist target kein Attribut, das die Darstellung betrifft, sondern eines, das hypertextuelle Organisation unterstuetzen kann. Die Entscheidung, ob ein Verweisziel in einem anderen Fenster angezeigt werden soll, ist schliesslich was anderes als Schriftgroessen und Hintergrundfarben. target ist also ein Attribut mit logischen Aufgaben.
Das sehe ganz und gar anders (was aber auch daran liegen koennte, dass ich an und fuer sich vor 4 Stunden schon saumuede war und nichts als in Bett wollte). Ich kann mich dunkel an eine Diskussion in www-html@w3.org erinnnern, bei der das zur Debatte stand. Dort kam man mitunter zu dem Schluss, dass target "presentational" sei, was auch meiner Meinung entspricht.
Das target-Attribut sagt nichts darueber aus, wie das "aufrufende Dokument" und das Ziel-Dokument miteinander auf logischer Ebene in Verbindung stehen, es schreibt einzig und allein vor, _wo_ das Zieldokument geoeffnet werden soll. Auch stellt es keinerlei strukturelle Information zur Verfuegung. Ich kann den prinzipiellen Unterschied zu Schriftgroessen und Hintergrundfarben nicht so deutlich erkennen: Sowohl die Anweisung an den Browser, eine Schrift in bestimmter Groesse darzustellen, als auch die Anweisung, ein Dokument in einem Bestimmten Fenster/Frame zu oeffnen, sind ausschliesslich Sache der Darstellung und gehoeren daher IMHO keinesfalls in die strict-Version.
Im uebrigen gilt das auch fuer Frames. Ich bin selber kein grosser Freund von Frames, aber die Art, wie W3C diese immer noch ausklammern will, finde ich idiotisch.
Wenn ich mein Menue in ein <div> packe und das via CSS links mittig positioniere, dann ist die Positionierung - da werden wir uns glaube ich einig - eine Angelegenheit der Darstellung ("presentational issue" ist hier um einiges feiner). Warum ist es das nicht mehr, wenn ich einzelne HTML-Dokumente ausrichte und dann festlege, in welche "Seitenpositionscontainer" bestimmte Seiten (per Link) geladen werden sollen?
Eine strict-Variante, die das Frames-Konzept mit integrieren wuerde, waere begruendbar [...]
Sie waere IMHO nicht konsistent. Frames gehoeren hier nicht hin ;-)
und wuerde eine wesentliche hoehere Akzeptanz haben als es jetzt der Fall ist.
Hierueber sind wir uns einig.
Friedliebende (auch wenn's manchmal anders klingt) Gruesse,
--- Ingomar Wesp, der sich nach alldem schreiben nicht mehr so sicher ist, ob sein Standpunkt ganz so haltbar ist, wie er gedacht hatte.-
Hi!
Friedliebende (auch wenn's manchmal anders klingt) Gruesse,
--- Ingomar Wesp, der sich nach alldem schreiben nicht mehr so sicher ist, ob sein Standpunkt ganz so haltbar ist, wie er gedacht hatte.Also ich finde, Du hast das sehr schoen auf den Punkt gebracht und im uebrigen auch recht. ;-)
So long
-
-
-
Hallo Gottfried,
Nun ja, nicht ganz. Es fehlt noch das Oeffnen eines neuen Fensters ueber einen bisher nicht benutzten Fensternamen und die Steuerung dessen Fensterinhalts aus dem andern Fenster heraus.
die erste Sache (bisher nicht benutzter Fenstername) halte ich für
absoluten Unfug. Entweder ich verwende vorhandene Framenamen oder
einen der vier genannten Werte. Sachen wie target="fsajdfasjdi",
wie es *leider* auch in SELFHTML 8.0 steht, sind meiner Meinung
völlig unnötig, weil der Benutzer dann beim zweiten Link mit
diesem Ziel nicht mehr weiß/sieht, wo die Seite geöffnet wird.
Entweder man öffnet ein neues Fenster mit target="_blank" oder
man tut es nicht.
Die Sache mit "Steuerung des Fensterinhaltes" erschließt sich mir
nicht so ganz, nähere Infos wären hilfreich.Genau das - Externe Links kann man IMHO eh besser kennzeichnen als mit _blank - SelfAktuell/HTML zeigt auch schon, wie das geht.
Kein weiterer Kommentar notwendig, vollste Zustimmung.
Ich denke nicht, dass sich die Benutzerfreundlichkeit einer Website idR durch die Verwendung von target="_blank" erhöht.
idR wuerd ich jetzt hier schon fast streichen - Ich persoenlich kenne keinen Fall, wo es so waere.
PS: *Ausnahmen* bestätigen die Regel.
Und die waeren?
die Erfahrung zeigt, dass sich oft Einzelbeispiele finden lassen
und diese von "der Gegenseite" zur Grundlage ihrer Argumentation
gemacht werden. Mit der Aussage, dass die Existenz solcher Einzel-
beispiele, wo target="_blank" sinnvoll ist" nicht ausgeschlossen
werden kann, will ich dieser Art von Argumentation entgegenwirken.
Heißt im Klartext, ich kann jetzt keine solchen Beispiele nennen,
möchte sie aber präventiv nicht ausschließen ;-)Viele Grüße,
Stefan-
Moin Heinz-Guenther,
Nun ja, nicht ganz. Es fehlt noch das Oeffnen eines neuen Fensters ueber einen bisher nicht benutzten Fensternamen und die Steuerung dessen Fensterinhalts aus dem andern Fenster heraus.
die erste Sache (bisher nicht benutzter Fenstername) halte ich für absoluten Unfug. Entweder ich verwende vorhandene Framenamen oder einen der vier genannten Werte. Sachen wie target="fsajdfasjdi", wie es *leider* auch in SELFHTML 8.0 steht, sind meiner Meinung völlig unnötig, weil der Benutzer dann beim zweiten Link mit diesem Ziel nicht mehr weiß/sieht, wo die Seite geöffnet wird. Entweder man öffnet ein neues Fenster mit target="_blank" oder man tut es nicht. Die Sache mit "Steuerung des Fensterinhaltes" erschließt sich mir nicht so ganz, nähere Infos wären hilfreich.
Hmm, also, ich meinte damit, du oeffnest ein fenster "blub" und du laedst in dieses Fenster bestimmte seiten, jedesmal wieder mit target="blub". Es gibt Seiten, die so ihre Navigation machen oder anderes darueber darstellen. IMHO schlecht, aber es wird haeufig so gemacht. Ergo ist es fuer mich natuerlich kein Grund, diese in strict aufzunehmen ;-)
Genau das - Externe Links kann man IMHO eh besser kennzeichnen als mit _blank - SelfAktuell/HTML zeigt auch schon, wie das geht.
Kein weiterer Kommentar notwendig, vollste Zustimmung.
Danke ;-)
PS: *Ausnahmen* bestätigen die Regel.
Und die waeren?
die Erfahrung zeigt, dass sich oft Einzelbeispiele finden lassen und diese von "der Gegenseite" zur Grundlage ihrer Argumentation gemacht werden. Mit der Aussage, dass die Existenz solcher Einzelbeispiele, wo target="_blank" sinnvoll ist" nicht ausgeschlossen werden kann, will ich dieser Art von Argumentation entgegenwirken. Heißt im Klartext, ich kann jetzt keine solchen Beispiele nennen, möchte sie aber präventiv nicht ausschließen ;-)
Naja, das koennen wir so akzeptieren. Die Frage ist nur, ob es tatsaechlich solche Beispiele gibt ;-)
Viele Grüße,
Ebenso!
Einbecker
-
-
-
Hallo Stefan,
Ergo wäre da nur noch target="_blank" und dies wiederum bewirkt,
dass beim Benutzer immer neue Fenster geöffnet werden, was nicht
unbedingt sinnvoll sein muß. Ergo kann man es besser in der and.
DTD (loose.dtd) unterbringen, die solche "Extras" berücksichtigt.Wer es wirklich darauf anlegt, auch in "Strict" neue Fenster zu öffnen, kann völlig standardkonform onclick="window.open(...)" verwenden (natürlich nur unter der bekannten Voraussetzung, daß JS aktiviert ist ;-). Wobei ich persönlich diese Variante völlig bescheuert finde...
Viele Grüße
Carsten
-
-
-
Moin!
Mal abgesehen davon, dass es ein Fehler in SELFHTML ist, halte ich es aber auch fuer einen Fehler von W3C, target nur bei Framesets zu erlauben. Denn die Wertzuweisung "_blank" oder die Adressierung eines mit JavaScript geoeffneten Fensters hat ja nicht unbedingt was mit Frames zu tun. Das target-Attribut gehoert deshalb finde ich durchaus auch in die strict-Variante uebernommen.
So wie ich "strict" verstehe, soll das der kleinste gemeinsame Nenner sein, also Dinge enthalten, die *jeder* User agent irgendwie seinem Benutzer "rueberbringen" kann (muss ja nicht "darstellen" sein, kann auch "erzaehlen" sein). Und da faengt's schon an: Wie mache ich auf der Console mit Lynx ein neues Fenster auf? Von daher wird sich "strict" im wesentlichen auf den logischen Teil von HTML beschraenken und keine physischen Auszeichnungen enthalten.
Wie Einbecker schon in <?m=24602&t=4355> dargestellt hat, ist "target" aber nicht logik-beschreibend. In der Verwendungsweise target="_blank" impliziert es jedoch meistens eine logische Bedeutung, naemlich das der Verweis als sowas wie "extern" einzustufen ist. Das ist eine tolle Information, aber target ist gewiss nicht das optimale Attribut, um diese Information in HTML niederzuschreiben. "rel" (von relationship; auch schon in der strict-Version von HTML2 enthalten) scheint mir da schon geeigneter. Ich koennte mir vorstellen, dass man sich auf etwas wie rel="extern" einigen kann und den User agents, fuer die das sinnvoll ist, dann beibringt, dass solche Links in einem neuen Fenster geoeffnet werden sollen.
So long
-
-
Hallo,
ich habe gerade ein Verständnisproblem. Ich habe in einer html Datei,
die als 4.01 strict gekennzeichnet ist geschrieben:Internet: <a href="http://www.url.de" target="_top">
und die Datei unter http://validator.w3.org/check geprüft. Dabei erhielt ich unter anderem folgende Meldung:
Error: there is no attribute "TARGET" for this element (in this HTML
version)In SelfHTML wurde dieses Attribut aber gelistet. Was gilt denn nun?
In der HTML 4.01 Strict-DTD haben a-Elemente kein target-Attribut, in der Transitional-DTD dagegen schon.
Man vergleiche
http://www.w3.org/TR/html401/sgml/dtd.html und
http://www.w3.org/TR/html401/sgml/loosedtd.htmlMfG, Thomas
-
Hallo Lars,
wenn Du den Validator des W3C benutzt hast -- und das hast Du ja -- dann gelten folgende Regeln:
Regel 1: Der Validator hat immer recht.
Regel 2: Sollte der Validator einmal irren, siehe Regel 1. ;o)Will sagen: wenn Du target verwenden mußt und trotzdem valide Seiten haben willst, dann nimm doch:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
Dann dürfte zumindest der Validator zufrieden sein...?
Im übrigen hat Stefan recht: target macht nicht nur in Framesets Sinn -- aber diese Frage wird leider nicht per Forums-Voting entschieden... ;o)
Herzliche Grüße und ein schönes Wochenende,
Meg-
Hallo Meg,
Will sagen: wenn Du target verwenden mußt und trotzdem valide Seiten haben willst, dann nimm doch:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
Dann dürfte zumindest der Validator zufrieden sein...?
In den einzelnen Frameunterseiten waere dann 4.01 Transitional angesagt und dann ist der Validator auch zufrieden.
MfG, Thomas
-