Kleinere Version einer Webseite

[Deus Figendi]

Hallo zusammen,
ersteinmal: "huch" das self-Forum sieht ja ganz anders aus, ich war wohl echt ne Weile nicht mehr hier ^^

Vorneweg: Ich rede hier über ein privates Projekt, das bedeutet u.a. ich muss mich nicht an seltsame Kundenwünsche halten wie "muss im IE 5.5 funktionieren" oder "der Pixel ist mir zu links".

Also ich habe eine kleine Webseite gebaut und die ist erm groß :D Also genauer ist sie rund acht Megabyte groß, wenn man sie erstmals (mit leerem Cache) aufruft. Was daran liegt, dass eine große Bannergrafik und eine große Hintergrundgrafik geladen werden, beide jeweils über 3MB groß (und ja ich hab die schon optimiert ;D)
Ich bin auch allgemein recht zufrieden mit dem Layout, es ist ein bisschen oldscool, aber das ist schon okay, ich find's hübsch und ich komme damit klar, dass es pre-cache einen Moment dauert bis die Seite vollständig da ist, benutzbar ist sie von Anfang an.

Ein bisschen tuts mir aber leid um die Leute da draußen, die mit Volumen-Tarifen leben und die vielleicht nur 2GB oder sogar nur 100MB im Monat zur Verfügung haben. Ich würde also gerne eine Art minimierte Webseite anbieten (wobei RSS schon da ist...), bei der diese beiden Grafiken durch deutlich kleinere ersetzt werden.
Für das Hintergrundbild, ist das noch sehr machbar einfach Medien-Gebundenes Stylesheet und wer mit dem Telefon kommt bekommt eine bedeutend kleinere Grafik ausgeliefert. Nicht erschlagen habe ich damit natürlich die Leute mit LTE-Routern oder Mobilfunk-Sticks an ihren Notebooks. Denn die lesen ja korrekterweise immernoch das screen-Sheet und nicht das handheld-Sheet.

Darüber hinaus das Banner... das ist einfach ein img-Element, ich erkläre gleich warum… und folglich ist das im HTML-Code und nicht im CSS und daher kann ich sie nicht einfach mit media-queries ersetzen... (hmm oder kann ich doch? Wenn ich 2 Grafiken setze und einmal dieses und einmal jenes display:none; ? Wird die Grafik dennoch geladen?)
Das Banner ist aus folgendem Grund ein IMG-Element und kein h1 mit background oder so...

  
#head_banner {  
	display:block;  
	max-width:100%;  
	max-height:333px;  
	min-height:100px;  
}

Anders gesagt: Die Grafik **möchte** gerne ihre volle Breite von 1.800 Pixel ausnutzen (wobei mir einfällt dass die Hälfte sicher ausreichte), wird durch die Breite des Browserfensters aber darin beschränkt. Ich finde das sieht gut aus und passt sich wunderbar dynamisch an und so fort. Ich wüsste nicht dass oder wie man mit CSS eine Hintergrundgrafik skallieren kann... sonst täte ich dies (das Bild ist ja eigentlich kein "Inhalt").

So, mein Gedanke war nun irgendeine Art von UA-Sniffing oder so, aber ich würde halt am Liebsten auch die Art der Verbindung (Mobil oder Kabel) ermitteln und so fort und aufgrund dessen dann die eine oder die andere Grafik anzeigen. Das kann Client- oder Serverseitig geschehen, das ist mir egal. Aber UA-Sniffing ist eben auch so... ew pfui und unzuverlässig und wie angedeutet auch eigentlich unzureichend.

Daher bin ich allgemein auf der Suche nach einer Lösung für eine minimalistische(re) Webseite, wie macht man das 2013? Wie gesagt, media-query und dann dieses oder jenes Bild ein-/ausblenden kam mir gerade während ich diesen Beitrag schrieb, hilft mir aber nur wenn Browser so ein Bild wenn es nicht gezeigt wird auch wirklich nicht laden.

Vielen Dank schonmal für alle Anregungen :)

[Jörg Reinholz]

Hier steht quasi alles auf einmal:

http://line25.com/tutorials/create-a-responsive-web-design-with-media-queries

Jörg Reinholz

[Matthias Apsel]

Om nah hoo pez nyeetz, Deus Figendi!

ersteinmal: "huch" das self-Forum sieht ja ganz anders aus, ich war wohl echt ne Weile nicht mehr hier ^^

≋
^^ Augenbrauen in die Höhe zieh? ^~^ mit Nase rümpfen oder ^ ^ Stirn in Falten?
Wie dem auch sei: Willkommen zurück.

Ich wüsste nicht dass oder wie man mit CSS eine Hintergrundgrafik skallieren kann... sonst täte ich dies (das Bild ist ja eigentlich kein "Inhalt").

background-size scheint mir ein angemessener Name einer solchen Eigenschaft zu sein.

Matthias

[micha2013]

