Hallo.

Wenn irgend ein Anfänger mitbekommt, dass der IE auf fast jeden Rechner läuft, geht er automatisch davon aus dass die anderen Browser nichts taugen (sonst würden sie sich ja durchsetzen und mehr verwendet werden) und dass damit sowieso nur Freaks surfen, die eh schon alles haben und von daher aus dem potentiellen Kundenkreis herausfallen...

Sind Freaks per se keine Kunden?
MfG, at

Hallo.

Aber niemand muß einen Relaunch machen für Element, die niemanden stören (zumindest weder den Surfer, noch den HTML-Browser).

Das Problem hieran ist der Sachverhalt, dass sich gestört fühlende Surfer sich nicht beschweren, sondern die Seite schlicht nicht mehr besuchen oder den Besuch gar sofort abbrechen.
Und du kennst alle Browser, die in Zukunft entwickelt werden, insbesondere für Mobiltelefone etc.?

Na ja, außer vielleicht die Optik des Quellcodes und das Verständnis der "Validitäts-Kleriker". ;-)

Suchmaschinen mögen validen Code auch sehr.
MfG, at

Hallo Cybaer,

Zum anderen hat es durchaus eine Relevanz, ob der Dokumentyp angegeben
ist oder nicht, das sprichst du selbst weiter unten an.

Zum Beispiel verfallen Browser aufgrund unterschiedlicher DTDs in
unterschiedliche Rendermodi.

Dokumententyp != DTD!

Äh bitte? Es gibt zur Zeit  noch keine andere Methode einen Dokumententyp
festzulegen, als die der DTD. Was meinst Du also hier? Du willst doch
nicht etwa an dieser Stelle unnötig mit Begriffen knausern?

Ich habe leider die Doks meiner HTML-1.0-Zeit schon entsorgt (..)

Ich habe für Dich mal nachgeschaut. Der erste richtige Standard war
HTML 2.0 in RFC 1866: http://www.ietf.org/rfc/rfc1866.txt
Dort heißt es:

»markup in the form of a start-tag or end-tag, whose generic identifier
  is not declared is mapped to nothing during tokenization.«

...also ignoriert. Allerdings wird überall in diesem Absatz das schwächere
»should« benutzt, nicht das bindende »must« und später heißt es:

»Information providers are warned that this convention is not binding:
  unspecified behavior may result, as such markup does not conform to
  this specification.«

Ein klare Warnung für Seitenersteller.

Es gibt noch ein früheres, einem HTML Standard ähnlichen Dokument: Ein
Internet Draft auf der Stufe zum RFC. http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

Dort wird nichts über unbekannte Elemente gesagt. Jedoch ist zu lesen:

»The name of a tag refers to an element type declaration in the HTML DTD.«

Ich denke, der Umkehrschluß dürfte klar sein.

AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.

Du meinst HTML-Dokumente. Meines Wissens nach galt das nur für den
ursprünglichen (nach sechs Monaten ausgelaufenen) Internet Draft von
Tim Berners-Lee, danach war gab es immer mehr Rufe nach Doctypes, so
zum Beispiel in Raggetts HTML+. Und im ersten wirklichen Standard dann
HTML 2.0 der IETF HTML Working Group (RFC 1866) wurde dann der DOCTYPE
verpflichtend. Alles noch vor W3C-Zeiten.

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.

Wobei dieses Verhalten anscheinend gerade für XHTML-Dokumente im Gespräch
ist, da die XML-Spec dies verlangt. Dave Hyatt versucht sich für das Webkit
gerade an einem Mittelweg.

Semantik steht bei mir für den *Sprachumfang* (also die
erlaubten/definierten Tags & Atribute). Erliege ich hier einem
Begriffsirrtum (habe gerade keinen Duden rumliegen)?

Die Semantik einer formalen Sprache ist für mich die Bedeutung der Tags
und Attribute. Ich würde das, was Du meinst, mit Grammatik bezeichnen.

Tim

Hallo,

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

Ich meinte eher, dass, wenn sich die Seite weiterentwickelt, dieser Code in neuen Konzepten nicht mehr brauchbar ist und sich in diese nicht einschmiegt. Je unflexibler der Code durch solches Markup wird und die Trennung und Rationalisierung der unterschiedlichen Komponenten eingeschränkt wird, desto eher muss der Gesamtcode bei einem Relaunch grundlegend verändert werden anstatt dass die Veränderung nur eine Komponente erfasst (etwa das Stylesheet).

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

