Re: SVG and MathML in text/html

On Mar 15, 2008, at 15:58, Doug Schepers wrote:

> In practice, that would require all the implementations that  
> currently do the due diligence of string matching the namespace name  
> to update their code, and I don't see enough of a win there, since  
> most people probably use boilerplate.

I'd go further and say that it's now only not enough of a win but a  
downright lose due to the incompatibility and inefficiency that would  
be inflicted.

> What happens when I have an unquoted attribute value with no spaces,  
> then change the value using script to have a space (as in the  
> above)? Since it's not at the parser level, it should be fine... but  
> what happens when I serialize?  Are all unquoted attribute values  
> quoted,

All attribute values are quoted by a sane serializer no matter how  
they originated. No problem.

> What happens if I'm using one of these legendary content generation  
> tools that can't handle quoted values (as has been asserted),

What tools are those and who has asserted?

> And what about a scenario like <a xlink:href=http://example.net/ 
> ><circle ... /></a>?  How is that handled?  Is the circle linked, or  
> not?  I'm sure it's described in the HTML5 spec, but it wasn't clear.


The circle element becomes a child of the a element, so yes, the  
circle would be linked.

|Attribute value (unquoted) state
[...]
|   U+003E GREATER-THAN SIGN (>)
|        Emit the current tag token. Switch to the data state.

> What happens if I do accidentally create a parse error by forgetting  
> to quote an attribute value that has a space?

You get some garbage attributes in the DOM for the stuff after the  
space.

> As far as I can tell, parse errors give unpredictable results: "user  
> agents must either act as described below when encountering such  
> problems, or must abort processing at the first error that they  
> encounter for which they do not wish to apply the rules described  
> below."
>
> So, it's not mandated that a UA follow the parsing rules... but if  
> it doesn't, it has to halt and catch fire.  How is that less  
> draconian?

I asked for that rule to make the true streaming SAX mode of the  
Validator.nu parser conforming. That rule is there to allow streaming  
implementations for special purposes. Browsers aren't expected to take  
advantage of that rule.

> Rather than the consistent and easy step of always quoting attribute  
> values, the user now has to think about something that would  
> normally be automatic.  Maybe it's just me, but that seems harder,  
> especially to debug.

If the author doesn't want to think about that, it is always OK to  
quote values.

> My first suggestion is that a UA simply hands the SVG snippet off to  
> an XML parser.  If that's unpalatable, my alternate suggestion is  
> that if an SVG element uses unquoted attribute values, the parser  
> ignores that attribute

How do you know where that attribute ends without parsing rules like  
the ones HTML 5 already has?

> and any subsequent attributes (quoted or not) and proceeds on to the  
> end of the element, then continues parsing the next element normally.

How is that more useful that following HTML 5 attribute tokenization  
as currently drafted?

> So, with the following snippet:
>
> <svg xmlns="http://www.w3.org/2000/svg">
> <circle cx="100" cy="50" r="25" fill=red stroke="blue" />
> <circle cx="100" cy="50" r="15" fill="yellow" stroke="blue" />
> </svg>
>
> You would see a yellow circle with a blue stroke on top of a black  
> circle with no stroke.  That's well defined, and not particularly  
> draconian.  And it's easy to understand.

How is that more useful that having the first circle filled red and  
stroked blue?

How is that worth the complexity of having two different attribute  
tokenization rules that get toggled in mid-parse?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Saturday, 15 March 2008 15:01:53 UTC