@@Gunnar:

nuqneH

Hmmm ..., mal ganz davon abgesehen, dass das aktuell nur im Chrome funktioniert, berücksichtigt das in keinster Weise die 'line width' (sondern nur die Viewportbreite).

Die Breite der Box (in Prozent der Viewportbreite) hat man üblicherweise unter Kontrolle.

Hier trifft man aber auch gleich auf eines der aktuellen Probleme bei der Layoutgestaltung und der Verwendung von 'em' basierten Media Queries.

Jeder der aktuell relevanten Browser verwendet zur Berechnung die im Browser eingestellte Basis-Schriftgröße.

Angenommen ich habe jetzt folgende MQ:

@media screen and (min-width: 100em) {...}  

Wenn ich jetzt bspw. ein 3-spaltiges Layout erreichen möchte mit den Breiten

30em | 40em | 30em

dann könnte man sehr schnell eine Überraschung erleben (gilt nur für Browser mit "permanenter" Scrollbar) ...!
Denn mittlerweile machen es alle Browser (auch Webkit) gemäß der Spec und berücksichtigen bei der MQ keine Scrollbars!

Das bedeutet, dass wenn der Viewport (ohne Scrollbar) exakt den 100em Breite entspricht, man trotzdem nicht davon ausgehen kann, dass auch tatsächlich für die Elemente 100em Breite zur Verfügung stehen.

Ich brauche wohl nicht zu erwähnen, dass man per CSS nicht auf eine eventuelle Scrollbar-Breite zugreifen kann.
Und ferner ist die Scrollbar-Breite "variabel" ..., auch wenn sie auf vielen Systemen und deren Browsern 17px (wie passend, wo die Basis-Schriftgröße meist 16px entspricht) beträgt.

Um also vor "Überraschungen" sicher zu sein, müsste man Prozentwerte verwenden, denn 100% entsprechen der Viewportbreite_ohne_Scrollbar - also in diesem Beispiel:

30%  | 40%  | 30%

Das führt aber zu einem ungleich anderen Ergebnis!
Denn während die Verwendung von 'em' zu festen Breiten führt, sind die Spaltenbreiten mit '%' variabel.

Um das zu verhindern (bspw. weil man eine max. Zeilenlänge erreichen möchte), muss man also jeder Spalte zusätzlich noch eine 'max-width' Angabe hinzufügen.

Dann könnte man ja bspw. lieber gleich schreiben:

p {

margin: calc(1.1em + 1%) 0;
}

>   
> Für margin ja; für line-height nicht, da würde sich % auf die Schriftgröße beziehen.  
  
Autsch! Ja, da war mein "Denkfehler" ...!  
  

> > Auch das funktioniert nur im Chrome.  
>   
> Nö, im Firefox (31 auf MacOS) funktioniert das auch.  
  
Neein ..., immer nur für 'margin'.  
Es ging und geht aber um die 'line-height'!  
Du hast 'margin' doch nur ins Spiel gebracht, weil das außer in Chrome auch noch im Firefox funktioniert. Das ist aber in diesem Zusammenhang völlig irrelevant! :-P  
  
  

> > > > Ich finde den Ansatz, die line-height (neben der font-size) auch von der line width abhängig zu machen, gar nicht so verkehrt.  
> > Schön wenn du das auch so siehst, nur berücksichtigen tust du es nicht ...!?  
>   
> \*Ich\* schon. Firefox nicht. ;-)  
  
Wie war das noch gleich?  
[Zitat]Frickler können mit Unzulänglichkeiten leben, Entwickler nicht.[/Zitat]  
  

> > Und leider ist calc() hier auch keine "Hilfe", denn abgesehen davon, dass aktuell nur Chrome eine entsprechende Angabe für 'line-height' unterstützt, ist das, was wirklich hilfreich wäre, nämlich z.B.:  
> > ~~~css

div {  

> >    max-width: calc(1em / 1rem * 40rem);  
> > }  
> > 

generell nicht möglich,

Kann dir nicht folgen. Warum schreibst du nicht gleich 40em?

Das war ja auch nur als Beispiel dafür gedacht, um zu demonstrieren, dass man per calc() keine Berechnungen basierend auf der vom User eingestellten Basis-Schriftgröße durchführen kann.
Dass es hier eine ganz einfache Alternative gibt, ist eine Unzulänglichkeit des Beispiels ...!

da der Divisor immer eine <number> sein muss!

Hach, wie wird man von Sass verwöhnt.

Nö, daran ändert auch SASS nichts, da es als Preprocessor niemals irgendwelche tatsächlichen Werte des Browsers berücksichtigen kann.

Also bist du genauso auf die Verwendung von calc() angewiesen, wie ohne SASS - mit den dementsprechenden "Einschränkungen" von calc().

Gruß Gunther