nicht angemeldet
HTML5 und die Sprache des Dokuments
0 
Struppi
0 0 
Gunnar Bittersmann
0 0 0 0 Gunnar Bittersmann
1
HTML5 und die Sprache des Dokuments
Hallo,
ich habe schon danach gegoogelt bin aber nicht wirklich schlauer geworden.
Wie setze ich in HTML5 die Sprache des Dokumentes richtig?
<meta http-equiv="content-language" content="de" />
oder
<meta name="content-language" content="de" />
oder
<meta name="language" content="de" />
oder geht das doch noch anders?
Danke für die Hilfe.
Viele Grüße,
Michael
-
ich habe schon danach gegoogelt bin aber nicht wirklich schlauer geworden.
Warum hast du nicht einfach den validator mal bemüht? Der sollte dir sagen was falsch ist.
Struppi.
-
ich habe schon danach gegoogelt bin aber nicht wirklich schlauer geworden.
Warum hast du nicht einfach den validator mal bemüht? Der sollte dir sagen was falsch ist.
Struppi.
Weil da auch sowas wie:
<meta name="dededelanguage" content="de" />
durchgeht.
-
-
Wie setze ich in HTML5 die Sprache des Dokumentes richtig?
-
@@Michael:
nuqneH
oder geht das doch noch anders?
Ja. Declaring Language in XHTML and HTML sagt, wie.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain) -
Moin Moin!
http://diveintohtml5.org/semantics.html#html-element sagt:
<html lang="de">Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Moin Moin!
http://diveintohtml5.org/semantics.html#html-element sagt:
<html lang="de">Alexander
Danke Alexander,
so habe ich es jetzt auch umgesetzt. Mir ist aufgefallen, dass der Validator für den Doctype html (also HTML5) wirklich noch überarbeitet werden muss. Ich habe sogar das öffnende <html> vergessen und er hat nicht gemeckert.Naja, danke an alle, die mir geholfen haben.
Michael
-
Moin Moin!
Mir ist aufgefallen, dass der Validator für den Doctype html (also HTML5) wirklich noch überarbeitet werden muss.
HTML5 ist ja auch noch nicht fertig.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". -
@@Michael:
nuqneH
Ich habe sogar das öffnende <html> vergessen und er hat nicht gemeckert.
Da gibt’s auch nichts zu meckern. [HTML5 §8.1.2.4]
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain) -
Mir ist aufgefallen, dass der Validator für den Doctype html (also HTML5) wirklich noch überarbeitet werden muss. Ich habe sogar das öffnende <html> vergessen und er hat nicht gemeckert.
Das ist kein Fehler des Validators und das ist auch keine Neuerung von HTML5.
HTML 5 erlaubt, ebenso wie HTML 4, das Weglassen vieler Tags. In beiden Versionen kann man ziemlich »unnormalen« oder scheinbar fehlerhaften Code schreiben und der Validator lässt es durchgehend. Insbesondere muss das Dokument-Grundgerüst (Doctype, html, head, title, body) nicht streng eingehalten werden.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title>Foo</title>
<p>BarDas ist ein mögliches minimales HTML-4-Dokument (von weiteren Gemeinheiten wie SHORTTAG einmal abgesehen).
<!DOCTYPE html>
<title>Foo</title>Das ist ein mögliches minimales HTML5-Dokument.
Alle anderen Elemente werden von einem (theoretischen) SGML- bzw. HTML5-Parser so eingefügt, wie man es gewohnt ist. Nur verhalten sich noch nicht alle Browser entsprechend, daher macht es (ebenso aus Stilgründen) Sinn, immer ein vollständiges Dokumentgerüst zu notieren.
Mathias
-
Alle anderen Elemente werden von einem (theoretischen) SGML- bzw. HTML5-Parser so eingefügt, wie man es gewohnt ist. Nur verhalten sich noch nicht alle Browser entsprechend, daher macht es (ebenso aus Stilgründen) Sinn, immer ein vollständiges Dokumentgerüst zu notieren.
Es ist durchaus sinnvoller XML-Notation zu verwenden, denn echte XML-Parser gibt es wie Sand am Meer. Funktionstüchtige SGML- oder HTML5-Parser sind schwer zu finden.
Will man mit seinem Dokument noch mehr machen als es nur im Browser darzustellen, ist diese Schreibweise vorzuziehen.
Man erspart sich dadurch eine Menge arbeit - RSS-Feeds lassen sich auch aus statischen Seiten leichter extrahieren, eine selbstgeschriebene Suchfunktion kann leichter den Nutztext von unnötigem Markup trennen usw.
-
Es ist durchaus sinnvoller XML-Notation zu verwenden, denn echte XML-Parser gibt es wie Sand am Meer. Funktionstüchtige SGML- oder HTML5-Parser sind schwer zu finden.
Funktionstüchtige SGML-Parser gibt es seit 20 Jahren. Der W3C-Validator beispielsweise verwendet OpenSP zur Verarbeitung von HTML 4, das ist ein durchaus funktionstüchtiger SGML-Parser. Der W3C-Validator verwendet den Validator.nu-Parser zur Verarbeitung von HTML5, das ist ein durchaus funktionstüchtiger HTML5-Parser in Java. Der ist mittlerweile auch schon seit 5 Jahren in der Entwicklung. Eine C++-Version davon findet sich in Firefox 4, daran wurde auch Jahre lang geschraubt. Chrome enthält seit Version 7 den HTML5-Parser aus Webkit.
Echte Parser für HTML5 und SGML gibt es also ebenfalls wie Sand am Meer. Was du meinst ist eher, dass nicht sämtliche Programmiersprachen einfach nutzbare Schnittstellen zu diesen haben, wie es bei XML-Parsern wie libxml2 der Fall ist. Prinzipiell ist der Sinn von HTML5-Parsern gerade, sämtliche (X)HTML-Dokumente einheitlich verarbeiten zu können. Es fehlen bis dato nur die Schnittstellen in den verbreiteten Scriptsprachen. Lediglich für PHP und Python gibt es html5lib. Allerdings ist eine HTML5-Parser-Bibliothek geplant, die zur libxml2-API kompatibel ist. Übrigens hat libxml2 auch einen liberalen HTML-Parsemodus, der durchaus brauchbar ist, allerdings ist das meines Wissens ein unspezifiziertes Mittelding zwischen SGML-, XML- und Tag-Soup-Parser.
Mathias
-
Was du meinst ist eher, dass nicht sämtliche Programmiersprachen einfach nutzbare Schnittstellen zu diesen haben, wie es bei XML-Parsern wie libxml2 der Fall ist.
Richtig, das meinte ich.
Prinzipiell ist der Sinn von HTML5-Parsern gerade, sämtliche (X)HTML-Dokumente einheitlich verarbeiten zu können.
Ja, das ist bei HTML5 ein Vorteil da bei "Fehlern" exakt definiert ist, wie sich der Parser zu verhalten hat.
Dennoch ist eine HTML-Suppe schwieriger zu lesen (für einen Menschen) als ein XML-kompatibles Dokument.
Die Verarbeitungsregeln sind einfacher da die Fehlerbehandlung einfach sehr drakonisch ist - das hat imho. den essentiellen Vorteil, dass parser weniger komplex sein müssen und dadurch Fehler einfacher zu vermeiden sind.
-
Dennoch ist eine HTML-Suppe schwieriger zu lesen (für einen Menschen) als ein XML-kompatibles Dokument.
Für Menschenlesbarkeit sind Lints zuständig, weniger Dokumenttypen und Validierung. Klar, bei XML ist das ein nützliches »Abfallprodukt«.
Die Verarbeitungsregeln sind einfacher da die Fehlerbehandlung einfach sehr drakonisch ist - das hat imho. den essentiellen Vorteil, dass parser weniger komplex sein müssen und dadurch Fehler einfacher zu vermeiden sind.
Das sehe ich nicht so. XML ist sehr komplex, vielseitig und allgemein, HTML5 ist hingegen sehr speziell. Zwar sind die Parser-Algorithmen bei HTML5 teilweise komplexer, weil verschiedene Syntaxen möglich sind. Dafür gibt es bei XML eine Menge an Features und Eigenheiten, die bei einfachen HTML5 nicht möglich sind. XML ist ein ganzes Ökosystem an verbundenen Techniken, selbst wenn diese in konventionellem XHTML 1.0 wenig Verwendung finden. Es hat schon seine Gründe, warum sich die HTML5-Macher gegen Features wie Namensräume wehren, die die Komplexität unglaublich erhöhen.
Der HTML5 Tokenizer und Tree Builder ist vergleichsweise überschaubar. Ersterer hat 1.698 Zeilen C++-Code in Webkit, letzterer 2.811 Zeilen. Die Java-Implementierung (Basis für Gecko) hat 6.946 bzw. 5.557 Zeilen. Die PHP-Implementierung 2.421 bzw. 3.840 Zeilen. (Es kommen jeweils noch kleinere Helferklassen hinzu und z.B. die ellenlange Entity-Liste.)
parser.c aus libxml2 umfasst 14.982 Zeilen C-Code. Sicher ließe sich einfaches XML, z.B. XHTML 1.0 Strict ohne funky Markup aus anderen Namensräumen und ohne Sperenzchen, auch einfach parsen. Einen total dummen, aber für diese Zwecke ausreichenden Parser, der XML nicht vollständig implementiert, könnte man sicher in ein paar tausend Zeilen schreiben. xmlparse.c aus Expat umfasst bspw. 6.291 Zeilen C-Code.
Parser wie libxml2 implementieren nicht nur einfach XML-Grundlagen, sondern sämtliche Sonderfälle und ein dutzend Zusatztechniken aus dem XML-Umfeld. Im Vergleich dazu kann man einen HTML5-Parser »mal eben« in ein paar dicken, aber in weitesgehend geschlossenen Ruby-, PHP- oder Python-Klassen schreiben. XML ist mehr die eierlegende Wollmilchsau. Das ist ja erst einmal ein Vorteil, wenn man DOM, XPath, XSLT, DTD-/Schema-/Relax-Validierung usw. frei Haus bekommt. Aber unter dem Strich ist das selbstverständlich komplexer als HTML5 mit seinem bewusst sehr beschränkten Aufgabenbereich.
Mathias
-
@@molily:
nuqneH
die ellenlange Entity-Liste.
Kann mir jemand eklären, wozu die gut sein soll? Wer braucht den Quatsch? Hat Hixie mal wieder an den Bedürfnissen vorbeigedacht?
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
die ellenlange Entity-Liste.
Kann mir jemand eklären, wozu die gut sein soll?Wenn ich mich recht entsinne, kommt die aus der Integration von SVG und vor allem MathML in HTML5.
-
@@Tim Tepaße:
nuqneH
die ellenlange Entity-Liste.
Kann mir jemand eklären, wozu die gut sein soll?Wenn ich mich recht entsinne, kommt die aus der Integration von SVG und vor allem MathML in HTML5.
Das wäre eine Erklärung, wenn auch keine ganz schlüssige.
HTML5 implementiert keine anderen Standards, es baut sie bestenfalls mehr oder weniger nach. Siehe Ruby-Annotationen, wo das dort spezifizierte 'rb'-Element in HTML5 fehlt.
HTML5 schert sich einen Dreck um andere Standards. Wozu also an der Stelle haufenweise nutzlose Zeichenentitys einführen?
Auf der anderen Seite gibt es für Zeichen, die sinnvollerweise escapet werden, weiterhin keine Zeichenentitys. U+202F narrow no-break space fällt mir da ein, welches bevorzugt zwischen Maßzahl und Maßeinheit bzw. zwischen abgekürzte Namensbestandteile zu setzten ist: '
37 °C', 'J. R. Ewing'. Eine Zeichenentity-Referenz '&nnbsp;' wäre da durchaus nützlich. Aber Fehlanzeige.#html5 #fail
Qapla'
PS. Die HTML5-Spec (§8.5) schaft es nicht einmal, sich an die Unicode-Spec (PDF) zu halten, wo geschrieben steht: “In running text, an individual Unicode code point is expressed as U+n, where n is four to six hexadecimal digits, using the digits 0–9 and uppercase letters A–F (for 10 through 15, respectively). Leading zeros are omitted, unless the code point would have fewer than four hexadecimal digits […]”
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
#html5 #fail
Das war aber zu lang für einen Tweet :p
PS. Die HTML5-Spec (§8.5) schaft es nicht einmal, sich an die Unicode-Spec (PDF) zu halten, wo geschrieben steht: “In running text, an individual Unicode code point is expressed as U+n, where n is four to six hexadecimal digits, using the digits 0–9 and uppercase letters A–F (for 10 through 15, respectively). Leading zeros are omitted, unless the code point would have fewer than four hexadecimal digits […]”
Sei so nett, pack das in den Wikipedia-Artikel zu HTML5, da mangelts an Kritik :)
-
PS. Die HTML5-Spec (§8.5) schaft es nicht einmal, sich an die Unicode-Spec (PDF) zu halten
Wenn deine Kritik darin besteht, dass Hexzahlen in dieser Liste einheitlich fünfstellig statt mal vier- und mal fünfstellig notiert werden, dann gebührt das #fail eher dieser Erbsenzählerei. Substantielle Kritik an HTML5 gibt zur Genüge. Das hingegen ist eher lächerlich.
Mathias
-
@@molily:
nuqneH
Wenn deine Kritik darin besteht, dass Hexzahlen in dieser Liste einheitlich fünfstellig statt mal vier- und mal fünfstellig notiert werden, dann gebührt das #fail eher dieser Erbsenzählerei. Substantielle Kritik an HTML5 gibt zur Genüge. Das hingegen ist eher lächerlich.
Nein, meine Kritik besteht darin, dass HTML5 grundsätzlich andere Standards missachtet. Und das ist eher nicht zum Lachen.
Die Missachtung des Unicode-Standards hatte ich lediglich als ein weiteres Beispiel dafür im P.S. angeführt.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
meine Kritik besteht darin, dass HTML5 grundsätzlich andere Standards missachtet.
Und da hast du noch andere Beispiele als das fehlende rb-Element (ich habe im Übrigen nicht geprüft, ob diese Entscheidung sinnvoll ist) oder wie kommst du von zwei Beispielen auf »grundsätzlich«? Ist das das Induktionsprinzip made easy?
Mathias
-
@@molily:
nuqneH
meine Kritik besteht darin, dass HTML5 grundsätzlich andere Standards missachtet.
Und da hast du noch andere Beispiele […]
input[@type="email"] ist falsch spezifiziert.
[…] als das fehlende rb-Element (ich habe im Übrigen nicht geprüft, ob diese Entscheidung sinnvoll ist)
Ist sie nicht, IMHO. Wenn das 'rb'-Element wirklich überflüssig ist, dann sollte die Ruby-Annotationen-Spec dementsprechend geändert werden. _Dann_ kann 'rb' auch in HTML5 entfallen.
Es ist wohl auch nicht so, dass es den HTML5-Machern im W3C an Einfluss mangeln würde, eine Änderung der Ruby-Annotationen-Spec zu erwirken.
oder wie kommst du von zwei Beispielen auf »grundsätzlich«? Ist das das Induktionsprinzip made easy?
Yep. ;-)
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
-
-
-
-
-
-
-
-
-
-