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

David Singer:
> Dr Hofman
...Dr. Hoffmann...
>
> It would help me (and maybe others) if you could please
>   (a) read the previous discussions on whether we need units such as 'true
> mm', 'true inch', 'true pixel'; this was discussed at length, and while it
> is possible you have something to add, your points may have already been
> discussed;

I did now a search along with the key expression 'true mm'
and found a longer discussion about 'Making pt a non-physical unit'
and  'Issue 149 - px vs. pt' and later on a discussion I contributed
to as well 'SVG and unit-less length values '.

My understanding is, that due to bugs in browsers some authors did
not understand the meaning of the units pt and px, with the
result of stylesheets with surprising presentations in browsers without bugs
(however, we have to keep in mind, that per definition, such a surprising
presentation is the written down intention of the author for all currently
existing CSS files).
Note that the initial comment was only about pt and not about real
standard units like cm or mm.

This resulted in implementing bugs in even more browsers simulating the
bugs of the browsers doing it wrong, with the result, that absolute units 
are practically not supported in current browsers, what fits to my own SVG 
tests of this issue - browsers/viewers have massive problems with length
values in SVG, if they contain a unit at all - authors should not use unit
identifiers within values in SVG attributes/properties, because it does 
not work. And if noted as CSS for SVG, they should only use px to
get the same effect as no unit identifier.

From the initial idea to cover up the problem with the pt in 
'Issue 149 - px vs. pt' there it was started to define a fixed relation of 
px to absolute units.
But as far as I have seen, in this proposal the wording was misleading.
Instead of caring only about the pt-problem or talking about accuracy 
limitations, this obviously developed somehow in an odd direction of having
two contradictory definitions of units. 

And along these three discussion lines there were several warnings
from different people about the problem of corrupting standard units in 
CSS with a careless change.  Following these discussions it is 
surprising to see what is currently noted in the draft - it could have
been fixed before, taking into account the warnings. 

To resume - looking in these old discussions, there was nothing,
what I did not already have assumed without reading it all - it
took mainly time to care about this unsorted kind of information,
where I often cannot distinguish between opinion, time dependent
developments and relevant information anyway - 
therefore the relevant information has to be found in the draft, 
not in the mailing lists.

>(b) try not to imply that the members of this group do not
> understand what centimeters, inches etc. are; and 

I did not imply that, but following the discussions as suggested,
indeed it seems to be obvious, that some implementors did not
understand, what it is, resulting in implementation bugs. 
And confronted with these bugs even more authors did not 
understand it - and finally this struck back to some members 
of the CSS group, that do not (want to) understand it (anymore).
Obviously quality and understanding got worse within the 
years, CSS exists.

> (c) be clear about what you are objecting to.  
> Is it the lack of CSS 'true' units?   
> The fixed ratio of CSS pixels to length units such as point, inch, etc.?

Whatever 'true' means. Following the first part of the draft, everything
is related now to the absolute unit 'cm' - if you mean this by 'true' in
a sense of an international standard unit for a length, there is no lack.
The number and choice of different available units is a matter of taste.
On the other hand, some authors may miss an option to present
a raster image without interpolation now - what is another (important)
issue. After fixing the problem 'contradicting definitions of units'
we can face this issue ;o)

> Which of the two
> 'anchor' methods are you particularly concerned about?
>

I think, the sentences about anchor methods are misleading/inconsistent,
because everything is already defined before:

"Absolute length units are fixed in relation to each other. They are mainly 
useful when the output environment is known. The absolute units consist of 
the physical units (in, cm, mm, pt, pc) and the px unit: 
in: inches — 1in is equal to 2.54cm.
cm: centimeters
mm: millimeters
pt: points — the points used by CSS are equal to 1/72nd of 1in. 
pc: picas — 1pc is equal to 12pt.
px: pixel units — 1px is equal to 0.75pt."

As already mentioned before instead of '1in is equal to 2.54cm.'
it should be: 'note, that 1in is equal to 2.54cm.'
And if the last line persists, there is no need anymore for
'The absolute units consist of the physical units (in, cm, mm, pt, pc) and the 
px unit:', this can be shortened to:
'The absolute units consist of the physical units:'

