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

Re: [CSS21] 4.3.2 Lengths (reference pixel?)

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 12 Dec 2010 14:48:56 +0100
Message-ID: <4D04D2C8.2060909@moonhenge.net>
To: www-style@w3.org
On 12/12/2010 14:05, Dr. Olaf Hoffmann wrote:
> Brad Kemper :
>> The point you seem to be missing is that we are not trying to define inches
>> and centimeters. We are defining the CSS units of 'in' and 'cm'. In some
>> contexts, these have a direct relationship to inches and centimeters, and
>> in others they do not. On projector screens, for instance, 'in' is just
>> about as divorced in meaning from a physical "inch" as it is from the
>> preposition "in".
>
> No, as cited several times, it is written in the draft:
>
> "
> cm: centimeters
> mm: millimeters
> "
> This means, that 'cm' represents centimeters and
> 'mm' represents millimeters. These are the same
> letters (symbols) and words as commonly used for international
> standard length units called 'centimeter' and 'millimeter'.

True, but the draft goes on to clearly define what the notation and 
terminology means in the specific context of CSS.

I agree that it's possibly undesirable to use the words "centimeters", 
"millimeters" etc at that specific point in the spec, since it seems to 
me that it's not necessary to redefine those words; it should be 
sufficient to redefine just the unit notation and to then go on and 
state the conditions under which those units do represent "real" 
centimeters and millimeters (print media and similar high-resolution 
devices).  However, it's not "wrong" to expropriate those terms provided 
that the new meanings are clearly defined.

The CSS WG appears to have a reasonably strong pragmatism streak.

> If the CSS WG wants to define own units for whatever purpose,
> they must not use 'cm', 'mm' and words like 'centimeter' and 'millimeter'.

But that defeats the purpose.  (I'm sure the WG would do so precisely 
that, if it served any useful purpose.)  The fact that the notation and 
terminology matches existing established notation and terminology is 
perhaps unfortunate from a universality perspective, but given the 
motivating reason behind deciding to redefine these CSS unit through 
hooking them to the reference pixel (namely to work around the fact 
there there is significant misuse of these units when they were 
originally defined to match the existing established meanings) it's 
inevitable that we end up at a situation where the notation and 
terminology has to be redefined for CSS's own purposes.

> However the problem with the section about the 'reference pixel'
> is, that it gives the impression, that the CSS WG tries to define, what
> centimeters and millimeters are, related to viewing circumstances
> and device resolution.

Well that's exactly what they /are/ doing; it's not an impression.

It's not clear to me why this is so very objectionable to you.  If you 
prefer, just regard the strings "cm", "mm", "centimeter" and 
"millimeter" as identifiers.  I agree that this could be confusing if 
the redefinition were obfuscated, but given that it's clearly and 
explicitly stated in the section of the spec that discusses <length>s, I 
don't see that this is a problem.

I'm not claiming that the situation is ideal.  However, it serves a purpose.

> As already suggested, there could be an information, how to
> present millimeters or centimeters in such problematic cases, where
> the user-agent does not know anything about the resolution of the
> device or for such cases, only viewing angles are relevant and not
> lengths, but such information is currently not available in the draft -
> or at least the wording is misleading, if it is the intention of the
> reference pixel section to care about such problematic situations
> and devices.

If there is a internal inconsistency with the new definitions then 
that's a different issue which needs to be addressed separately from 
your issue about disliking the notation/terminology.

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Sunday, 12 December 2010 13:49:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT