Nichtvalider Code bei imagemap

[webling]

Hallo,

beim validieren einer Website habe ich einige Probleme.

Erstmal zur Imagemap. Beim validieren erhalte ich folgende Meldung:

Schließendes area-Element wurde nicht gefunden, obwohl dies zwingend notwendig ist.

Der Code dazu:

<map name="logo" id="logo">
<area shape="rect" coords="3,3,246,79" href="index.html" alt="Logo" title="Logo">
</map>

Ein <area> tag wird doch nicht mit einem </area> geschlossen?!
Jedenfalls nicht nach dieser Anleitung:
http://de.selfhtml.org/html/grafiken/verweis_sensitive.htm

Desweiteren angemahnt das die Elemente li und a an dieser Stelle nicht erlaubt sind. Die Zeile lautet folgendermaßen:

<a href="link1.html"><li id="navLink"><span class="navTxt">Link1</span> </li></a>
Der Validator ist übrigens http://validator.de.selfhtml.org/validate

Ich hoffe Ihr könnt mir helfen!

[MudGuard]

Hi,

Schließendes area-Element wurde nicht gefunden, obwohl dies zwingend notwendig ist.

Verwendest Du XHTML?
H

Ein <area> tag wird doch nicht mit einem </area> geschlossen?!

In X(HT)ML muß jedes Element geschlossen werden.

Desweiteren angemahnt das die Elemente li und a an dieser Stelle nicht erlaubt sind. Die Zeile lautet folgendermaßen:
<a href="link1.html"><li id="navLink"><span class="navTxt">Link1</span> </li></a>

Listenelemente (li) dürfen nur in Listen (ul, ol, ...) vorkommen. Ein a-ELement ist keine Liste.

cu,
Andreas

[suit]

In X(HT)ML muß jedes Element geschlossen werden.

In SGML/HTML auch - der Unterschied ist, dass in XML/XHTML explizit mit mit einem End-Tag oder aber direkt im Start-Tag mittels NESTC und NET passieren muss - in HTML hingegen sind die DTDs so locker gehalten, dass auch implizites schließen durch den Parser ausreicht (was in der Praxis aber kaum funktioniert, weil es keinen wirklich SGML-fähigen Browser gibt).

Und anstatt einen XML- oder SGML-fähigen Browser zu machen, wurde mit HTML5 einfach beschlossen, dass man sich eigene Fehlerkorrekturroutinen aus den Fingern saugt umd das Fehlerkorrekturverhalten zu standardisieren. Der Haken: Standards gab es zuvor auch (eben SGML und danach, weil zu kompliziert eben XML als Teilmenge davon) - gehalten hat sich keiner dran. Was die Fehlerkorrekturvorgaben von HTML5 nun daran ändern sollen, ist mir immer noch schleierhaft :)

[webling]

jetzt habe ich einiges gegoogelt und bin im grunde genommen genauso schlau wie vorher. anscheinend ist beim einen standard ein name="" attribut notwendig, beim anderen aber verboten.
wobei das nicht klärt, wieso ich die <area> die laut html nicht geschlossen werden muß, schließen soll?!

für mich heißt das alles so lassen wie es ist und auf´s validieren pfeifen solagen es funktioniert.

das ist aber recht wenig zufriedenstellen.

und beim anderen problem (@ andreas):

Listenelemente (li) dürfen nur in Listen (ul, ol, ...) vorkommen. Ein a-ELement ist keine Liste.

das a-Element steht in einer ul liste die auch entsprechend geschlossen ist.
wenn ich das richtig interpretiere, darf in einer liste nicht folgende reihenfolge vorkommen:
<ul>
  <a>
    <li>
    </li>
  </a>
</ul>

???

[Der Martin]

Hallo,

jetzt habe ich einiges gegoogelt und bin im grunde genommen genauso schlau wie vorher.

die Unterschiede zwischen HTML und XHTML hast du dann anscheinend noch nicht gefunden.