Hi,

... über 3MB groß (und ja ich hab die schon optimiert ;D)

bist du dir da sicher? Vielleicht kannst Du noch die Farbtiefe herunter setzen.

Ein bisschen tuts mir aber leid um die Leute da draußen, die mit Volumen-Tarifen leben und die vielleicht nur 2GB oder sogar nur 100MB im Monat zur Verfügung haben.

das begrenzte Transfervolumen ist nicht zwingend der Knackpunkt, sondern die Bandbreite. Wenn man zu lange warten muss, bis das Bild geladen wurde ... macht einen schlechten Eindruck.

... wie man mit CSS eine Hintergrundgrafik skallieren kann...

leider hat eine Skalierung nichts mit der Übertragung zu tun.

Als Fazit bleibt mir nur die Empfehlung, das Bild einfach kleiner zu machen.

[Deus Figendi]

Ein bisschen tuts mir aber leid um die Leute da draußen, die mit Volumen-Tarifen leben und die vielleicht nur 2GB oder sogar nur 100MB im Monat zur Verfügung haben.
das begrenzte Transfervolumen ist nicht zwingend der Knackpunkt, sondern die Bandbreite. Wenn man zu lange warten muss, bis das Bild geladen wurde ... macht einen schlechten Eindruck.

Korrekt, eigentlich wüsste ich auch gerne die Transferrate und das Datenvolumen und die Rechnerleistung XD dann kann ich mich prima daran anpassen ^.^

Naja ich denke wie sooft wenn man den Zielclient nicht 100%ig kennt muss man eben hier und da mit Abstrichen leben wie eben "dann sieht's im IE6 halt blöd aus"

... wie man mit CSS eine Hintergrundgrafik skallieren kann...
leider hat eine Skalierung nichts mit der Übertragung zu tun.

Das ist richtig, da ging es aber darum, dass ich wenn ich das mit CSS löse anstatt direkt im Markup... dann kann ich Gerätespeziefisch unterschiedliche Grafiken ausliefern... wieder erfasse ich nicht die Notebooks mit UMTS-Stick im EDGE-Land, aber... naja immerhin die Schlau-Telefone und Mobiltelefone und PDAs und so.

[micha2013]

Moin,

alternativ zu den genannten Punkten zur Optimierung könnte ich mir vorstellen, eine Basisgrafik anzubieten, wo nur jede zweite Pixel-Zeile etwas darstellt (Jalousieeffekt?). Einfach nur um die Seite schnell anzuzeigen. Und darüber hinaus dann im Hintergrund versuchen, das große Bild nachzuladen.

[Gunther]

Hallo!

Also ich habe eine kleine Webseite gebaut und die ist erm groß :D Also genauer ist sie rund acht Megabyte groß, wenn man sie erstmals (mit leerem Cache) aufruft.

Sorry, aber dazu kann ich nur sagen, dass ist ungeachtet jedweder Argumentation definitiv viel zu groß für eine "normale" Webseite!

Was daran liegt, dass eine große Bannergrafik und eine große Hintergrundgrafik geladen werden, beide jeweils über 3MB groß (und ja ich hab die schon optimiert ;D)

Noch schlimmer - mehr als 6 MB, die nichts mit dem eigentlichen Inhalt zu tun haben ...!?

Ich bin auch allgemein recht zufrieden mit dem Layout, es ist ein bisschen oldscool, aber das ist schon okay, ich find's hübsch und ich komme damit klar, dass es pre-cache einen Moment dauert bis die Seite vollständig da ist, benutzbar ist sie von Anfang an.

Wie lange ist für dich denn "ein Moment"!?
Smartphone User mit EDGE ..., und tschüss! ;-)

Ein bisschen tuts mir aber leid um die Leute da draußen, die mit Volumen-Tarifen leben und die vielleicht nur 2GB oder sogar nur 100MB im Monat zur Verfügung haben. Ich würde also gerne eine Art minimierte Webseite anbieten (wobei RSS schon da ist...), bei der diese beiden Grafiken durch deutlich kleinere ersetzt werden.

Das würde ich dir generell empfehlen!

Für das Hintergrundbild, ist das noch sehr machbar einfach Medien-Gebundenes Stylesheet und wer mit dem Telefon kommt bekommt eine bedeutend kleinere Grafik ausgeliefert.

Wie stellst du denn per "Medien-Gebundenem Stylesheet" fest, "wer mit dem Telefon kommt"!?
Falls du den Medientyp "Handheld" meinst, muss ich dich leider enttäuschen. Die allermeisten Browser auf mobilen Endgeräten unterstützen diesen Medientyp nicht, sondern "reagieren" wie jeder Desktop-Browser nur auf "Screen".

Nicht erschlagen habe ich damit natürlich die Leute mit LTE-Routern oder Mobilfunk-Sticks an ihren Notebooks. Denn die lesen ja korrekterweise immernoch das screen-Sheet und nicht das handheld-Sheet.

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.

