nicht angemeldet
Erklärung von Media_Queries im Wiki
Matthias Apsel
Matthias Scharwies
Auge
Gunnar BittersmannHallo,
nachdem ich mich noch nie mit Mediaqueries befasst habe, wollte ich heute endlich damit beginnen und habe mich intensiv mit den beiden Wikiseiten über flexibles Layout und Media Queries beschäftigt.
Ich sitze jetzt seit ca. 10 Stunden vor dem Laptop und meine anfängliche Freude hat sich in der zwischenzeit in puren Hass und Frustration gewandelt, weil was immer ich auch versuchte, das Ergebnis auf meinem Smartphone war nicht das erwartete.
Ich habe mich stundenlang mit allen möglichen min-width und max-width Angaben bei der @media Angabe herumgeschlagen und bekam nur unlogische Ergebnisse.
Nachdem ich einfach nicht mehr weiter wusste, habe ich dann zum Googeln begonnen, um auf anderen Seiten Hilfe und weitere Erklärungen zu finden. Und ziemlich bald fand ich dann auf der Kulturbanausen-Seite zu dem Thema folgende Information:
Wenn ihr die Beispiel-Website nun am Computer testet funktioniert alles wie gewünscht. Auf einem echten mobilen Endgerät ist das allerdings noch nicht der Fall, denn hier arbeitet eine Technik namens Layout-Viewport im Hintergrund. Damit Tablets, Smartphones & Co. unsere Media Queries korrekt interpretieren, muss folgende Zeile Code in den <head> der Website eingebunden werden.
<meta name="viewport" content="width=device-width; initial-scale=1.0;" />
Ich habe das entsprechend eingefügt und sofort waren alle Ergebnisse so wie erwartet.
Ich dachte, das kannn nicht sein und habe dann den Quelltext der SELFHTML Beispielseite aufgerufen und siehe da: Dort steht genau das selbe im <head> Bereich der Seite!!
In weiterer Folge habe ich durch Googeln dann im SELFHTML Angebot auf der Wikiseite zum Thema HTML/Kopfdaten/meta eine Erwähnung des Problems mit der selben Lösung gefunden. Nur wer bitte kommt auf die Idee, dort nach einer Lösung zu suchen, wenn er die Information nicht hat und sich wundert, wieso die @media Angaben nicht greifen??
Jetzt frage ich mich, wieso das nicht zumindest auf einer der beiden Seiten erwähnt wird. Oder zumindest ein Link gestzt wird zu der Wikiseite, wo das Thema Erwähnung findet!
Ich bin jetzt echt, um es gelinde zu sagen, etwas unentspannt, weil ich stundenlang völlig sinnlos vor dem Laptop verbracht habe, nur weil mir diese wichtige Information im Wiki vorenthalten wird. Und wenn ich nicht auf andere Seiten gegangen wäre und dann den wichtigen fehlenden Teil dort (und später auch im Quelltext hier) gefunden hätte, dann würde ich jetzt noch voller Verzweiflung dasitzen und mich fragen, ob ich wirklich zu blöd bin, um das richtig zu machen.
Conclusio: Kann man das im Wiki bitte dazuschreiben oder ist es gewollt, sich das aus dem Quellcode herauszaubern zu müssen?
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
What – me worry?
-
Hallo Melvin Cowznofski,
Conclusio: Kann man das im Wiki bitte dazuschreiben oder ist es gewollt, sich das aus dem Quellcode herauszaubern zu müssen?
Vielen Dank für deine Kritik. Wenn an solchen Artikeln gearbeitet wird, ist es nicht ungewöhnlich, dass (manchmal auch wichtige) Dinge übersehen werden oder sich Fehler einschleichen. Auch aus diesem Grund haben wir die Dokumentation auf ein Wiki umgestellt, damit jeder Änderungen einfügen kann.
Auch du hättest also die entsprechenden Änderungen einfügen können. Aber wenigstens gibts du hier eine Rückmeldung. Möglicherweise haben sich viele andere vor dir über genau dasselbe Problem geärgert, für sich selbst die Lösung gefunden und waren damit zufrieden.
Es tut mir dennoch aufrichtig leid für deine vertane Zeit und deine Erlebnisse, die bei einer besser recherchierten Wiki-Seite wesentlich angenehmer gewesen wären.
Ich möchte dich einladen, dich am Wiki zu beteiligen. Ein Wiki über aktuelles HTML, CSS und sonstige Webtechniken ist niemals fertig oder gar vollständig. Insofern freuen wir uns über jede Unterstützung, sowohl über diesen Hinweis als auch über Verbesserungen an den Artikeln.
Conclusio: Ja, ich werde das jetzt im Wiki dazudazuschreiben, nein das Wiki soll zielführende Informationen liefern und keine, die in den Tiefen der Quelltexte verstckt sind.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Hallo Matthias,
Es tut mir dennoch aufrichtig leid für deine vertane Zeit und deine Erlebnisse, die bei einer besser recherchierten Wiki-Seite wesentlich angenehmer gewesen wären.
Mein "Erlebnisbericht" war aus meiner Sicht keine Kritik an Dir oder irgend einer anderen Person, sondern einfach am System! =)
Ich möchte dich einladen, dich am Wiki zu beteiligen.
Ganz ehrlich, ich würde mich nie trauen, mich am Wiki zu beteiligen, weil ich mich einfach nicht als kompetent genug ansehe. Es ist nicht nur die knappe Zeit, ich glaube einfach, dass es mir auf Grund meines Wissens nicht zusteht, in der Liga der "Wikimitschreiber" mitzuspielen.
Conclusio: Ja, ich werde das jetzt im Wiki dazudazuschreiben, nein das Wiki soll zielführende Informationen liefern und keine, die in den Tiefen der Quelltexte verstckt sind.
Vielen Dank, Matthias!
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
-
Hallo Melvin,
danke für deine Rückmeldung!
Auf der MV hatten wir schon angedacht, ein Tutorial zu einem minimalen Grundgerüst zu erstellen:
Beide Seiten sind nun aktuell.
Ich möchte dich einladen, dich am Wiki zu beteiligen.
Ganz ehrlich, ich würde mich nie trauen, mich am Wiki zu beteiligen, weil ich mich einfach nicht als kompetent genug ansehe. ...
JEDER kann am Wiki mitschreiben!
Vielen Dank an @Schein (und andere), dass er die Seiten auf Rechtschreibfehler, ungeschickte Formulierungen und inhaltliche Fehler durchforstet und das Wiki so verbessert.
Auge hat mal vorgeschlagen, mehr Querbezüge und Seitenverlinkungen herzustellen. Wem da etwas auffällt, nur zu mit den Links.
Es müssen nicht immer vollständige Grundlagenartikel oder Tutorials sein, wer 2 oder 3 Absätze schreiben kann, hilft allen!
Herzliche Grüße
Matthias Scharwies
-
Hallo Matthias,
zunächst Danke für die Antwort und die Korrektur der entsprechenden Wikiseiten!
Nachdem ich das Thema heute wieder aufgenommen habe, hat sich eine Frage ergeben, die ich nicht so recht beantworten kann.
Folgender Inhalt einer extrenen CSS Datei funktioniert nicht:
@charset "utf-8"; @media screen and (min-width: 320px) { @import url('reset.css'); } @media screen and (min-width:320px) and (max-width:750px) { @import url('smartphone.css'); } @media screen and (min-width:750px) and (max-width:1024px) { @import url('tablet.css'); } @media screen and (min-width:1024px) { @import url('desktop.css'); }Dieses Nichtfunktionieren kann ich mir noch am ehesten durch den Satz "Eine @import-Regel muss am Beginn eines Stylesheets (nach @charset, aber vor allen anderen Regelsätzen) notiert werden." erklären.
Dann habe ich im Web für das selbe Ziel auch noch folgende Schreibweise gefunden:
@charset "utf-8"; @import url('reset.css') (min-width:320px); @import url('smartphone.css') (min-width:320px) and (max-width:750px); @import url('tablet.css') (min-width:750px) and (max-width:1024px); @import url('desktop.css') (min-width:1024px);Und das funktioniert! Kann mir bitte jemand erklären, wieso die zweite Schreibweise greift und die erste nicht? Spricht etwas gegen die Verwendung der 2. Schreibweise? Und generell: Wieso kommt die 2. Schreibweise ohne einem "@media" aus? Ist das einfach eine Kurzschreibweise, die ebenfalls gültig ist, so wie $a++ in PHP?
Ich bin für jede Hilfe dankbar, ich beschäftige mich mit dem Thema erst seit gestern und bin diesbezüglich ein völliger Noob.
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
-
Hallo,
ohne das ausprobiert zu haben:
Im zweiten Beispiel werden die Dateien mit dem Aufruf der Seite importiert, deren Inhalt eingelesen und aktiviert. Bei einer Änderung der Fensterbreite kann der Browser entsprechend reagieren.
Im ersten Beispiel wird die Seite aufgerufen, aber nur die Dateien importiert und ausgewertet, die zur aktuellen Fensterbreite passen. Bei einer Änderung der Fensterbreite werden dann zwar die entsprechenden Dateien eingelesen, aber nicht aktiviert. Dies geschieht erst bei einem darauf folgenden Neueinlesen der Datei.
Das erste Beispiel funktioniert also, aber anders als von dir erwartet.
Die normalen Besucher ändern die Fensterbreite ihres Browsers in der Regel nicht. Die bekommen also die für ihre Fensterbreite passenden CSS-Anweisungen.
Gruss
MrMurphy
-
Hallo MrMurphy,
Im ersten Beispiel wird die Seite aufgerufen, aber nur die Dateien importiert und ausgewertet, die zur aktuellen Fensterbreite passen. Bei einer Änderung der Fensterbreite werden dann zwar die entsprechenden Dateien eingelesen, aber nicht aktiviert. Dies geschieht erst bei einem darauf folgenden Neueinlesen der Datei.
nein, es kommt zu überhaupt keiner Übernahme der Stylesheets. Egal, wie breit der Viewport zum Zeitpunkt des Aufrufes ist, kein einziges der Stylesheets wird je angewendet, auch wenn die entsprechende Seitenbreite gerade oder zum Zeitpunkt des Aufrufs zutrifft.
Also ist offensichtlioch Schreibweise Nr. 1 per se falsch und so nicht zu verwenden.
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
-
Hallo
nein, es kommt zu überhaupt keiner Übernahme der Stylesheets. Egal, wie breit der Viewport zum Zeitpunkt des Aufrufes ist, kein einziges der Stylesheets wird je angewendet, auch wenn die entsprechende Seitenbreite gerade oder zum Zeitpunkt des Aufrufs zutrifft.
Also ist offensichtlioch Schreibweise Nr. 1 per se falsch und so nicht zu verwenden.
Ja. Das Warum hat Matthias beschrieben (u.A. keine Schachtelung von
@importin Media-Queries).Notierst du deine Regeln direkt in den Queries, funktioniert es.
Tschö, Auge
--
Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
Terry Pratchett, „Gevatter Tod“
-
-
@@MrMurphy1
Die normalen Besucher ändern die Fensterbreite ihres Browsers in der Regel nicht.
Doch, das tun sie. Nicht mal selten, sondern oft. Mit jedem Dreh ihres Gerätes.
LLAP 🖖
--
„Wir haben deinen numidischen Schreiber aufgegriffen, o Syndicus.“
„Hat auf dem Forum herumgelungert …“
(Wachen in Asterix 36: Der Papyrus des Cäsar)
-
-
Hallo Melvin Cowznofski,
@charset "utf-8"; @import url('reset.css') (min-width:320px); @import url('smartphone.css') (min-width:320px) and (max-width:750px); @import url('tablet.css') (min-width:750px) and (max-width:1024px); @import url('desktop.css') (min-width:1024px);Und das funktioniert! Kann mir bitte jemand erklären, wieso die zweite Schreibweise greift und die erste nicht? Spricht etwas gegen die Verwendung der 2. Schreibweise? Und generell: Wieso kommt die 2. Schreibweise ohne einem "@media" aus? Ist das einfach eine Kurzschreibweise, die ebenfalls gültig ist, so wie $a++ in PHP?
- die erste geht nicht, weil
@importvor allen anderen Regelsätzen notiert werden muss, wie du selbst gelesen hast. - nein, es spricht nichts gegen die Verwendung der 2. Schreibweise.
- weil die Spec diese Schreibweise so festgelegt hat http://www.w3.org/TR/css3-cascade/#at-import
- nein, es ist eine völlig andere Schreibweise. Das eine ist ein Paramter der
@import-Regel, das andere eine@media-Regel - Wieder etwas, was im Wiki noch fehlt.
Erlaube mir noch einige Hinweise zu deinen Mediaqueries:
Man möchte die Breakpoints nur in Ausnahmefällen in Pixel zementieren, das Layout soll sich dem Inhalt anpassen. Deshalb sollten die Breakpoints im
emgesetzt werden.Es ist nicht gut, mehrere Stylesheets zu pflegen. Schau mal wieviele Regelsätze du mehrfach hast. Schreibe einfach die neuen Regeln dazu, indem du mediaqueries nach Schreibweise 1 in dein Stylesheet integrierst.
Ich könnte mir vorstellen, dass bei einer Änderung der Orientierung eines Tablets ein Breakpoint überschritten wird, mit der Folge, dass ein komplettes Stylesheet verworfen und ein neues geladen werden muss. Im besten Fall dauert das nur lange.
Ein reset-Stylesheet halte ich nicht für sinnvoll. Die meisten default-Einstellungen der Browser sind sinnvoll und auch browserübergreifend sehr ähnlich. Siehe auch wiki/wiki/CSS/Anwendung_und_Praxis/Guter_CSS-Stil#Normalisierung Du schreibst sonst wieder Regeln hinzu, die du eigentlich gerade verworfen hast.
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini)-
Hallo
stimmt. Das hatte ich noch nicht gewußt.
Mit der @import Regel kann man innerhalb von CSS eine weitere CSS-Datei einbinden. Diese Regel muss vor allen anderen Regeln notiert werden (Ausnahme: @charset) und kann nicht in andere Regelblöcke geschachtelt werden.
Gruss
MrMurphy
-
@@Matthias Apsel
- nein, es spricht nichts gegen die Verwendung der 2. Schreibweise.
Doch. Wie du später selbst schriebst: Durch
@importwird eine neue Ressource geladen; noch ein HTTP-Request mehr. Und bei Änderung der Viewportgröße noch eine.Man möchte nicht
@importverwenden, sondern alle Regeln für verschiedene media queries in einem Stylesheet. Mit HTTP/2 könnte sich das ändern.Man möchte die Breakpoints nur in Ausnahmefällen in Pixel zementieren, das Layout soll sich dem Inhalt anpassen. Deshalb sollten die Breakpoints im
emgesetzt werden.Denn Using pixels is not very polite.
LLAP 🖖
--
„Wir haben deinen numidischen Schreiber aufgegriffen, o Syndicus.“
„Hat auf dem Forum herumgelungert …“
(Wachen in Asterix 36: Der Papyrus des Cäsar)-
Hallo
… Mit HTTP/2 könnte sich das ändern.
Oder mit OS/2.
Tschö, Auge
--
Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
Terry Pratchett, „Gevatter Tod“-
@@Auge
Oder mit OS/2.
Und die NASA sucht einen FORTRAN-Entwickler.
LLAP 🖖
--
„Wir haben deinen numidischen Schreiber aufgegriffen, o Syndicus.“
„Hat auf dem Forum herumgelungert …“
(Wachen in Asterix 36: Der Papyrus des Cäsar)
-
-
Hallo Matthias,
- nein, es ist eine völlig andere Schreibweise. Das eine ist ein Paramter der
@import-Regel, das andere eine@media-Regel
das eine sagt "Importiere dieses CSS, wenn die Viewportbreite so und so ist", das andere sagt "Wenn die Viewportbreite so und so ist, importiere dieses CSS". Das empfand ich irgendwie als das gleiche.
- Wieder etwas, was im Wiki noch fehlt.
War das Hinweis darauf, dass Du eine Wikiseite diesbezüglich gerade verändert/erweitert hast? =) Welche genau denn?
Man möchte die Breakpoints nur in Ausnahmefällen in Pixel zementieren, das Layout soll sich dem Inhalt anpassen. Deshalb sollten die Breakpoints im
emgesetzt werden.Das ist der einzige von Deinen Einwänden, dem ich nicht folgen kann. Ich habe mir gestern kiloweise Youtube Videos zu dem Thema angesehen und Tutorials durchgelesen und habe die Sache so verstanden, dass es OK ist, Breakpoints in px zu setzen, weil man ja trotzdem noch innerhalb eines Bereichs, für den dann bestimmte Regeln greifen, ein fluides Layout mit Flexboxen und em- oder %-Weiten anwenden kann. Du hast sicher Recht mit dem, was Du sagst, aber ich stehe wohl grade auf der Leitung, weil ich kann einfach nicht nachvollziehen, wieso em statt px besser ist. Vielleicht kann man mtr bitte noch näher erläutern, wieso eine px-Angabe hier nicht gut ist!
Es ist nicht gut, mehrere Stylesheets zu pflegen.
Ich teile meine externen CSS Dateien seit jeher in 4 Bereiche auf: Zuerst kommen alle Anweisungen, die Positionierung, Größe, Padding und Margin betreffen. Dann folgen die Anweisungen bezüglich Farbe, Rahmen und Hintergrund. Im Anschluss stehen die Anweisungen für alles, was mit dem Schriftbild zu tun hat. Und der 4. und letzte Teil ist der "Sonstiges" Teil, da werden zB. spezielle Ausnahmen oder besondere IDs und Klassen definiert. Das bedeutet, dass bei mir zB. die Anweisungen für Absätze aufgeteilt sind, weil wie sich ein Absatz bzgl. Margin und Padding verhält steht bei mir in Teil 1, die Schriftfamilie, -farbe oder Größe aber in Teil 3. Das mag für viele unnötig umständlich klingen, ich persönlich empfinde das als sympathischer, übersichtlicher, logischer und - und das ist der ausschlaggebende Punkt für mich - wenn es bei Abständen zu Problemen kommt, brauche ich mich nur um einen kleinen Teil der Datei kümmern und die Padding- und Margin-Angaben nicht quer verstreut über die ganze Datei zusammensuchen.
Diese mir vertraute Herangehensweise möchte ich nicht aufgeben und nicht mit Aufteilungen für verschiedene Auflösungen verkomplizieren.
Schau mal wieviele Regelsätze du mehrfach hast.
Also darauf achte ich. Mein Konzept ist folgendes: Ich schreibe (noch der oben beschriebenen Art) ein Regelwerk für all das, was unabhängig ist von der Viewportbreite. In den Stylesheets für die verschiedenen Auflösungen stehen dann (ebenfalls nach meinem 4-Teile-Konzept) wirklich nur noch die spezifischen Angaben, die sich unterscheiden.
Ich könnte mir vorstellen, dass bei einer Änderung der Orientierung eines Tablets ein Breakpoint überschritten wird, mit der Folge, dass ein komplettes Stylesheet verworfen und ein neues geladen werden muss. Im besten Fall dauert das nur lange.
Das ist ein guter Einwand, ich habe das deshalb soeben getestet: Ich habe eine Standard HTML Datei geschrieben und für die Viewportbreite und Höhe meines iPads 2 verschiedene Stylesheets, in denen jeweils eine Hintergrundfarbe für den Body steht, hochgeladen. Dann habe ich mein iPad im Hochformat gehalten, die Seite aufgerufen, die Internetverbindung unterbrochen und dann das Gerät um 90 Grad ins Panoramaformat gewendet und die Hintergrundfarbe ist wie gewollt umgesprungen. Also ist es offensichtlich so, dass beim erstaufruf der Seite beide extrenen Stylesheets geladen wurden und auch zur Anwendung kommen. Sprich - kein Nachladen.
Ein reset-Stylesheet halte ich nicht für sinnvoll.
Ich wusste, dass das kommen wird. Die Diskussion, ob Reset Stylesheets sinnvoll sind oder nicht, ist seit Jahren eine immer wieder aufkommende Streitfrage. Viele sind dagegen, viele befürworten es. Ich persönlich arbeite nur noch mit Resets, wobei ich es etwas anders mache, als die meisten, weil in meinen Reset Sheets stehen nur Elemente, die auf den Seiten auch wirklich existieren. Aber egal - jedenfalls würde ich die Diskussion ob Reset Stylesheets ja oder nein heute gerne außen vor lassen und beim eigentlichen Thema bleiben. Bitte!
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
-
Hallo Melvin Cowznofski,
- Wieder etwas, was im Wiki noch fehlt.
War das Hinweis darauf, dass Du eine Wikiseite diesbezüglich gerade verändert/erweitert hast? =) Welche genau denn?
In dem Fall war es so, dass ich nur nicht aufmerksam geschaut habe. Der entsprechende Abschnitt war im Wiki drin. Sogar mit einer eigenen Überschrift. (@-Regeln)
Man möchte die Breakpoints nur in Ausnahmefällen in Pixel zementieren, das Layout soll sich dem Inhalt anpassen. Deshalb sollten die Breakpoints im
emgesetzt werden.Vielleicht kann man mtr bitte noch näher erläutern, wieso eine px-Angabe hier nicht gut ist!
Die kurze Antwort ist: Ein Pixel hat auf verschiedenen Geräten verschiedene Abmessungen. Die Größe em bezieht sich auf die Schriftgröße. rem auf die Schriftgröße des Wurzelelements. Damit kannst du die breakpoints entsprechend deines Inhaltes setzen. Schau dir dazu beispielsweise mal unser Wiki an und spiele mit der Fensterbreite. Dort habe ich mich an der Navigationsleiste "Lesen - Diskutieren - Fragen - Bearbeiten" orientiert. Wenn das nicht mehr in eine Zeile passt, habe ich die Gestaltung verändert. Jemand der eine große Schrift eingestellt hat, für den wechselt das Layout eher. Du kannst es testen indem du einstellst, dass nur der Text gezoomt werden soll.
Das ist ein guter Einwand, ich habe das deshalb soeben getestet: Ich habe eine Standard HTML Datei geschrieben und für die Viewportbreite und Höhe meines iPads 2 verschiedene Stylesheets, in denen jeweils eine Hintergrundfarbe für den Body steht, hochgeladen. Dann habe ich mein iPad im Hochformat gehalten, die Seite aufgerufen, die Internetverbindung unterbrochen und dann das Gerät um 90 Grad ins Panoramaformat gewendet und die Hintergrundfarbe ist wie gewollt umgesprungen. Also ist es offensichtlich so, dass beim erstaufruf der Seite beide extrenen Stylesheets geladen wurden und auch zur Anwendung kommen. Sprich - kein Nachladen.
Das könnte auch daran liegen, dass dein iPad gemerkt hat, dass es über wlan im Internet ist, möglicherweise sogar am Browsercache. Im Allgemeinen würde dieses Verhalten aber dem Grundgedanken der Verwendung der @import-Regel zuwider laufen, nämlich nicht benötigte Ressourcen nicht zu laden.
Ein reset-Stylesheet halte ich nicht für sinnvoll.
Aber egal - jedenfalls würde ich die Diskussion ob Reset Stylesheets ja oder nein heute gerne außen vor lassen und beim eigentlichen Thema bleiben. Bitte!
Ich will dich nicht bekehren, meinen Standpunkt habe ich geschrieben, den möchte ich dennoch wiederholen: Alle default-Einstellungen sind sinnvoll, die meisten browserübergreifend sehr sehr ähnlich. Nur damit ich das letze Wort habe ;-)
Bis demnächst
Matthias--
Das Geheimnis des Könnens liegt im Wollen. (Giuseppe Mazzini) -
@@Melvin Cowznofski
ich stehe wohl grade auf der Leitung, weil ich kann einfach nicht nachvollziehen, wieso em statt px besser ist. Vielleicht kann man mtr bitte noch näher erläutern, wieso eine px-Angabe hier nicht gut ist!
Ich hatte doch schon einen Artikel dazu verlinkt.
LLAP 🖖
--
„Wir haben deinen numidischen Schreiber aufgegriffen, o Syndicus.“
„Hat auf dem Forum herumgelungert …“
(Wachen in Asterix 36: Der Papyrus des Cäsar)
- nein, es ist eine völlig andere Schreibweise. Das eine ist ein Paramter der
- die erste geht nicht, weil
-
Hallo
Du hast ja schon einige Hinweise bekommen. Mir fiel noch folgendes auf.
@media screen and (min-width: 320px) {} @media screen and (min-width:320px) and (max-width:750px) {} @media screen and (min-width:750px) and (max-width:1024px) {} @media screen and (min-width:1024px) {}An den mittleren Breakpoints werden unnötigerweise die Regeln eines Regelsatzes mit denen des anderen überschrieben. Ich gehe davon aus, dass die später im Quelltext notierten Regeln angewendet werden. Die an diesen Stellen konkurrierenden Mediaqueries könnten aber dafür sorgen, dass der Browser nicht weiß, welchem Query er folgen soll. Wenn du nur mit
min-widtharbeitest, werden ab dem Breakpoint einfach die „neuen“ Regeln in Kraft gesetzt.Man muss dabei aber darauf achten, Regeln, die für breitere Viewports ungültig werden sollen, explizit zu überschreiben. Das System lässt sich mMn später dennoch einfacher pflegen. Das gilt insbesondere, wenn alle Regeln in einer Datei gefasst werden. Die eingesparten Requests für die nicht zusätzlich zu ladenden Dateien seien an der Stelle nicht verschwiegen.
Desweiteren stellt sich mir die Frage nach Viewports, die schmaler sind als 320px. Das mag in der Praxis selten vorkommen, die Frage lässt sich aber einfach vermeiden, wenn die grundsätzlich Regeln und jene, die für schmale Viewports gelten, ohne Media-Query notiert werden.
Folgendes bleibt übrig [1].
/* Allgemeine Regeln und Regeln für schmale Viewports. */ @media screen and (min-width:750px) { /* Regeln für mittelbreite Viewports. Regeln für schmale Viewports bei Bedarf überschreiben! */ } @media screen and (min-width:1024px) { /* Regeln für breite Viewports. Regeln für schmale und mittelbreite Viewports bei Bedarf überschreiben! */ }Noch ein Tip. Du kannst für bestimmte Elemente andere Breakpoints definieren. So könntest du z.B. mit den obigen Queries den Hauptinhalt der Seiten anders anordnen, die Darstellung der Navigation aber bei anderen Breiten/Höhen unabhängig von der Anordnung des Hauptinhalts ändern.
Tschö, Auge
--
Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
Terry Pratchett, „Gevatter Tod“
Den Hinweis auf die Verwendung von
emstattpxfür die Breitenangaben hast du ja schon von Matthias bekommen. Den muss ich jetzt nicht nochmal bringen. ↩︎
-
Hallo Auge,
An den mittleren Breakpoints werden unnötigerweise die Regeln eines Regelsatzes mit denen des anderen überschrieben.
ich bin mir nicht sicher, ob ich Dich da richtig verstehe. Meinst Du, weil die Schnittpunkte, also bei dem Beispiel 750px und 1024px jeweils einmal als min und ein mal als max definiert sind? Wenn es das ist, was Du gemeint hast: Ich habe das beim Schreiben meines Postings falsch hingeschrieben, bei meinen Versuchen empfand ich das nämlich schon als störend und habe 749 und 1023 als max sowie 750 und 1024 als min Angaben.
Desweiteren stellt sich mir die Frage nach Viewports, die schmaler sind als 320px.
Dem Zugrunde liegt die Überlegung, dass alles, was eine Viewportbreite von unter diesem Wert hat, was, wie Du sagst, sowieso eher selten der Fall ist, von meiner Seite aus überhaupt keine Stylesheetanordnungen bekommt. Ich überlasse die Renderung der Seiten dem Endgerät.
Das mag in der Praxis selten vorkommen, die Frage lässt sich aber einfach vermeiden, wenn die grundsätzlich Regeln und jene, die für schmale Viewports gelten, ohne Media-Query notiert werden.
Die "grundsätzlich Regeln" sind in dem Falle dann die Regeln über das Verhalten von HTML Elementen. Und wie heißt es so schön - das ist das flexibelste Layout, dass es geben kann. =)
Doch, ich hoffe sogar, dass das nochmal von wem gebracht wird. Weil wie ich Matthias gerade geschrieben habe: Ich glaube Euch schon, dass em besser ist als px, nur kann ich es nicht nachvollziehen und sehe einfach den Grund nicht. =/
Mit lieben Grüßen
Melvin Cowznofski
--
What – me worry?
-
-
-
-