nicht angemeldet
Hallo,
Und, BTW, Validität ist nicht alles. Jeder "Depp" kann sich 'ne HTML-x.x-Doku besorgen, nach "Schema F" arbeiten (lassen) und das Ergebnis solange durch einen Validator schicken, bis der keine Fehler mehr meldet. Naja, dafür könnte auch noch ein Schimpanse ausreichen ... ;->
Es gibt auch keinen Grund, proprietäre Elemente nicht zu verwenden. Hauptsache, das Dokument ist sonst OK ("wohlgeformt") und diejenigen, die davon nichts haben, müssen darunter nicht unnötigerweise leiden. :-)
Freilich gibt es solche Gründe. Die Verwendung von offen und konsensuell standardisierten Techniken bedeutet Zukunftssicherheit und Nachhaltigkeit. 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. Sofern es keine essentiellen Gründe gibt, die das Einfügen von invalidem Markup gebieten, sollte man es sich gut überlegen, denn später sitzt man auf dem veralteten Code, der durch proprietäres Markup aufgeblasen ist. Das bedeutet schlechte Wartbarkeit und schlechte Skalierbarkeit.
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. Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben ist oder nicht, das sprichst du selbst weiter unten an.
»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? »Hersteller-spezifische DTD« gibt es nicht, höchstens verschiedene Element- und Attributsätze. Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen, das bedeutet syntaktische Fehlerfreiheit, aber auch das ständige Bewusstsein darüber, an welchen Stellen bzw. in wie weit proprietärer Code verwendet wird.
»Anders als bei der "Mutter" der Beschreibungssprachen, SGML (worauf auch HTML beruht), bei der zu jedem Dokument verbindlich durch die real (und zuerst) existierende DTD dessen Gültigkeit (Validität) festgelegt wird, ...« - Das ist bei HTML ebenso der Fall.
»... ist es das Grundprinzip von HTML (aber auch von CSS), daß die Tags & Attribute vom Browser zu ignorieren sind, die er nicht kennt« - Das ist Unsinn, dieses »Grundprinzip« existiert nicht. Es gibt lediglich zum einen die verbreitete Praxis, dass die existierenden Browser fehlertolerant sind. Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist (http://www.w3.org/TR/html401/appendix/notes.html#notes-invalid-docs). Und das »Grundprinzip« von HTML ist es schon gar nicht (du darfst es gerne belegen).
»(Achtung: Bei Scripts ist dies nicht der Fall: sie müssen so programmiert werden, daß neue Scriptelemente von Browsern mit älteren Scriptversionen nicht interpretiert werden)« - Diese Unterscheidung ist unbegründet: Die Fehlertoleranz der Browser in Bezug auf unbekannte JavaScript-Konstrukte/-Objekte/-Methoden ist ebenfalls nicht standardisiert und es obliegt dem Browser, wie er mit fehlerhaftem/unbekannten Code umgeht. Du hast praktisch recht, dahinter steckt aber keine Notwendigkeit.
»D.h., ein ordnungsgemäßes SGML-Dokument darf wirklich nur die Elemente aufweisen, wie sie in der DTD definiert wurden, um von einer SGML-fähigen Software verarbeitet werden zu können.« - Wenn sich ein HTML-Dokument »ordnungsgemäß« nennen will, dann gilt dies im Falle eines validierenden Parsers ebenso. Es können natürlich nicht ordnungsgemäße SGML- und HTML-Dokumente existieren, genauso wie es nicht-validierende Parser gibt und fehlertolerante Parser/Prozessoren, die auch fehlerhafte SGML-Dokumente soweit es möglich ist verarbeiten.
»Ist die syntaktische Korrektheit aber gegeben, so spricht man von einem "wohlgeformten" Dokument.« - Das Konzept der Wohlgeformtheit gibt es in SGML nicht.
»Sinn dieser Lockerung war, daß ein HTML-Dokument möglichst einfach zu erstellen sein sollte, um so möglichst hohe Verbreitung zu finden« - Diese Lockerung, wie du sie beschreibst, gab es nie. Die Browser waren und sind zwar nachlässig Fehlern gegenüber, in normativer Hinsicht war dies aber nie vorgesehen, schon gar nicht vorgeschrieben und schon gar nicht mit der Absicht, dass es nichts ausmacht, dass invalide HTML-Dokumente entstehen.
»Ein SGML-Dokument bedarf, insbesondere was Planung und Erstellung der DTD angeht, eines weitaus höheren Aufwands, was auch der Grund ist, warum es vergleichsweise wenig Programme gibt, die HTML-Code prüfen: Die anfangs existenten (teuren) Validatoren kannten gar kein HTML.« - Das stimmt nicht, sobald ein validierender SGML-Parser die SGML-Deklaration und die DTD von HTML in die Finger bekommt, kann er HTML validieren. Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).
»Sie behandelten HTML-Dokumente eben wie SGML-Dokumente, ohne auf das HTML-Grundprinzip Rücksicht zu nehmen.« - Dieses Grundprinzip gibt es wie gesagt nicht und validierende SGML-Parser prüfen nunmal SGML-Dokumente gegen die DTD. Es gibt keine besondere Ausnahme für HTML, wo sollte diese auch artikuliert sein, in der SGML-Deklaration? Dann hätte das Validieren wenig Sinn.
»Hieraus dürfte sich auch der in bestimmten Kreisen verbreitete Irrglaube gebildet haben, ein HTML-Dokument habe unbedingt valide zu sein.« - Irrglaube ist ein gutes Stichwort angesichts deiner unfundierten Argumentation... 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. Aber er muss natürlich die Elemente und Attribute kennen, um sie verarbeiten zu können. Dass er darüber hinwegsieht, wenn ihm ein Konstrukt unbekannt ist oder fehlerhaft vorkommt, beruht auf einer informalen Vereinbarung, nicht auf einer Norm (und schon gar nicht auf einem Prinzip!).
»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.
»Der Nachteil, daß die üblichen [...] Validatoren "meckern", weil sie leider nicht nur die Syntax prüfen [...], sondern (eben konträr zum definierten Verhalten eines HTML-Browsers) ...« - Dieses Verhalten ist nicht »definiert«, es ist historisch gewachsen und hat sich ale praktisch erwiesen.
»... auch versuchen, die Semantik zu überprüfen (also z.B.: sind die Elemente bekannt und "erwünscht", d.h. gehören sie zur einer bestimmten, ggf. auch einer vielleicht zukünftigen, noch zu schreibenden DTD =:-o)« - Ein Validator prüft lediglich, ob ein Attribut bzw. Element zum Sprachumfang gehört und an dieser Stelle im Dokumentbaum vorkommen kann. Mit Semantik im Sinne einer semantischen Stimmigkeit der Elementverwendung hat dies hingegen nichts zu tun.
Mathias