Darüber hinaus das Banner... das ist einfach ein img-Element, ich erkläre gleich warum… und folglich ist das im HTML-Code und nicht im CSS und daher kann ich sie nicht einfach mit media-queries ersetzen... (hmm oder kann ich doch? Wenn ich 2 Grafiken setze und einmal dieses und einmal jenes display:none; ? Wird die Grafik dennoch geladen?)
Das Banner ist aus folgendem Grund ein IMG-Element und kein h1 mit background oder so...

#head_banner {
display:block;
max-width:100%;
max-height:333px;
min-height:100px;
}

> Anders gesagt: Die Grafik \*\*möchte\*\* gerne ihre volle Breite von 1.800 Pixel ausnutzen (wobei mir einfällt dass die Hälfte sicher ausreichte), wird durch die Breite des Browserfensters aber darin beschränkt. Ich finde das sieht gut aus und passt sich wunderbar dynamisch an und so fort. Ich wüsste nicht dass oder wie man mit CSS eine Hintergrundgrafik skallieren kann... sonst täte ich dies (das Bild ist ja eigentlich kein "Inhalt").  
  
Auch hier sehe ich deine Vorgehensweise höchst skeptisch, denn nur wenn eine Grafik zum eigentlichen Inhalt gehört, ist IMHO das IMG Tag angebracht. Alles andere ist "Dekoration" und gehört ins CSS.  
Das macht insbesondere auch für den Druck einen entscheidenden Unterschied.  
  

> So, mein Gedanke war nun irgendeine Art von UA-Sniffing oder so, aber ich würde halt am Liebsten auch die Art der Verbindung (Mobil oder Kabel) ermitteln und so fort und aufgrund dessen dann die eine oder die andere Grafik anzeigen. Das kann Client- oder Serverseitig geschehen, das ist mir egal. Aber UA-Sniffing ist eben auch so... ew pfui und unzuverlässig und wie angedeutet auch eigentlich unzureichend.  
  
UA Sniffing ist so ungefähr das Einzige, was du serverseitig tun kannst. Allerdings kannst du mit den so gewonnenen Informationen wenig bis gar nichts anfangen.  
  
