W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2010

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

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Sat, 7 Aug 2010 14:13:29 +0200
To: public-fx@w3.org, www-style@w3.org
Message-Id: <201008071413.30473.Dr.O.Hoffmann@gmx.de>
..........
>I suggest that SVG defines a <coord> value type, and uses <length> | <coord>
>wherever needed. This way there is no confusion about <length>: it always
>requires a unit.

Something similar called <coordinate> is already defined
"A <coordinate> is a length in the user coordinate system that is the given 
distance from the origin of the user coordinate system along the relevant 
axis (the x-axis for X coordinates, the y-axis for Y coordinates). Its syntax 
is the same as that for <length>."

Because for <length> units are optional, this covers already the needs
for SVG.
To change something, that <length> suddenly requires a unit will
corrupt the tiny profiles completely and typical usage of SVG in
general as well.

And to define for every related attribute or property '<length> | <coord>'
with <length> with unit and  <coord> is indeed compatible with
the current definition of <length> - it changes nothing, therefore it is
not obvious, what the purpose of such a change would be...
One could simply change the wording from <length> to <svg-length>
and use <svg-length> instead of <length> for SVG to avoid 
confusion with <length> defined for example in CSS, what could
be changed in the same way to <css-length>.

>Older SVG specs can simply be errata'd to clarify this loophole with an
>explicit list of properties that can take <length> or <coord> where
><length> is specified.

Because as already mentioned, no viewer I tested managed units
completely at all, one cannot expect, that a change of older specifications
will change the behaviour or success of currend of older SVG viewers.
This will only confuse authors with the assumption, that this might 
work somehow in older versions - what is certainly not true, because
practically documents with mixed units already allowed now do not
really work in current viewers. What is the purpose to change the
old recommendations? This might have some use in case of contradictions
of if the behaviour of all old user agents is the same and differs from
the recommendations - but this is not the case here.
At least without unit identifiers there is no problem with the viewers,
there appear only major problems, if unit identifiers are added ;o)
Therefore more plausible would be to remove unit identifiers
at all for <length> ;o)

>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.
What is the advantage of adding 'cu' in detail?
It is basically only two letters more per length value - and because in
SVG documents such length values can appear very often this can
sum up to a much larger file - not really an advantage.

Note further, that any SVG document with a path element (this will
be the majority of SVG documents) uses automatically local units for
this, therefore due to bugs and gaps of current viewers it would be
pretty stupid for authors to mix this with other things, dimensioned
in absolute units like mm. Due to my tests only the Geckos can currently
convert something like mm or cm properly into local units (they seem to 
have a bug however for pt already relative to mm). 
Because the use of other units than local units, boundingBox units
or percentage is very limited, it is a waste of efforts for authors to add
always a unit letter or two to a local unit.
As long as there is only one unit implicated, if there is no unit identifier
provided, there is no practical problem to leave it and there is no
advantage to add it, if the local unit is intended.


Best wishes 

Olaf
Received on Thursday, 12 August 2010 08:51:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 August 2010 08:51:43 GMT