anscheinend ist beim einen standard ein name="" attribut notwendig, beim anderen aber verboten.

Nein. Notwendig ist es (außer bei Formularelementen) nie, erlaubt bei bestimmten Elementen. Aber das hat ja mit deiner Frage bzgl. Imagemap recht wenig zu tun, oder?

für mich heißt das alles so lassen wie es ist und auf´s validieren pfeifen solagen es funktioniert.

Das ist die schlechteste Lösung. Besser: Hinterfragen und verstehen. Gern auch nochmal gezielt nachfragen (obwohl der Hinweis von MudGuard auf XHTML eigentlich schon deutlich war).

Listenelemente (li) dürfen nur in Listen (ul, ol, ...) vorkommen. Ein a-ELement ist keine Liste.
das a-Element steht in einer ul liste die auch entsprechend geschlossen ist.
wenn ich das richtig interpretiere, darf in einer liste nicht folgende reihenfolge vorkommen:
<ul>
  <a>
    <li>
    </li>
  </a>
</ul>

Stimmt, diese Verschachtelung ist falsch. Das Kindelement von ul muss zunächst ein li sein. _Dessen_ Kindelement darf dann gern auch ein a-Element sein.

Ciao,
 Martin

[webling]

Hallo,

jetzt habe ich einiges gegoogelt und bin im grunde genommen genauso schlau wie vorher.

die Unterschiede zwischen HTML und XHTML hast du dann anscheinend noch nicht gefunden.

stimmt, sowas wie hier geht´s so und beim anderen so hab ich noch nicht gefunden.

anscheinend ist beim einen standard ein name="" attribut notwendig, beim anderen aber verboten.

Nein. Notwendig ist es (außer bei Formularelementen) nie, erlaubt bei bestimmten Elementen. Aber das hat ja mit deiner Frage bzgl. Imagemap recht wenig zu tun, oder?

stimmt, etwas offtopic. bin darauf gestoßen das jemand probleme bei einer imagemap hatte die bei valider codierung im firefox nicht funktionierte

für mich heißt das alles so lassen wie es ist und auf´s validieren pfeifen solagen es funktioniert.

Das ist die schlechteste Lösung. Besser: Hinterfragen und verstehen. Gern auch nochmal gezielt nachfragen (obwohl der Hinweis von MudGuard auf XHTML eigentlich schon deutlich war).

ja ich weiß. eine trotzige fomulierung da ich leider immer noch nicht fündig wurde.

Listenelemente (li) dürfen nur in Listen (ul, ol, ...) vorkommen. Ein a-ELement ist keine Liste.
das a-Element steht in einer ul liste die auch entsprechend geschlossen ist.
wenn ich das richtig interpretiere, darf in einer liste nicht folgende reihenfolge vorkommen:
<ul>
  <a>
    <li>
    </li>
  </a>
</ul>

Stimmt, diese Verschachtelung ist falsch. Das Kindelement von ul muss zunächst ein li sein. _Dessen_ Kindelement darf dann gern auch ein a-Element sein.

aha, danke. das ist ein echt hilfreicher hinweis!!!

Ciao,
Martin

kann mir denn jemand sagen wie/warum meine imagemap falsch/nicht geschlossen ist?

[Matthias Apsel]

Om nah hoo pez nyeetz, webling!

die Unterschiede zwischen HTML und XHTML hast du dann anscheinend noch nicht gefunden.

stimmt, sowas wie hier geht´s so und beim anderen so hab ich noch nicht gefunden.

Zumindest für die Elemente kann ich dir behilflich sein, für weitere Unterschiede gibt es das Wiki.

kann mir denn jemand sagen wie/warum meine imagemap falsch/nicht geschlossen ist?

area ist ein inhaltsleeres Element.

Matthias

[webling]

die Unterschiede zwischen HTML und XHTML hast du dann anscheinend noch nicht gefunden.

stimmt, sowas wie hier geht´s so und beim anderen so hab ich noch nicht gefunden.