Eine weitere Möglichkeit ist per Javascript etwas über die Fähigkeiten des jeweiligen Browsers und der Hardware herauszufinden.  
Ein Beispiel ist etwa [Modernizr](http://modernizr.com/).  
  
  

> Daher bin ich allgemein auf der Suche nach einer Lösung für eine minimalistische(re) Webseite, wie macht man das 2013? Wie gesagt, media-query und dann dieses oder jenes Bild ein-/ausblenden kam mir gerade während ich diesen Beitrag schrieb, hilft mir aber nur wenn Browser so ein Bild wenn es nicht gezeigt wird auch wirklich nicht laden.  
  
Siehe: [http://timkadlec.com/2012/04/media-query-asset-downloading-results/](http://timkadlec.com/2012/04/media-query-asset-downloading-results/)  
  
Bei deinen "Mega-Grafiken" solltest du evt. auch mal über Möglichkeiten von [SVG](https://www.google.de/search?q=w3c+svg) nachdenken.  
  
Bei sehr großen Hintergrundgrafiken (von denen ich prinzipiell immer abraten würde) böte sich ggf. auch noch die Möglichkeit an, diese in mehrere kleine(re) Teile zu zerlegen und per [multiple backgrounds](https://www.google.de/search?q=css+multiple+backgrounds) später wieder zusammenzufügen. So ließe sich die Downloadzeit wenigstens etwas verringern, da mehere Dateien parallel heruntergeladen werden können.  
  

> Vielen Dank schonmal für alle Anregungen :)  
  
Aber nochmal: Eine Webseite, und insbesondere eine Startseite, sollte ohne ganz triftigen Grund nicht größer als max. 1 MB sein!  
  
Mehr als 6 MB für Dinge, die nicht zum Inhalt der Seite gehören, ist ein absolutes No-Go! Selbst in Zeiten von DSL + LTE widerspricht das allen Grundlagen von "gutem Webdesign".  
  
Gruß Gunther

[Deus Figendi]

Hallo Gunther,
hach, ein bisschen hab ich euch auch vermisst :)

Noch schlimmer - mehr als 6 MB, die nichts mit dem eigentlichen Inhalt zu tun haben ...!?

Jep, aber während die laden ist die Webseite durchaus schon benutzbar.

Wie stellst du denn per "Medien-Gebundenem Stylesheet" fest, "wer mit dem Telefon kommt"!?
Falls du den Medientyp "Handheld" meinst, muss ich dich leider enttäuschen. Die allermeisten Browser auf mobilen Endgeräten unterstützen diesen Medientyp nicht, sondern "reagieren" wie jeder Desktop-Browser nur auf "Screen".

Ja, das ist mir bewusst, aber ich ignoriere diesen Umstand, denn ich halte das für einen Fehler dieser Browser/Benutzer. Wenn ein Gerät meint nicht die Daten annehmen zu wollen, die ich extra für dieses Gerät bereitgestellt habe ist das nicht mein Fehler, denn soweit ich mich erinnere passt die Beschreibung sehr gut.

Intended for handheld devices (typically small screen, limited bandwidth).

Wenn ein Drucker meint er müsse 'screen' verwenden ist das ja auch nicht meine Sorge ;D
(defacto ist das halt einer der Unterschiede zwischen privater Webseite und einer mit Kunde im Nacken, ich kann auf die Realität scheißen und ein bisschen dem Idealismus fröhnen).
Die Spezifikation sagt nicht "jaaa handheld gilt aber nicht bei multitouch oder wenn es den Browser auch für Desktop-Rechner gibt".
Anders gesagt: **Ich** bin es imho nicht, der sich **nicht** an die Specs hält.

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.

*seufz* ja, man wird doch noch träumen dürfen ;D (wie gesagt sagt "handheld" immerhin schon was über die Bandbreite und **eigentlich** müssten Netbooks umschalten wenn sie ins EDGE-Land kommen)

Auch hier sehe ich deine Vorgehensweise höchst skeptisch, denn nur wenn eine Grafik zum eigentlichen Inhalt gehört, ist IMHO das IMG Tag angebracht. Alles andere ist "Dekoration" und gehört ins CSS.
Das macht insbesondere auch für den Druck einen entscheidenden Unterschied.

Jep, hab ich nun auch aufgrund von Matthias' Hinweis geändert.

UA Sniffing ist so ungefähr das Einzige, was du serverseitig tun kannst. Allerdings kannst du mit den so gewonnenen Informationen wenig bis gar nichts anfangen.

Najaaa... ich dachte ggf. daran IP-Blöcke mobilen Providern zuweisen zu können... zum Beispiel. Aber auch das ist dirty.

Daher bin ich allgemein auf der Suche nach einer Lösung für eine minimalistische(re) Webseite, wie macht man das 2013? Wie gesagt, media-query und dann dieses oder jenes Bild ein-/ausblenden kam mir gerade während ich diesen Beitrag schrieb, hilft mir aber nur wenn Browser so ein Bild wenn es nicht gezeigt wird auch wirklich nicht laden.

Siehe: http://timkadlec.com/2012/04/media-query-asset-downloading-results/

mhm, ich werde das berücksichtigen, danke

Bei deinen "Mega-Grafiken" solltest du evt. auch mal über Möglichkeiten von SVG nachdenken.

hmmm wahrscheinlich ungeeignet, aber ich kann mal damit herumspielen, wäre nicht uninteressant.

Aber nochmal: Eine Webseite, und insbesondere eine Startseite, sollte ohne ganz triftigen Grund nicht größer als max. 1 MB sein!

Mehr als 6 MB für Dinge, die nicht zum Inhalt der Seite gehören, ist ein absolutes No-Go! Selbst in Zeiten von DSL + LTE widerspricht das allen Grundlagen von "gutem Webdesign".

Ich mach' halt schlechtes Webdesign ;D
Nee im Ernst, daher bitte ich euch ja um Hilfe, auf 1MB werde ich wohl kaum kommen, aber wenigstens um die Hälfte werde ich es drücken können aufgrund der Hinweise in diesem Faden denke ich.

[Der Martin]

Hallo,

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.
*seufz* ja, man wird doch noch träumen dürfen ;D (wie gesagt sagt "handheld" immerhin schon was über die Bandbreite und **eigentlich** müssten Netbooks umschalten wenn sie ins EDGE-Land kommen)

nein, das müssten sie eigentlich nicht.
Denn es ist ja der Browser, der sich einen der angebotenen Media Types raussucht. Und das soll er aufgrund seiner Anzeigeeigenschaften und -fähigkeiten tun. Über die Art und Qualität der Datenverbindung weiß der nämlich nichts. Es ist also ein Trugschluss, wenn man von einem Media Type (z.B. handheld) auf die Bandbreite der Übertragung schließt. Gunthers Beispiel mit dem Notebook zeigt das IMO recht anschaulich.

UA Sniffing ist so ungefähr das Einzige, was du serverseitig tun kannst.

Aber auch das lässt keinerlei Rückschlüsse auf die Bandbreite zu. Selbst wenn du das System damit als Chrome auf Android identifizierst und daher mit an Sicherheit grrnzender Wahrscheinlichkeit von einem Smartphone ausgehen kannst, könnte dieses Smartphone im Moment auch ein vorhandenes schnelles WLAN nutzen und hätte damit eine ählich große Bandbreite wie ein stationärer Desktop-PC zur Verfügung.

Najaaa... ich dachte ggf. daran IP-Blöcke mobilen Providern zuweisen zu können... zum Beispiel. Aber auch das ist dirty.

Das wäre aber, so wie ich es im Moment sehe, das einzige Kriterium, das einen zumindest qualitativen (aber nicht quantitativen) Rückschluss aif die Bandbreite zulässt.

Nee im Ernst, daher bitte ich euch ja um Hilfe, auf 1MB werde ich wohl kaum kommen

Warum nicht? Wenn ich bedenke, dass man auch Fotos in der 5MP-Klasse als JPEG auf etwa 300..500kB komprimiert bekommt, ohne dass die Qualität allzusehr leidet, solltest du das mit deinen Grafiken eigentlich auch schaffen. Eventuell könntest du auch zunächst eine bewusst stark komprimierte Fassung laden (~100kB oder noch weniger), und die hochwertige (und damit mehrere MB schwere) Fassung erst auf ausdrücklichen Wunsch.

So long,
 Martin

[Deus Figendi]

Hallo,

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.
*seufz* ja, man wird doch noch träumen dürfen ;D (wie gesagt sagt "handheld" immerhin schon was über die Bandbreite und **eigentlich** müssten Netbooks umschalten wenn sie ins EDGE-Land kommen)

nein, das müssten sie eigentlich nicht.
Denn es ist ja der Browser, der sich einen der angebotenen Media Types raussucht. Und das soll er aufgrund seiner Anzeigeeigenschaften und -fähigkeiten tun. Über die Art und Qualität der Datenverbindung weiß der nämlich nichts. Es ist also ein Trugschluss, wenn man von einem Media Type (z.B. handheld) auf die Bandbreite der Übertragung schließt. Gunthers Beispiel mit dem Notebook zeigt das IMO recht anschaulich.

Das ist im Kern korrekt, sagt jetzt aber nicht warum sie das nicht müssten. Browser sind normalerweise Anwendungsprogramme mit ausreichend Hardwarezugriff, sie können die Art aktuellen Verbindung kennen (also ob Gigabit-LAN, WLAN, LTE oder GPRS), die sie zum nächsten Zugriffspunkt (Heimrouter, DSLAM, Sendemast...) haben. Und sie können auch permanent ihren derzeitigen Durchsatz messen und daraus Rückschlüsse ziehen (sie wissen zwar "WLAN / 54Mbit/s" aber können ja nicht ahnen, dass da blos nen EDGE-Phone teathert).
Doch ich sehe die Browser allgemein absolut in der Lage das einzuschätzen und im Sinne des W3C "müssten" sie dann eigentlich andere mediaqueries verwenden. Ich kann aber durchaus nachvollziehen, dass sie es nicht tun. Gunnars Gedanke mit HTTP-Headern finde ich aber dennoch sehr gut und den hatte ich jüngst auch mal.

UA Sniffing ist so ungefähr das Einzige, was du serverseitig tun kannst.
Aber auch das lässt keinerlei Rückschlüsse auf die Bandbreite zu. Selbst wenn du das System damit als Chrome auf Android identifizierst und daher mit an Sicherheit grrnzender Wahrscheinlichkeit von einem Smartphone ausgehen kannst, könnte dieses Smartphone im Moment auch ein vorhandenes schnelles WLAN nutzen und hätte damit eine ählich große Bandbreite wie ein stationärer Desktop-PC zur Verfügung.
Najaaa... ich dachte ggf. daran IP-Blöcke mobilen Providern zuweisen zu können... zum Beispiel. Aber auch das ist dirty.
Das wäre aber, so wie ich es im Moment sehe, das einzige Kriterium, das einen zumindest qualitativen (aber nicht quantitativen) Rückschluss aif die Bandbreite zulässt.

Ja, ich sagte ja dass das alles nur dreckiges Herumgerate ist, das ist mir alles schon bewusst.

Nee im Ernst, daher bitte ich euch ja um Hilfe, auf 1MB werde ich wohl kaum kommen
Warum nicht? Wenn ich bedenke, dass man auch Fotos in der 5MP-Klasse als JPEG auf etwa 300..500kB komprimiert bekommt, ohne dass die Qualität allzusehr leidet, solltest du das mit deinen Grafiken eigentlich auch schaffen. Eventuell könntest du auch zunächst eine bewusst stark komprimierte Fassung laden (~100kB oder noch weniger), und die hochwertige (und damit mehrere MB schwere) Fassung erst auf ausdrücklichen Wunsch.

Ich bin jetzt in einem ersten Schritt von 5,8MB auf 1,7MB 'runter für diese beiden Grafiken (was die gesamte Webseite jeweils wiegt hängt halt von verschiedensten Faktoren ab).

[Gunther]

Hallo!

Falls du den Medientyp "Handheld" meinst, muss ich dich leider enttäuschen. Die allermeisten Browser auf mobilen Endgeräten unterstützen diesen Medientyp nicht, sondern "reagieren" wie jeder Desktop-Browser nur auf "Screen".
Ja, das ist mir bewusst, aber ich ignoriere diesen Umstand, denn ich halte das für einen Fehler dieser Browser/Benutzer. Wenn ein Gerät meint nicht die Daten annehmen zu wollen, die ich extra für dieses Gerät bereitgestellt habe ist das nicht mein Fehler, denn soweit ich mich erinnere passt die Beschreibung sehr gut.

Intended for handheld devices (typically small screen, limited bandwidth).
Wenn ein Drucker meint er müsse 'screen' verwenden ist das ja auch nicht meine Sorge ;D
(defacto ist das halt einer der Unterschiede zwischen privater Webseite und einer mit Kunde im Nacken, ich kann auf die Realität scheißen und ein bisschen dem Idealismus fröhnen).
Die Spezifikation sagt nicht "jaaa handheld gilt aber nicht bei multitouch oder wenn es den Browser auch für Desktop-Rechner gibt".
Anders gesagt: **Ich** bin es imho nicht, der sich **nicht** an die Specs hält.

Nun der Punkt hierbei ist folgender:
Da haben die vom W3C seinerzeit extra mal vorausgedacht, dabei aber leider vergessen, dass das kein Mensch in seine Seite implementiert (mangels entsprechender Geräte).
Sprich als also dann die ersten Geräte auf den Markt kamen, die diesen Medientyp eigentlich hätten verwenden sollen, war dies in der Praxis schlicht nicht möglich, da es so gut wie keine Seite im Web gab, die ein entsprechendes Stylesheet bereit hielt.
Mit anderen Worten: Hätten diese Geräte den Medientyp genutzt, wären sie quasi unbrauchbar gewesen. Also blieb den Herstellern nichts anderes übrig, als die Milliarden vorhandener Seiten im Netz irgendwie für ihre Geräte nutzbar zu machen.
Deshalb war der Medientyp 'Handheld' eine Totgeburt.

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.
*seufz* ja, man wird doch noch träumen dürfen ;D (wie gesagt sagt "handheld" immerhin schon was über die Bandbreite und **eigentlich** müssten Netbooks umschalten wenn sie ins EDGE-Land kommen)

Ja, ich gehöre selber zu den Leuten, die der Meinung sind, dass die Browser etliche ihrer durchaus sehr umfassenden Informationen über die Hardware, auf der sie gerade laufen, weitergeben sollten. Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.
Hierzu plädiere ich seit geraumer Zeit dafür, dass die HTTP Header entsprechend geändert, bzw. erweitert werden.

Gruß Gunther

[Der Martin]

Hi,

Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.

bist du da sicher? Das würde bedeuten, dass die saubere Trennung zwischen Anwendungs- und Betriebssystemebene, die man auf herkömmlichen PCs anstrebt, bei den Smartphones absichtlich aufgeweicht wird. Das kann ich mir nur schwer vorstellen, zumal beispielsweise Android auf Linux basiert und daher auch nach dessen Grundarchitektur funktionieren müsste. Und das heißt nun mal: Der Browser (Anwendung) will eine Verbindung zu einem Remote-Host herstellen und fordert das OS auf, diese Verbindung aufzubauen. Wie und über welches Medium das OS das tut, bekommt die Anwendung normalerweise nicht mit.

Und selbst wenn, dann könnte das immer noch zu erheblichen Fehleinschätzungen führen. Angenommen, die Browser auf meinem Notebook oder Desktop-PC würden Informationen über ihre Netzanbindung bekommen. Dann würden sie von einer LAN- oder WLAN-Verbindung ausgehen und eine Bandbreite in der Größenordnung von 100Mbit oder mehr annehmen. Ob es aber vom Router aus ebenso flott weitergeht, oder mit einer schwachen 2Mbit-DSL-Leitung, oder gar schnarchlahm über ISDN, wissen meine PCs nicht. Und die darauf laufenden Browser logischerweise auch nicht.

Im Mobilbetrieb ist der Rückschluss vom Übertragungsmedium auf die verfügbare Bandbreite ebenso trügerisch. Denn auch wenn ein Smartphone eine flotte HSDPA- oder LTE-Verbindung zur nächsten Basisstation "sieht", kann die tatsächliche Übertragungsrate trotzdem sehr niedrig sein - beispielsweise wenn die physikalisch mögliche Bandbreite auf viele Nutzer aufgeteilt werden muss.

Hierzu plädiere ich seit geraumer Zeit dafür, dass die HTTP Header entsprechend geändert, bzw. erweitert werden.

Das würde nur helfen, wenn deine Annahme tatsächlich stimmt, dass Smartphone-Browser ihre Umgebungsbedingungen kennen, und selbst dann wäre die Aussagekraft gering.

Ciao,
 Martin

[dedlfix]

Tach!

Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.
Und selbst wenn, dann könnte das immer noch zu erheblichen Fehleinschätzungen führen. Angenommen, die Browser auf meinem Notebook oder Desktop-PC würden Informationen über ihre Netzanbindung bekommen. Dann würden sie von einer LAN- oder WLAN-Verbindung ausgehen und eine Bandbreite in der Größenordnung von 100Mbit oder mehr annehmen. Ob es aber vom Router aus ebenso flott weitergeht, oder mit einer schwachen 2Mbit-DSL-Leitung, oder gar schnarchlahm über ISDN, wissen meine PCs nicht. Und die darauf laufenden Browser logischerweise auch nicht.

Hinzu kommen noch die Bestrebungen der Provider, den Anwendern Volumenbegrenzungen aufzudrücken, bei denen nach dem Erreichen des Limits die Daten nur noch mit geringerer Bandbreite durchgereicht werden. Im Mobilfunk ist das schon Realität, im Festnetz kommt das langsam in Mode. Die physikalische Übertragungsgeschwindigkeit bleibt dabei unverändert hoch, nur die Daten werden auf die angekündigte Nasse-Bindfaden-Geschwindigkeit abgebremst.

dedlfix.

[Gunther]

Hi,

Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.

bist du da sicher?

Ziemlich sicher ... ;-)
Siehe u.a.: https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection

Das würde bedeuten, dass die saubere Trennung zwischen Anwendungs- und Betriebssystemebene, die man auf herkömmlichen PCs anstrebt, bei den Smartphones absichtlich aufgeweicht wird. Das kann ich mir nur schwer vorstellen, zumal beispielsweise Android auf Linux basiert und daher auch nach dessen Grundarchitektur funktionieren müsste. Und das heißt nun mal: Der Browser (Anwendung) will eine Verbindung zu einem Remote-Host herstellen und fordert das OS auf, diese Verbindung aufzubauen. Wie und über welches Medium das OS das tut, bekommt die Anwendung normalerweise nicht mit.

Ich bin kein "Fachmann", was diese technischen Innereien auf Betriebssystemebene angeht, aber soweit ich das sehe & verstehe, stellt das OS eben entsprechende APIs bereit, über die der Browser halt diese Art Informationen erhält, bzw. abrufen kann.
Das nutzt aber nur knapp die Hälfte, wenn man als Autor nur per JS darauf zugreifen kann, denn viel "interessanter" wäre es ja, diese bereits serverseitig nutzen zu können, um bspw. spezielle low resolution images auszuliefern oder Images sogar nur rein auf Anforderung auszuliefern.

Was mich persönlich an dem heutigen "System" am meisten "stört" ist, dass es quasi nach dem Prinzip funktioniert, jeder kriegt erstmal pauschal alles geliefert, um sich dann das rauszupicken, was für ihn "passt". Das ist ziemlich ineffizient und verursacht auch enorm viel (eigentlich) unnötigen Traffic.

Und selbst wenn, dann könnte das immer noch zu erheblichen Fehleinschätzungen führen. Angenommen, die Browser auf meinem Notebook oder Desktop-PC würden Informationen über ihre Netzanbindung bekommen. Dann würden sie von einer LAN- oder WLAN-Verbindung ausgehen und eine Bandbreite in der Größenordnung von 100Mbit oder mehr annehmen. Ob es aber vom Router aus ebenso flott weitergeht, oder mit einer schwachen 2Mbit-DSL-Leitung, oder gar schnarchlahm über ISDN, wissen meine PCs nicht. Und die darauf laufenden Browser logischerweise auch nicht.

Im Mobilbetrieb ist der Rückschluss vom Übertragungsmedium auf die verfügbare Bandbreite ebenso trügerisch. Denn auch wenn ein Smartphone eine flotte HSDPA- oder LTE-Verbindung zur nächsten Basisstation "sieht", kann die tatsächliche Übertragungsrate trotzdem sehr niedrig sein - beispielsweise wenn die physikalisch mögliche Bandbreite auf viele Nutzer aufgeteilt werden muss.

Da hast du völlig Recht und ich stimme dir da auch zu. Es kommt halt immer darauf an, welche Rückschlüsse man aus irgendwelchen Informationen zieht. Ich denke da auch eher an zukünftige Konfigurationsmöglichkeiten seitens des Users, wie eben z.B. "bitte möglichst kleines Datenvolumen senden", wie er sie heute bereits mit dem Accept Language Header hat.

Hierzu plädiere ich seit geraumer Zeit dafür, dass die HTTP Header entsprechend geändert, bzw. erweitert werden.

Das würde nur helfen, wenn deine Annahme tatsächlich stimmt, dass Smartphone-Browser ihre Umgebungsbedingungen kennen, und selbst dann wäre die Aussagekraft gering.

Nicht unbedingt ..., wenn ich mir die aktuelle Situation bezüglich der Hi-Res oder "Retina Display" Image Geschichte betrachte, dann wäre alleine eine per HTTP Header übertragene Information über die (unveränderliche) Resolution/ Pixel Density eine Sache, mit der sich das Problem recht einfach lösen lassen ließe.

Nur um das nochmal in aller Deutlichkeit zu sagen: Speziell irgendwelche Angaben über die Bandbreite sind beliebig uninteressant. Denn neben den von dir bereits angesprochenen Punkten kommt auch noch hinzu, dass sich diese jederzeit sehr schnell, also selbst innerhalb eines Requests und dessen Antwort, ändern kann (man denke bspw. an einen User, der sich im Auto sehr schnell bewegt und dementsprechend seine Netzverbindung ggf. starken Schwankungen unterworfen ist).

Gruß Gunther

[Gunther]

Hi Martin!

Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.

bist du da sicher?

Hab' gerade noch die entsprechende Javascript Variante (wieder)gefunden:

if (navigator.connection.type==navigator.connection.WIFI) {  
  // code for WiFi connections (high-bandwidth)  
}

Funktioniert, wie bereits im Titel angedeutet, aktuell nur unter Android ab Version 2.2 und aufwärts.

Gruß Gunther

[Deus Figendi]

Nun der Punkt hierbei ist folgender:
Da haben die vom W3C seinerzeit extra mal vorausgedacht, dabei aber leider vergessen, dass das kein Mensch in seine Seite implementiert (mangels entsprechender Geräte).
Sprich als also dann die ersten Geräte auf den Markt kamen, die diesen Medientyp eigentlich hätten verwenden sollen, war dies in der Praxis schlicht nicht möglich, da es so gut wie keine Seite im Web gab, die ein entsprechendes Stylesheet bereit hielt.
Mit anderen Worten: Hätten diese Geräte den Medientyp genutzt, wären sie quasi unbrauchbar gewesen. Also blieb den Herstellern nichts anderes übrig, als die Milliarden vorhandener Seiten im Netz irgendwie für ihre Geräte nutzbar zu machen.
Deshalb war der Medientyp 'Handheld' eine Totgeburt.

Janaja, jein... Du hast recht, vor der Verbreitung der Smartphones... als WindowsCE/mobile die einzigen waren, die da echten Bedarf gehabt hätten (und ein bisschen Symbian, aber denen konnte man WML ausliefern soweit ich mich erinnere) hat kaum eine Webseite da irgendeine Rücksicht genommen. Aber üblicherweise hat man auch nicht screen-Stylesheets eingebunden sondern welche vom Medientyp unabhängige (plus print). Die Entwickler von mobilen Browsern hätten sich meiner Meinung nach daher durchaus an die Spezifikation halten können, weil sie im Wesentlichen eh nur allgemeine Stylesheets bekamen und keine auf screen spezifizierten.
Aber Webentwickler sind eben Arschlöcher wie man ja an den jüngeren und jüngsten Ereignissen bei Opera sieht (ich beziehe mich darauf dass sie das -webkit-Präfix auswerteten, nicht dass sie Presto aufgaben, das ist imho eine andere Sache).

Und darüber hinaus hätten Apple und Google da auch einen kleinen Hack machen können, indem sie nachsehen ob da ein handheld-sheet da ist und nur falls nicht auch ein screen-sheet auswerten. Nein ich nehme die Browser-Hersteller hier kein Stück in Schutz, you're doing it wrong!
(Sie machen noch ganz andere Sachen falsch wie ich finde... schonmal ne CA ausm Smartphone gelöscht?)

Defakto ist es heutzutage nicht möglich, irgendetwas (sinnvolles) über die "Art der Internetverbindung" herauszufinden. Deshalb eingangs mein dringender Appell ...! ;-)
Nur mal ein Beispiel: Du kannst nicht bestimmen, ob ein Smartphone User deine Seite über GPRS oder bspw. ein WLAN aufruft.
*seufz* ja, man wird doch noch träumen dürfen ;D (wie gesagt sagt "handheld" immerhin schon was über die Bandbreite und **eigentlich** müssten Netbooks umschalten wenn sie ins EDGE-Land kommen)
Ja, ich gehöre selber zu den Leuten, die der Meinung sind, dass die Browser etliche ihrer durchaus sehr umfassenden Informationen über die Hardware, auf der sie gerade laufen, weitergeben sollten. Ein Browser auf einem Smartphone weiß nämlich sehr wohl, ob gerade eine GSM oder WLAN Verbindung genutzt wird.
Hierzu plädiere ich seit geraumer Zeit dafür, dass die HTTP Header entsprechend geändert, bzw. erweitert werden.

Wie ich dem Martin schon schrieb würde ich das auch begrüßen und der Gedanke kam mir auch neulich. Natürlich alles höchst freiwillig, so wie auch Standortdaten etc. aber es kann eben dem Benutzer zum Vorteil gereichen, ob er diesen Vorteil will kann und soll er dann selbst entscheiden.
Und eigentlich wäre es auch keine große Sache X-Bandwidth und X-avarage_downrate einzuführen.