The only thing, that could be quite useful here is to add an informational
part about accessibility problems, existing problems of browsers to realise 
this and about limitations of accuracy (as SVG has for example) to simply 
the life of implementors and testers.
Depending on what is assumed that browsers can realise, one could
say for example the required accuracy for the display of lengths is one 
device pixel (respectively a related resolution length, if the device has no 
pixels at all).

Instead of this it is mentioned:
"For a CSS device, these dimensions are either anchored (i) by relating the 
physical units to their physical measurements, or (ii) by relating the pixel 
unit to the reference pixel. For print media and similar high-resolution 
devices, the anchor unit should be one of the standard physical units 
(inches, centimeters, etc). For lower-resolution devices, and devices with 
unusual viewing distances, it is recommended instead that the anchor unit be 
the pixel unit. For such devices it is recommended that the pixel unit refer 
to the whole number of device pixels that best approximates the reference 
pixel. ..."

A physical unit like a centimeter is always related to a physical measurement
of a length, not to viewing circumstances or resolutions of devices - this is
the whole point about it, a centimeter is a device independent absolute
unit and it is defined in such a way, that this entity is independent from the
method used to realise/present it, else it is not a centimeter. 
There is no choice. That the draft mentiones a choice, indicates, that there
is a problem to understand, what a centimeter is.
And because above px is fixed to such an absolute unit, there is no other 
option for px as well anymore with this definition (unfortunately - my 
opinion - but whether this is a good idea or not, is another issue).

Maybe this section was intended to be about browser problems and accuracy, but
in fact it introduced two definitions for entities, that are indicated to be 
lengths - apart from accuracy problems there can be only one definition for a 
standard unit like cm.
Following the second definition for a moment, if you have for example a 
device with a pixel size of 0.2mm you suddenly get for an SVG image with the 
noted/intended width of 10cm a presentation of an image
with the width of 10cm * (96/127) = 7.559... cm, what causes a deviation
far more than one device pixel (0.02cm here), and therefore 
a) an unusable presentation
b) a second definition of a centimeter.
Or following the first definition with the same device and an author wanting
to present a raster image (embedded in (X)HTML or SVG) matching
on image pixel with one device pixel, this author will get an unusable 
presentation again.
Even worse, if the author has both - having a raster image (today
an image width of 5000px is not unusal for digital cameras, together 
with typical sizes of a sheet of paper this already limits the usability of
the CSS section about reference pixels, a helpful resolution of the
device would be about 400-1000dpi  or 16-40px per mm to print the 
complete image on the paper, therefore not even high-resolution device 
should have to care in such a case about reference pixels or viewing 
distances)  of a meeting point with the requirement to see details 
without interpolation and an SVG map (true to scale) to find the rendezvous.
Following the current draft, such an author can rely, that no user agent can
fulfill these requirements even in theory. It is not even predictable for the
author which part will fail - or both, but at least one must fail now.


If it is the intention to explain a work-around for problematic cases, one
could write something like:
'For some devices the user-agent might not have reliable information about
how to present an absolute unit properly. 
In such cases the user-agent can instead guess/use  the relation of 1 device 
pixel (or alternatively a reference pixel) = 1px = (127/480)mm to present an 
absolute unit. 
The user-agent should/must inform the user about the problem
of presenting absolute units in different size in such a case and
should provide a mechanism to the user to add the missing information
about the resolution to fix the problem manually.
As an accessibility tool in case of guessing, the user-agent might provide
a scale to indicate the current presentation size of a cm.'

This avoids the impression, that there are two definitions for the same
units - and especially that the CSS WG does not know, what a cm is.
Maybe the main advantage of such an approach for the CSS WG is, 
that if the user-agent provides an option to the user to add missing
resolution information, finally the user is responsible for a proper
presentation of the absolute units and not the CSS WG or implementors.
The main advantage for the user is, that there is a chance at all to
fix the presentation, in case it matters.

Olaf

Received on Saturday, 11 December 2010 19:01:06 UTC