nachdem aber jeder abweichung von den vorgaben der dtd durch die fehlerkorrektur des browsers korrigiert werden muss oder erraten muss, kostet das wesentlich mehr rechenzeit als ohne fehler
Es braucht doch nicht mehr Rechenzeit, eine Nicht-Entity-Referenz von einer echten zu unterscheiden. Das ist ein und dieselbe Parserroutine. Ob die nun bei einem & das nächste ; suchen muss und schaut, ob ein entsprechender Entity existiert, oder beim folgenden = schon merkt, dass daraus keine Entity-Referenz mehr wird, gibt wahrlich keinen Ausschlag.
Was andere Fehler angeht, so kann es durchaus sein, dass der Parser einige Extrarunden drehen muss, um aus Verschachtelungsfehlern ein sauberes DOM zu bauen (oder ein unsauberes wie in vielen Browsern, dass den kaputten Code auch wieder der Baumlogik repräsentiert). Die paar Millisekunden, die dafür draufgehen, dass der Parser das tut, wofür er optimiert ist, nämlich fehlertolerant jeden Müllcode noch zu schlucken, fallen aber sicher nicht ins Gewicht und bleiben unmerklich. Schwerer wiegt, dass CSS und JavaScript schwer mit einem kaputten bzw. nicht vorhersehbaren DOM zusammenarbeiten.
<a href="http://example.com/index.php?foo=bar©=baz">weee</a>
Klar gibt es Fallstricke, wenn man sich auf Browserquirks verlässt. Hier schlägt dann lustigerweise noch mehr Browserquirks zurück. Wer mit den Schmuddelkindern spielt, darf später nicht jammern.
im übrigen ließen sich 50% der fehler durch das entfernen des unsinnigen "
<script></script>
" vor der dtd beheben
Du meinst, es ließen sich 50% der Validatormeldungen unterbinden. Was mit Fehlerbehebung erstmal wenig zu tun hat...
Mathias