Zumindest für die Elemente kann ich dir behilflich sein, für weitere Unterschiede gibt es das Wiki.

kann mir denn jemand sagen wie/warum meine imagemap falsch/nicht geschlossen ist?

area ist ein inhaltsleeres Element.

Matthias

Hallo Matthias,

vielen Dank für die Links!
Das macht alles endlich mal viel übersichtlicher und die Fehlermeldung dahingehend ist behoben, :-)

[Daniel.S]

Grüße dich, suit,

... - in HTML hingegen sind die DTDs so locker gehalten, dass auch implizites schließen durch den Parser ausreicht (was in der Praxis aber kaum funktioniert, weil es keinen wirklich SGML-fähigen Browser gibt).

Demnach dürfte so gut wie keine Webseite in HTML funktionieren. Man bedenke nur die ganze meta- oder br-Elemente. Die funktionieren aber auch nie ;)

Und anstatt einen XML- oder SGML-fähigen Browser zu machen, wurde mit HTML5 einfach beschlossen, dass man sich eigene Fehlerkorrekturroutinen aus den Fingern saugt umd das Fehlerkorrekturverhalten zu standardisieren. Der Haken: Standards gab es zuvor auch (eben SGML und danach, weil zu kompliziert eben XML als Teilmenge davon) - gehalten hat sich keiner dran.

XML(-fähige)-Parser gabs vorher auch schon (und wurden und werden auch verwendet). Bessere Webseiten gabs deswegen auch nicht [1].

Das Fehlerkorrekturverhalten in HTML5 wurde, wie du sagst, nicht aus irgendwelchen Fingern gezogen (nicht primär) sondern fasst die bereits bestehenden Algorithmen der verschiedenen Browser zusammen.

Dass es die auch heute noch gibt ist den Autoren von HTML 4.0 anzulasten. Die hätten ja auf bessere Konformität zu SGML hinarbeiten können.

Oder die XHTML WG. Wenn man sich schon die Mühe macht, eine Delta-Spezifikation zu erstellen, warum hat man nicht die DTDs von HTML 4.01 angepasst, sodass darin X(HT)ML-Konstrukte erlaubt werden? Etwa das tbody-Problem, das ja durch HTML 4 erst eingeführt wurde.

Was die Fehlerkorrekturvorgaben von HTML5 nun daran ändern sollen, ist mir immer noch schleierhaft :)

An den HTML5-Parser halten sich die Browserhersteller: Erst Firefox, dann Chrome, dann IE und jetzt auch Opera.

Gruß, der gerade schreiblustige Daniel

[1] rebell.at hat momentan 14 Fehler. Ein XML-Parser dürfte die Seite garnicht darstellen. Tatsächlich ignorieren selbst XML-fähige Browser

[suit]

... - in HTML hingegen sind die DTDs so locker gehalten, dass auch implizites schließen durch den Parser ausreicht (was in der Praxis aber kaum funktioniert, weil es keinen wirklich SGML-fähigen Browser gibt).

Demnach dürfte so gut wie keine Webseite in HTML funktionieren. Man bedenke nur die ganze meta- oder br-Elemente. Die funktionieren aber auch nie ;)

Nein, gerade weil es keine SGML-fähigen User Agents gibt, funktionieren die Webseiten - besonders XHTML ausgeliefert als text/html funktioniert nur aus aus diesem Grund - wenn das wirklich korrekt liefe, würde einiges angezeigt werden, was eigentlich nicht da sein soll. Ein Beispiel für einen SMGL-fähigen User Agent ist Emacs/W3 - der ist zwar schon lange tot, aber zeigt deutlich, dass ein standardkonformer Browser (zumindest was den SGML-Teil angeht) keine gute Idee ist.

Und anstatt einen XML- oder SGML-fähigen Browser zu machen, wurde mit HTML5 einfach beschlossen, dass man sich eigene Fehlerkorrekturroutinen aus den Fingern saugt umd das Fehlerkorrekturverhalten zu standardisieren. Der Haken: Standards gab es zuvor auch (eben SGML und danach, weil zu kompliziert eben XML als Teilmenge davon) - gehalten hat sich keiner dran.

