ChrisB: Script und Style Sprache per meta/ http header festlegen?

Beitrag lesen

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

--
Light travels faster than sound - that's why most people appear bright until you hear them speak.