Select Option Firefox vs Chrome

[dedlfix]

Tach!

Validität ist kein Selbstzweck.

Nein, wahrlich nicht. Aber es gibt Gründe und eben jene sind in diesem Fall tatsächlich verletzt. Beispilsweise wenn man die Maschinenlesbarkeit anführt, die für Suchmaschinen wichtig ist.

Wenn man Gründe hat, eine SPA oder andere ganz erheblich im DOM rumfummelnde Webseite zu erstellen, spielt die statische Analyse durch Spider üblicherweise eine untergeordnete bis gar keine Rolle - zumindest für den Teil, der diesen mehr oder weniger heftigen Veränderungen unterliegt.

Die Maschinenlesbarkeit an sich ist ja nicht zwangsläufig gefährdet. Die Maschine muss sich aber am DOM orientieren und nicht am Quellcode. Wenn eine assistive Technik im DOM liest, wird alles gut, denn die SPA muss ja für den Browser und damit auch für die assistive Technik verständliche Ergebnisse erzeugen. Ob darin ungenormte Elemente vorkommen oder nicht, spielt dabei keine Rolle - darf dabei keine Rolle spielen. Ein Browser wird diese ignorieren, so wie er es schon immer getan hat, und andererseits sind diese Elemente ja auch gar nicht direkt dafür vorgesehen, vom Anwender gesehen zu werden. Das sind nur Anweisungen für die SPA. AngularJS verhindert ja beispielsweise auch nicht, dass aria-Attribute eingefügt werden. Im Gegenteil bringt es sogar ein Modul mit, mit dem diese Attribute angular-like in die entsprechenden (DOM-)Elemente eingefügt werden können. Andererseits werden, wenn man dieses Modul verwendet, einige (sinnvolle) Attribute auch automatisch eingefügt, wenn sie der Entwickler nicht selbst angegeben hat.

Vergleich eine SPA mal mit einer Desktop-Anwendung, da muss auch keine (assistive) Maschine den Qellcode oder den Maschinencode lesen. Quellcode kommt in den meisten Fällen auch gar nicht zum Anwender, weil der beim Entwickler verbleibt, und der Maschienncode ist nur für die CPU von Interesse. Wichtig ist nur, was auf dem Bildschirm oder anderen Ausgabemedien erscheint. Und auch da gibt es Unterschiede. Bei einem Spiel ist oft gar nicht möglich, dass eine assisitive Technik das sinnvoll für andere Sinnesorgane übersetzen kann, bei Textanwendungen ist das schon eher machbar. Das kann nun aber nicht zur Schlussfolgerung haben, dass man keine Spiele mehr erstellen sollte, weil ein Teil der Menschen sie bedauerlicherweise nicht spielen kann.

Zurück zum HTML & Co. Wenn es nicht (nur) um assistive Techniken geht, sondern den Spidern was zum Futtern zu geben, muss man sich was anderes einfallen lassen, als die SPA in ihr selbst vorzustellen. Für den Zweck kann man immer noch eine gute alte statische Seite (oder eine statisch sinnvoll lesbare) als Landing Page erstellen. - Und auch das braucht man nicht für sämtliche Einsatzzwecke von SPAs. Es gibt genügend Anwendungen, die im Browser laufen, aber nur firmenintern zur Verfügung stehen sollen und die öffentlichen Spider überhaupt nichts angehen.

Da ist das...

Das Ziel von Angular-durchsetztem HTML-Code ist nicht, dass der Browser alles korrekt versteht, denn Angular kommt noch daher und manipuliert das DOM entsprechend den Angular-Anweisungen.

...nur ein schwacher Trost, da das dann (und nur dann) geschieht, sobald JavaScript geladen und interpretiert wurde. Wehe, wenn das nicht passiert (wie zum Beispiel, wenn nur ein Suchmaschinen-Crawler drüberläuft), denn dann ist das Markup tatsächlich kaputt. Meiner Meinung nach ist das genau das, was ein Framework eigentlich nicht tun sollte.

Du gehst nicht von für SPAs vorgesehenen Einsatzszenarien aus, sondern von öffentlichen Webseiten zu allgemeinen Informationszwecken. Das ist eine andere Baustelle.

Ein Framework sollte nach meinem Verständnis den Zugriff auf oft benötigte Elemente (nicht im HTML-Sinn) erleichtern, dient also als enhancement auf Basis der grundlegenden Technologie, auf der das Framework aufsetzt. Insbesondere ist es sehr problematisch, wenn ein JS-Framework verlangt oder dazu verleitet, invaliden HTML-Code zu kreieren, das würde ich als problematischen Seiteneffekt bezeichnen - ganz abgesehen davon, dass JavaScript aus guten Gründen sinnvollerweise als progressive enhancement eingesetzt werden sollte, das betrifft auch JS-Frameworks. Immerhin predigt man aus Gründen schon länger, dass JS unobtrusive eingesetzt werden sollte, was durch Angular dann offenbar auch nicht sinnvoll unterstützt wird.

Abgesehen davon, dass das deutsche Wort für side effects Nebenwirkungen heißt ... auch unobtrusive Javascript ist kein Selbstzweck, sondern hat ein genauso begrenztes Einsatzgebiet, wie SPAs ihrerseits eins haben. Und diese Einsatzgebiete müssen sich nicht zu 100% überschneiden.

Was bringt es außerdem für Vorteile, wenn man (im Falle von Attributen, für Elemente geht das nicht) nicht ng-attribute sondern data-ng-attribute nimmt? Dann hast du außer validem HTML immer noch keinen direkten Nutzen für Spider oder assistive Techniken. Es bleibt weiterhin ein Attribut, das lediglich für die Interpretation durch Angular vorgesehen ist. Alles was der Browser zur Anzeige bringen soll, wird ja weiterhin in HTML etc. übersetzt und steht dann DOM-lesenden Techniken zur Verfügung. Nur eben nicht den Spidern, die dafür keine Zielgruppe sind.

Trotzdem denke ich, dass an Martins Einschätzung

Die produzieren mit ihren Phantasie-Attributen bewusst invalides HTML? Das ist in der Tat traurig.

nicht viel relativierungsbedürftig ist.

Relativierungsbedürftig finde ich sie auch nicht, sondern von falschen, zu eng begrenzten Voraussetzungen ausgehend, womit sie in weiten Teilen ungeeignet ist, die komplette aktuelle Vielfalt zu beurteilen. Das muss nicht relativiert, sondern durch Wissen um aktuelle Gegebenheiten und weitere Anwendungsfälle erweitert werden.

Zwar mag der Schaden verhältnismäßig gering sein, trotzdem bin ich davon überzeugt, dass das Konzept, auf das in Angular dann scheinbar in diesem speziellen Fall gesetzt wird (ich habe keine Erfahrung mit Angular, kann mich also nur auf den Eindruck berufen, den ich hier gewonnen habe), kaputt oder mindestens ungünstig/suboptimal ist...

Das ist wieder zu engstirnig gedacht. Niemand kommt allein durch die Existenz von SPAs für ganz bestimmte Anwendungsfälle zu Schaden. Sie erweitern die Möglichkeiten für browserbedienbare Anwendungsfälle. Und genausowenig, wie sämtliche statisch lesbare Seiten für die Öffentlichkeit zugänglich und vorgesehen sind, gilt das auch für SPAs. Nicht umsonst gibt es die robots.txt und andere Dinge, mit denen ganz bewusst auch valider HTML-Code durch das maschinelle Lesen (in dem Falle Spider) ausgeschlossen werden soll.

Kurzfassung: Maschinenlesbarkeit ist auch kein Selbstzweck.

dedlfix.