valides XHTML 1.0 strict in TypoLight ?

Druckbare Version

11.09.2009, 12:37
abackhaus

valides XHTML 1.0 strict in TypoLight ?

Hallo,

habe heute einen TL Seite fertiggestellt und bin wie üblich abschliessend nochmals mit einem Validierungstool über die Seiten gegaangen um evtl. HTML- oder CSS-Fehler zu finden und zu beseitigen.

Bei der Validierung bekomme ich zwei Fehler, welche meines Erachtens in TL von Haus aus in den Templates bei TL vermieden werden sollten/können:

Zitat:

Zitat von 1. Validierungsfehler

Beim Verwenden von eingebetteten Ereignissen (Event-Handler) muss die verwendete Scriptsprache in einen Meta-Tag (<meta http-equiv="Content-Script-Type" content="text/javascript" />) und/oder im HTTP-Header (Content-Script-Type: text/javascript) mitgeteilt werden.

Hintergrund: Wenn in einen Dokument Event-Handler verwendet werden -

Beispiele:

Code:

<body onload="mein Script"... <a onclick="mein Script"... <form onsubmit="mein Script"...

- dann muss dem Browser mitgeteilt werden, um welche Scriptsprache es sich handelt. Mitnichten kann man davon ausgehen, dass Javascript verwendet werden soll, auch wenn alle Browser aus Gründen der Fehlertoleranz Javascript verwenden - richtig ist dieses Verhalten nicht.
Der Internet Explorer versteht z. B. auch VB-Script und über Plugins können fast alle Browser um etliche Scriptsprachen erweitert werden.
Damit ein Browser "weiß", welche Scriptsprache er in dem jeweiligen Dokument verwenden soll, muss ihm dies mitgeteilt werden.

Zitat:

Zitat von 2. Validierungsfehler

Beim Verwenden von style-Attributen muss die verwendete Stylesprache in einen Meta-Element (<meta http-equiv="Content-Style-Type" content="text/css" />) und/oder im HTTP-Header (Content-Style-Type: text/css) mitgeteilt werden.

Hintergrund:

Solche Formatierungsauszeichnungen nimmt u.a. z.B. TinyMCE im Quelltext vor, so dass man also nicht davon ausgehen kann, daß sie nicht vorkommen und alles sauber in externen CSS-Files ausgelagert ist.

Zitat:

Zitat von W3C Recommendation

Documents that include elements that set the style attribute but which don't define a default style sheet language are incorrect. Authoring tools should generate default style sheet language information (typically a META declaration) so that user agents do not have to rely on a default of "text/css".
http://www.w3.org/TR/html401/present....html#h-14.2.1

Aus meiner Sicht sollten diese beiden Punkte in TL von Hause aus berücksichtigt werden.

Gruss, Albrecht

PS. Beide Themen waren mir selbst auch neu - by courtesy of validome.org
11.09.2009, 15:39
Antipitch

Hi Alfred,

Zitat:

Aus meiner Sicht sollten diese beiden Punkte in TL von Hause aus berücksichtigt werden.

nein, sollten sie nicht.

Vielleicht solltest du aber die entsprechenden Dokumente/ Stellen nochmal lesen:
1. Die Scriptsprache kann ebenso gut lokal deklariert werden.
2. Intrinsische Events (onclick etc.) betrifft das nicht (solange denn das aufzurufende Script die entsprechende Angabe enthält)
3. CSS ist die Default Style-Sprache. Die Spezifikation sagt zwar, dass das Weglassen der Angabe inkorrekt sei, entsprechende Dokumente validieren aber trotzdem.

Ansonsten: wen interessiert validome.org? Nimm doch den Validator der Leute, die den Mist verzapfen (w3c), falls dir die Sache Kopfzerbrechen bereitet...

cheers
Antipitch
11.09.2009, 16:57
abackhaus

Zitat:

Zitat von Antipitch

Vielleicht solltest du aber die entsprechenden Dokumente/ Stellen nochmal lesen:

Wäre mein Tipp an Dich, Antipatch !

Zitat:

Zitat von Antipitch

1. Die Scriptsprache kann ebenso gut lokal deklariert werden.

Niemand hat was Gegenteiliges behauptet.

Zitat:

Zitat von Antipitch

Intrinsische Events (onclick etc.) betrifft das nicht (solange denn das aufzurufende Script die entsprechende Angabe enthält)

Hört sich toll an - ist aber falsch - weder ist ein Event-Handler (z.B. onclick) intrinsisch - noch gibt es dazu ein aufrufendes Script. Er reagiert eben wie gesagt auf Events. Und diese treten nicht von alleine auf - sondern sie werden ausgelöst.
Gemäß dem HTML-Standard muss man die Default-Script-Sprache wie erläutert angeben, sobald man Event-Handler-Attribute einsetzt.

Zitat:

Zitat von Antipitch

