nicht angemeldet
Hallo,
Progressive Enhancement bezieht sich auf alle technischen Gegebenheiten und Fähigkeiten. Natürlich auch den Viewport. Größerer Viewport == ich habe mehr Raum, Inhalte darzustellen, mehr Möglichkeiten, Inhalte zu layouten.
Das ist mir völlig neu, und ich halte das auch für eine "nicht hilfreiche" Ausdehnung/ -weitung des Begriffs.
Was ist daran eine Ausweitung? Das war schon immer die Bedeutung des Begriffs.
Und warst/ bist du nicht einer derjenigen, die hier schon öfter geschrieben haben, dass es praktisch nicht möglich ist, etwas über den jeweils verwendeten Internetzugang "zu wissen"!?
Ja, und? Es gibt genug Parameter, die ich bereits ohne Probleme ins Progressive Enhancement einbeziehen kann. Dass etwas momentan nicht praktisch möglich, ist schließt nicht aus, dass es irgendwann einmal einfach möglich ist. Dass ein Parameter existiert, z.B. der verwendete Internetzugang, heißt nicht zwangsläufig, dass ich die Seite daraufhin anpasse. Wichtig ist, dass man sich nicht verzettelt und sehr genau auswählt, nach welchen Umgebungsbedingungen unterschieden wird.
Anstatt zu propagieren, dass man pauschal immer den "Mobile first" Ansatz mit seinen overlapping MQs (min-width) verwendet, …
Himmel, wer tut das denn bitte?! Niemand!
Auf die Gefahr hin, mich zu wiederholen: »Mobile First« hat mit konkreten CSS-Techniken wenig zu tun. Wenn du mir auch nur eine einflussreiche Quelle nennst, die Mobile First *notwendig* mit overlapping MQs zusammenbringt und stacked *kategorisch ausschließt*, würde ich vielleicht verstehen, warum du hier so gegen Mobile First und overlapping MQs wetterst. Ich denke nicht, dass du eine finden wirst, sondern dass ein Missverständnis deinerseits vorliegt.
Overlapping MQs haben imho einen wesentlichen Nachteil, und zwar dass es bei Ihnen auf die Reihenfolge im CSS ankommt!
Ja, das tut es. Aber ist das ein praktisches Problem oder nur ein theoretisches? Ich habe diese »etlichen Gefahren« noch nie in meinem professionellen Leben gesehen. Warum nicht? Weil ich Regeln für ein Modul so notiere (Sass, indented syntax):
.modul
color: red
+screen-min-sm
color: blue
+screen-min-lg
color: green
Das ist die logische und intuitive Reihenfolge, die das Layout von klein nach groß schrittweise aufbaut – und gleichzeitig die, die bei stacked MQs nötig ist. Warum sollte ich auch eine andere Reihenfolge notieren? In welchem Fall muss ich erst Regeln für größere Viewports notieren? Ich kenne keinen.
Selbst wenn ich stacked MQs verwenden würde, würde ich die Reihenfolge doch nicht umdrehen! Das wäre völlig verwirrend. Ich würde genauso schreiben:
.modul
+screen-xs
color: red
+screen-sm
color: blue
+screen-lg
color: green
Aber lassen wir das einfach mal dahingestellt sein, denn es geht ja eigentlich nur darum, dass wie oben erwähnt, man von Fall zu Fall (Einzelfallentscheidung) entscheiden sollte, und nicht "blind" einfach irgendeinem "Slogan" folgt.
Diesen Slogan gibt es nicht und niemand behauptet, man solle ihm »blind« folgen. Mir scheint, du konstruierst hier einen Strohmann und kämpfst gegen Windmühlen.
Was man vielleicht auch nicht vergessen sollte ist, dass es ja nicht nur "Professionals" gibt. Und ich behaupte einfach mal, dass 'overlapping MQs' für "Laien" wesentlich "unübersichtlicher" und somit nachteiliger sind!
Wir haben doch gerade festgestellt, dass keine der Techniken per se übersichtlicheren Code produziert, sondern es ganz darauf ankommt, ob Code zwischen den Viewport-Klassen wiederverwendet werden kann oder nicht.
Mathias
Gunnar Bittersmann