W3C home > Mailing lists > Public > www-style@w3.org > October 2011

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 20 Oct 2011 14:03:07 -0700
Message-ID: <CAAWBYDBbqZ9AMF5w6zXP4PZaavsUfiCiUMjx_QJHN2FGtO401Q@mail.gmail.com>
To: Brian Blakely <anewpage.media@gmail.com>
Cc: www-style@w3.org
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.

Received on Thursday, 20 October 2011 21:03:49 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:05 UTC