XML(-fähige)-Parser gabs vorher auch schon (und wurden und werden auch verwendet). Bessere Webseiten gabs deswegen auch nicht [1].

Ich sprach primär von SGML-fähigen Browsern - einen XML-Parser zu schreiben ist im vergleich zu einem SGML-Parser ein Kinderspiel.

Das Fehlerkorrekturverhalten in HTML5 wurde, wie du sagst, nicht aus irgendwelchen Fingern gezogen (nicht primär) sondern fasst die bereits bestehenden Algorithmen der verschiedenen Browser zusammen.

Bei HTML5 hat man an allen Ecken und Enden das gefühl, dass Hixie schlechtes Zeug raucht und sich irgendwas aus den Fingern saugt. Sollte HTML5 nicht etwas sein, dass das derzeitige Web abbildet? Wie kommen dann so Geschichten wie die cite-Sache zustande wo man nicht auf die Community hört und sein eigenes Ding durchzieht?

Dass es die auch heute noch gibt ist den Autoren von HTML 4.0 anzulasten. Die hätten ja auf bessere Konformität zu SGML hinarbeiten können.

Die Autoren oder die die Browserhersteller? Ich würde eher sagen die Browserhersteller wären hier verlangt gewesen - es hat praktisch nie einen massentauglichen Browser gegeben, der tatsächlich SGML verstand - man war, selbst wenn man es besser wusste, gezwungen nur eine Teilmenge zu nutzen und konnte versehentlich SGML-Features nutzen, die zwar ein Validator als Gültig abstempelt, aber in den meisten Browser nicht funktionieren.

Folgendes ist valide[1]:

  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
       "http://www.w3.org/TR/html4/loose.dtd">  
<title>foo</>  
<p/bar/  

Der einzige Browser der das zumindest ansatzweise richtig macht ist Safari - er zeigt zumidnest den Titel richtig an - nicht aber den Inhalt des body. Alle anderen Browser zeigen  "foo></> <p/bar/" im Titel an.

Das ist zwar ein krasses Beispiel wo "nichts" funktioniert - aber es zeigt, dass es gewisse Subsets von SGML gibt, die nur bestimmte Browser unstützen.

Ändert man obenstehendes Beispiel z.B. auf folgendes, wird der Titel überall korrekt angezeigt - der Viewport bleibt aber leer. Ausnahme ist der Internet Explorer - der zeigt "<p/bar/" an.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
       "http://www.w3.org/TR/html4/loose.dtd">  
<title>foo</title>  
<p/bar/

An den HTML5-Parser halten sich die Browserhersteller: Erst Firefox, dann Chrome, dann IE und jetzt auch Opera.

Ja - aber wie lange wird es dauern bis die ersten Bugs auftauchen? :) Nein, die Regeln sind wenig komplex - das wird hoffentlich nicht passieren.

[1] rebell.at hat momentan 14 Fehler. Ein XML-Parser dürfte die Seite garnicht darstellen. Tatsächlich ignorieren selbst XML-fähige Browser

rebell.at wird als text/html ausgeliefert und _darf_ nicht als XML verarbeitet werden. Würde die Site tatsächlich als XML verarbeitet, käme eine Fehlermeldung des XML-Parsers.

[1] Vor einiger Zeit hat der W3-Validator hier übrigens nichtmal eine Warnung ausgespuckt.

[Daniel.S]

Demnach dürfte so gut wie keine Webseite in HTML funktionieren. Man bedenke nur die ganze meta- oder br-Elemente. Die funktionieren aber auch nie ;)

Nein, gerade weil es keine SGML-fähigen User Agents gibt, funktionieren die Webseiten - besonders XHTML ausgeliefert als text/html funktioniert nur aus aus diesem Grund - wenn das wirklich korrekt liefe, würde einiges angezeigt werden, was eigentlich nicht da sein soll. Ein Beispiel für einen SMGL-fähigen User Agent ist Emacs/W3 - der ist zwar schon lange tot, aber zeigt deutlich, dass ein standardkonformer Browser (zumindest was den SGML-Teil angeht) keine gute Idee ist.

