Warum valides HTML?
Nach obenDer Validiator.
Ich gehe mal davon aus, dass Webmaster bei der Seitenerstellung darauf achten, fehlerfrei zu arbeiten. Dazu gehört aber nicht nur gute Benutzbarkeit, ansprechendes Design und interessanter Inhalt, sondern auch korrekter HTML Code.
Man hört immer wieder von Webdesignern oder solchen, die es werden wollen, den Satz: "Hauptsache es läuft in Mozilla, Opera und dem Internetexplorer, also den drei 'grössten' Browsern - wenn's da läuft, ist es in Ordnung und mein HTML ohne Fehler"; - dem ist leider nicht so. Als fehlerfrei kann man nämlich sein HTML erst dann betrachten, wenn es ohne Ausnahme dem HTML- Standard genügt. Dies kann man mit einem Validator, also einem Prüfprogramm, das die HTML-Syntax überprüft, leicht feststellen; also ist der Quellcode einer Seite erst dann in Ordnung, wenn keine Fehlermeldungen vorliegen.
Nach obenWas bedeutet valides HTML?
Valides HTML ist von einem Validator als fehlerfrei bestätigtes Markup. Für die Identifikation von Fehlern, wie z.B. unzulässige HTML - Tags und Attribute, sowie falsche Verschachtelung der Tags wird eine DTD (Dokumententyp-Definition) genutzt. Welche DTD für das jeweilige HTML Dokument verwendet wird, steht in der ersten Zeile des HTML Codes, die Dokumententyp-Deklaration, in welcher die Elemente und Attribute, aber auch Sonderzeichenkodierungen festgelegt werden.
Nach obenFür nicht-valides Markup keine Garantie.
Bei der Darstellung von fehlerhaftem Markup, werden Browser dazu gezwungen zu raten was richtig ist und was nicht. Dies kann teilweise zu starken Unterschieden bei der Seitendarstellung durch unterschiedliche Browser führen, da jeder Browser mit Fehlern unterschiedlich umgeht. Das Testen in vielen Browsern ist zwar immer ratsam, aber die Gewährleistung einer richtigen Darstellung kann auch so nicht gegeben sein, da es einfach zu viele Browser gibt.
Nach obenValides XHTML und WYSIWYG-Editoren.
Nutzer von so genannten WYSIWYG - Editoren müssen oft fehlerhaftes Markup ihrer Programme nachträglich manuell korrigieren.
Kaum eines dieser Programme ist in der Lage, valides (X)HTML zu generieren. Am schlimmsten sieht es meiner Meinung nach mit Frontpage von Microsoft aus. Mit Dreamweaver MX funktioniert das mittlerweile eigentlich ganz gut, aber es ist ratsam, zu Texteditoren zu wechseln,
da man dadurch automatisch seine Fähigkeiten verbessert und ein besseres Verständnis für die Materie bekommt.
Nicht-valides XHTML: Fehlermeldung statt Seitenanzeige
Da XHTML auf XML basiert, einer Auszeichnungssprache, die keine Fehler zulässt, gelten entsprechend auch die Regeln für XML bei der Verarbeitung von XHTML. Da ältere Browser nur unzureichend oder gar nicht mit XML umgehen können, speichert man XHTML-Dokumente, um nicht browserinkompatibel zu werden, als HTML ab. Wenn man nicht valide XHTML-Dokumente, die auch als solche abgespeichert worden sind (.xhtml), mit einem XML-fähigem Browser aufrufen würde, würde einfach eine Fehlermeldung statt der Seite erscheinen.
Hinweis: Wenn Sie eine Seite verfassen, schreiben Sie von Anfang an valides XHTML. Schreiben Sie nur solchen Code, wie er in der XHTML oder HTML 4.01 Spezifikationen festgelegt ist. Damit kann man sich schließlich eine Menge Korrekturarbeit ersparen, die auftritt, wenn man seine Seite nachträglich noch für andere Browser akzeptabel darstellen lassen möchte.
Nach obenFast alles ist möglich.
Leider hört man auch noch sehr oft, dass das ein oder andere Designmerkmal, mit validem HTML nicht zu erreichen wäre; zum Beispiel, über das Target-Attribut target="_blank" Seiten in einem neuem Fenster zu öffnen, was ab XHTML nur noch in der Transitional-Variante erlaubt und in Zukunft kein Standard mehr ist. Auch die CSS-Formatierung zu gefärbten Scrollbalken ist nicht valide. Hier wird empfolen, da es sich um browserspezifisches CSS für Benutzer des Internet Explorers handelt, diese Angaben mit Conditional Comments zu machen. Erstens, sollte der Besucher ihrer Seite selbst entscheiden können, ob er Links in einem neuen Fenster aufmacht oder auch nicht; zweitens sind Features, die nur in einem Browser dargestellt werden können, schlecht zu gebrauchen. Man kann einfach solche Argumente nicht mehr gelten lassen, da man mit CSS und seit HTML 4.0 so gut wie alles erreichen kann.
Wichtig ist auch den geeigneten Dokumententyp für sich zu finden. Wer beispielsweise XHTML 1.0 Strict "programmiert" und seine Links dennoch in einem neuem Fenster aufgehen lassen möchte, sollte einfach die Transitional Variante auswählen. Wer mehr benötigt, zum Beispiel seine Scrollbalken einfärbt, geht bewusst das Risiko ein, browserinkompatibel zu werden.
LeijiONE
aber es ist doch möglich durch anwendung des *html hacks im css die browser (in diesem falle IE) separat anzusprechen und anzusteuern.
damit ist dann das file streng genommen nicht mehr valide, aber praktisch doch fehlerfrei...
oder sollte man da viel mehr angst vor der zukunft haben und etwaige umstellungen der browsertypen in sachen fehlerhafter css implementierung vorhersehen und beachten?
andig
Die Aussage, dass ein User ja selber entscheiden will, ob sich eine Seite nun in neuem Fenster öffnet oder nicht, hab ich schon immer als undurchdacht empfunden. Zum Einen sollte man dem Browser mitteilen können, dass er solche Attribute (bzw. Verhaltensweisen) ignorieren soll, wenn man es wünscht (wie man ihm ja auch eigene bevorzugte stylesheets mitteilen kann), zum anderen wird es (wahrscheinlich) in CSS3 eine Möglichkeit geben eine Verhaltensweise hinzuzufügen, damit eine Seite sich zB in einem neuen Tab öffnet. Der vermutlich wahre Grund, warum "target" nun aus dem XHTML-Standard langsam verschwindet, ist dass die W3C Jungs die Meinung vertreten, dass ein XHTML-Dokument nur Informationen bzw. Daten (natürlich logisch strukturiert) bereitstellen soll und sowohl die visuelle Ausgabe, als auch das Verhalten dieses Dokuments in eine CSS-Datei gehört.
Nel
Oh mein Gott, meine Website ist nicht valide:
[Quote]
<td><a href='index.php?lang=de&site=home' >Startseite</a></td><td><a href='i
✉
An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs".
Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive; &Aelig; and æ are different characters.
If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.
Note that in most documents, errors related to entity references will trigger up to 5 separate messages from the Validator. Usually these will all disappear when the original problem is fixed.
[/Quote]
Wie kann ich das umgehen ausser per ModRewrite? Liebe Grüße...
antwort
@Nel,
das kannst du umgehen, indem du im Link das & nicht ausschreibst, sondern "&" benutzt.