Wird HTML 5 Validierung der Mühe wert sein?

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

Frage

Es ist allgemein der Ansicht, dass der beste Grund, eine HTML zu validieren ist, um sicherzustellen, dass alle Browser es konsequent und vorhersagbar behandeln.

Der HTML 5 Entwurf enthält jedoch zwei Spezifikationen in einem. Zunächst wird ein Autor spec, beschreibt die Elemente und Attribute, die HTML-Autoren verwenden sollten, und ihre Beziehungen untereinander. Validierung einer HTML-5-Seite wird auf dieser Spezifikation basiert. Die Elemente und Attribute enthalten sind, nicht direkt von HTML 4 gezogen, sondern von Grund gerechtfertigt werden benötigt, was bedeutet, dass einige HTML 4 Features, wie die Zusammenfassung Attribut auf

, longdesc auf und das Profil Attribut auf , erscheint nicht zur Zeit in diesem Entwurf. Solche Merkmale sind veraltet nicht berücksichtigt, sie sind einfach nicht enthalten. (Ihre Abwesenheit aus dem Entwurf bleibt umstritten, obwohl ihre Aufnahme in absehbarer Zeit nicht wahrscheinlich scheint.)

Zweitens definiert der Entwurf einen Browser Verarbeitungsvorschrift, die genau zu definieren sucht, wie ein Parser des Browsers jeden Byte-Stream behandeln wird es gegeben hat, unabhängig davon, wie gut geformt und gültig die HTML. Das bedeutet, dass, wenn sie vollständig der Browser HTML 5 unterstützt, wird es möglich sein, vorherzusagen, wie jeder Browser behandelt diejenigen, die Validierung HTML-Code für eine viel breitere Palette von Eingängen als nur übergeben.

Insbesondere weil HTML 5 definiert ist, mit dem heutigen Web 100% abwärtskompatibel sein, die alle gültigen HTML 4 und alle ungültigen aber häufig Aufschlag verwendet wird, wird auch weiterhin genau verarbeitet wird so, wie es heute ist, und zwar unabhängig ob es sich um HTML 5 gültig ist oder nicht.

Daher ganz am Minimum, jemand eine Funktion von HTML 5, HTML 4 oder einer früheren Version von HTML, sowie vielen proprietären Erweiterungen, kann sicher sein, mit, dass ihr HTML wird konsistente und vorhersagbare Behandlung in allen Browsern bekommen.

Dieses gegeben, macht es Sinn machen diejenigen HTML 5 zu, dass zu begrenzen, die bestätigen wird, und welche praktischen Nutzen bekommen wir zu tun, so?

War es hilfreich?

Lösung

  • Erste gibt es die Schicht der Gültigkeit entsprechend „Fehler analysieren“ in der HTML5 Parsing-Algorithmus . Diese Schicht ist ähnlich Wohlgeformtheits- in XML. Der wichtigste Grund zu vermeiden, Fehler in Ihren Dokumenten auf dieser Ebene ist, dass Sie einen überraschenden Parse-Baum bekommen können. Wenn Ihr Dokument fehlerfrei auf dieser Ebene ist, erhalten Sie weniger suprises zu debuggen, wenn JS oder CSS zu schreiben, die mit dem DOM funktioniert.
  • Als Sonderfall der oben genannten Schicht, gibt es noch die HTML5 Doctype: <!DOCTYPE html>. Der Grund, warum man sich wünschen würde hier zu erfüllen ist immer den Standards-Modus auf die einfachste Art und Weise möglich. Es ist etwas, das man im Gegensatz zu dem HTML 4.01 oder XHTML 1.0 doctypes merken können Sie nachschauen müssen, und kopieren und jedes Mal einfügen. Natürlich der Grund, warum Sie den Standards-Modus wollen würden weniger Überraschungen auf der CSS-Ebene ist.
  • Der Hauptgrund zur Validierung auf der Schicht höher ist als der Parsing-Algorithmus zu kümmern ist Ihre Fehler zu kontrollieren, so dass Sie weniger Zeit damit verbringen, das Debuggen, warum Ihre Seite nicht funktioniert, wie Sie erwarten.
  • Der bisherige Punkt erklärt nicht, warum Sie Validierung sorgen soll, wenn ein bestimmtes Element oder Attribut, das Sie falsch schreiben nicht von Browsern als eine Angelegenheit von Legacy unterstützt wird, aber die HTML5-Spezifikation es noch meidet. Hier ist der Grund HTML5 Syntax wie folgt veralteter hat:
    • HTML5 verwendet Obsoletion zu Autoren zu signalisieren, dass einige Funktionen eine Verschwendung ihrer Zeit sind. Dazu gehören longdesc, summary und profile. (Beachten Sie, dass die Menschen nicht einig, ob diese sind in der Tat, Zeitverschwendung, sondern als derzeit ausgearbeitet, HTML5 macht sie überflüssig.) Das heißt, wenn Sie nur über begrenzte Ressourcen zur Verbesserung der Zugänglichkeit, Ihre begrenzten Ressourcen besser ausgegeben auf etwas anderes als longdesc und summary. Wenn Sie Ressourcen für die semantische Reinheit begrenzt haben, sind Ihre Ressourcen besser ausgegeben auf etwas anderes als dafür, dass Sie die richtige Beschwörung in profile haben.
    • obsoletes HTML5 einige Präsentations-Features, die in CSS dupliziert werden können Autoren führen CSS für ihre eigenen gut zu bedienen. Auf diese Weise Autoren, die Wartbarkeit berücksichtigen nicht auf ihre eigenen sollen dennoch zu mehr wartbaren Code geführt werden. Ich persönlich würde es vorziehen, mehr von dem Erbe Präsentations Sachen machen konform und lassen es zu Autoren selbst, die Art und Weise, Dinge zu tun, zu entscheiden, für sie funktioniert.
    • Einige Dinge aus politischen Gründen verworfen wird. Das <font> Element ist veraltet, da macht es konformen anti-<font> standardistas würde denken, dass die HTML5 Menschen verrückt geworden, was zu schlechten PR führen könnte. <applet> wird hauptsächlich als grundsätzlich nicht unter besonderem Markup auf einen bestimmten Plug-in veralteten. Das classid Attribut auf <object> ist veraltet, weil es in der Praxis ist ActiveX-spezifisch.
    • Einige Dinge auf der Grundlage der Sprache Design-Ästhetik holt. Dazu gehört auch das name Attribut auf <a> und das language Attribut auf <script>.

