Gunther: HTTP-Header für eine serverseitige Lösung des Problems

Beitrag lesen

Hi!

Und das "beruhigt" mich ehrlich gesagt, denn normalerweise erhält man auf diese Vorschläge hin so Reaktionen wie die von suit oder Martin ...! ;-)

Was soll das jetzt heissen?

Das was ich geschrieben habe - dass die meisten Leute der Meinung sind, dass das keine "geeignete" Lösung ist - aus welchen Gründen auch immer.

Hast du eine praktische Lösung für das Problem unbekannter Schemata die sich auf einem Web lösen lässt?

Welches Scheme von einem Browser unterstützt wird hat im HTTP-Header (Accept) weder im Request noch im Response etwas verloren, da der Browser selbst oft garnicht dafür zuständig ist.

Wenn das mailto:-Schema registriert ist, muss es nicht unbedingt der Browser sein der es bearbeitet - was nutzt es also dem Browser diese information zu kennen?

Unter Android ist es sogar so, dass nichtmal das http-Scheme direkt vom Browser verarbeitet wird - das erledigt das OS und reicht es dann erst an eine App weiter - man wird (wenn man das möchte) sogar jedes mal gefragt was er jetzt damit tun soll.

Erstens rede ich nicht nur von Schemes, und zweitens ist es völlig egal, wer oder was letztendlich dafür zuständig ist. Es ist Sache des Browsers diese Dinge über seine "Betriebsumgebung" zu wissen - tut er letztendlich ja auch. Nur leider behält er dies größtenteils für sich, oder lässt sich diese Dinge erst clientseitig entlocken.

Darum ist für die Lösung dieses Problems der HTTP-Header völlig unpraktikabel - ebenso ist das Kaum ein Ding, welches man per CSS lösen müsste - es hat mit der Formatierung nur bedingt etwas zu tun. Wäre vielleicht aber ganz cool wenn es einen "unknow-scheme"-Attribut-Selektor gäbe, den man auf Attribute anwenden kann, deren Wert ein URI sein muss - das betrifft aber nur die Darstellung, da wären sie trotzdem noch - es muss wie schon von Martin und mir festgestellt eine API her die soetwas regelt, die man befragen kann und die einem sagt ob und was das System mit dem genannten Scheme-Werten etwas anfangen kann oder nicht.

Sorry, aber scheinbar reden wir aneinander vorbei. Deine API-Lösung ist doch wieder eine rein clientseitige Geschichte, und das halte ich schon vom Grundsatz her für "nicht hilfreich"!

Hilfreich wäre es, wenn der Browser bereits dem Server mitteilen würde, "womit" er etwas anfangen kann, damit er anschließend auch nur das geliefert bekommt.

Ich verstehe auch ehrlich gesagt nicht, wo du da den großen Unterschied zu bereits existierenden Headern, wie dem Accept Language Header siehst!?

Du würdest es ja vermutlich auch nicht für sinnvoll erachten, jedem Client alle 5 Sprachvarianten auszuliefern, damit er sich dann die passende raussucht, oder?

Und wie sich in jüngster Vergangenheit herausgestellt hat, gibt es aufgrund der verschiedensten neuen Geräte auch eine Vielzahl neuer Funktionalitäten, die größtenteils Unterschiede im Markup erfordern würden.

Der Internet-Explorer stellt dies wie schon gesagt per JavaScript grundlegend zur Verfügung - aber eben nicht mit "ja/nein" sondern nur über eine Krücke oder einen Umweg.

Solange Javascript deaktivierbar ist, ist das für mich keine "brauchbare" Lösung! Zumal damit das "Problem" jedem Alles auszuliefern in keinster Weise beseitigt wird.

Meiner bescheidenen Meinung nach ist das weder ein Problem von HTML, noch HTTP noch CSS.

Das ist doch auch völlig egal, wessen Problem das ist. Letztendlich hat man als Autor das Problem, dass man nicht in der Lage ist, jedem User die bestmögliche Usability zu liefern.
Und von daher sollte eine möglichst schnelle und einfache Lösung für das Problem her ...!

Zu den Dingen, die imho interessant zu wissen wären, gehören u.a.

  • Pixelratio (wäre hilfreich für Images im Quelltext)
  • GPS/ Geolocation, sprich ob Standortdaten verfügbar sind oder nicht
  • Art der Verbindung
  • Telefonie
  • SMS

Und ggf. auch Infos darüber, welche CSS Module unterstützt werden.

Gruß Gunther