|
|||
[XHTML] HTML Kompatibilitätsrichtlinen 2.0a1
Ich wurde ja vor einiger Zeit mal danach gefragt.
Dieser Artikel, oder wie man es bezeihnen will ist ein erster Entwurf, das bedeutet er ist vollständig, Inhalte können sich aber wie immer ändern. Daher bitte ich um Kritik und Anregungen. Danke. Hinweis: Auf Grund der Zeichenbeschränkung sind vier Beiträge nötig, um diesen Beitrag vollständig wiederzugeben (Ich hoffe die Forensoftware macht da keine Probleme..). HTML Kompatibilitätsrichtlinien 2.0a1 Arbeitsentwurf vom 16. November 2007 Übersicht
Hintergrund Als Anfang 2000 die erste XHTML-Spezifikation veröffentlich wurde, gab es kaum Browser die XHTML tatsächlich als solches verarbeiten konnten. Genauer gesagt war den Browsern der XHTML-Medientyp „application/xhtml+xml“ unbekannt. Webautoren waren jedoch neugierig und wollten das „neue“ HTML ausprobieren. Aus diesem Grund enthält die Spezifikation der XHTML-Version 1.0 einen informativen Anhang. Dieser gibt Hinweise, wie XHTML-Quelltext beschaffen sein muss, damit dieser auch von HTML-Browsern verarbeitet werden kann. Damit dies möglich wird, wurde es Dokumenten der XHTML-Version 1.0 (und nur dieser) erlaubt, mit dem HTML-Medientyp „text/html“ versendet zu werden. Dieser Anhang war nötig, da XHTML auch ein bisschen „Ballast“ von XML mitgenommen hat. Darüberhinaus kann Quelltext in HTML eine andere Bedeutung haben als in XHTML. Wie bereits angesprochen wurden diese Regeln im Jahr 2000 verfasst. Ende 2002 wurde die XHTML-1.0-Spezifikation, und damit diese Richtlinien, leicht überarbeitet. Dennoch sind diese Hinweise aus heutiger Sicht veraltet, teilweise falsch und vor allem lückenhaft, denn viele problematischen Punkte werden gar nicht erwähnt. Ist es ein (X)HTML-Dokument? Damit man mit den Kompatibilitätsrichtlinien vernünftig arbeiten kann, ist es notwendig zu verstehen, ob es sich bei einem Dokument um ein HTML- oder ein XHTML-Dokument handelt. Dies wird durch den Medientyp des Dokuments bestimmt, denn daran erkennt der Browser, wie er das Dokument verarbeiten muss. HTML-Dokumente sind untrennbar mit dem Medientyp „text/html“ verbunden. Ein XHTML-Dokument dagegen sollte als Medientyp „application/xhtml+xml“ besitzen, kann aber auch als „application/xml“ versendet werden. Früher war auch „text/xml“ möglich, gilt heute aber als veraltet. Trotz dieser Definition kommt es oft zu Verständnisproblemen. Vielen Autoren ist nicht klar, dass XHTML-Quelltext, der als „text/html“ versendet wird, als HTML verarbeitet wird und daher ein HTML-Dokument ist. Wir merken uns folgendes:
Richtlinien zur HTML-Kompatibilität Dieser Abschnitt führt die Richlinen auf, die beachtet werden müssen, wenn XHTML-Quelltext als HTML verarbeitet werden soll. Zudem wird gezeigt, woher diese Verarbeitungsunterschiede kommen, damit diese besser verstanden werden können. Achtung: Einige dieser Unterschiede, vor allem im Bereich der Verarbeitung von Stilangaben und Skripten, werden browserweit sehr unterschiedlich interpretiert. Oftmals werden Regeln nicht ausgeführt oder gar gebrochen. Nur die in Diesem Dokument enthaltene Definition ist in diesen Fällen gültig. 1. Angabe der verwendeten Zeichenkodierung Diese Richtlinie muss befolgt werden. Die Zeichenkodierung, die das Dokument verwendet, muss so angegeben sein, dass diese sowohl von HTML- als auch von XML-Parsern erkannt werden kann. Begründung Dokumente, die keine Informationen über den Zeichensatz enthalten, mit dem sie kodiert wurden, müssen mit der Standardzeichenkodierung verarbeitet werden. Zitat:
Zitat:
Vorgehensweise Die verwendete Zeichenkoderung kann innerhalb eines HTML-Dokuments sehr einfach festgelegt werden. Dazu ist es notwendig ein meta-Element mit diesen Informationen als erstes Kind des head-Elements zu erzeugen. Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <!-- weiterer Quelltext --> In der Angabe muss der Medientyp „text/html“ angegeben werden. Einerseits, weil das der Wahrheit entspricht, andererseits weil nicht jedes Benutzerprogramm aus einer Metaangabe mit „application/xhtml+xml“ die Zeichenkodierung herauslesen kann. Wird als Zeichenkodierung UTF-8 oder UTF-16 verwendet ist diese Angabe die einzig notwendige. Wird eine andere Zeichenkodierung verwendet, muss diese für XML-Parser angegeben werden. Code:
<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> <!-- weiterer Quelltext --> Hinweis: XML-Parser können zusätzlich auch eine Byte-Order-Mark verarbeiten. Da diese aber vor allem bei der Arbeit mit serverseitigen Werkzeugen Probleme verursachen kann, sollte keine Byte-Order-Mark gesetzt werden. Problemfall: Internet Explorer 6 Aus dieser Richtlinie ergibt sich ein Problem im Zusammenspiel mit dem Internet Explorer. Da der Version 6 die XML-Deklaration unbekannt ist, wird der IE 6 in den Quirksmodus versetzt. Das bedeutet die Darstellung entspricht dem IE 5.5 und all dessen Fehlern wie beispielsweise das falsch berechnete Boxenmodell. Wird also eine andere Zeichenkodierung als UTF-8 oder UTF-16 verwendet, kann keine browserweit ähnliche Darstellung erreicht werden. Da der Internet Explorer 6 noch über ein Drittel des Marktes beherrscht ist eine abweichende Zeichenkodierung (oder alternativ: XHTML selbst) keine Option. |
Sponsored Links |
|
|||
2. Verarbeitungsanweisungen
Diese Richtlinie muss befolgt werden. Ein Dokument darf keine Verarbeitungsanweisungen (Processing Instructions) enthalten. Beispiel: Eine Verarbeitungsanweisung, die eine Stildatei referenziert. Code:
<?xml-stylesheet href="./stilangaben.css" type="text/css" ?> Verarbeitungsanweisungen versetzen den Internet Explorer bis Version 7 in den Quirksmodus, d.h. eine browserweit ähnliche Darstellung wird unmölich. Unabhängig davon können können Verarbeitungsanweisungen, wie andere XML-Features, von HTML-Parsern nicht verarbeitet werden (meist werden sie ignoriert). 3. Angabe der Elementsprache Diese Richtlinie muss befolgt werden. Wird die Elementsprache definiert, muss diese Information für HTML- und XML-Parser verfügbar und identisch sein. Begründung Die Sprache eines HTML-Elements wird mit dem lang-Attribut definiert. Wird das Dokument von einem HTML-Parser verarbeitet ist dieses Attribut ausschlaggebend. Die Elementsprache in XHTML-Dokumenten wird mit dem xml:lang-Attribut definiert. Bei der Verarbeitung mit einem XML-Parser wird nur dieses Attribut beachtet. Beide Attribute müssen den selben Wert enthalten. Beispielsweise ein Absatz: Code:
<p lang="de" xml:lang="de">Deutscher Text</p> Zitat:
Code:
<p lang="de" xml:lang="de">Deutscher und <em>betonter</em> Text.</p> Wird ein Dokument als HTML verarbeitet trifft die :lang-Pseudoklasse auf das lang-Attribut zu, anderfalls auf das xml:lang-Attribut. Der Attributselektor [lang=de] würde nur das p-Element formatieren. Außerdem würde ein Attributselektor unabhängig von der Verarbeitung des Dokuments zwischen dem lang- und dem xml:lang-Attribut unterscheiden. Zu beachten ist jedoch, dass das xml:lang-Attribut einerseits in HTML unbekannt ist, andererseits vom Internet Explorer bis Version 7 nicht erkannt wird. Das ist aber kein Problem, da das lang-Attribut beiden Sprachen und dem Internet Explorer bekannt ist. 4. Auslagerung von Stil- und Skriptdaten Diese Richtlinie muss befolgt werden. Stilangaben und Skripte (z.B. Javascript) müssen in externen Dateien gelagert werden. Begründung Für HTML-Dokumente ist es unproblematisch, Stilangaben und Skripte innerhalb des Dokuments in style- bzw. script-Elemente zu verpacken. Lediglich XHTML-Dokumente haben hier Probleme. In XHTML wurde das Inhaltsmodell der style- und script-Elemente verändert, so dass Sonderzeichen wie < und & dort eine andere Bedeutung besitzen als in HTML. Würden diese Zeichen verwendet werden, könnte das Dokument nicht angezeigt werden, da die Sonderzeichen laut XML-Regeln „falsch“ eingesetzt wären. Die aus früheren Zeiten bekannte (und heute überflüssige) Methode, problematischen Inhalt dieser Elemente durch Kommentare zu verstecken, ist in XHTML-Dokumenten nicht möglich, da ein XML-Parser den Kommetarinhalt löschen würde, bevor dieser berücksichtigt wird. XML bietet für dieses Problem eine Lösung, diese kann aber von HTML-Parsern nicht verarbeitet werden und führt daher wiederum zu Fehlern. Problemlösung: Guten Stil bewahren Die Lösung für dieses Problem ist sehr simpel und ist für gute Webautoren längst selbstverständlich, denn Inhalt, Design und Verhalten eines Dokuments sollten stets voneinander getrennt werden. Folgt man diesem Grundsatz, ist eine fehlerfreie Verarbeitung des Dokuments möglich. Stilangaben und Skripte können sehr einfach im Kopf eines Dokuments eingefügt werden, ohne Probleme zu verursachen: Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <link rel="stylesheet" type="text/css" media="screen" href="stilangaben.css" /> <style type="text/css">@import './stilangaben.css' projection;</style> <script type="text/javascript" src="./script.js"></script> <!-- weiterer Quelltext --> Diese Richtlinie muss befolgt werden. Elemente mit leerem Inhaltsmodell (area-, base-, basefont-, br-, col-, frame-, hr-, img-, input-, isindex-, link-, meta- und param-Elemente) müssen selbstschließend geschrieben werden. Begründung Die genannten Elemente dürfen in HTML nur als Start-Tag vorkommen. In XHTML ist eine derartige Definition der Elemente nicht möglich, daher müssen diese Elemente selbstschließend (z.B. <hr/>) oder in einer Start- und End-Tag-Kombination geschrieben werden (z.B. <hr></hr>). Die Start- und End-Tag-Kombination wird jedoch von HTML-Parsern unterschiedlich interpretiert und führt bei verschiedenen Elementen zu unerwarteten Ergebnissen. Daher hat sich die selbstschließende Schreibweise durchgesetzt. Bei der selbstschließenden Schreibweise sollte man darauf achten, vor den Solidus ein Leerzeichen einzufügen (z.B. <hr />), da die Schreibweise <hr/> in standardkonformen HTML-Parsern <hr>> entspricht (dies wird aber vom Großteil der HTML-Parser ebenfalls ignoriert). 6. Inhaltslose Elemente ohne leerem Inhaltsmodell Diese Richtlinie muss befolgt werden. Elemente, deren Inhaltsmodell nicht leer ist (Elemente mit leerem Inhaltsmodell wurden in Richtlinie 5 besprochen), aber keinen Inhalt besitzen (z.B. <script></script> oder <div></div>), dürfen nicht in der selbstschließenden Schreibweise geschrieben werden. Begründung In HTML gibt es keine selbstschließenden Elemente, die Schreibweise <div/> wäre also fehlerhaft. Bei Elementen ohne leerem Inhaltsmodell kann der Parser diesen Fehler aber nicht einfach ignorieren. Stattdessen werden diese Elemente als Start-Tag interpretiert, d.h. <div/> entspricht <div>. Wird beim parsen des Dokuments kein passendes End-Tag gefunden wird dieses vor Beginn des body-End-Tags eingefügt. In Kombination mit Stilangaben oder Skripten durchaus eine zerstörerische Kraft. Bei script-Elementen ist es ähnlich, denn wird <script/> als Start-Tag interpretiert kann ein Teil des folgenden Quelltextes als Skript verarbeitet werden und für den Betrachter des Dokuments unsichtbar. 7. Maskierung von (Markup-)Sonderzeichen Diese Richtlinie muss, muss und sollte befolgt werden. Die Markup-spezifischen Sonderzeichen < (kleiner als), > (größer als), & (kaufmännisches Und) sowie " (das Zollzeichen bzw.) müssen maskiert werden (<, >, & und " respektive). Das Sonderzeichen ' (Apostroph) darf nicht durch ' maskiert werden. Es kann durch die numerische (& #39;) bzw. hexadezimale Schreibweise (') maskiert werden. Andere Sonderzeichen wie die deutschen Umlaute sollten nicht maskiert werden, stattdessen sollte ein entsprechender Zeichensatz für das Dokument gewählt werden. Begründung Das kleiner-als-Zeichen leitet ein Element bzw. eine Auszeichnung ein, würde es in einem Text vorkommen, z.B. als 2<3 würde ein XML-Parser auf ein unbekanntes bzw. fehlerhaftes Element treffen und einen Fehler verursachen. Das kaufmännische Und leitet in den Auszeichnungssprachen eine Entität ein, d.h. die Maskierung eines Sonderzeichens. Unmaskiert wird der darauf folgende Text selbst als Maskierung misverstanden. Für einen XML-Parser grund genug das Parsen abzubrechen und eine Fehler auszuwerfen. Das größer-als-Zeichen, das Zollzeichen und der Apostroph verursachen in der Regel keine Fehler. Zollzeichen und Apostroph können Attributwerte umschließen und müssen daher maskiert werden, wenn sie selbst innerhalb von Attributwerten vorkommen. Die Maskierung ' für den Apostroph wurde in XML eingeführt, ist HTML-Parsern jedoch unbekannt. Daher muss die numerische bzw. hexadezimale Schreibweise verwendet werden. Andere Sonderzeichen wie die deutschen Umlaute und Satzzeichen sollten nicht maskiert sondern ein entsprechender Zeichensatz (idealerweise UTF-8) verwendet werden. Einige XML-Werkzeuge prüfen das Dokument nicht auf Gültigkeit nach den Regeln der DTD (der Dokumenttypdefinition), daher sind ihnen die darin definierten Entitäten unbekannt. Das gilt auch für alle HTML-Maskierungen. Stößt ein XML-Werkzeug nun auf eine dieser Maskierungen stellt dieses ein unbekanntes Objekt dar und es wird ein Fehler verursacht, das Dokument kann nicht weiter verarbeitet werden. 8. Fehlende Attribute in XHTML Diese Richtlinie muss befolgt werden. In der Variante Strict darf das form-Element kein name-Attribut besitzen. In keiner Variante darf das input-Element das ismap-Attribut besitzen. Begründung In den XHTML-DTDs sind diese Attribute nicht definiert, sie können daher in einem XHTML-Dokument nicht verwendet werden. 9. Zeilenumbrüche in Attributen Diese Richtlinie muss befolgt werden. Innerhalb von Attributen müssen Zeilenumbrüche vermieden werden. Begründung Attributwerte, die Zeilenumbrüche enthalten werden von den Benutzerprogrammen unterschiedlich interpretiert, daher müssen sie vermieden werden. |
Sponsored Links |
|
||||||
10. Nur in XML erlaubte Zeichen verwenden
Diese Richtlinie muss befolgt werden. Das Dokument darf nur aus Zeichen bestehen, die in einem XML-1.0-Dokument ebenfalls erlaubt sind. Begründung Zeichen, die in einem XML-Dokument der Version 1.0 (dazu gehören alle XHTML-Dokumente) nicht erlaubt sind, dürfn nicht verwendet werden, da ein XML-Parser sonst einen Fehler wirft. Beispiel: In HTML wird das Zeichen U+000C () wie ein Leerzeichen behandelt. In XML ist es verboten. 11. Das tbody-Element Diese Richtlinie muss befolgt werden. Tabellen (table-Elemente) dürfen keine tr-Elemente als Kindelemente besitzen. tr-Elemente dürfen nur Kinder von thead-, tfoot- und tbody-Elementen sein. Begründung In HTML können einige Elemente im Quelltext weg gelassen werden. Sie werden dann nachträglich vom Parser eingefügt. Das gilt z.B. für das html-, body- und tbody-Element. In XHTML (genauer: XML) kann diese Eigenschaft eines Elements nicht ausgedrückt werden, daher ist das html- und das body-Element in XHTML Pflicht. Das tbody-Element jedoch nicht. Dieser Unterschied ergibt sich nicht direkt aus der Spezifikation, sondern aus den Dokumenttypdefinitionen (DTDs): Zitat:
Zitat:
In HTML kann ein table-Element keine tr-Elemente als Kind besitzen, dafür ist das tbody-Element pflicht. Das tbody-Element ist jedoch so definiert, dass der Autor es nicht in den Quelltext schreiben muss, der HTML-Parser fügt das Element selbstständig ein. Da diese Eigenschaft XML-Elementen unbekannt ist wurde die Definition des table-Elements in XHTML leicht verändert: Es kann entweder thead-, tfoot- und tbody-Elemente als Kind haben - dann müssen diese auch in den Quelltext geschrieben werden - oder tr-Elemente. 12. Die Interpretation von Stilangaben Diese Richtlinie muss befolgt werden. Stilregeln müssen so definiert werden, dass sie bei der Verarbeitung eines Dokuments als HTML bzw. XML eine identisch Ausgabe erzeugen. Begründung Für HTML gibt es eine Reihe von Sonderregelungen, die bei der Interpretation von Stilangaben beachtet werden müssen. In XHTML-Dokumenten werden diese Sonderregelungen jedoch nicht berücksichtigt. Zitat:
Die Spezifikation von CSS 2.1 ist zwar schon recht ausgereift, aber noch immer in Bearbeitung. Daher könnten diese Sonderregelungen in Zukunft auch wegfallen. Im einzelnen sind folgende Bereiche betroffen: 12.1 Hintergrundfarbe und -Bild des Anzeigebereichs Zitat:
12.2 Die overflow-Eigenschaft des Anzeigebereichs Zitat:
12.3 Groß- und Kleinschreibung Wird ein Dokument als XML verarbeitet spielt die Groß- und Kleinschreibung eine wichtige Rolle. Die trifft auch auf Stilangaben zu. Element- und Attributnamen müssen kleingeschrieben werden. 13. Die Verabeitung von Skripten Diese Richtlinie muss befolgt werden. Die write()- bzw. writeln()-Methoden in JavaScript dürfen nicht verwendet werden. Wird mit Methoden des DOM gearbeitet müssen die Namensraum-fähigen Methoden des Level-2-DOMs verwendet werden. Die Begründung folgt in den Unterpunkten. 13.1 document.write() Die JavaScript-Funktionen write() und writeln() können in XHTML nicht verwendet werden, da es durch die Definition von XML Skripten verboten ist, während des Parsevorgangs beliebigen neuen Text in das Dokument einzufügen. 13.2 Verwendung von DOM-Level-2-Methoden Alle XHTML-Elemente und -Attribute befinden sich im XHTML-Namensraum (http://www.w3.org/1999/xhtml). Soll in das Dokument dynamisch ein neues Element eingefügt werden, so muss das einzufügende Element (das gilt auch für Attribute) dem XHTML-Namensraum angehören. Dies ist nur mit den Methoden des DOM-Level-2-Kerns möglich. Zitat:
Stattdessen muss man die Namensraum-fähigen Level-2-Methoden verwenden. Diese haben den selben Namen, nur mit „NS“ als Suffix. Code:
NeuesElement = document.createElementNS('http://www.w3.org/1999/xhtml','p'); Elemente aus dem XHTML-Namensraum werden von üblichen HTML-Parsern als identische HTML-Elemente erkannt. Der tatsächliche HTML-Namensraum wäre aber „null“, da HTML selbst über keinen Namensraum verfügt. |
|
|||
Weitere Informationen
Die folgenden Informationen sind zwar sehr wichtig, haben aber nicht die nötige Relevanz für eine Richtlinie. 1. Das isindex-Element Das isindex-Element ist veraltet und daher nur in den Varianten Transitional und Frameset erlaubt. Es soll durch das input-Element ersetzt werden, da isindex keine brauchbaren Informationen liefert und nicht browserweit implementiert ist. Als HTML verarbeitete Dokumente zeigen durch dieses Element ein Eingabefeld für Suchanfragen an. Als XML verarbeitet, wird die Anzeige des Dokuments nicht beeinflusst. Als Richtlinie wäre dieses Element verboten. 2. Boolische Attribute In HTML gibt es so genannte boolische Attribute. Das sind Attribute wie compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize und defer, denen kein Wert zugewiesen wird. In XHTML muss diesen Attributen ihr Name als Wert zugewiesen werden. Es soll Parser geben, die diese Schreibweise nicht verstehen. Das ist jedoch ein Fehler des Parsers, denn die ausgeschriebene Schreibweise entspricht gültigem HTML. 3. Definition und Ansteuerung von Sprungzielen Für XHTML ist definiert, was tatsächlich schon für HTML definiert war. Ein Sprungziel wird definiert, indem man einem beliebigen Element eine ID gibt. Als Vereis zu diesem Sprungziel wird die ID mir vorangestelltem Gatterzeichen (#) referenziert. Code:
<a href="#IDReferenz">Sprungziel ansteuern.</a> <!-- Quelltext dazwischen --> <p id="IDReferenz">Sprunziel definieren.</p> XHTML 1.1 ist inkompatibel zu XHTML 1.0, denn der Wert des usemap-Attributs der img-, input- und object-Elemente muss in den beiden Versionen unterschiedlich Angegeben werden. In XHTML 1.0 (identisch zu HTML 4.01) muss der Wert eine Hypertext-Referenz sein (identisch zum Ansteuern von Sprunfzielen) z.B. „#map“. Ab XHTML 1.1 muss der Wert eine ID referenzieren und darf nur diese referenzierte ID als Wert enthalten, z.B. „map“. Das ist einerseits Problematisch, weil die Darstellungsprogramme dieses Verhalten kaum implementiert haben. Zum anderen wird dadurch unklar, wie sich ein XML-Werkzeug verhalten soll, das den XHTML-Namensraum implementiert hat, aber nur ein XHTML-Fragment parst. XHTML 1.1 basiert offiziell nicht auf dem Sprachschatz von HTML 4.01, daher ist das versenden von XHTML-1.1-Dokumenten als „text/html“ verboten. 5. Zukunftsfähigkeit von XHTML XHTML 2.0 befindet sich seit Jahren im Entwurfsstadium und plant große Veränderungen im Vergleich zur Vorgängerversion. So werden beispielsweise Formulare durch die XML-Technik XForms ersetzt, p-Elemente sollen Blockelemente enthalten können und nahezu jedes Element wird als Verweis bzw. Bildalternative eingsetzt werden können. Das hört sich alles sehr gut an, und tatsächlich bietet XHTML 2.0 einige Vortschritte, doch gibt es mehr als einen Wermutstropfen. Aktuell möchte die XHTML-2.0-Arbeitsgruppe den XHTML 1.x-Namensraum übernehmen. Dies hätte fatale Auswirkungen: Dokumente, die nach den Regeln von XHTML 1.x verfasst wurden könnten so übernacht ungültig werden. Hier tritt erneut das Problem der Verarbeitung auf: Wie soll ein XML-Werkzeug wissen, welche Elementdefinition, wenn es nur ein XHTML-Fragment verarbeitet? Unabhängig davon haben Browserentwickler bereits kommentiert, dass die Ausweitung der Verweis- und Alternativtechnik für Bilder einen nicht verantwortbaren Aufwand bei der Implementierung darstellen würde. 6. Ausblick auf XHTML5 Auch auf Grund der Problematik von XHTML 2.0 haben sich seit Mitte 2004 die Browserhersteller Mozilla, Opera und Apple zu der WHATWG zusammengeschlossen. Diese Arbeitsgruppe hat sich zum Ziel gesetzt HTML weiterzuentwickeln. Der Arbeitsentwurf, Web Applications 1.0 wurde Anfang 2007 von der HTML-Arbeitsgruppe beim W3C zur Basis für die neue HTML Version 5 gewählt. HTML5 definiert die Sprache HTML (HTML5), die XML-Formulierung dieser Sprache (XHTML5) und die Darstellung dieser Sprache im DOM (DOM5). Zwar definiert HTML5 einige Elemente ebenfalls neu, legt dabei aber hohen Wert auf Rückwärtskompatibilität. Der Entwurf der Spezifikation definiert die Syntax von HTML selbst neu, so dass diese in Zukunft von Validatoren besser überprüft werden kann. Für XHTML5 gelten die Regeln von XML, aber auch hier wird Wert darauf gelegt, die Unterschiede zwischen HTML und XHTML zu verringern (das gilt für die Syntax ebenso wie für die Arbeit mit DOM-Methoden). Die HTML-Arbeitsgruppe möchte für XHTML5 den XHTML-Namensraum verwenden und steht damit in Konkurrenz zur XHTML-2.0-Arbeitsgruppe. Die HTML-Arbeitsgruppe hat aber angekündgt auch ohne diesen Namensraum zu XHTML 1.0 kompatibel zu bleiben. Ende des Beitrags. |
|
||||
Das hatte ich vor ein paar Wochen bereits geschrieben, als ich Dich auf das fehlende meta-Element aufmerksam gemacht hatte
|
|
||||
Ich hab den Text auch erst nur überflogen. Dabei sind mir bisher nur ein paar Grammatikfehler (vor allem Zeichensetzung) aufgefallen. Auch könnten oder müssten einige Passagen etwas deutlicher formuliert werden, da sie etwas missverständlich wirken.
Ob es auch inhaltliche Fehler gibt, kann ich erst sagen, nachdem ich den Text genauer gelesen habe.
__________________
Markus Wulftange |
Sponsored Links |
|
|||
Da möchte/muss ich auch noch weitere Test durchführen. So wie es aussieht reicht die Angabe für die Erkennung der UTF-16-Kodierung nicht aus.
Zitat:
Wenn bestimmte Abschnitte besondere Pflege benötigen, sag mir bitte um welche es sich dabei handelt. Ich kann mich leider nicht sehr gut in die Leserseite versetzen. |
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Redesign für Steiner Cycling Team | pkipper | Site- und Layoutcheck | 11 | 09.02.2011 13:25 |
per jquery flash entfernen und html anzeigen lassen | destroy90210 | Javascript & Ajax | 2 | 02.01.2010 18:15 |
DIV immer ganze Breite - normal?!?!? | csski | CSS | 3 | 02.07.2008 13:20 |
Wie parse ich mit php Markdown syntax nach html? | asdfgqw | Serveradministration und serverseitige Scripte | 0 | 03.06.2008 01:11 |
CSE HTML Validator Standard Anschaffung wert? | DieterWelzel | Offtopic | 10 | 17.08.2007 18:02 |