nicht angemeldet
Fordert die WCAG 2.0 noch Standardtreue? Und wenn, wo?
Moin, moin,
bin gerade über die WCAG 2.0 gestolpert und nein, ich habe sie noch nicht ganz gelesen. Was ich aber beim überfliegenden Suchen nicht mehr gefunden habe ist ein Passus, der besagt, dass die Web-Standards (XHTML 1.0, CSS2.1 und so weiter) eingehalten werden müssen.
Bestimmt gibt es den, aber wo? Kann mir jemand die Guideline nennen, in der Standardtreue gefordert wird?
Vielen Dank und viele Grüße
Nis Randers
******
Da hängt noch ein Mann im Mast, wir müssen ihn holen!
-
Hi,
bin gerade über die WCAG 2.0 gestolpert und nein, ich habe sie noch nicht ganz gelesen. Was ich aber beim überfliegenden Suchen nicht mehr gefunden habe ist ein Passus, der besagt, dass die Web-Standards (XHTML 1.0, CSS2.1 und so weiter) eingehalten werden müssen.
Bestimmt gibt es den, aber wo? Kann mir jemand die Guideline nennen, in der Standardtreue gefordert wird?
Ich finde beim schnellen drueberschauen nur das:
Principle 4: Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)MfG ChrisB
--
„This is the author's opinion, not necessarily that of Starbucks.“-
Hallo ChrisB,
danke für deine schnelle Antwort. Ich habe noch etwas weitergeklickt und bin auf folgenden Satz gestossen:
"When markup languages are used in a way that fully conforms to their specifications, all of the requirements in 4.1.1 are met. Therefore, while fully conforming to specifications is not required to conform to WCAG 2.0, it is a best practice and is sufficient to meet Success Criterion 4.1.1." (http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G192)
Wenn mein Englisch stimmt, dann heißt das, dass zur Erfüllung der WCAG 2.0 Standardtreue nicht unbedingt gehört (wenngleich es sehr empfohlen wird und ein hinlängliches Kriterium für die Prüfung von Guideline 4.1.1 ist.
Wenn ich bis hierher recht habe, dann wird es eine interessante Aufgabe sein, die Abweichungen von der/den Spezifikation/en festzustellen, die die Konformität mit der WCAG 2.0 nicht gefährden.
Viele Grüße
Nis Randers
*****
Da hängt noch ein Mann im Mast, wir müssen ihn holen!-
Hi,
Wenn ich bis hierher recht habe, dann wird es eine interessante Aufgabe sein, die Abweichungen von der/den Spezifikation/en festzustellen, die die Konformität mit der WCAG 2.0 nicht gefährden.
Eigentlich nicht. Es gehört zum Grundwissen eines Web-Autors, zu wissen, was man sich erlauben kann, und was nicht. Was man sich insbesondere nicht erlauben kann, steht beschrieben, erlauben kann man sich aber z.B. nicht-standardisierte Attribute & Elemente (Basisregel aller HTML-Versionen: unbekannte Elemente & Attribute sind zu ignorieren).
Ich schätze, diese "angepaßte Sichtweise/Beschreibung" hat mit der Einführung von HTML 5 zu tun, bzw. mit dem damit einhergehenden "back to the roots" ...
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
Hallo Cybaer,
danke für deine Antwort.
Ich schätze, diese "angepaßte Sichtweise/Beschreibung" hat mit der Einführung von HTML 5 zu tun, bzw. mit dem damit einhergehenden "back to the roots" ...
mit HTML 5 und seinen Forderungen habe ich mich bisher noch gar nicht befasst. Meine Zeit war eher HTML 4.01. Und ich bin auch immer ein Verfechter der Lehre des validen Codes gewesen.
Was ist denn für dich als Praktiker das "back to the roots" am HTML 5? Ich meine, mit seiner (wenngleich nicht konsequenten) Missbilligung der Layout-Elemente und der damit verbundenen Trennung von Struktur und Layout ist doch auch HTML 4.01 einen guten Schritt gegangen?!? Wird das jetzt noch konsequenter oder geht's eher wieder in die gegenteilige Richtung?
Viele Grüße
Nis Randers
*****
Da hängt noch ein Mann im Mast, wir müssen ihn holen!-
Hallo.
Was ist denn für dich als Praktiker das "back to the roots" am HTML 5? Ich meine, mit seiner (wenngleich nicht konsequenten) Missbilligung der Layout-Elemente und der damit verbundenen Trennung von Struktur und Layout ist doch auch HTML 4.01 einen guten Schritt gegangen?!? Wird das jetzt noch konsequenter oder geht's eher wieder in die gegenteilige Richtung?
Das ist eine Frage der Definition. Wer HTML 5 als Nachfolger von HTML 4 versteht, wird es als konsequenter empfinden. Aus der Perspektive von XHTML 1.1 oder gar 2.0 ist das Gegenteil der Fall. Der Ausdruck "back to the roots" bezieht sich aber mehr auf dir Rückkehr zu pragmatischen Lösungen und die Abkehr von Konstrukten die in ihrer Komplexität kaum mehr von Laien bewältigt werden können.
MfG, at-
Hallo at,
danke für die Erklärung. Das lässt hoffen, jedenfalls solange die Pragmatik nicht auf Kosten der Barrierefreiheit geht und das Gewicht auf der Semantik bleibt. Denn die Idee, die Information unabhängig vom Ein- und Ausgabegerät zu transportieren ist das, was mir am HTML am Besten gefällt.
Viele Grüße
Nis Randers
******
Da hängt noch ein Mann im Mast, wir müssen ihn holen!-
Hallo.
Das lässt hoffen, jedenfalls solange die Pragmatik nicht auf Kosten der Barrierefreiheit geht und das Gewicht auf der Semantik bleibt.
HTML 5 erweitert den Begriff der Barrierefreiheit auf die Entwickler. Allerdings beschleicht einen dabei gelegentlich das Gefühl, als sei den Autoren der Spezifikation die Bedeutung der Aussage "Mache es so einfach wie möglich, aber keinesfalls einfacher." nicht immer bewusst. Naja, dafür war den Schöpfern von XHTML > 1.0 das KISS-Prinzip offenbar kein Begriff. Es bleibt zu hoffen, dass beide voneinander lernen.
Denn die Idee, die Information unabhängig vom Ein- und Ausgabegerät zu transportieren ist das, was mir am HTML am Besten gefällt.
Das ist ebenso lobenswert wie auch selten.
MfG, at
-
-
-
Hi,
Was ist denn für dich als Praktiker das "back to the roots" am HTML 5?
Nicht gegen eine bestimmte erweiterbare/austauschbare Semantik zu coden (also Validität gegen eine offizielle W3C-DTD), sondern einfach die Grundregel befolgen: Was du, lieber Browser, nicht kennst, ignorierst du halt. Aber die Welt geht nicht unter, wenn eigene oder neue Attribute oder Elemente hinzukommen, und man dann nicht mehr "valide zu W3C-DTD XYZ" ist.
Auch die (ehedem nicht notwendige) Doctype-Angabe kommt in (X)HTML 5 ohne Versionierung daher. Eigentlich ist sie sogar nur deswegen ratsam, wg. des dösbaddeligen Doctype-Sniffings. In XHTML 5 wird prinzipiell vom Standardmodus ausgegangen, weswegen dort der Doctype auch praktisch entfallen kann ...
Ich meine, mit seiner (wenngleich nicht konsequenten) Missbilligung der Layout-Elemente und der damit verbundenen Trennung von Struktur und Layout ist doch auch HTML 4.01 einen guten Schritt gegangen?!? Wird das jetzt noch konsequenter oder geht's eher wieder in die gegenteilige Richtung?
Das ist nicht der (strittige) Punkt.
Es geht bei HTML 5 "nur" darum, die Sprache praxistauglicher zu machen (sowohl aus Sicht des Coders, als auch aus Sichht des Anwenders - man denke nur an neue Elemente wie insbes. CANVAS), nicht darum ein "neues, fehlertolerantes HTML" zu kreieren.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
Hallo Cybaer,
Was du, lieber Browser, nicht kennst, ignorierst du halt. Aber die Welt geht nicht unter, wenn eigene oder neue Attribute oder Elemente hinzukommen, und man dann nicht mehr "valide zu W3C-DTD XYZ" ist.
Tatsächlich stellt das dann einen parse error dar. Die derzeitige Spec definiert für viele Fälle eine Möglichkeit, wie bei einem parse error weiter ein vernünftiges DOM erstellt werden kann, sagt aber auch:
The error handling for parse errors is well-defined: user agents must either
act as described below when encountering such problems, or must abort
processing at the first error that they encounter for which they do not wish to
apply the rules described below. [Parsing HTML documents]Sprich: Man kann sich nicht zwangsläufig darauf verlassen.
Ein weiteres Problem beim tree construction Algorithmus scheint zu sein, dass in HTML 5 Serialisierung eingebettetes XML (außer MathML und demnächst vielleicht SVG) im HTML Namensraum ins DOM eingefügt wird und nicht im vom XMLNS-Attribut angegebenen Namensraum. Dies ist zum einen eine Inkonsistenz zwischen der eigentlich angestrebten Gleichheit der Möglichkeiten in beiden Serialisierungen, zum anderen ist dies eine Inkonsistenz zu den anderen Syntax-Erleichtungen (z.B. "/>") im HTML-5-Parsing-Algorithmus, wie aus mit falschem MIME-Typ versendeten XHTML-1-Dokument dennoch ein konsistentes DOM entstehen kann. Das ganze wird hin und wieder unter dem Stichwort „distributed extensibility“ heiß diskutiert.
Es kann auch sein, dass ich das Monster von Algorithmus da falsch verstehe. Es wäre schön, wenn Du das selber mal nachgucken und mich bei Gelegenheit verbessern könntest. Ich würde Dir das detaillierte Lesen des Working Drafts und der Mailing-Listen durchaus aus anderen Gründen mal ans Herz legen.
Es geht bei HTML 5 "nur" darum, die Sprache praxistauglicher zu machen (sowohl aus Sicht des Coders, als auch aus Sichht des Anwenders - man denke nur an neue Elemente wie insbes. CANVAS), nicht darum ein "neues, fehlertolerantes HTML" zu kreieren.
HTML 5 ist vieles zugleich, Praxistauglichkeit liegt oft im Auge des Betrachters und viele Parteien projizieren eigene Vorstellung auf HTML 5. Gründe für HTML 5 sind:
• Zukünftige Abwärtskompabilität: man will eine Spezifikation, die für den Großteil der Dokumente da draußen in der Wildnis ein konsistentes DOM erzeugt.
• Eine Möglichkeitkeit zur öffentlichen Spezifizierung proprietärer Erfindungen. <canvas> hätte es wohl auf dem normalen Wege von HTML 5 nicht in die Spezifikation geschafft, hätte Apple nicht vorher mit der unilateralen Veröffentlichung nicht zu ignorierende Tatsachen geschaffen.
• Harmonisierung all der kleinen, nicht in vorherigen Standards enthaltenen Bugfixes, die Browser-Hersteller als best practice erkannt haben.
• Eine zentralisierte Erweiterung des Vokabulars von HTML wobei die entscheidende Zentrale hier eine Person ist. Für ein Konzept dezentraler Erweiterung ist in der Zentrale eher kein Platz vorgesehen.
• Ein soziales Experiment, ob man mit einem benevolent dictator, einer kleinen, aber sehr lauten Gruppe von ihm Unterstützenden und dem daraus folgenden eher rauen, lauten, sozialen Klima besser eine Spezifikation schaffen kann als mit den vorherigen in IETF und W3C genutzten sozialen Mechanismen.
• Eine zentrale Anlaufstelle, in der jeder seinen Wunsch nach einem Pony erklären kann, wobei jedes Pony anders ist und manchmal auf ein Dachs oder ein Elefant gewünscht wird.
Tim
-
Hi,
Sprich: Man kann sich nicht zwangsläufig darauf verlassen.
... daß ein (X)HTML-5-Browser zukünftige (X)HTML-Dokumente (z.B. ein (X)HTML 6) noch parst. >;->
Das wäre natürlich grober Unfug. =;-) Unbekannte Elemente & Attribute sind *kein* "parsing error". Auch für HTML 5 gilt nach wie vor: Unbekannte Elemente & Attribute sind zu ignorieren.
Neu in HTML 5 ist aber, daß unbekannte Elemente & Attribute trotzdem im DOM repräsentiert werden sollen (das war bisher undefiniert - und die Browser <= HTML 4.x verhalten sich ja auch unterschiedlich).
In dem von dir verlinkten Dokument steht auch *ausrücklich*, daß ein "parsing error" sich auf die *Syntax* bezieht, also *nicht* auf die *Semantik*.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
Hallo Cybaer,
Das wäre natürlich grober Unfug. =;-) Unbekannte Elemente & Attribute sind *kein* "parsing error".
Pardon, sie sind doch kein "parse error". Ich habe mich da verlesen.
Auch für HTML 5 gilt nach wie vor: Unbekannte Elemente & Attribute sind zu
ignorieren.
Neu in HTML 5 ist aber, daß unbekannte Elemente & Attribute trotzdem im DOM repräsentiert werden sollen
Lustige Definition für „ignorieren“. ;)
In dem von dir verlinkten Dokument steht auch *ausrücklich*, daß ein "parsing error" sich auf die *Syntax* bezieht, also *nicht* auf die *Semantik*.
Die Notiz finde ich da etwas fehl formuliert. Geht man den tree construction Algorithmus durch, dann wird ein parse error auch geworfen, wenn nicht nur die Syntax nicht stimmt, also beispielsweise ein End- ohne vorher öffnendes Start-Tag da steht, sondern auch bei semantischen Fehlern wie z.B. der Verschachtelung von Überschriften innerhalb von Überschriften und ähnliche, sich nicht selbst enthaltende Elemente.
Tim
-
Hi,
Lustige Definition für „ignorieren“. ;)
Wie mit einem "lästigen Bekannten": Man weiß, daß er da ist, kann auch sagen,daß er da ist, aber man ignoriert ihn ansonsten. ;)
parse error wird auch geworfen (...) bei semantischen Fehlern wie z.B. der Verschachtelung von Überschriften innerhalb von Überschriften und ähnliche, sich nicht selbst enthaltende Elemente.
Hmm, hätte ich jetzt aber auch zur Syntax gerechnet.
Gruß, Cybaer
--
Man muß viel gelernt haben, um über das, was man nicht weiß, fragen zu können.
(Jean-Jacques Rousseau, Philosoph u. Schriftsteller)
-
-
-
-
-
-
-
-