Script und Style Sprache per meta/ http header festlegen?

[Antipitch]

Hi Leute,
kein akutes Problem meinerseits, aber zufällig mal wieder drauf gestoßen:

Laut W3C Spezifikationen ist es bekannterweise "incorrect", Script- und Stylesprachen nicht per meta-Angabe oder http-Header festzulegen (der W3C Validator meckert nicht, andere schon). Aber niemand tut dies (SELF auch nicht).

1[zwei in eins]. Wie siehts mit der Theorie aus (über die Specs hinaus)? Oder ist das "incorrect" ein reiner W3C-Bürokratismus?

2. Praktische Vor- und Nachteile insbesondere bzgl. Barrierefreiheit?

cheers
Antipitch

[ChrisB]

Hi,

Laut W3C Spezifikationen ist es bekannterweise "incorrect", Script- und Stylesprachen nicht per meta-Angabe oder http-Header festzulegen (der W3C Validator meckert nicht, andere schon). Aber niemand tut dies (SELF auch nicht).

1[zwei in eins]. Wie siehts mit der Theorie aus (über die Specs hinaus)? Oder ist das "incorrect" ein reiner W3C-Bürokratismus?

In der Praxis gibt's zum Formatieren von HTML-Dokumenten nichts anderes als CSS, und als Scriptsprache ist auch JavaScript die einzig aktuell relevante. Wenn du also nichts weiter angibst, in welcher "Sprache" deine Formatierungen und Scripte vorliegen - dann gehen alle aktuellen Browser von CSS und JavaScript aus.

2. Praktische Vor- und Nachteile insbesondere bzgl. Barrierefreiheit?

Vorteile - aktuell eigentlich keine wirklichen.
Wenn's davon abhängt, ob man sich ein "barriereifrei nach Norm XY" auf die pappen darf oder nicht, dann nimmt man diese Angaben halt mit auf.

MfG ChrisB

[Antipitch]

