nicht angemeldet
Hi Martin,
ich antworte mal in zwei Teilen (weil mich das Foren-Script für "geschwätzig" hält - tss, keine Ahnung wie es darauf kommt ...)!
Es kommt immer drauf an, was die Besucher wollen. Wollen sie Information, oder wollen sie ästhetisches Design? Solange man beides zugleich haben kann, okay.
ACK. Aber die Entscheidung darüber sollte doch beim User liegen, oder?ja, sehe ich auch so. Ein Autor, der sich drei Ohren abbricht, um doch irgendwie die Layout-Vorstellung zur Anwendung zu bringen, die er für gut hält, passt dann aber nicht dazu. Und den Eindruck habe ich bei dir zumindest teilweise: Du hältst eine bestimmte Darstellung für richtig, also versuchst du intensiv, diese Darstellung zu "erzwingen".
Denn je nach "Situation" (Internetanbindung, verwendete Hardware, etc.) habe ich völlig unterschiedliche Wünsche.
Ja, keine Frage. Nur klaffen die Wünsche des Autors und die des Nutzers oft deutlich auseinander.
Ja, unbestritten. Ich bezog das aber auf mich als Nutzer und_nicht_als Autor in diesem Zusammenhang.
Beispiel: Wenn ich eine Seite von meinem Smartphone mit Datenverbindung übers Mobilfunknetz aus aufrufe, dann habe ich ganz andere Priritäten, als wenn ich dieselbe Seite von zu Hause auf ansurfe. Nur habe ich derzeit ja de facto keine "offizielle" Möglichkeit dies dem Server vorab mitzuteilen ...!
Da will ich einerseits zustimmen, andererseits widersprechen. Zustimmen insofern, als man sicher nicht auf jede "exotische" Konfiguration eingehen kann und in Kauf nimmt, dass *sehr* untypische Fälle mal unter die Räder kommen.
So, jetzt sind wir bei einem (meiner) "Knackpunkte" ..., wo bei mir seit geraumer Zeit eher Unverständnis vorherrscht.Ich bin gespannt ...
Erste Frage, die sich mir in dem Zusammenhang stellt: Warum ist es überhaupt erforderlich, dass es (mal abgesehen von individuell manipulierten) überhaupt eine derartige Vielzahl von UAs geben muss?
Ist es nicht. Der User-Agent-String ist streng nach der HTTP-Spezifikation überhaupt nicht nötig,
Wobei jeder mir bekannte auch nur halbwegs verbreitete Browser diesen mitsendet. Stellt sich mir also folglich die Frage, warum ihn dann nicht (in nicht manipulierbarer Version) mit in die Spezifikation aufnimmt?
sondern nichts weiter als schmückendes Beiwerk im Protokoll. Aber selbstverständlich nutzen die Browserhersteller gern die Möglichkeit, hier nochmal den Produktnamen und Detailinformationen unterzubringen und in die Welt hinauszubrüllen.
Eine zuverlässige Information war das aber noch nie.
Und warum macht man keine daraus? Das (zuverlässige) Wissen über das zugrundeliegende Betriebssystem und die Browser-Engine würde zumindest einiges vereinfachen. Natürlich nicht restlos alle Prüfungen "verstehst du das?" überflüssig machen.
Und warum gibt es nicht neben einer "manipulierbaren" Variante auch eine nicht manipulierbare?
Wozu? Unterschiedlich ausgeprägte Fähigkeiten z.B. in der Darstellung werden dadurch berücksichtigt, dass der eine Browser bestimmte CSS-Eigenschaften interpretiert, ein anderer eben nicht. Für ganz grobe Unterschiede gibt es Media Queries (für die Browser, die sie unterstützen). Und wenn man Ressourcen in generell unterschiedlichen Datenformaten vorhalten und individuell ausliefern will, könnte man den Accept-Header auswerten. So erkennt man ja beispielsweise einen alten IE, bei dem es keinen Sinn ergibt, XHTML als application/xhtml+xml auszuliefern.
Also was vermisst du noch?
Überlege nur mal wieviel Traffic/ Datenvolumen man einsparen könnte, wenn der Browser u.a. Informationen über die aktuelle Viewportgröße und Javascript (on/off) mitliefern würde. Oder speziell bei den "mobilen Endgeräten" zusätzlich Informationen über die aktuelle Datenanbindung, Touchscreen (ja/nein) und einige andere Dinge, die mir jetzt spontan natürlich nicht einfallen. ;-)
Das Mehr an Daten, welches durch diese Informationen im Header anfällt würde man imho doppelt und dreifach (oder noch mehr) wieder einsparen, dadurch dass man wesentlich kleinere, weil besser angepasste Inhalte ausliefern könnte.
Rest siehe Teil 2
suit
Der Martin
JürgenB