Ja, unter diesen Voraussetzungen ist es natürlich verantwortbar. Leider hat dein Artikel meiner Auffassung nach eine etwas andere Aussage. Vielleicht ist es auch nicht absichtlich und nur eine mögliche Wirkung, aber die Argumentation läuft darauf hinaus, dass man sich über Validität keine so großen Gedanken machen sollte bzw. ihr nicht so große Bedeutung zumessen sollte. Und das greift für sich genommen m.E. zu kurz.

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

Es handelt sich um SGML. Jeder kann eigene Hypertextauszeichnungssprachen schreiben, die mehr oder weniger an W3C-HTML angelehnt sind und mehr oder weniger in Hypertextbrowsern funktionieren, und gegen entsprechende DTDs validieren. (Einige machen das sogar, um den Schein der Konformität zu wahren.) Niemand ist auf die eine einzige HTML-DTD festgelegt. Ich verstehe nicht, worauf du hinauswillst, denn auch hier verhält sich HTML nicht anders als irgendeine anderes SGML-Derivat.

HTML ist aber bewußt offener gehalten (auf mehr als eine weltweite DTD)

Wer sollte das entschieden haben? Die Browserhersteller, indem sie durch das Einfügen eigener Elemente und Attribute den W3C-Standard geöffnet haben? Vorher war der Standard aber nicht offen und er schlug auch nicht vor, HTML wie eine Basissprache zu behandeln, auf der jeder seine eigene Hypertextsprache aufbauen kann.
Darüber hinaus sind auch von anderen SGML-Sprachen eigene Abkömmlinge möglich, die dem Original mehr oder weniger nahe kommen, insofern sind auch dort verschiedene DTDs möglich. Nur enstanden sie anders.

und deswegen braucht der HTML-Browser (im Gegensatz zu einem SGML-Browser) auch kein DOCTYPE mit einer bestimmten DTD

Was ist ein »SGML-Browser«?

Darüber macht es ein fehlender DOCTYPE unmöglich, das Dokument automatisiert auf Fehler zu überprüfen,

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

Ok, da gebe ich dir recht, das hatte ich nicht bedacht.

Das ist Unsinn, dieses »Grundprinzip« existiert nicht.

Tja, da haben wir wohl unterschiedliche Meinungen. :)

Verzeihung, aber was ist das denn für eine absurde Argumentation? Du kannst meinetwegen ein subjektives Verständnis von HTML haben und diese Technik dementsprechend verwenden, nur hat das nichts mit rationaler Auseinandersetzung zu tun, bei der es um gute Argumente, nicht um unbegründete Bauchmeinungen geht. Du könntest wahrscheinlich gute Argumente dafür nennen, warum es angemessen ist, HTML so zu verstehen. Nichtsdestoweniger unterstellst du HTML hier ein objektives »Grundprinzip«, das sich vermutlich derjenige ausgedacht haben soll, der HTML erfunden/entwickelt hat.
Anstatt deine Aussage zu belegen, ziehst du dich in diesem Punkt weitesgehend kommentarlos darauf zurück, dass es ja deine subjektive Auffassung sei und daher aus sich heraus wahr und begründet ist. Das ist wirklich enttäuschend.

Dies basiert aber nicht auf einer Norm, es gibt lediglich nicht-normative Empfehlungen, wie mit invalidem Markup umzugehen ist

Soso ...

Was soll dieser Kommentar? Du kannst meine Aussage gerne widerlegen.

»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

Die Spezifikationen zu 1992er-Versionen von HTML stehen noch im Netz, zu HTML 2 bis 4 ebenfalls, darauf könntest du dich bspw. beziehen. Am besten natürlich auf halbwegs ausgereifte (HTML 2) bzw. heute direkt relevante Versionen (HTML 4). Wo lässt sich darin dieses Grundprinzip finden?

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

Das stimmt, weil ich gerne möglichst handfeste Begründungen statt nur Hypothesen hören möchte. Dass eine Art historisch gewachsene informale »Übereinkunft« existiert, habe ich ferner nicht angezweifelt, die sprach Selfhtml vermutlich an.

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?! ;-))

