nicht angemeldet
Hallo!
Ergo dürften Browser, die eine "Basisansicht" brauchen, nicht unbedingt auf Geräten mit einem sehr kleinen Viewport anzutreffen sein.
Welche Browser brauchen denn deiner Meinung nach eine Basisansicht? Meinst du Dinosaurier wie IE 6?
Außerdem bezog und bezieht sich imho progressive enhancement, genauso wie graceful degradation, immer auf den verwendeten Browser und dessen Fähigkeiten - nicht auf die Größe eines verwendeten Displays/ Monitor.
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.
Wonei sich der Gedanke nicht nur aufs Layout bezieht, sondern viel früher ansetzt: Inhaltsmanagement, Informationsarchitektur, … Nicht zu vergessen: Bandbreite und Performance.
Das ist sicher alles richtig und ich gehe da auch mit dir d'accord. Nur hat das für mich nichts mit "Mobile first" zu tun.
Was Gunnar schildert, *ist* die gängige Definition von Mobile First.
Denn wenn eine Website nachher zwar die "optimale" Benutzbarkeit für kleine Viewports bietet, dafür aber auf Bildschirmen mit Full HD Auflösung "schei... aussieht" (als Sammelbegriff für schlechte Bedienbarkeit, fehlende Übersicht etc.), dann ist das Endresultat genauso misslungen.
Ja, klar. Fragt sich allerdings, ob das Hinzufügen von noch mehr Inhalt und Funktionen auf großen Viewports die Site unbedingt besser macht (Gunnar hatte es angesprochen).
- relevante Inhalte
- nicht relevante Inhalte
(…) Diese kann man dann eben vom vorhandenen Platzangebot abhängig machen.
Ja, sicher, das ist nicht ausgeschlossen. Dafür gibt es verschiedene Techniken. Z.B. das Unterbringen der Inhalte im HTML und Verstecken/Zusammendampfen auf kleinen Viewports, oder das Nachladen von Inhalten auf großen Viewports.
Und wieder braucht es keinen "Mobile first" Ansatz ...!
Du scheinst das Konzept misszuverstehen. »Mobile First« trägt der Tatsache Rechnung trägt, dass Mobilgeräte bald die vorherrschenden Web-Zugangsgeräte sein werden. Man bräuchte ihn nicht, wenn die Webindustrie schon immer funktionierende Produkte für alle relevanten Zugänge herausgebracht hätte. Das ist nicht der Fall, vielmehr herrscht immer noch ein starres »Desktop First«, das uns immer noch überladene Sites mit Flash-Plugins und Hinweisen wie »Bitte benutzen sie einen Desktop-Browser, damit sie die Site vollwertig nutzen können« bringt. »Mobile First« versucht das in erster Linie konzeptionell, in zweiter Linie hinsichtlich UI-/UX-Design, in dritter Linie technisch aufzusprengen.
Denn wenn ich unter einem Begriff/ Konzept wie "Mobile first" so ungefähr "alles" verstehen kann
Es gibt Artikel/Bücher, die das Konzept sauber definieren und die auch den Begriff geprägt haben:
http://www.lukew.com/
http://bradfrostweb.com/
Und für mich ist bis heute zumindest ein wesentlicher Bestandteil von "Mobile first" der, dass man sein CSS so aufbaut, dass man (ohne MQ) beim KAV anfängt und dann per 'overlapping' MQs mit 'min-width' für immer größer werdende Viewports erweitert.
Diese Vorgehensweise ist am verbreitesten, würde ich vermuten. Als »wesentlich« würde ich das nicht bezeichnen, weil es bei »Mobile First« nicht um einzelne CSS-Techniken geht, sondern um ein größeres Design- und Technik-Konzept.
Übrigens glaube ich nicht, dass es größere responsive Sites gibt, die streng *nur* overlapping MQs verwenden. Warum sollte man sich darauf beschränken? Ich habe schon das Gridsystem von Bootstrap verlinkt. Dort werden üblicherweise overlapping MQs verwendet, aber es gibt genauso Klassen und Helfer zum Generieren von stacked MQs. Zurb Foundation arbeitet genauso.
Ich entscheide das einmal für die Site, aber immer wieder im Einzelfall: Wenn das Interface für kleine Viewports komplett anders aussieht als das für große, ergibt es wenig Sinn, dutzende Regeln für größere Viewports wieder rückgängig zu machen. Dazu müsste ich eine Menge an Code schreiben, der von anderem Code abhängt und immer mitgewartet werden will.
Also arbeite ich an dieser Stelle mit stacked MQs, selbst wenn die Site allgemein mit overlapping MQs arbeitet. In meinem Sass-Werkzeugkasten habe ich Mixins für beides.
Was mich im Grunde genommen stört ist, dass per "Mobile first" Slogan im Bezug auf das CSS eine Methode favorisiert wird, die imho vielleicht vor 3-4 Jahren "sinnvoll" gewesen sein mag, die heutzutage aber für die allermeisten Projekte eher von Nachteil, denn von Vorteil ist!
Das halte ich für falsch. Was sind denn die »allermeisten« Projekte, bei denen das von Nachteil ist?
Bei textlastigen Sites ist es kein Problem, dass die meisten Styles für alle Viewport-Größen gelten. Es ist keine scharfe Trennung zwischen verschiedenen Viewport-Größen nötig, wie es stacked MQs tun.
Auszug aus Gunnars Link:
»Most sites don’t have radically different looks between media queries—sure, the layout might appear very different, but things like the typography, colors, and various visual effects are usually the same.«
Es demnach also keinen (vernünftigen) Grund gibt, automatisch eines der Konzepte dem anderen gegenüber vorzuziehen!
Doch. Overlapping MQs haben den eingebauten Vorteil, dass Code per default wiederverwendet wird. Das ist eine gute Sache, daraufhin sollte man CSS optimieren.
Viel Grüße
Mathias
Gunnar Bittersmann