Respnosive Webdesign

[Gunther]

Hallo,

Die immer nur dann funktioniert, wenn JS verfügbar + aktiviert!

Das ist richtig, sind aber zumindest in den von mir betreuten und/oder untersuchten Projekten über 99% der Clients.

Die Frage ist halt immer die, wie viel sind das eine Prozent?
Und kann man darauf "verzichten"?

Mich würde aber mal interessieren, wie du auf die Zahlen kommst?

Anhand der rein serverseitig verfügbaren Daten lassen sich mittels einer umfangreichen Device Database die Möglichkeiten der Endgeräte auch schon sehr gut ermitteln.

Und wieder eine Sache mehr, die laufend gepflegt und aktualisiert werden muss!

Ich finde es ehrlich gesagt ziemlich paradox, dass wir auf der einen Seite alles unternehmen, um CSS soweit zu nutzen, dass wir für RWD nicht (mehr) auf JS angewiesen sind, und dann auf der anderen Seite doch wieder auf JS zurückgegriffen wird, und das teils in der Form, dass die Seite ohne nicht "vernünftig" angezeigt wird, bzw. benutzbar ist.

Die Anzahl der Clients ohne aktives JS ist, zumindest in meinen Beobachtungen, von "verschwindend gering" weiter zurückgegangen.
Davon ab sollte eine Seite natürlich auch ohne JS funktionieren. Auch dafür kann die gezielte Auslieferung von Code sinnvoll sein. So bekommt der No-JS Client eben auch keine JS-Libs etc. ausgeliefert.

Das "passiert" ja von alleine ...! :-P

Wie schon in der Antwort an Mathias - bitte konkrete Fälle/ Umstände nennen.
Ansonsten ist die Diskussion eher rein hypothetischer Natur ...! ;-)

Tabellen sind immer so ein Fall. Ist genug Platz (Viewport) und Bandbreite vorhanden können umfangreiche Daten ohne Probleme in durchaus großen Tabellen ausgeliefert werden. Auf kleineren Viewports und/oder mit geringerer Bandbreite kann es durchaus sinnvoll sein die Daten in anderer Form aufzubereiten und initial nur eine Teilmenge an den Client zu schicken.

Windows Phone 7 setzt(e) auf den IE7.

Ja und? Den wolltest du heutzutage auch immer noch unterstützen?

Natürlich. Es sind noch erstaunlich viele Windows Phone 7 Geräte unterwegs. Vor allem, da sich die meisten dieser Geräte nicht auf Windows Phone 7.5 aktualisieren lassen.

Komisch ..., bei JS "stört" dich das ein Prozent nicht, aber bei Windows Phone ...
Windows Phone OS 7.0 Market Share on Mobile/Tablet
Windows Phone OS 7.5 Market Share on Mobile/Tablet
ist es dann relevant!? :-P

Wenn der Overhead solche Größenordnungen annimmt, wie von dir genannt, dann liegt in meinen Augen eher schon ein "konzeptioneller Fehler" vor.

Nein. Je granularer die Adressierung ist, desto mehr Code fällt an. Im clientseitigen RD macht es doch auch einen Unterschied ob 5 oder 50 Media Queries definiert werden.

Und wenn man die möglichen Kombinationen von Viewport, Orientierung, Touch, OS, Browser, etc. mal hochrechnet kommen da deutlich mehr bei rum.

Das ist doch schon ein "konzeptioneller Fehler". Die entwickelst doch nicht für eine bestimmte Viewportgröße oder Browser etc.

Du legst einige (wenige) Breakpoints gemäß deinem Inhalt an (die sich natürlich durchaus auch an den "gängigen" Viewportgrößen orientieren dürfen).

Innerhalb dieser Breakpoints gestaltest du deine Site fluide.

Und was spricht dagegen, eine Site so anzulegen, dass sie sowohl mit einer Maus, als auch per Finger/ Stift (Touch) gleichermaßen gut bedienbar ist?

Sorry, aber 20 oder mehr MQs halte ich persönlich für völlig unsinnig.
Und je größer, oder wie du es bezeichnest je "granularer die Adressierung" ist, umso größer wird nicht nur der Erstellungsaufwand, sondern auch der Pflege- & Aktualisierungsaufwand!

Den "Aufwand", den du da scheinbar betreiben willst, wird dir kein Kunde bezahlen!
Mal davon abgesehen, dass ich ihn, wie schon erwähnt, auch nicht als sinnvoll erachte.

Gruß Gunther