CSS media querys oder user agents

lordg2009

Lt. Commander
Registriert
Apr. 2009
Beiträge
1.552
Hi,

Mal wieder das leidige Thema:
Webgestaltung für Desktop vs smartphones

Habe jetzt gelesen über media querys und user agents. User agents, die man mit JS abfragen kann und media querys, die man direkt in das link-tag einfügen kann.

Aber was nimmt man nun am einfachsten?

media querys unterscheiden doch anhand der Auflösung, da smartphones sich nicht als handheld-device ausgeben. Aber dank retina displays wird die auflösung immer höher. Das iphone 5 hat eine breite von 640px. Wenn man als 'max-width: 700px' angibt, müsste man noch auf der sicheren Seite sein, oder?
Netbooks kommen doch teilweise auch mit sehr kleinen Auflösungen daher, welches ist also die optimale Weite, die man angeben sollte?
Wenn der Besucher sein Smartphone quer hält, zählt dann die eigentlich höhe als Weite, so dass z.B. das iPhone5 dann eine Breite von 1136px zurückgibt?

User agents sind von Browser zu Browser und Version zu Version unterschiedlich. Um hier eine sinnvolle Unterscheidung zu erreichen, muss man wohl eine Weiche für jede Möglichkeit coden, oder wie muss man sich das vorstellen.

Ich find das Thema sehr kompliziert, dabei möchte man doch nur, dass Die Seite auf Smartphones so und auf Desktops so aussieht.

Kennt jemand eine aktuell etablierte Methode?

Vielen Dank
 
1.) Niemals JS nehmen, wenn es mit CSS lösbar ist
2.) Mediaqueries haben nix im <link> zu suchen. Das pappt man schön alles in eine einzelne CSS-File, spart enorm Ladezeit
3.) Größen gibt man nicht in px an, sondern z.B. in em. Man könnt auch die Viewport-Einheit nehmen, aber die können noch zu wenig Browser.

http://mediaqueri.es/
 
Warum nicht JS?

Ich wollte die mobile Website mit jQuery gestalten und da muss ich doch mit JS mitteln die Größe auslesen, oder?

Werden die em auf Smartphones größer berechnet, als auf Desktops? Ich habe, glaube ich damals gelesen, dass auf dem Desktop 1em 16px entspricht, wenn man mit CSS noch nichts verändert hat und Standardschrift nutzt. Ich nehme an ein mobile Browser setzt 1em per default auf mehr als 16px.

wie viel em würdest du empfehlen?
 
