- 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
.......... >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 UTC