Hi Chris,
guckst du meine Antwort an Gunnar?! Ich würde es (auch in Bezug auf's W3C als Papst) mal ganz interessant finden, sowas ein bißchen weiterzuführen.

cheers
Antiüitch

[Gunnar Bittersmann]

@@Antipitch:

nuqneH

Laut W3C Spezifikationen ist es bekannterweise "incorrect", Script- und Stylesprachen nicht per meta-Angabe oder http-Header festzulegen

Das gilt ohnehin nur für Inline-JavaScript (in 'on…'-Eventhandlerattributen) bzw. Inline-CSS in ('style'-Attributen). Sowohl das eine wie auch das andere sollte man vermeiden und Struktur (HTML), Verhalten (JavaScript) und Präsentation (CSS) sauber voneinander trennen. Dann stellt sich das Problem der Angabe von Script- und Stylesprachen gar nicht erst.

Qapla'

[Detlef G.]

Hallo Gunnar

… Dann stellt sich das Problem der Angabe von Script- und Stylesprachen gar nicht erst.

Und du bist dir sicher, niemand käme auf die Idee, dort das type-Attribut wegzulassen?

Auf Wiederlesen
Detlef

[Antipitch]

@@Antipitch:

nuqneH

Laut W3C Spezifikationen ist es bekannterweise "incorrect", Script- und Stylesprachen nicht per meta-Angabe oder http-Header festzulegen

Das gilt ohnehin nur für Inline-JavaScript (in 'on…'-Eventhandlerattributen) bzw. Inline-CSS in ('style'-Attributen). Sowohl das eine wie auch das andere sollte man vermeiden und Struktur (HTML), Verhalten (JavaScript) und Präsentation (CSS) sauber voneinander trennen. Dann stellt sich das Problem der Angabe von Script- und Stylesprachen gar nicht erst.

Qapla'

Hi Gunnar,
natürlich. Es geht mir um den Punkt an sich (Theorie _und_ Praxis) und dann um tendenziell nicht strikt kontrollierbare Situationen (z.B. Eventhandler-Angaben und Inline-Styles in Content Management Systemen etc.).

Kurzer Exkurs: Events z.B. sind doch in HTML vorgesehen/ intrinsisch und können mit einem Attribut belegt werden. Wenn nun das vom Attribut-Inhalt aufgerufene Script eine type-Angabe liefert (lokal/ per Instanz ist ja per Spec zulässig), warum dann per meta oder http global deklarieren (müssen)? Logisch-argumentativ ähnlich für Styles: wenn CSS als default festgeschrieben ist, warum ist das Weglassen dann inkorrekt?

Praktisch bin ich natürlich deiner und der von Chris geposteten Meinung, aber ich glaube auch, dass wir ebenso zum Web und seinen Specs beitragen (sollten) wie irgendwelche Leute bei IBM oder SinnerSchrader und dass z.B. dieser Punkt eine Diskussion wert ist. Insbesondere würden mich weiterhin Accessibility-relevante Für-und Widers interessieren...

cheers
Antipitch

[ChrisB]

Hi,

Kurzer Exkurs: Events z.B. sind doch in HTML vorgesehen/ intrinsisch und können mit einem Attribut belegt werden.

Ja - als "Schnittstelle" zu *irgendeiner* Scriptsprache, die - wenn im Browser verfügbar - beim Eintreten bestimmter Ereignisse in Aktion treten soll.
HTML's support for scripts is independent of the scripting language.

Wenn nun das vom Attribut-Inhalt aufgerufene Script eine type-Angabe liefert (lokal/ per Instanz ist ja per Spec zulässig), warum dann per meta oder http global deklarieren (müssen)?

Welches *ist* denn das "aufgerufene" Script?
Wenn du mehrere Arten von Scripten - bspw. im IE JavaScript und VBScript in einem Dokument gleichzeitig verwendest, und die beinhalten jedes eine Funktion namens XYZ - welche davon ist denn jetzt aufzurufen, wenn im HTML irgendwo onclick="XYZ()" steht?

Logisch-argumentativ ähnlich für Styles: wenn CSS als default festgeschrieben ist, warum ist das Weglassen dann inkorrekt?

Es ist nicht als Default festgeschrieben, sondern lediglich ein de facto-Standard.

Insbesondere würden mich weiterhin Accessibility-relevante Für-und Widers interessieren...

Auf Grund der Tatsache, dass die meisten Screenreader o.ä. Assistenz-Programme zum besuchen von Webseiten ihrerseits wieder die Engine eines der bekannten Browser als Untersatz haben, dürften diesbezüglich relevante Probleme auch spärlich bekannt sein; auch diese Diskussion dürfte also eine weitgehend theoretische werden.
Nehmen wir an, ein solcher Screenreader, der sich der IE-Engine bedient, würde zusätzlich noch ein eigenes in VBScript geschriebenes Script in das, was die Engine für ihn parst, hinschleusen - direkt auf HTTP-Ebene als Proxy einspringen, <script src="blubb.vbs" type="..."></script> in den HEAD-Bereich eines HTML-Dokumentes einfügen, um dann anschliessend auf bestimmte Ereignisse wie einen Klick hin gesondert reagieren zu können, so wie es die Aufbereitung des Dokumentes in Audio-Form erfordert ... Dass die Abarbeitung eines Events, bspw. onclick, der in den verschiedenen Scripten zu unterschiedlichen Reaktionen führen würde (ein mal den vom Seitenautor gewünschten, und ein mal zu den vom Screenreader gewünschten), dann zu Problemen führen könnte, die vom Erstellen eines "normalen" Webdokumentes, das über einen der herkömmlichen und gängigen Browser betrachtet wird, gar nicht bekannt sind - selbst wenn dort nicht der Script-Type für inline-Eventattribute explizit definiert wird, "hat schon immer so funktioniert", basta - ist zumindest in der Theorie vorstellbar.

MfG ChrisB

[Antipitch]

Hi Chris,
dank dir für die Info!

cheers
Antipitch