Gerade deshalb hätte man, als man XHTML zur dominaten Sprache im Web machen wollte, hier eine Vereinheitlichung auslösen sollen.

XML(-fähige)-Parser gabs vorher auch schon (und wurden und werden auch verwendet). Bessere Webseiten gabs deswegen auch nicht [1].

Ich sprach primär von SGML-fähigen Browsern - einen XML-Parser zu schreiben ist im vergleich zu einem SGML-Parser ein Kinderspiel.

Einen HTML5-Parser zu schreiben ist auch nicht schwieriger als einen XML-Parser zu schreiben.

Bei HTML5 hat man an allen Ecken und Enden das gefühl, dass Hixie schlechtes Zeug raucht und sich irgendwas aus den Fingern saugt. Sollte HTML5 nicht etwas sein, dass das derzeitige Web abbildet? Wie kommen dann so Geschichten wie die cite-Sache zustande wo man nicht auf die Community hört und sein eigenes Ding durchzieht?

Der genannte Fall ist mir nicht bekannt, daher kann ich dazu nichts sagen.
Mir gefällt auch nicht alles in HTML5. Es wäre auch besser, wenn es noch einen zweiten starken Editor geben würde (nicht so ne Pfeife wie Hyatt).

Allerdings wächst auch nicht alles auf Hixies mist. Verschiedene Browserhersteller sind direkt dafür verantwortlich, dss bestimtme Elemente nicht mehr spezifiziert sind oder wieder erlaubt wurden (dialogue, s, etc.).

Dass es die auch heute noch gibt ist den Autoren von HTML 4.0 anzulasten. Die hätten ja auf bessere Konformität zu SGML hinarbeiten können.

Die Autoren oder die die Browserhersteller? Ich würde eher sagen die Browserhersteller wären hier verlangt gewesen - es hat praktisch nie einen massentauglichen Browser gegeben, der tatsächlich SGML verstand - man war, selbst wenn man es besser wusste, gezwungen nur eine Teilmenge zu nutzen und konnte versehentlich SGML-Features nutzen, die zwar ein Validator als Gültig abstempelt, aber in den meisten Browser nicht funktionieren.

Ich glaube nichtmal Tim hatte einen SGML-Parser; vielleicht hatte er den notwendigen Obolus für die Spezifikation nicht übrig, wer weiß?
Ich würde die Autoren nicht so einfach aus der Verantwortung ziehen. Die Spezifikationen die HTML im Laufe der Zeit beschrieben, haben keine Anstalten gemacht, die Situation zu verändern.

Folgendes ist valide[1]:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">
<title>foo</>
<p/bar/

>   
> Der einzige Browser der das zumindest ansatzweise richtig macht ist Safari - er zeigt zumidnest den Titel richtig an - nicht aber den Inhalt des body. Alle anderen Browser zeigen  "foo></> <p/bar/" im Titel an.  
  
Das Beispiel ist ja bekannt :)  
Ich gebe zu, meine Kenntnis über SGML ist nicht sehr groß, aber die Autoren von HTML hätten sicher die Möglichkeit gehabt, derlei Späße einzuschränken. Vor allem, da bereits feststand, dass es keine echten SGML-Parser gibt.  
  
Hätte es SGML-Parser gegeben, dann hätte XHTML vermutlich gar keinen Aufschwung erleben können. Von daher hatte die ganze Problematik ja auch ihre Vorteile, nicht?  
  

> > An den HTML5-Parser halten sich die Browserhersteller: Erst Firefox, dann Chrome, dann IE und jetzt auch Opera.  
>   
> Ja - aber wie lange wird es dauern bis die ersten Bugs auftauchen? :) Nein, die Regeln sind wenig komplex - das wird hoffentlich nicht passieren.  
  