(I entwickeln, um den Validator.nu HTML5 Validator, die auch die Validierungsmaschine durch das W3C-Validator verwendete HTML5 ist.)

Andere Tipps

  

Dieses gegeben, macht es Sinn machen diejenigen HTML 5 zu, dass zu begrenzen, die bestätigen wird, und welche praktischen Nutzen bekommen wir zu tun, so?

Ja, natürlich. Sie vergessen, dass die Zukunft nicht festgelegt ist. Insbesondere übernehmen Sie implizit, dass HTML 5-Spezifikationen wird sich nie ändern, und deprecate nie irgendwelche Funktionen. Dies ist natürlich, Zemente nur den Status quo. Es ist auf jeden Fall wünschenswert, Unterstützung für einige Funktionen in langfristig zu entfernen, um es einfacher für neue Entwicklungen stattfinden (insbesondere wenn diese möglicherweise miteinander in Konflikt geraten).

Es kann in der Herstellung gültigen HTML 5 (außer, dass es noch macht Validierung und damit die Entwicklung einfacher) kein unmittelbarer Nutzen sein. Aber es kann eine weitreichende Nutzen sein, wenn die meisten Websites in die Qualität zu verbessern, weil sie über die aktuellen Technologien und Standards zu bewegen auf viel einfacher macht.

Die Validierung hat nie wirklich über konsistente Ergebnisse in allen Browsern immer noch vor HTML5 begann. Das ist ein Mythos, von denen propagiert, die nicht verstehen, was sie reden, auch wenn sie denken, dass sie es tun.

Der wahre Grund für die Validierung ist und immer eine reine Frage der Qualitätssicherung hat. Es ist nur ein Weg, um Fehler zu detektieren, die. Auch wenn Ergebnisse für einen bestimmten Fehler sein kann oder bald werden, konsistent unter Browsern, es ist immer noch möglich, dass das Ergebnis sich nicht wie beabsichtigt ist.

Es ist wichtig für Autoren in der Lage sein, Fehler in ihrem Code zu fangen, weil sauberen, fehlerfreier Markup einfacher zu handhaben ist und zu pflegen, vor allem, wenn in einem Team zu arbeiten. Während die meisten individuellen Fehler sind gutartige kann am Ende und keine größeren Probleme verursachen, gibt es einige, die zu unerwarteten Ergebnissen führen kann. z.B. Falsch, überlappende oder nicht geschlossene Elemente unerwartete Layoutprobleme in einigen Fällen dazu führen kann, und lassen ein Validator Ihnen sagen, wo der Fehler ist, hilft, das Problem bei der Beseitigung. Aber wenn die Ergebnisse mit Dutzenden von sonst gutartigen Fehlern gefüllt sind, kann es die Erkennung machen und verarbeitet schwieriger, als es sein muss.

Dies ist in der Tat ein meine Spitzfindigkeiten mit HTML5. Es gibt keinen Grund eine Teilmenge des Stromes als ‚gültig‘ definiert, wenn ein Browser sowieso alle Streams in gleicher Weise behandeln muß. Die Äonen auf der WHATWG Liste diskutieren Ausweichmechanismen ausgegeben ist eine massive Verschwendung von jeder Zeit, vor allem, wenn XML sollten bereits alle Parsing Probleme gelöst haben.

