Re: User Agents Do Not Implement Absolute Length Units, Places Responsive Design in Jeopardy

*> That seems like a very bad idea, because it's explicitly lying.*
*> "height:3in" is supported just fine; you can use it in your stylesheet*
*> today.*

I see it the other way around - it isn't supported.  The UA intentionally
lies to the author because a bug caused by an engineering problem became the
standard.

*> So, we think that #3 seems like a good direction to pursue.*

I don't hate any of those solutions, and this is almost perfect.

*RE: Multiple Stylesheets*
It should probably work like "use strict" in JavaScript.  If your stylesheet
(or <style>) has the switch in it, then you have real physical units.  If it
doesn't, you don't.  This allows you to use stylesheets from other authors
(jQuery UI et al) without conflict, should it exist.

*RE: Inline Styles*
Something in the switch syntax should toggle this.  If you need to use fake
in in one inline value but real cm in another, that is bonkers and I doubt
it has ever happened.

-Brian


On Thu, Oct 20, 2011 at 5:03 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Thu, Oct 20, 2011 at 9:14 AM, Brian Blakely <anewpage.media@gmail.com>
> wrote:
> > The solution to this problem is possibly tied to the @supports rule.
> > I suggest that any @supports test which includes physical units evaluate
> > false (true for the "not" keyword) when physical units are in a fixed
> ratio
> > to pixels and, hence, not actually representative of their units to the
> > viewer.
> > Example (physical units not actually supported)
> > @supports (height: 3in) /* false */
> > @supports not (height: 1cm) /* true */
>
> That seems like a very bad idea, because it's explicitly lying.
> "height:3in" is supported just fine; you can use it in your stylesheet
> today.  @supports has a very simple and easy-to-understand meaning,
> and we shouldn't corrupt it with complexity just because you don't
> like how the physical units are defined.
>
>
> Fantasai and I brainstormed on this issue a little while ago, and came
> up with three possible solutions for addressing this situation:
>
> 1. Introduce a "true physical unit", which is untethered from the px.
> (It still might not exactly match the real length, if the browser gets
> inaccurate data from the OS, but we can't solve that.)  Mozilla
> currently does this with its "mozmm" unit.
>
> 2. Introduce a switch that lets you specify the reference unit, like
> "@unit-anchor [physical | pixels];".
>
> 3. Introduce a switch that just decouples the px and other physical
> units, so the latter return to being "real" physical units.
>
> We decided that we didn't like #1.  It seems awkward to have a single
> real physical unit and require authors to convert their preferred unit
> into it.  I don't know offhand what the conversation ratio between pt
> and mm is, and I shouldn't have to know.
>
> We also believe that #2 is worse than #3.  It gives you true physical
> units, but at the potential cost of px that no longer align to device
> pixels, which is a performance nightmare.  (Not to mention, probably
> simply unworkable, since the underlying unit used by browsers is
> typically either a float based on the device pixel, or an integer
> based on subdivisions of the device pixel.)
>
> So, we think that #3 seems like a good direction to pursue.
>
> ~TJ
>