Die Bugs sind nicht das Problem. Das Problem ist eher, dass man sich nicht traut (oder das Web es unmöglich macht - oder beides) ein paar der vorhandenen Regeln zu lockern.  
Hixie gibt daran ja teilweise auch sich selbst die Schuld.  
  

> > [1] rebell.at hat momentan 14 Fehler. Ein XML-Parser dürfte die Seite garnicht darstellen. Tatsächlich ignorieren selbst XML-fähige Browser  
>   
> rebell.at wird als text/html ausgeliefert und \_darf\_ nicht als XML verarbeitet werden. Würde die Site tatsächlich als XML verarbeitet, käme eine Fehlermeldung des XML-Parsers.  
  
Welchen Vorteil hat dann das Nutzen von XHTML.  
Was wäre, wenn ein XML-Parser ohne Kenntnis des Medientyps das Dokument verarbeitet?

[suit]

Einen HTML5-Parser zu schreiben ist auch nicht schwieriger als einen XML-Parser zu schreiben.

HTML5 hat aber weder etwas mit XML noch mit SGML zu tun - es sieht nur so aus und hat völlig eigene Regeln.

Bei HTML5 hat man an allen Ecken und Enden das gefühl, dass Hixie schlechtes Zeug raucht und sich irgendwas aus den Fingern saugt. Sollte HTML5 nicht etwas sein, dass das derzeitige Web abbildet? Wie kommen dann so Geschichten wie die cite-Sache zustande wo man nicht auf die Community hört und sein eigenes Ding durchzieht?

Der genannte Fall ist mir nicht bekannt, daher kann ich dazu nichts sagen.

http://wiki.whatwg.org/wiki/Cite_element

Ich gebe zu, meine Kenntnis über SGML ist nicht sehr groß, aber die Autoren von HTML hätten sicher die Möglichkeit gehabt, derlei Späße einzuschränken. Vor allem, da bereits feststand, dass es keine echten SGML-Parser gibt.

Zu der Zeit als TBL HTML geschaffen hat, gab es noch keien Browser wie wir sie heute kennen - das kam erst später, als das Web zum Massenmedium wurde und jeder HTML schreiben könnte. Und da es auch damals schon um Marktanteile ging, konnte der Browser der "den Mist der Autoren" am schönsten anzeigt natürlich gewinnen.

Hätte es SGML-Parser gegeben, dann hätte XHTML vermutlich gar keinen Aufschwung erleben können. Von daher hatte die ganze Problematik ja auch ihre Vorteile, nicht?

Sicher - aber mit HTML5 geht das eben wieder in die Gegenrichtung. Anstatt zu spezifizieren wie es sein soll und sich daran zu halten (no matter what) wird eine Regel geschafft, die beschreibt wie es sein soll, wenn es nicht so ist wie es sein soll, damit jeder "Depp ohne Ahnung" eine Website erstellen kann - womit wir wieder beim oberen Punkt sind: Marktanteile und potentielle Kunden. Das ist es was Google vornehmlich interessiert. Dass Chrome und Firefox beides Google-Browser sind, sollte klar sein.

Mehr Websites von Hobby-Autoren = mehr Werbeplatz für AdSense und somit AdWords-Kunden.

Und jetzt komm mir keiner mit Verschwörung :)

Die Bugs sind nicht das Problem. Das Problem ist eher, dass man sich nicht traut (oder das Web es unmöglich macht - oder beides) ein paar der vorhandenen Regeln zu lockern.

Oder eben zu straffen: wenn es HTML-Fehler gibt, soll der Browser eine Fehlermeldung ausspucken, gerne auch nur in der Fehlerkonsole.

CSS- oder JavaScript-Fehler bemeckert jeder Browser, aber HTML ist wurst.

Welchen Vorteil hat dann das Nutzen von XHTML.

Die Weiterverarbeitung als XML, wenn es ein XML-fähiger Agent es haben will (über die Accept-Header steuerbar).

