W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: Making pt a non-physical unit

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Tue, 12 Jan 2010 11:00:19 +0200
Message-ID: <4B4C3A23.1070307@peda.net>
To: www-style W3C Group <www-style@w3.org>
Giuseppe Bilotta wrote:
> On Tue, Jan 12, 2010 at 12:04 AM, Linss, Peter <peter.linss@hp.com>
> wrote:
>> Now, how CSS units map to real-world physical units is something
>> that simply has to be handled on a per-media, per-device basis by
>> the UA. For interoperability sake, it makes sense to have a defined
>> algorithm to use when 1:1 physical mapping is unavailable (or
>> unwise). [...]
> The proposal to consider the difference between logical and physical 
> units could be standardized in CSS by rewriting and expanding the 
> discussion about the "reference pixel".
> The ratio between logical and true physical units would be influenced
>  by factors such as monitor resolution, assumed viewing distance,
> zoom level, etc. Lacking information, these would be assumed to be at
> a 1:1 ratio (at the default zoom level), using whatever reference is 
> available from the (visual) media: screen pixel for monitor display, 
> printer metrics for print media, etc.
> The current CSS absolute lengths would keep their description, with 
> the additional specification that they are _logical_ units of length.
>  Additionally, px would be made into a logical absolute length too, 
> equal to 1/96in. The rewritten discussion about the reference pixel 
> would be de facto equivalent to what the current standard commands.

I think that this could be a nice way to fix the current mess. I really
don't like the fact that one can use e.g. "mm" in the style to refer
something else but SI defined mm (0.001 m). However, I do understand
that real world UA implementations cannot really implement the "mm" unit
according to SI definition because the amount of *existing* incorrectly
authored content.

> Additionally, CSS could introduce the proposed true physical units 
> (truept, truein, truecm, etc) which ought to be rendered, to the best
>  of the UA knowledge, as the actual given lengths measured _on the 
> physical object_. (Thus, a poster-specific CSS could use true
> physical units and express lengths in feet, etc). An important point
> about these units is that they would NOT be influenced by zoom
> levels.

I don't like this proposal. If authors misuse these too we'll end up
with truemm-and-i-really-mean-it in the future.

I'd rather have a property "measurement" with values "logical" (or
"apparent") and "physical" (or "exact") with the default value of
"inherit" (and UA default "logical"). However, I'm not familiar enough
with the CSS parsing algorithm to know if the scale of units must be
known before parsing the properties (which would mean that "measurement"
cannot be a property but e.g. @measurement "physical").

If the feature were a property, I could put "measurement: logical
!important" in my user style sheet and end up the rendering WebKit is
using right now (if I've understood its behavior correctly). I could
also use "measurement: physical" and end up with no zoom at all. Perhaps
there should another value "auto" which select "logical" or "physical"
as the UA sees best (e.g. "logical" for "px" and "physical" for "mm").

> The question at this point would be whether a 'truepx' should be 
> introduced as well, and whether it should be equal to 1/96truein or 
> rather the smallest representable physical unit on the device (single
>  screen pixel, single printer dot, etc).

I think that a real device pixel (single screen pixel, single printer
dot) should be available for style authors. However, it really does not
make any sense to use such unit unless the style uses media queries to
correctly match the device / pixel size and fallback to more generic
style if device pixel size does not match expectations.

Perhaps require that real device pixel unit must result in parse error
if media queries have not been used at all?


Received on Tuesday, 12 January 2010 09:00:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:31 UTC