CSS ist die Default Style-Sprache. Die Spezifikation sagt zwar, dass das Weglassen der Angabe inkorrekt sei, entsprechende Dokumente validieren aber trotzdem.

Ja ja - sie validieren trotzdem - z.B. beim Validator von, wie sagtes Du so schön, "den Leuten die den Mist verzapfen (w3c)" - und das ist falsch, da nicht konform mit der Spezifikation - wie Du ja schon selbst treffend festgestellt hast.

Zitat:

Zitat von Antipitch

Ansonsten: wen interessiert validome.org? Nimm doch den Validator der Leute, die den Mist verzapfen (w3c), falls dir die Sache Kopfzerbrechen bereitet...

Wie allgemein bekannt, sind alle Validatoren mehr oder weniger fehlerbehaftet. Das trifft für validome, ganz sicher aber auch für die Validatoren von W3C zu.

Das Ziel ist aber nicht eine tolle Validierung ( egal wo und wie falsch ) sondern das Ziel ist eine für alle Personengruppen (behindert oder nicht) zugängliche Webseite. Grundvoraussetzung ist hierfür ein (möglichst) barrierefreies Webdesign und die konsequente Nutzung von Webstandards.

Das sich TypoLight Barrierefreiheit und Standardkonformität auf die Fahne geschrieben, hat war der Auslöser für meinen Beitrag. Mir selbst macht's kein Kopfzerbrechen - ich habe es für meine Seiten erledigt.

Gruss, Albrecht
11.09.2009, 17:28
Antipitch

Hi Albrecht (sorry vorhin),

Zitat:

weder ist ein Event-Handler (z.B. onclick) intrinsisch - noch gibt es dazu ein aufrufendes Script.

ich schrieb "Event" und "aufzurufendes". Aber wenn es keine intrinsischen Events und Attribute gibt, kann dieses Kapitel wohl eh gestrichen werden ;) .

Ansonsten war mir so (und es ist auch so), dass es zu dem Thema schon mal ein Ticket gab: http://https://contao.org/ticket/527 .

Wenn du die Angaben machen willst, ist das ja völlig ok und kann dann doch alles so bleiben.

cheers
Antipitch
11.09.2009, 17:40
abackhaus

Hallo Antipitch,

das Ticket kannte ich noch nicht - danke für die Info.

Ich bleibe bei meinem Standpunkt, habe aber jetzt gesehen, daß Leo das Thema abgelehnt hat - ein richtige Begründung gibt es dazu leider nicht.
Er hat zwar angemerkt, dass W3C dass Mass aller Dinge sei, die Vorgabe aus der Spezifikation will er aber nicht übernehmen - verstehe ich nicht ...

Gruss, Albrecht
11.09.2009, 19:00
Nils Riel

Erstelle das Ticket neu und begründe dieses gut, dann wird Leo sich das bestimmt nochmals durch den Kopf gehen lassen.
11.09.2009, 19:07
Nina

Ne, mach das bitte nicht, da es nur eine unnötige Dopplung wäre.

Ich habe eine ausführlichere Argumentation gerade vorhin in das alte Ticket gepostet und werde es Leo zeigen. Wenn er den Ausführungen folgt, wird er es selbst wieder öffnen.
11.09.2009, 20:09
Antipitch

Hi Nina,
ich würde mal davon ausgehen, dass Leo die Textstellen aus den Specs bekannt sind, oder? Und (nicht auf dich, sondern auf's W3C bezogen) halte ich es nicht für eine Argumentation, einfach ohne Begründung "incorrect" zu schreiben. Wenn der Event bzw. das in HTML notierte Attribut (nicht: der in JS verwendete) Handler intrinsisch (für Albrecht ;)) sind und das aufgerufene Script lokal die Sprache/Typ deklariert, warum soll das dann inkorrekt sein, wenn andererseits die lokale Angabe ok ist? Dasselbe gilt agumentativ für CSS angesichts dessen Festgeschriebenheit als default-Sprache. Where's the point?

Jedenfalls nicht dort, dass das W3C der Papst sei. Wir sollten nicht vergessen, dass wir (anonym, bescheiden) diese Spezifikationen mit zu verantworten haben. Die Bubis bei SinnerSchrader & Co. (oder wer immer gerade beim W3C mitwirkt) sind 1. nicht alles Genies und gucken 2. schon was die anderen so machen (besonders letzteres hält ja das Internet am Leben und lässt Dinge wie XHTML schnell wieder sterben).

Ich werde mich um weitere Infos bemühen. Vielleicht andere auch...

cheers
Antipitch
11.09.2009, 22:42
abackhaus

Zitat:

Zitat von Antipitch

Jedenfalls nicht dort, dass das W3C der Papst sei. Wir sollten nicht vergessen, dass wir (anonym, bescheiden) diese Spezifikationen mit zu verantworten haben. Die Bubis bei SinnerSchrader & Co. (oder wer immer gerade beim W3C mitwirkt) sind 1. nicht alles Genies und gucken 2. schon was die anderen so machen (besonders letzteres hält ja das Internet am Leben und lässt Dinge wie XHTML schnell wieder sterben).

@ Antipitch:

ob es uns gefällt oder nicht - die Standards werden aber nun mal dort gemacht - wem das nicht passt, der muss sich dann dort engagieren und für Veränderungen sorgen.

Ohne jetzt nochmal auf auf die von Dir so beschworenen, "autotelischen" (;)) Event-Handler eingehen zu wollen - wir sollten nicht in die Beliebigkeit verfallen und die Vorgaben des W3C aus dem Hut ziehen, wenn es uns in den Kram passt und wenn es uns nicht in den Kram passt, dann finden wir tausend Gründe, warum es anders sein sollte. Schliesslich kann auch jeder z.B. trefflich über MS meckern, wenn es um die mangelnde Standardkonformität bei Browsern geht, also sollten wir uns bei der Gestaltung der Seiten auch eng an den Standard halten.

