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

Tab Atkins Jr.:
> 2010/8/7 Dr. Olaf Hoffmann:
> >>Going forward, if SVG needs coordinate units in addition to CSS lengths
> >>for SVG 2.0, we could define an actual unit identifier for them. Maybe
> >>"cu" for "coordinate system units". Unit identifiers are an important
> >>extension point in CSS syntax; we should take advantage of that.
> >
> > This unit is already defined, it is called 'px'. This corresponds to one
> > unit in the local coordinate system and is implicated, if a length value
> > has no unit identifier.
>
> This is not at all compatible with CSS.  'px' has a very specific
> meaning, and it is not dependent on the local coordinate system.
> Modulo visual-warping effects like zoom: and some transform: values,
> 1px is 1/96 of 1in.

??? If we just restrict the discussion currently on device pixels,
1px on a device is related to the resolution of the device and 1in is
a derived unit from the international standard unit meter. Meter one the
other hand it derived from the light velocity and the definition of a second
(hyperfinestructure of Cs etc).

Obviously it is not the task nor the capability of any W3C group to 
define, what a meter is or a second. 
And what a device pixel is, is simply defined by the technical properties 
of the device. 
There is nothing to define and no general relation as long as producers
of hardware to not agree on having always the same resolution.
This did not happen, therefore this does not apply ;o)

And due to my tests almost no viewer manages to present 1px as
1/96in. Some assume the opposite, that 1in corresponds to 96
or 90 device pixels, what is typically nonsense and results in a
nonsense display for example for maps or  technical drawings.
At least Mozilla/Gecko determine the proper size using the 
correct resolution for device pixels

>
> The LCS-dependent lengths that SVG employs are a different unit than 'px'.
>
> ~TJ

Well, up to now CSS has no scaling or general transformations like SVG,
this appears only in a new draft, current version defined together with SVG.
If an incompatibility appears, than this new draft defines something different 
about the meaning of 'px' - I did not note this in the current draft.
At least within SVG documents it has the same meaning for such a length
to write '1' or '1px'. And it is a little bit late now to change this and this 
behaviour appears independently from specifing a unit identifier or not
and does not depend on what unit identifier is used - all are transformed
into local units and transformed than. If an author really needs units like
cm or mm within the document with a related size at the display,
such an author should not use something like transform or viewBox.
To avoid such restrictions one can use the required units for width and
height of the root svg element and use only local units within the document.

Lukily there are only a few properties in SVG, that have a length value or
something, that depends on a length value, for example stroke-width and
stroke-dasharray.
Obviously these minor deviation in the definition, how to specify a length
value, is unfortunate. Because unit identifiers are not allowed in the tiny
profiles at all for these properties, it is no useful option to require a unit
now (with the consequence to corrupt these profiles).
One option could be indeed to modify just the wording in the definition
of these properties in SVG with the change from <length> to something
else like <SVG-length>.
However there would be still a problem with properties used both in
SVG and in general CSS like font-size - but only if noted within a
CSS environment like an external style-sheet file or within the style 
element - and I think, for these special cases (that do not appear
within tiny profiles at all) it should be no problem for authors to add a
unit identifier for font-size for example - this ensures that this style-sheet
is applicable for SVG documents and arbitrary other documents as
well, if this is required.

Olaf

Received on Friday, 13 August 2010 09:52:04 UTC