In vorliegenden Fall ist das aber nicht möglich, weil application/xhtml+xml zu einer Fehlermeldung führen würde. Das Theme über Rebell ist ein fertiges Theme und an den Updates daran bin ich nicht primär schuld - da wäre es dämlich, das ganze als XML verarbeiten lassen zu wollen, weil die gefahr besteht, dass jemand ohne Ahnung reinfingert und dann nichts mehr geht :)

Was wäre, wenn ein XML-Parser ohne Kenntnis des Medientyps das Dokument verarbeitet?

Fehlermeldung :)

Wenn das Dokument aber valide ist, kann man es ohne Probleme mit einem XML-Parser verarbeiten. Und das ist ein extremer Vorteil, besonders wenn es darum geht Informationen zu extrahieren, die man anderswo braucht.

[Daniel.S]

Einen HTML5-Parser zu schreiben ist auch nicht schwieriger als einen XML-Parser zu schreiben.

HTML5 hat aber weder etwas mit XML noch mit SGML zu tun - es sieht nur so aus und hat völlig eigene Regeln.

Stimmt. Den zusätzlichen Aufwand, HTML5 im Gegensatz zu nur XML oder nur SGML parsen zu können, gabs aber vorher auch schon.

Der genannte Fall ist mir nicht bekannt, daher kann ich dazu nichts sagen.

http://wiki.whatwg.org/wiki/Cite_element

Ja, da scheint die Spezifikation wirklich unsinnig zu sein. Offenbar darf man aber zumindest Werke, aus denen ein Zitat stammt, damit auszeichnen.

Ich gebe zu, meine Kenntnis über SGML ist nicht sehr groß, aber die Autoren von HTML hätten sicher die Möglichkeit gehabt, derlei Späße einzuschränken. Vor allem, da bereits feststand, dass es keine echten SGML-Parser gibt.

Zu der Zeit als TBL HTML geschaffen hat, gab es noch keien Browser wie wir sie heute kennen - das kam erst später, als das Web zum Massenmedium wurde und jeder HTML schreiben könnte. Und da es auch damals schon um Marktanteile ging, konnte der Browser der "den Mist der Autoren" am schönsten anzeigt natürlich gewinnen.

Das stimmt. Allerdings muss es schon Parser wie heute gegeben haben, sonst hätten die damaligen Browser "Tim's HTML tags" nicht verarbeiten können.

Hätte es SGML-Parser gegeben, dann hätte XHTML vermutlich gar keinen Aufschwung erleben können. Von daher hatte die ganze Problematik ja auch ihre Vorteile, nicht?

Sicher - aber mit HTML5 geht das eben wieder in die Gegenrichtung. Anstatt zu spezifizieren wie es sein soll und sich daran zu halten (no matter what) wird eine Regel geschafft, die beschreibt wie es sein soll, wenn es nicht so ist wie es sein soll, damit jeder "Depp ohne Ahnung" eine Website erstellen kann - womit wir wieder beim oberen Punkt sind: Marktanteile und potentielle Kunden. Das ist es was Google vornehmlich interessiert. Dass Chrome und Firefox beides Google-Browser sind, sollte klar sein.

HTML5 spezifiziert, wie es sein soll und spezifiziert, wie es sein sein, wenn es nicht ist, wie es sein soll, was XML ebenfalls tut, nur dass XML es sich leicht macht und die Verarbeitung abbricht, während HTML5 Korrekturen erlaubt.

Warum sollte nicht jeder Depp in der Lage sein, eine Webseite erstellen können? Du willst mir doch nicht ernsthaft weismachen, dass wir nennenswert weniger Werbung im Web hätten, wenn XML die dominate Sprache wäre.

Die Bugs sind nicht das Problem. Das Problem ist eher, dass man sich nicht traut (oder das Web es unmöglich macht - oder beides) ein paar der vorhandenen Regeln zu lockern.

Oder eben zu straffen: wenn es HTML-Fehler gibt, soll der Browser eine Fehlermeldung ausspucken, gerne auch nur in der Fehlerkonsole.

