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

On 13/12/2010 15:21, Dr. Olaf Hoffmann wrote:
> Anton Prowse:
>> True, but the draft goes on to clearly define what the notation and
>> terminology means in the specific context of CSS.
> Well, because the meaning of centimeter and millimeter is
> already well defined, if the draft stats something different, this
> results in a contradiction.

"Contradiction" isn't the right word here.  The definitions are merely 

> that disqualifies the section with
> this deviating definition automatically.

Why?  CSS has no formal dependency on the commonly-accepted scientific 
notions of centimeter and millimeter, and so it is free to redefine 
those words however it wishes...

   `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
   `it means just what I choose it to mean -- neither more nor less.'"

...however, the WG must undoubtedly have taken into consideration the 
potential of confusion arising by attempting to redefine such 
commonly-understood terms.

   `The question is,' said Alice, `whether you can make words mean so
   many different things.'

         - Alice in Wonderland (Lewis Carroll)

As I said earlier, the WG possibly hasn't done enough to avoid 
confusion; but this is probably an editorial failing rather than a 
technical one.  It seems that the potential confusion in using existing 
unit notation "cm", "mm" for the new non-typical units is probably less 
than in employing words like "centimeter" and "millimeter" for 
non-typical units, and so I suggest adjusting the description of the 
list of absolute units by continuing to express the ratio relationship 
between them but deferring mention of the full words "centimeter", 
"millimeter" etc until the discussion of anchoring "the physical units 
to their physical measurements" (which happens only for certain 
devices), so as to avoid redefining them away from their accepted 
scientific meaning.

> There is only the unit centimeter and no more or less 'true' or 'real'
> centimeters. This is the whole point about standards, that it is always
> the same and that everybody can rely on this within the accuracy level
> of relevance for the related application ;o)

I'm not sure that I accept that argument.  It may be the case that a 
standard which defined the word "centimeter" in any way other than the 
scientifically accepted way would be confusing and probably provoke 
annoyance.  But you seem to be confused about the difference between 
creating a new unit of measurement and assigning it an existing name, 
and redefining an existing unit of measurement to mean something new. If 
the WG is guilty of either (and it's not clear to me that it is, beyond 
a non-technical editorial failing) then it's the former rather than the 

>>> 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.
> Following the discussions, there is a strong  presentiment, what the
> 'real' purpose might be, only to camouflage implementation bugs instead
> of fixing them ;o) And I think, it helps authors, if we succedd in defeating
> this - especially because the camounflage results in contradiction,
> which results in unusable absolute length unit for the future.

Aside from your use of the word "contradiction", that's a very valid 
argument, of course.  But that's a different argument from the one you 
were using above, and needs to be addressed separately.  (I believe the 
WG bore this argument in mind, since I recall this being discussed on 
this list in the past.)

> Within CSS is is clearly incompatible with previous recommendations
> and therefore in fact with all currently existing documents using CSS
> with such units (whatever authors assume, how this should be presented
> or not).

Again, a valid argument which the WG must surely have taken on board. 
(For me personally, this is the strongest argument in favour of 
preserving the original units.)

> And even worse, it is incompatible with international standards, the
> base of culture, science, techniques and trade.
> Successful obfuscation here finally could result in a situation,
> where it is not possible anymore to build the devices that are needed
> to view documents styled with CSS, because the production of
> such devices require proper science, techniques and trade.

I can certainly see that there might be a demand for the re-introduction 
of "true physical units", presumably using new unit notations.  I recall 
someone suggesting "truecm".  I assume that the WG feels that the need 
for such units is currently insufficient to outweigh the benefits of 
repurposing the existing notations such as "cm".

>> 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.
> My comment is about the inconsistency, not about terminology.
> CSS lives in a cultural environment and has only a meaning related
> to such a cultural environment. It does not just end in itself.
> Therefore it is not possible to disconnect it from this environment
> that defines basic things like units, if there should remain any
> meaning for the cultural environment.
> Of course it is possible to call a building a flower, but the
> consequence it, that statements become meaningless for the
> environment.

I disagree that the situation is as extreme as you suggest.  I find 
myself dealing regularly with the same concept being given different 
names – and the same name being used for different concepts – across 
cultural boundaries, and although it can be irritating it causes me no 
great conceptual difficulties.

> If you do it properly as above, it improves CSS.
> I think, such reference pixel have use cases as many other units have as
> well, but these are not the only use cases, therefore the other units are
> important as well for several applications. And once implemented, one
> will see more and more of these use cases. That one cannot see them
> right now, is just an indication, that authors know about the bugs in
> current implementation and that CSS fails for their intentions
> and use others formats or communication channels for those applications -
> or do not realise their applications at all waiting for bug fixes instead
> of camouflage.

> To obfuscate the meaning and to frustrate use cases for such
> units is simply not explainable. I discussed it with other authors
> and what I got are shaking heads about such an obfuscation.

No doubt the WG would be interested to hear about the use cases.

> And if some authors are already mixing up pt and px as
> reported, do you really believe, that they understand the
> difference between a standard unit like cm and a obfuscated
> unit like cm in CSS?

No, but that's more or less the problem, isn't it.  Such authors are 
also unlikely to realize that using "cm" isn't a wise idea outside of 
media such as print, and hence their ignorance causes their pages to 
break on media such as screen because they've used inappropriate units.

Your argument is that such authors should be educated.  The various Web 
WGs seem to err upon the side of "pave the cowpaths".  (I choose not to 
express my opinion on this matter here.)

>> and at this point cannot be
>> changed retroactively because the old CSS units are already in widespread
>> use
> Well, I think, absolute units are currently not often used, due to the known
> bugs of browsers.

Yes, I wonder about this too.  How serious is the issue of 
backwards-compatibility and poor choice of units, really?  I'd be 
interested to see what kinds of examples are out there in the wild.  (I 
don't doubt they exist in abundance, else the WG's decision doesn't make 
much sense to me.)

> And another problem is of course, that older documents based on CSS2.0
> do not change their meaning. In fact one had to explore the date of creation
> to find out, whether the author used standard units or CSS obfuscated units.

This is the same argument you raised above, and a valid one.

Anton Prowse

Received on Monday, 13 December 2010 18:49:41 UTC