nicht angemeldet
Hi,
Es gibt auch keinen Grund, proprietäre Elemente nicht zu verwenden.
Selbst wenn angenommen wird, dass das invalide Markup nur zur Abwärtskompatibilität mit nicht standardkonformen Browsern eingefügt wird, wird es nach und nach zu einer Altlast, die den Code belastet und früher oder später durch einen Relaunch entsorgt werden muss.
Aber niemand muß einen Relaunch machen für Element, die niemanden stören (zumindest weder den Surfer, noch den HTML-Browser). Na ja, außer vielleicht die Optik des Quellcodes und das Verständnis der "Validitäts-Kleriker". ;-)
Sofern es keine essentiellen Gründe gibt, die das Einfügen von invalidem Markup gebieten, sollte man es sich gut überlegen,
Yep. Man sollte allerdings generell gut überlegen, was man macht (und insbesondere, wenn man es auf die Menschheit losläßt ... =;->
denn später sitzt man auf dem veralteten Code, der durch proprietäres Markup aufgeblasen ist. Das bedeutet schlechte Wartbarkeit und schlechte Skalierbarkeit.
... wenn man nicht weiß, was man tut, könnte das passieren (passiert dann allerdings so oder so leicht =:-o).
Im Übrigen erzählt dein verlinkter Artikel ziemliche Märchen:
:))
»Eigene DTDs [...] werden von den HTML-Browsern, trotz der dortigen Angabe des URLs der DTD, geflissentlich ignoriert« - Zum einen sind die Parser der Hypertextbrowser nicht-validierend. Sie haben sich für die DTD gar nicht zu interessieren, weil sie die Entities auch so kennen, für die restliche Verarbeitung wird die DTD nicht benötigt.
Eben - meine Rede.
Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben ist oder nicht, das sprichst du selbst weiter unten an.
Dokumententyp != DTD!
»Jeder Hersteller gängiger Browser verwendet intern ohnehin mindestens eine Hersteller-spezifische DTD, die von den "offiziellen" HTML-DTDs des W3Cs, von denen es ja ebenfalls mehrere gibt, mal mehr, mal weniger abweicht« - Was hat das damit zu tun, dass kein DOCTYPE angegeben wird?
Mit dem DOCTYPE lege ich mich auf eine DTD fest. Ein Problem, wenn es sich um SGML handeln würde (dann könnte jeder Server, jede Seite eine eigene DTD haben). HTML ist aber bewußt offener gehalten (auf mehr als eine weltweite DTD), und deswegen braucht der HTML-Browser (im Gegensatz zu einem SGML-Browser) auch kein DOCTYPE mit einer bestimmten DTD (auch wenn es HTML-Browser gibt die bei solchen Angaben anfangen, mehr oder weniger "rumzuraten" -> "SGML-unwürdiges Verhalten" ;->).
Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen,
Keineswegs. =:-o
Ich kann a) einen guten, herkömmlichen HTML-Validator mit "meinen" Regeln versehen oder b) meinem SGML-Validator anweisen, stets eine (nämlich meine eigene) DTD zu verwenden. 8-)
Das ist Unsinn, dieses »Grundprinzip« existiert nicht.
Tja, da haben wir wohl unterschiedliche Meinungen. :)
Es gibt lediglich zum einen die verbreitete Praxis, dass die existierenden Browser fehlertolerant sind.
Das meinte ich auch gar nicht nicht.
Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist
Soso ...
»Grundprinzip« von HTML ist es schon gar nicht (du darfst es gerne belegen).
Ich habe leider die Doks meiner HTML-1.0-Zeit schon entsorgt und mit relativ schwammigen Forumlierungen wie Stefan Münzers "gemäß einer alten Übereinkunft" (sinngemäß in selfHTML, bzw. einem entsprechenden Buch von ihm gelesen), werde ich Dich ohnehin nicht beeinflussen können. ;)
Du hast praktisch recht, dahinter steckt aber keine Notwendigkeit.
Ich würde mich ja freuen (sehr sogar: diese ständige "JavaScript-Aufpasserei" ist wirklich nervig), wenn es anders wäre. Also bleibt es solange bei der normativen Kraft des Faktischen. :)
(Aus Gründen der Rückwärtskompatibilität quasi ewig?! ;-))
»Ist die syntaktische Korrektheit aber gegeben, so spricht man von einem "wohlgeformten" Dokument.« - Das Konzept der Wohlgeformtheit gibt es in SGML nicht.
Yep, ist vielleicht mißverständlich. Ich beziehe mich bereits auf HTML (bzw. natürlich auch auf XML/XHTML). SGML-Doks müssen, wie ich ja auch schrieb, unbedingt valide sein.
Diese Lockerung, wie du sie beschreibst, gab es nie.
Ich muß Dir widersprechen: HTML wurde von jeher nicht so streng gesehen, wie SGML. Daß das W3C heute einige dieser Auswüchse (sinnvoll oder nicht, sei dahingestellt - anderes Thema) wieder korrigiert, ändert nichts an der Vergangenheit. 8-)
Die Browser waren und sind zwar nachlässig Fehlern gegenüber,
Wie gesagt (und dort auch geschrieben): Die zusätzliche Fehlertoleranz der Browser meine ich damit gar nicht! Sie ist ein *zusätzlicher* Fluch/Segen.
Das stimmt nicht, sobald ein validierender SGML-Parser die SGML-Deklaration und die DTD von HTML in die Finger bekommt, kann er HTML validieren.
Klar. Es ist dann ja auch kein HTML-Dokment mehr, sondern ein SGML-Dokument. =:-o (Nasenbär! ;-))
AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.
Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).
Was Du nicht sagst ... (kopfschüttel)
Nach meinen ersten HTML-Versuchen, war der erste Schritt, die Suche nach einem Validator, der zweite die Erstellung meiner persönlichen DTD (zugegebenermaßen später, mangels Notwendigkeit, nicht mehr weiter verfolgt).
Natürlich hat ein HTML-Dokumente nicht in dem Sinne valide zu sein, dass der Browser die Validität wie ein validierender SGML-Parser prüft und im Fehlerfalle abbricht.
Merci: Quod erat demonstrandum! Da hast gerade schön den Unterschied zw. einem HTML- und enem SGML-Browser beschrieben. :)
Und da ich fast von Anfang an dabei bin, sind neue Techniken halt einfach kumulativ hinzugekommen - sie haben das "alte Wissen" nicht verdrängt, ...« - Ja, dadurch entsteht der oben beschriebene mies wartbare Code voll Altlasten.
Also ich habe absolut keine Probleme. Weder mit der Wartbarkeit meines Codes, noch mit älteren Browsern ... =8-)
... und verglichen mit diveren Browser-Bug-Workarounds auch für aktuelle Browser, geradezu Peanuts. =;->
Daß meine Art zu coden sich nicht auf jedermann übertragen läßt (schon mangels Erfahrung), ist mir ja bewußt. Nur: In der Validität hängt eben nicht Gottes alleinige Glückseligkeit ... :-)
Dieses Verhalten ist nicht »definiert«, es ist historisch gewachsen und hat sich ale praktisch erwiesen.
Henne-Ei-Problem? Das gleiche Prinzip war dann für CSS gut genug, für JavaScript aber nicht? ;>
Mit Semantik im Sinne einer semantischen Stimmigkeit der Elementverwendung hat dies hingegen nichts zu tun.
Semantik steht bei mir für den *Sprachumfang* (also die erlaubten/definierten Tags & Atribute). Erliege ich hier einem Begriffsirrtum (habe gerade keinen Duden rumliegen)?
Gruß, Cybaer