CSS- oder JavaScript-Fehler bemeckert jeder Browser, aber HTML ist wurst.

Die Regeln wurden gestrafft, was allein schon dadurch begründet ist, dass es vorher keine Regeln gab. Zumindest keine, die problemlos durchsetzbar waren.

Im IE10 und in mindestens einem anderen Browser (Opera oder Safari/Chrome, bin grad nicht sicher) gibt es inzwischen auch HTML-Fehlermeldungen in der Fehlerkonsole, seit der HTML5-Parser implementiert wurde. Aber wie bei CSS- oder JS-Fehlern sollten diese die Webseite nicht unbenutzbar machen.

Tatsächlich ist der Firefox inzwischen auch der einzige Browser, der lediglich eine Fehlermeldung anzeigt, wenn im XML was nicht stimmt. Alle anderen rendern einfach so weit wie möglich.

Welchen Vorteil hat dann das Nutzen von XHTML.

Die Weiterverarbeitung als XML, wenn es ein XML-fähiger Agent es haben will (über die Accept-Header steuerbar).

Wie kann man diesen Vorteil nutzen, wenn das XML fehlerhaft ist?
Hier wäre XML wohl besser eingesetzt, wenn die Informationen extern gespeichert wären und für die Webseite eben daraus ausgelesen würden.
Ist ja durchaus ein sinnvoller Einsatz (wenn auch nicht so performant wie andere Lösungen, soweit ich weis).

In vorliegenden Fall ist das aber nicht möglich, weil application/xhtml+xml zu einer Fehlermeldung führen würde. Das Theme über Rebell ist ein fertiges Theme und an den Updates daran bin ich nicht primär schuld - da wäre es dämlich, das ganze als XML verarbeiten lassen zu wollen, weil die gefahr besteht, dass jemand ohne Ahnung reinfingert und dann nichts mehr geht :)

Als HTML wäre die Seite als einfacher zu warten.

Tatsächlich profitierst du ohnehin von HTML5, weil die Webseite in jedem Browser gleich angezeigt wird (dank HTML5-Parser), obwohl der Quelltext Fehler enthält. Ist das nicht toll?

Was wäre, wenn ein XML-Parser ohne Kenntnis des Medientyps das Dokument verarbeitet?

Fehlermeldung :)

Eben. :)

Wenn das Dokument aber valide ist, kann man es ohne Probleme mit einem XML-Parser verarbeiten. Und das ist ein extremer Vorteil, besonders wenn es darum geht Informationen zu extrahieren, die man anderswo braucht.

Ja. Wenn. :)

[MudGuard]

Hi,

In X(HT)ML muß jedes Element geschlossen werden.

In SGML/HTML auch

Nein.
Siehe z.B. img-Element:
Start tag: required, End tag: forbidden

in HTML hingegen sind die DTDs so locker gehalten, dass auch implizites schließen durch den Parser ausreicht

nein, manche Elemente werden in HTML nicht geschlossen.

cu,
Andreas

[Matthias Apsel]

Om nah hoo pez nyeetz, MudGuard!

in HTML hingegen sind die DTDs so locker gehalten, dass auch implizites schließen durch den Parser ausreicht

trifft für _optionale_ Endtags zu.

Matthias

[suit]

In X(HT)ML muß jedes Element geschlossen werden.

In SGML/HTML auch

Nein.

Du verwechselst Tag und Element ...

Siehe z.B. img-Element:
Start tag: required, End tag: forbidden

Kannst du bitte den von mir verlinkten Absatz nochmal lesen?

<img src="foo.jpg" alt="whatever"> ist ein einwandfrei nach den SGML-Regeln geschlossenes _Element_ - das Element hat zwar kein Start-Tag und keinen NESTC delimter vor dem NET aber das NET alleine reicht aus, um den Start-Tag und somit das Element zu schließen.

nein, manche Elemente werden in HTML nicht geschlossen.

Beispiele?