Hallo Mathias!

Es freut mich, dass du dich an der Diskussion beteiligst. :-)

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?

Meiner Meinung nach heutzutage eigentlich kein Browser mehr, da alle MQs unterstützen.
Von daher hätte ich besser den Konjunktiv verwendet, und 'bräuchten' geschrieben.
Ich habe das auch nur aus dem Grund angeführt, weil Gunnar die "Basisansicht für alle" erwähnt hatte.

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.

Das ist mir völlig neu, und ich halte das auch für eine "nicht hilfreiche" Ausdehnung/ -weitung 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"!?

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.

Sorry, aber das gehört imho alles zu dem (Ober)Begriff "Responsive Web Design", aber nicht alles zu "Mobile first".

Mobile first, unobtrusive JavaScript, und progressive enhancement kann man heutzutage sicher alle zu "RWD" zählen. Aber die beiden letztgenannten zu Mobile first zu zählen, halte ich dann doch für falsch.

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).

Das ist ja kein Muss, sondern eine Option, die nur dann gewählt werden sollte, wenn sie diese Bedingung erfüllt.

1. relevante Inhalte
2. 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.

Nein, von solchen Seiten rede ich gar nicht. Ich habe hier schon einen "RWD" Ansatz vorausgesetzt.
Und mir geht es im Prinzip auch rein um "Mobile first".

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.

Und mein Eindruck ist der, dass (sehr) viele aber genau das unter "Mobile first" verstehen.

Dazu braucht man sich ja nur mal Googles Ergebnisse für "Mobile first" anzugucken.

Und hier mal exemplarisch 2 Links:
1. http://blog.kulturbanause.de/2013/08/mobile-first-progressive-enhancement/
2. http://radar.oreilly.com/2013/06/mobile-first-not-so-fast.html?utm_content=buffer4dfe3&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer

Der erste "verdeutlicht" dann wohl das "allgemein vorherrschende Missverständnis".
Der zweite zeigt, dass es auch andere Menschen gibt, die ein ähnliches "Problem" mit "Mobile first" haben, wie ich.

Übrigens glaube ich nicht, dass es größere responsive Sites gibt, die streng *nur* overlapping MQs verwenden. Warum sollte man sich darauf beschränken?

Eben!

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:

Das ist doch genau einer der Punkte, um die es mir geht. Anstatt zu propagieren, dass man pauschal immer den "Mobile first" Ansatz mit seinen overlapping MQs (min-width) verwendet, sollte man diese Entscheidung vom Einzelfall abhängig machen.

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.

FACK

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.

Overlapping MQs haben imho einen wesentlichen Nachteil, und zwar dass es bei Ihnen auf die Reihenfolge im CSS ankommt!

Das birgt etliche "Gefahren" und macht den Code alles andere als "robust" (wie Gunnar das so gerne formuliert).

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.

Und imho handelt es sich bei den »allermeisten« Sites eben genau nicht um solche textlastigen Sites.
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.

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.«

Das ist doch kein Argument gegen 'stacking MQs'. Hier kann ich ja genauso meine Typografie und andere Dinge 'sitewide' und/ oder 'overlapping' festlegen!

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.

Und die eingebauten Nachteile, dass es u.a.

• auf die Reihenfolge im CSS ankommt
• bei Änderungen ggf. die neu hinzugekommene Eigenschaft in allen anderen Rules auch geändert (überschrieben) werden muss

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!

Und selbst wenn dann nachher bei ~ 2.000 Zeilen CSS Code (unkomprimiert) 50 Zeilen mehr Code dabei herauskommen - na und?

Das ist hinterher bei der 'gzip' Auslieferung des Codes so was von ...! ;-)

Gruß Gunther