Re: [SVGMobile12] uDOM attribute normalization and getAttribute

On Jan 19, 2006, at 17:55, Anne van Kesteren wrote:
> It only talks about modified attribute values (in one way or  
> another). The same
> is true for the "style" attribute in (X)HTML documents which will  
> after being
> modified give 'unexpected' results when you do a getAttribute on  
> it. Initially
> though it represents what is being set. And I have either misread  
> the above
> quote or implementations are not allowed to return a modified  
> (normalized)
> attribute value when it is not modified.

I won't say that you're misreading, rather that that paragraph was  
born to be misread (as has been made clear by the number of LC  
comments on the exact same topic). I think that big blurb of text can  
be made a bit clearer if analysed step by step:

o "The way attribute value normalization is performed by the DOM  
implementation depends on how much the implementation knows about the  
schema in use."

Knowledge that an implementation (in this case an SVG UA) may have of  
the XML language MAY influence normalisation. This sentence is a  
point of contention because it does not say "Implementations MAY  
normalise". That being said, if you don't read it that way the last  
sentence quoted below does not make much sense.

o "*Typically*, the value and nodeValue attributes of an  Attr node  
initially returns the normalized value given by the parser." (my  
emphasis)

This is typical, but not mandated behaviour.

o "But this may not be the  case after mutation, independently of  
whether the mutation is performed(...)"

Mutation may or may not influence the above non-mandatory behaviour.

And the contentious bit:
o "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." (my emph.)

This says that such implementations can normalise *again* at the time  
when mutation occurs. But the $1000 question is of course, "again"  
after what? After initial parse.

Yes, this is spec exegesis, but hey, that's job security for you :-)

The bottom line however is that this paragraph (and a few others)  
were added explicitly so that implementations such as SVG viewers  
would be allowed to perform normalisation immediately. If it turns  
out that the DOM does not allow this, then the bug is in the DOM. I  
think the above shows that the functionality is indeed there, but  
that the DOM spec could use an erratum to clarify that paragraph  
(which is reproduced multiple times). Now, since you seem interested,  
since DOM 3 Core errata are the responsibility of the Web API WG, and  
since you're a member of said WG... I smell an action item.

Please let us know shortly if this does not address your concerns  
(about SVG Tiny 1.2),

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/

Received on Thursday, 19 January 2006 17:28:38 UTC