@Nina:

Danke, daß Du das Ticket nochmals eröffnet und Leo zu dem Thema geschrieben hast.

Gruss, Albrecht
12.09.2009, 12:34
Antipitch

Hi Albrecht,
ich hoffe, dass meine Kompromissbereitschaft bzgl. des Themas rüberkommt und "in den Kram passt" ist ja nicht mene Argumentation. Selbige beruht ja auch eben darauf, dass das W3C eben _nicht_ dasselbe ist wie MS. Es sollte zumindest sogar eher das Gegenteil sein und wenn wir die Specs zu nicht-beeinflussbaren Industriestandards verkommen lassen, sind wir selbst mit (wiederholen macht anschaulich) verantwortlich. So viel zur Metaebene...

Praktisch habe ich bisher keinen Grund gefunden, die Angabe zu machen (außer "incorrect" und Validome. Es gibt meines Wissens auch keinen Screenreader o.ä. der nicht auf irgendeinem Standardbrowser als Chassis durch die Gegend führe). Allerdings sehe ich auch keinen Grund, der dagegen spräche, sie zu machen (außer W3C Validator und je schlanker desto besser)...

cheers
Antipitch
21.09.2009, 03:54
Stranger

Hallo,

ich wollte vermeiden ein neues Thema wegen dem relativ kleinen Problem zu erstellen. Deshalb poste ich es einfach mal hier, ich hoffe das stört niemanden.
Kann mir vielleicht jemand sagen was der hier für Probleme sieht?

http://validator.w3.org/check?uri=ht...idator%2F1.654

Was muss ich ändern damit es valide ist?
21.09.2009, 07:23
do_while

Hallo Stranger,

eigentlich nennt doch der Validator bereits die Ursachen, wenn Du dann noch den Show-Source anhakst, zeigt er Dir auch noch genau die Zeile, in der das Problem besteht.

Im Großen und Ganzen solltest Du die JavaScripts in HTML-Kommentare einbetten, dann sollten die meisten Fehler weg sein:

HTML-Code:

<script type="text/javascript">  </script>

Mit dem img-Tag scheint das ein Folgeproblem zu sein, oder es stimmt was mit den divs nicht. Vielleicht ist es ja weg, wenn Du JavaScript korrigierst.
21.09.2009, 08:23
lucina

Der zweite Fehler liegt definitiv daran, dass das Element für den Cron außerhalb der DIVs für den Seitenaufbau liegt. Am Template geschraubt?

LG, Carolina.
21.09.2009, 08:23
Nina

Mach mal aus:

HTML-Code:

<img src="http://www.total-reality.de/cron.php" alt="" class="invisible" />

das hier, da es die Strict-Variante stört, dass das <img>-Element sich in keinem Block-Element befindet.:

HTML-Code:

<p class="invisible"><img src="http://www.total-reality.de/cron.php" alt="" /></p>

Das Javascript bindest du bei XHTML mit CDATA-Angaben (oder gleich als externes File) ein:

HTML-Code:

<script type="text/javascript"> /* <![CDATA[ */ ... Hier der Inhalt des Scripts ... /* ]]> */ </script>
21.09.2009, 23:01
Stranger

Dankesehr euch allen, allen voran Nina! Jetzt hat sich bei mir auch endlich ein Mysterium aufgeklärt. Seit mehr als 14 Monaten hab ich schon mit diesem Problem (JS) gekämpft und nie hab ich gecheckt woran das liegt ^^

Der XHTML Code ist jetzt valide.

Edit: Die CSS Validität ist auch nicht gegeben. Da gibt es ein Problem mit der opacity. Die Funktion gibts erst in CSS3. Für IE gibts die Möglichkeit ja auch mit filter:alpha(opacity=30). Kann man das vielleicht so deklarieren, dass man opacity nutzt aber er trotzdem schreibt, dass die CSS valide sind?