Es wäre eine nützliche Idee gewesen, ein Best-Practices-Dokument auf produzieren Vermächtnis ungültige Dokumente Parsen aber dies hat in einem Web-Standard keine Rolle, es ist nur ein weiterer Bestandteil weiter vernebeln um HTML5, die sich nicht entscheiden können, ob sie will Verhalten zu kodifizieren bestehenden (wie HTML 3.2 tat), stückchenweise eine sauberere Plattform (wie HTML 3.0 versucht) oder das Hinzufügen neue Erweiterungen neu zu definieren.

Wie auch immer, kann die Frage verlegt werden, weil es nie ein Browser sein, dass „HTML5 unterstützt“. Es gibt einfach viel, viel zu viel davon: Browser-Hersteller konnte nicht implementieren absolut alles bis ins Detail selbst wenn sie wollten, die zumindest Microsoft ausdrücklich nicht. Stattdessen offensichtlich nützliche Features handverlesene von ihm durch Anbieter sein wird, und eine breitere Akzeptanz treffen.

HTML5 ist keine kohärente HTML-Spezifikation, es ist Hixie der ausufernden, unlesbar und unfertiges Rezept für jede zufällige Sache, die er ein Web-Browser denkt tun soll. Es wird fehlschlagen. Und W3 des alternativen Ansatz XHTML2 hat bereits gescheitert. Es gibt keine kohärente zukünftige Richtung für Web-Standards. Wir haben den Ball fallen gelassen.

Es ist eine gute Frage.

Der primäre Zweck der Validierung (für mich zumindest) ist mir zu helfen, Fehler in meiner Markup zu fangen, und mir eine gute Basis zu geben, auf dem zu bauen, wenn Seiten in verschiedenen Browsern zu testen; wenn das Markup gültig ist, und die Seite wird in IE6 borked, es ist ein IE6 Problem.

Die Tatsache, dass Browser alle noch in einer vorhersagbaren Weise verhalten soll, selbst wenn Ihr Markup technisch ungültig HTML5 wie eine Tabelle Zusammenfassung oder einen Anker accesskey umfasst, trübt das Wasser etwas.

Als allgemeine Faustregel würde ich immer meine Seiten will zu validieren, zu dem zuvor benannten Grunde. Wenn jedoch (zum Beispiel) ein Attribut aus der HTML5-Spezifikation ohne einen scheinbar geeigneten Ersatz hinzugefügt fällt gelassen wurde, könnte ich geneigt sein, um das veraltete oder veraltetes Attribut weiterhin zu verwenden, und akzeptieren Sie die Validierungsfehler.

Wie immer, ich denke, es ist ein Fall Ihr Handwerk zu wissen.

Wenn Sie wissen, was Sie tun, und haben gemacht ein bewusste Entscheidung eine Seite zu erstellen, die nicht aus wichtigem Grunde nicht bestätigen, es ist kein Problem. Wenn Sie nur das Schreiben von Code, der überprüft nicht, weil Sie nicht besser wissen, das ist eine ganz andere Sache.

Stephen

W3C HTML5 Validator Maintainer hier. Ich schrieb vor kurzem einen kurzen „Warum Validate?“ Abschnitt für die „Über“ des HTML5 Validator:

http://validator.w3.org/nu/about.html# why-validate

Die Quelle für den Text dieses Abschnittes ist es hier:

https://github.com/validator/ Validator / Blob / Master / site / nu-about.html # L160

Und ziehen Anfragen mit den vorgeschlagenen Verfeinerungen / Ergänzungen sind willkommen.

Was ich habe es zur Zeit ist dies:

  

Der Kern Grund, Ihre HTML-Dokumente über eine Konformität laufen   Checker ist einfach: Um könnten Sie unbeabsichtigte Fehler-Fehler zu fangen   haben sonst verpasst-so, dass man sie beheben können.

     

Darüber hinaus werden einige Dokument-Konformitätsanforderungen (Gültigkeitsregeln)   in der HTML-Spezifikation sind für Sie da und die Benutzer Ihrer Dokumente helfen   vermeiden bestimmte Arten von möglichen Problemen. Um zu erklären, die Gründe   hinter diesen Anforderungen enthält die HTML-Spezifikation diese beiden Abschnitte:

           

Um zusammenzufassen, was in diesen beiden Abschnitten angegeben ist:

     
      
  • Es gibt einige Markup-Fälle als Fehler definiert, weil sie   potenzielle Probleme für die Zugänglichkeit, Nutzbarkeit, Interoperabilität,   Sicherheit oder Wartbarkeit-oder weil sie in einem schlechten führen   Leistung oder das könnte Ihre Skripte verursacht in einer Weise scheitern, das   schwer zu beheben.
    •   
  • Zusammen mit denen, einige Markup Fälle definiert   als Fehler, weil sie verursachen können Sie in potenzielle Probleme laufen in   HTML-Analyse und Fehlerbehandlung verhaltens so dass, sagen wir, würden Sie am Ende   mit einiger unintuitive, unerwarteten Ergebnis im DOM.
    •   
     

Überprüfen Sie Ihre Dokumente warnt vor dieser potenziellen Probleme.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top