Ne, du brauchst für die Größe (des Bildschirmes) auch kein JS. (max-width, min-width, min-device-width, max-device-width, orientation, min-device-pixel-ratio, max-device-pixel-ratio ..... , damit kann man ganz gut bestimmte Geräte bestimmen, Beispiel: http://stackoverflow.com/a/13847835)

und em hängt von der verwendeten Schriftgröße ab, daher ist 1em nicht unbedingt 16px, außer du benutzt font-size: 16px
 
Zuletzt bearbeitet:
CSS ist fürs Aussehen zuständig. Mit Media Queries kann man viel machen, in fast allen Fällen nutzt man die aber einfach um die Bildschirm Breite abzufragen und dementsprechend das Aussehen zu verändern.
Einfach gesagt: Man baut ein möglichst Flexibles Layout, drückt die Seite zusammen bis es nicht mehr gut aussieht und baut man an der Stelle eine Media Query ein, um die Elemente anders Auszurichten.

"Retina-Displays" müssen einen im CSS gar nicht interessieren. Die Browser rechnen das automatisch um, damit 1px immer ungefähr gleich groß wirkt. Eine Website an die "Eigenheiten" mancher Hardware anzupassen ist auch nie der Job vom Webdesigner.

Wenn man Pixel mit JS ausließt muss man aber durchaus auf die DPI vom Gerät achten und es wird deutlich komplexer. Und von Dingen wie Viewports fang ich lieber gar nicht an...
Und Finger weg von User-Agent Strings! Browser Sniffing sollte man niemals tun, wenn man keinen wirklich guten Grund hat z.B. irgendwelche Browser-Bugs die man per Polyfill lösen kann. Die Eigenheiten von Browsern / Gräten sollten einen eben nicht interessieren. Es ist der Job der Browser deinen Kram entsprechend der Standards darzustellen.
 
OK, danke. Damit hat es sich geklärt, danke euch.
Ergänzung ()

Doch noch mal ne Frage:

Ich binde also jQuery mit ein:
PHP:
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.min.css">
<script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.min.js"></script>
<script src="./EIGENESJQUERYSCHRIPT"></script>

Im Link Tag könnte ich ein:
PHP:
media="only screen and (min-device-width : 320px) and (max-device-width : 480px)"
einfügen.

In meinem eigenen jQuery script muss ich dann aber noch mal neu die Fenstergröße abfragen, oder?

Und noch mal die Frage:
Welche Werte würdet ihr für 'min- und max-device-width' empfehlen?
 
lordg2009 schrieb:
Wichtigste Antwort: Spätestens seit Snowden geht der Trend massiv hin zu NoScript. Verlasse dich NIE NIE NIE NIE auf JavaScript, außer es muss unbedingt sein.... nicht einmal bei einfachen Animationen.
Media Queries sind etwas, dass CSS wunderbar und performant lösen kann, da brauchst du definitiv kein JS.

wie viel em würdest du empfehlen?
Hängt von Schriftart und -größe ab.

T0a5tbr0t schrieb:
Einfach gesagt: Man baut ein möglichst Flexibles Layout, drückt die Seite zusammen bis es nicht mehr gut aussieht und baut man an der Stelle eine Media Query ein, um die Elemente anders Auszurichten.
Anders rum...
Da Mobile Devices inzwischen tatsächlich die Mehrzahlt sind (meine eigenen Server-Stats sagen mir dasselbe), verwendet man einen Mobile First - Ansatz. Man schreibt die Seite so, dass sie auf ner Device mit meinetwegen 320px Breite brauchbar aussieht (wäre in etwa n altes MeeGo). Danach skaliert man hoch und setzt Media Query Break Points an den Stellen, ab dem es anfängt Scheiße auszusehen. Da setzt man dann neue Attribute, z.B. neue Spalten-Aufteilungen per Box Model

"Retina-Displays" müssen einen im CSS gar nicht interessieren. Die Browser rechnen das automatisch um, damit 1px immer ungefähr gleich groß wirkt.
Bedingt richtig. Gerade bei pixelbasierten Icons macht es Sinn, eine signifikant höhere Auflösung für Retina zu liefern.

Wenn man clever ist, setzt man eh nur SVG als Icons ein, mit JavaScript-Fallback auf png/jpg für IE<=8.

lordg2009 schrieb:
Ich binde also jQuery mit ein:
PHP:
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.min.css">
<script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.2/jquery.mobile-1.3.2.min.js"></script>
<script src="./EIGENESJQUERYSCHRIPT"></script>
Hier wirst du richtig schön gef*ckt, wenn das CDN doch mal nicht reagier. Bau einen JS-basierten Fallback auf lokale Quellen.

Außerdem: Wozu genau braucht man jquer mobile? Ich hab schon x-wieviele Responsive Layouts geschrieben, aber niemals jQuery Mobile wirklcih gebraucht. Das Zeug ist Platzverschwendung.

Im Link Tag könnte ich ein:
PHP:
media="only screen and (min-device-width : 320px) and (max-device-width : 480px)"
einfügen.
Ich dachte, ich hätte dir schon gesagt, dass es da nichts zu suchen hat und Schwachsinn ist.

Welche Werte würdet ihr für 'min- und max-device-width' empfehlen?
Keine.
Verwende em's als Grenzen, und passe die Grenzwerte gemäß deinem Gefühl von unten nach oben an.
 
Hey Danke für die ausführliche Antwort.

Noch mal zu der letzten Sache, die media-queries hätten nichts im linkt-tag gesucht. Wenn ich gerne jQuery mobile nutzen möchte, so wird in diesem Fall ja doch ein Teil des Designs über JS definiert. Ergo kann ich nicht die gesammte Gestaltung im Style-Sheet unterbringen. Irgendwie muss ich ja aber auch noch definieren, dass das jQuery Script nur anspringt, wenn die Breakpoints der media Querys erreicht sind. Deshalb fiel mir nur ein: media Query im link-tag oder Fenster Größe mit JS auslesen, was man ja laut euren Beiträgen nicht machen soll.

CSS3 bietet einige wirklich schöne Funktionen, die jedoch ständig nicht von irgendwelchen Browsern unterstützt werden. Anstatt irgendwelche Ausweichlösungen per JS für ältere Browser zu schreiben, kann ich doch auch gleich JS einsetzen.

Nächster Punkt:
Die Tendenz geht in Richtung noscript?
Fast jede Seite nutzt doch aber JS. Sachen wie Formvalidation oder das simple beeinflussen des DOM lassen sich mit CSS nicht bewerkstelligen und dazu ist es ja auch nicht gedacht, sondern nur für den Style. Ich dachte die Tendenz geht eher dahin, einige Aufgaben an den Clienten auszulagern, wo sich ja JS anbieten würde. Ich meine, wie soll es denn ohne JS funktionieren?

Die Sache mit dem Fallback ist ein guter Vorschlag, werde ich einbauen
 
lordg2009 schrieb:
CSS3 bietet einige wirklich schöne Funktionen, die jedoch ständig nicht von irgendwelchen Browsern unterstützt werden. Anstatt irgendwelche Ausweichlösungen per JS für ältere Browser zu schreiben, kann ich doch auch gleich JS einsetzen.
Och Gottchen, was für millionenschwere Firmenprojekte mit Legacy-Kunden hast du denn, dass du tatsächlich noch Fallback für Nicht-CSS3/HTML5 - Browser machst?
Selbst bei uns heißt es: IE9 Minimum, macht gefälligst Updates! Wir unterstützen keine unsicheren Browser sondern erziehen selbst unsere Legacy-Kunden zu regelmäßigen Aktualisierungen ihrer Software.

Nochmal: Schreib niemals JS, wenn CSS3 den Job erledigen kann. JS ist langsamer, kostet mehr Ladezeit (und gerade mobil sind Datenmengen sehr kostbar) und störanfällig.

Die Tendenz geht in Richtung noscript?
Schau dich im Sicherheitsforum um...
Fast jede Seite nutzt doch aber JS. Sachen wie Formvalidation oder das simple beeinflussen des DOM lassen sich mit CSS nicht bewerkstelligen und dazu ist es ja auch nicht gedacht, sondern nur für den Style. Ich dachte die Tendenz geht eher dahin, einige Aufgaben an den Clienten auszulagern, wo sich ja JS anbieten würde. Ich meine, wie soll es denn ohne JS funktionieren?
Formularvalidierung muss eh der Server machen, der hat das letzte Wort. JS ist hier nur Bequemlichkeit.... und selbst das ist unnötig. HTML5 kann das auch allein.
Wenn DOM-Manipulation nötig ist, dann geht natürlich nix an JS vorbei. Ich bin auch kein Fan von NoScript, aber ich akzeptiere, dass spätestens im Firmen-Umfeld gern mal alles mögliche abgeschaltet ist. Trotzdem: Für Media Queries ist CSS zuständig, niemals JS.


Und was jQ Mobile angeht: Willst du es nur verwenden, weil da "Mobile" dran steht und weil es eben gerade bei den Hipstern total angesagt ist? Oder hast du einen definitiven Verwendungszweck, der sich nicht viel leichter ohne den Mist lösen lässt?

Und wenn ich das hier in der offiziellen Doku sehe, da rollen sich mir die Fußnägel auf.
HTML:
<div data-role="page">
	<div data-role="header">...</div>
	<div role="main" class="ui-content">...</div>
	<div data-role="footer">...</div>
</div>
Semantisches HTML5 ist bis zu denen noch nicht durchgedrungen, hm?
 
Habe hier an solche Atribute wie
flex
keyframes
transition
animation

also eigenschaften die man durchaus als JS Alternative nutzen kann, leider erst ab IE10/11 benutzbar

und nicht zuletzt diese nervigen Präfixe. Um einen sinnvollen linearen Gradient zu erstellen (den ich übrigens liebe) muss man das auf sich nehmen

HTML:
#click
{
background: -webkit-linear-gradient(red, blue);
background: -o-linear-gradient(red, blue);
background: -moz-linear-gradient(red, blue);
background: linear-gradient(red, blue);
}

und wer weiß, wie sich das in Zukunft wieder ändert.

jQuery wollte ich nutzen, weil man da mit sehr simplen Mitteln einen tollen gestalterichen Effekt erreichen kann. Klar geht das auch mit CSS, aber so geht es viel schneller, sieht gut aus und das wichtigste: Da es die Nutzer von ihrer Smartphonesteuerung kennen ist es intuitiv nutzbar und zu deinem Semantikproblem: Ein divblock enthält eine Informationseinheit, ich finde das jetzt nicht so falsch und die neue Anfrage nach jeder kleinen Miniseite spart man sich auch. Außerdem kann man darauf verzichten, wenn man das möchte.

Ich weiß doch nur nicht, was im Moment das Maß der Dinge ist, Wenn du sagst: möglichst kein JS dann klingt das für mich logisch, vor allem, was gestalterische Dinge angeht.
Was formvalidation angeht, macht der server nochmal die Arbeit, dasist richtig. Ich mag zum Beispiel die Möglichkeit, zusätzlich mittels onkeyup() oder onchange() das Formular gleich vor Ort zu prüfen und den Nutzer direkt darauf hinzuweisen, dass etwas nicht stimmt. Den Senden button deaktiviere ich dann ganz gerne mal, so lange, bis alles stimmt. Das spart das Absenden und noch mal hochgescrolle, bis man wieder alle Fehler gefunden hat. Ohne JS leider nicht möglich. Ist JS deaktiviert validiert der Server sowieso noch mal. Aber es bietet zusätzlichen Komfort.
 
lordg2009 schrieb:
flex
keyframes
transition
animation
Für Flex schreibst du einen Fallback auf klassische Floats oder Inline-Block - Ansätze.
Alles andere... tja, je nachdem, was du vor hast. Ist der Kram denn so unglaublich wichtig? Genau dafür gibts Modernizr....
und nicht zuletzt diese nervigen Präfixe. Um einen sinnvollen linearen Gradient zu erstellen (den ich übrigens liebe) muss man das auf sich nehmen
Das schreibt man 1x und kopiert es rum.
Wenn man dazu noch die präfixlose Variante schreibt wird es auf ewig funktionieren.

Ein divblock enthält eine Informationseinheit, ich finde das jetzt nicht so falsch
Ein <header> ist eben nicht nur eine strukturlose Informationseinheit... Semantisches HTML5 rockt!

Ich mag zum Beispiel die Möglichkeit, zusätzlich mittels onkeyup() oder onchange() das Formular gleich vor Ort zu prüfen und den Nutzer direkt darauf hinzuweisen, dass etwas nicht stimmt.
Dafür gibts HTML5.
 
html5 mag eine schöne sache sein, aber auf w3school steht die Verfügbarkeit der verschiedenen neue input-typen, die sofort geprüft werden. Mag ma den Angaben dort glauben schenken, ist die Unterstützung auch für kleine Projekte schlecht.

http://www.w3schools.com/html/html5_form_input_types.asp

Aber ich bin einer Meinung mit dir:
Semantisches html rockt ;)
 
lordg2009 schrieb:
Habe hier an solche Atribute wie
flex
keyframes
transition
animation

also eigenschaften die man durchaus als JS Alternative nutzen kann, leider erst ab IE10/11 benutzbar.

"Feature detection" ;) Einfach mit JS Fallbacks schreiben und die Lücken "auffüllen". Bei Dingen wie Transitions ist das häufig nicht mal nötig, denn die Funktion bleibt erhalten, es sieht nur schlechter aus (Ein Argument mehr nen neuen Browser zu installieren).
Hier ist ne nette Liste: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills

Und Präfixe sind wirklich Müll. Mittlerweile haben Chrome / FF das auch eingesehen und es soll keine neuen Präfixe mehr geben. In ca. 10 Jahren hat Chrome die dann auch alle rausgepatcht... xD
 
Zurück
Oben