W3C Valider xHTML und CSS Code

Valider Code ist wichtig, um für Seitenbesucher eine einwandfreie Darstellung zu garantieren. Daher ist es sinnvoll, sich bei der Gestaltung möglichst an die Vorgaben der Standardsetter zu halten. Auch Suchmaschinen legen Wert auf validen Code.

Die strikten Programmier-Richtlinien des xHTML 1.1 Standards (xHTML 1.0 Strict ist ähnlich) sind ziemlich aufwendig umzusetzen. Das habe ich bei den jüngsten Anpassungen des Designs und der Plugins meines Blogs gemerkt. Falsche oder ungültige Attribute, Fehler in den URLs und ungültige oder ehemals gültige HTML Tags sind häufige Ursachen dafür, dass der Code nicht validiert wird.
Meine Vorgehensweise beim Validieren bestand darin, die Fehler schrittweise und systematisch zu eliminieren, wobei nach jedem behobenem Fehler erneut überpüft wurde.

Im CSS Code sind häufig Fehler bezüglich ungültiger  Eigenschaften zu finden: bei Fehlern ist meist entweder die Eigenschaft nicht CSS 2.1 konform, oder es liegt nur eine Kompatibilität zu bestimmten Browsern z.B. bei moz-opacity für Firefox vor.

Für mich neu war, dass das <iframe>-Tag ab xHTML 1.0 Strict nicht mehr unterstützt wird. Stattdessen nimmt nun das <object>-Tag im weitesten Sinne seinen Platz ein. Was allerdings auch ein interessanter Fehler im xHTML Code war, ist, wenn in URLs fälschlicherweise das „kaufmännische Und“ ( & ) verwendet wird. Stattdessen sollte das „&“ durch das HTML-Entity &amp; ausgedrückt werden.

Im Anwendungsbeispiel sieht das konkret so aus:

aus:

http://blog.omaximus.de/?p=655 & preview=true

wird:

http://blog.omaximus.de/?p=655& a m p ;preview=true

 

Naja, das Resultat hat sich wenigstens gelohnt. Mein CSS und xHTML Code ist nun vollständig valide. Das sichert die Qualität meiner Website durch seine Zukunftssicherheit und Kompatibilität zu allen Browsern … mein RSS-Feed ist übrigens auch valide.

Zum xHTML-Validator: *W3C (x)HTML Validator*
Zum CSS-Validator: *W3C Jigsaw CSS Validator*
Zum RSS-Validator: *W3C Feed Validator*

10 Gedanken zu „W3C Valider xHTML und CSS Code“

  1. Dazu habe ich eine Frage: Welche Vorteile bringt es, mit einer normalen Webseite auf die strenge strict Variante zu gehen? Ich meine, bei frühen Browserversionen war die Ausgabe der Seite hinüber, wenn man vergessen hat, einen div Tag zu schließen. Die modernen Browser verzeihen aber viele Fehler, was jetzt kein Apell für schlampig zusammengesetzte Seiten sein soll. Aber eine erfolgreiche Validierung für die transitional Variante müsste doch bereits die sichere Seite bedeuten?

  2. Sicherlich ist man mit einer W3C-konformen XHTML 1.0 Transitional Webseite auf der sicheren Seite, gar keine Frage.

    XTHML 1.0 Strict bzw. XHTML 1.1 ist natürlich aufgrund seiner Zukunfstsicherheit – hinsichtlich kommenden Standards und Supports – , plattformunabhängiger Kompatibilität (wobei das i.d.R. auch bei 1.0 gegeben ist), einfacher Handhabung durch klar definiertes und striktes Regelwerk (wenn man mal von seiner Vorbelastung des Regelwerks durch den „alten“ HTML 4 Standard absieht), multimedialer Integration durch das nun vollständig unterstützte -Tag und zu guter letzt noch besser gewährleisteter Barrierefreiheit bei Möglichkeit vorzuziehen. Insbesondere die Zukunftssicherheit dürfte hier wohl das ausschlaggebende Argument sein.

  3. Warum kann man sich nicht einfach auf ein Standard einigen. Warum muss es immer solche Geschichten geben, die das Leben des Webmaster nur schwerer machen. Verstehe ich nicht

  4. Hallo,
    ich denke es ist an der Zeit für eine komplett neue Art von Programmierrichtlinie.
    W3C & Co. sind offensichtlich veraltet und nicht mehr up-to-date.
    Meiner Meinung nach wäre eine Richtlinie angebracht, die die neuen XHTML-Standards mit dem neuen Sinneswandel im Web 2.0 miteinander kombiniert.

    Ich lasse mich aber auch gerne eines Besseren belehren und bin gespannt auf eure Vorschläge.

  5. Die Frage ist nur wer soll diesen Standart festlegen. Nimmt man alle Parteien die etwa zu sagen haben mit rein gibt es chaos. Bleiben welche draussen bauen diese ihr eigenes Dingen. Ich denke wir müssen noch einige Jahre mit diesem Codehickhack leben

  6. Scheint als wäre ich dieser Tage nicht allein mit dem Optimieren des Quelltextes beschäftigt gewesen. Die moz- Attribute haben mir auch Kopfzerbrechen bereitet und sind auch weiterhin so hinterlegt. So kommt es dann auch, dass der Blog beim Prüfen circa 300 CSS Fehler aufweist. Aber wenigstens konnte ich den Fehlerquote des HTML-Codes um 90% reduzieren. Besonders unschön ist es, wenn WordPress-Plugins (BlackbirdPie zum Einbinden von Twitter-Stati, AppStore Links, etc.) diese Fehler produzieren und man mit jedem Update wieder Hand anlegen darf.

  7. Um auch iframes in xhtml strict zu validieren kann man ein wenig javascript benutzen. (manchmal geht es halt nicht anders, z.B. wenn man keinen Einfluss auf den Junk Code hat)
    included das mootools oder anderes framework

    1. Werbe/junk html in eine Datei auslagern etwa junk.html
    2. einen bereich in der Seite definieren etwa

    3. dann ein zweizeiler JS code
    window.addEvent('domready',function(){
    $('junk1').load('junk.html')
    })

    4. sehen das die seite validiert

  8. Man muß für sich immer einen vernünftigen Mittelweg finden zwischen „valide“ und „schönen Aussehen“. Sicher ist das moz-Attribut noch nicht valide und wird angemeckert, aber dafür sind die Effekte sehenswert. Und mit HTML5 und CSS3 ist man auf der Autobahn Richtung Zukunft.

    Gruß
    Klaus

  9. Super das nun deine Seite keine Fehler mehr hat. Es ist wirklich viel arbeit bis man alle Fehler behoben hat. Ich muss nachher auch noch ein Projekt anpassen.

    Gruß Marc

Kommentar verfassen