Im Prinzip ja, strenggenommen müsste jedes JavaScript die Existenz nahezu jedes grundlegenden Objektes bzw. jeder Methode abfragen, das bzw. die erst nach JavaScript 1.0 eingebaut wurde. Das wäre natürlich praktisch Overkill und die wenigsten Scripte achten darauf, Netscape 2 zu berücksichtigen usw.

Diese Lockerung, wie du sie beschreibst, gab es nie.

Ich muß Dir widersprechen: HTML wurde von jeher nicht so streng gesehen, wie SGML.

Was bedeutet das, »HTML wurde nicht so streng gesehen«? In welcher Hinsicht, wenn nicht hinsichtlich der Browserverarbeitung? Wo waren die Spezifikationen früher im Bezug auf Validität weniger streng?

Daß das W3C heute einige dieser Auswüchse (sinnvoll oder nicht, sei dahingestellt - anderes Thema) wieder korrigiert, ändert nichts an der Vergangenheit. 8-)

Ich wüsste nicht, dass es dem W3C um weniger Fehlertoleranz geht (von XHTML einmal abgesehen), was meinst du also? Proprietäres Markup?

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.

Ok. Dann weiß ich aber nicht, was du überhaupt mit deinem Aussagen über das »Grundprinzip« u.ä. sagen willst.

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! ;-))

Ähm... häh? Jedes HTML-Dokument ist ein SGML-Dokument.

AFAIR kamen selbst die ersten W3C-Dokumente noch ohne DOCTPE aus.

Das stimmt. Allerdings weiß ich nicht, welche Bedeutung dieser Umstand heute hat bzw. angesichts der späteren Entwicklung hat. Seitdem sind über zehn Jahre vergangen und das HTML von heute hat mit dem HTML von damals extrem wenig zu tun. Die Konformität zur DTD und die Abstammung von SGML ist spätestens seit HTML 2 ein Kernbestandteil dessen, was HTML ausmacht (siehe etwa die Definition http://www.w3.org/MarkUp/html-spec/html-spec_2.html#GLOSS18).

Und kostenlose validierende SGML-Parser gibt es schon seit Jahrzehnten (sgmls, m.W. auch arcsgml).

Was Du nicht sagst ... (kopfschüttel)

Was soll dieser Kommentar sagen? Bleibe doch einmal sachlich.

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

Wenn du damit sagen willst, dass du damals keinen kostenlosen validierenden SGML-Parser gefunden hattest, dann hast du sgmls o.ä. wahrscheinlich einfach nur nicht gefunden, sie existierten auf jeden Fall schon.

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

Nein, ich habe den Unterschied zwischen validierenden und nicht-validierenden Parsern beschrieben. Ein »SGML-Browser«, also ein auf einer anderen von SGML abgeleiteten Markupsprache basierender Client, hätte ebenfalls keinen validierenden Parser. Du wolltest aber ein Unterschied zwischen HTML einerseits und SGML *an sich* andererseits herausstellen, der alleine schon deshalb nicht funktioniert, weil HTML eine von SGML abgeleitete Sprache ist und SGML »an sich« nur eine Metasprache ist.

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

Ja, das lässt sich nur, wie du auch sagst, schwer verallgemeinern.

... und verglichen mit diveren Browser-Bug-Workarounds auch für aktuelle Browser, geradezu Peanuts. =;->

Das stimmt, ich sehe diese Workarounds prinzipiell ebenso skeptisch wie das Weiterbenutzen von altem Code, es ist m.E. ebenfalls wenig nachhaltig.

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

Schon klar, wie du es meintest, ich wollte lediglich darauf hinweisen, dass es hier noch eine Differenzierung gibt: Sich auf den normativen Sprachumfang zu beschränken, bedeutet nicht, dass die Kombination dieser syntaktischen Einheiten letztlich einen Sinn ergibt. Wenn im allgemeinen von semantischem Markup gesprochen wird, dann ist nicht (nur) gemeint, dass es nur die definierten Elemente und Attribute in entsprechenden definierten formalen Kontexten verwendet, sondern dass es die Textauszeichnung auch semantisch ist (eine Überschrift wird mit hX ausgezeichnet, Absätze mit p, Listen mit ol/ul usw.).

Mathias