Re: SVG12: 'display' trait

Ian,
The SVG WG coordinated with the DOM WG long ago about attribute value 
normalization which might result in getAttributeNS() returning a different 
string than was set via setAttributeNS(). It was decided that SVG 
implementers needed to have the normalization option in order to achieve 
performant implementations. For example, it is common to implement the 
<path> element by reducing the 'd' attribute to numeric data structures and 
toss out the original attribute string value.

Here is the text in the DOM3 spec that talks about this 
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-637646024, then 7th 
paragraph):

-----------------------------
The way attribute value normalization is performed by the DOM 
implementation depends on how much the implementation knows about the 
schema in use. Typically, the value and nodeValue attributes of an Attr 
node initially returns the normalized value given by the parser. It is also 
the case after 
<http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-normalizeDocument>Document.normalizeDocument() 
is called (assuming the right options have been set). But this may not be 
the case after mutation, independently of whether the mutation is performed 
by setting the string value directly or by changing the Attr child nodes. 
In particular, this is true when 
<http://www.w3.org/TR/2004/REC-xml-20040204#dt-charref>character references 
are involved, given that they are not represented in the DOM and they 
impact attribute value normalization. On the other hand, if the 
implementation knows about the schema in use when the attribute value is 
changed, and it is of a different type than CDATA, it may normalize it 
again at that time. This is especially true of specialized DOM 
implementations, such as SVG DOM implementations, which store attribute 
values in an internal form different from a string.
-----------------------------

Jon

At 01:57 PM 6/9/2005, Ian Hickson wrote:

>On Thu, 9 Jun 2005, Chris Lilley wrote:
> >
> > The point is that
> >
> > <g display="
> >
> >
> >             inline-block
> >
> >
> >
> >
> >             ">
> >
> > Does not have to store, and be able to provide on request, the full
> > glory of all the carriage returns, tabs, and leading and trailing spaces
> > in the attribute value.
>
>Well, some of those characters get converted during parse time (XML1
>3.3.3), but apart from that, it seems to me that DOM Core requires you to
>return what the author specified, not some normalised version of it... Is
>SVG trying to define DOM Core behaviour? Because that would seem to be
>outside SVG's mandate...
>
>--
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'