Re: [css21][css3][svg] SVG and unit-less length values

2010/8/13 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> Boris Zbarsky:
>> On 8/13/10 5:51 AM, Dr. Olaf Hoffmann wrote:
>> > ??? If we just restrict the discussion currently on device pixels,
>>
>> CSS px and device px are not the same thing.
>>
>> You're right that the CSS definition is not "1/96 in", of course; it's
>> much more complicated.
>>
>> > At least Mozilla/Gecko determine the proper size using the
>> > correct resolution for device pixels
>>
>> This is no longer the case as of last night.  We now define 'in' to be
>> 96 css px (whatever number of device pixels that is), as other UAs do;
>> too many web sites depend on that.
>>
>
> Sounds like a bug as for the others, at least for SVG documents.
> It it surely possible to define some arbitrary unit 'px' with an equation
> 96px == 1inch == 0.0254m, but not the other way round ...
> However, I think, many authors are interested as well to have a
> unit for one ordinary pixel of a raster image - at least for this
> application device pixels can be pretty useful - and sometimes
> not a trivial thing in SVG to embed a raster image without
> interpolation or without knowing the intrinsic pixel size of the
> raster image.
>
> If you get wrong sizes for maps and technical drawings, this is certainly
> a bug and every user can see this using a simple measuring stick.
> Well maybe not very important for inches, but if the same bug appears
> for cm or mm, this is close to ridiculous to pessimise Mozilla/Geckos,
> just because a few authors obviously do not understand, what an
> inch is (I think, it is defined to be 25.4mm, respectively 0.0254m and
> nothing else - but I'm not sure, who defined, what an inch is, but
> I'm pretty sure what the definition of m (cm, mm is) ;o)
> Up to now, one can at least say - if you need a proper size of your
> image in cm, use Mozilla/Geckos. After such a pessimisation one
> can always write:
> Note, due to bugs of viewers, the size of the map/drawing will
> typically displayed wrong. Do not rely on  defective viewers and
> convert into another (CSS independent) format to get a proper size -
> I cannot see, that this is useful for authors or the audience to switch to
> another format to get something predictable, if they need a drawing
> with a true scale. Why should it not be possible for W3C formats simply
> to get 1cm or 1in if this is noted?
> If someone wants to buy an apple and get a banana, just because some
> people like bananas much more than apples - what is the advantage of
> this cheating for the cheated?

The issue has been discussed *to death* in the CSSWG, but I can
quickly summarize the reasoning.

Though the CSS px unit was intended to be a physical unit (defined by
reference to a particular visual angle it should subtend), for various
technical reasons it was never quite able to actually be one.  In
order to have decent performance and visuals, you have to ensure that
a CSS px makes up some whole number of device pixels.

Further, there's historical precedent for there to be 96 device pixels
per inch.  So, for a long time there were 96 CSS pixels per inch as
well.

Now, authors don't distinguish between real physical units and
sorta-physical units.  In particular, they relatively commonly specify
fonts in pt (defined as 1/72 of an inch) while specifying everything
else in px.

This causes a problem when screen DPI starts to rise, because the CSS
px has to track the device pixel and shrink, while physical units have
to stay the same size.  If we naively followed this, webpages would
break - in the worst case (screens at about 140 dpi) fonts could be
50% larger than they were "supposed" to be (in relation to the rest of
the page which is measured in px), which would break a lot of layouts.

There's also a smaller subset of authors who use the other physical
units (in, cm, mm, etc.) in conjunction with px, which would cause the
same issues.

So, we're stuck.  We can either (1) just keep units as accurate as
possible, thus breaking sites, (2) maintain the px/in ratio by making
the CSS px map to a fractional number of device pixels, thus causing
horrible performance regressions, or (3) maintain the px/in ratio by
making the physical units equal something different than their "true"
measurements.

We can't break sites.  We can't allow horrible performance
regressions.  So #3 is the only realistic choice.

It's not nearly as weird as it sounds, though.

First, it's the ratio that's important, not the actual value.  Devices
which either have a very high dpi or which can afford to take the
performance hit can just make the CSS in be a real inch, and the CSSpx
1/96th of that (or close enough that the difference doesn't matter).
So printers are just fine.

Second, we're currently at the most painful point in the entire
situation.  Devices around 150dpi are relatively common right now,
which produces the greatest mismatch between what a CSS in "should" be
and what it realistically has to be (depending on whether you make the
CSS px 1 or 2 device pixels, the CSS in is either 2/3 or 4/3 of a real
inch).  The next major pain point is around 250dpi, but it's much less
of a problem then (a CSS in is .8 or 1.2 real inches).  Once we pass
300dpi, the pain is low enough that we shouldn't really have to worry
about it again.

So, don't worry.  This is nothing more than a compatibility hack with
temporary extent.  Many devices can proceed like nothing is wrong, and
technology will save the rest in the near future as screen dpi climbs
upward.

~TJ

Received on Friday, 13 August 2010 17:40:06 UTC