Re: SVG and MathML in text/html

On Mar 15, 2008, at 18:28, Doug Schepers wrote:

> Henri Sivonen wrote (on 3/15/08 11:01 AM):
>> On Mar 15, 2008, at 15:58, Doug Schepers wrote:
>>> 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?
>
> I don't know of any such tools, but when the argument of using XML  
> parsing rules is mentioned, the assertion is frequently made that  
> not all content generation tools can follow XML rules.

There's a difference between not being able to handle quoted attribute  
values and being able to make sure unquoted values are never passed  
through.

> If you're saying you don't know of any content generation tools that  
> cannot generate quoted attribute values consistently, then that  
> means there's no known block in requiring quotes.  So there's really  
> no harm in requiring them.

No, I'm saying there are tools that cannot guarantee the well- 
formedness of what flows through them in general.

>>> 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.
>
> You're assuming a single-author system, which is not always the  
> case. Giving the option of using unquoted attribute values will mean  
> that some people will use it and others won't.  Given mashups, this  
> is likely to cause some collisions.

Ajax mashups happen on the parsed DOMs. What kind of collisions do you  
have in mind?

>>> 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?
>
> You've already conceded that we need to close elements in SVG.  
> Encountering the string "/>" (or ">" and a subsequent "</...>" for  
> open elements) should do it, no?

Nope:
<foo attr=val aother="/>" third=val/>

>>> 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?
>
> Because it preserves compatibility with all other SVG content and  
> UAs, thus capitalizing on the network effect.

That's a fallacy. As I have pointed out before, *no* SVG-in-text/html  
scheme can capitalize on compatibility with deployed SVG-as-XML  
clients, because the clients trip up on the text/html Content-Type or  
at least the HTML wrapped around the SVG image.

>>> 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?
>
> See above.

Even if you extracted the SVG part on the source level and fed it to  
an SVG-as-XML client, you'd get a fatal error on the XML layer. How  
exactly would this capitalize on a network effect?

>> How is that worth the complexity of having two different attribute  
>> tokenization rules that get toggled in mid-parse?
>
> See above.  Also, you've already conceded that SVG and MathML need  
> particular parsing rules (thus requiring some sort of "SVG/MathML  
> parsing mode"),

I've conceded that some special casing is needed. It doesn't follow  
that gratuitous special casing that isn't strictly necessary should be  
added.

> this is simply one more aspect of that, and not a onerous one,  
> because the parser already knows how to handle quoted attributes.   
> It puts little to no additional burden on implementations.

It's additional burden that isn't strictly necessary.

> I honestly don't understand why the pragmatics of legacy support are  
> being disregarded for the sake of ideological consistency that has  
> no proven benefit to authors.

Legacy support by XML clients gets broken no matter what due to the  
HTML wrapper. At that point the attribute syntax doesn't save things.

> What about the design principles of "Degrade Gracefully",

Graceful degradation excludes Draconian behavior.

> "Do not Reinvent the Wheel",

The XHTML+SVG wheel is not round enough.

> "Pave the Cowpaths",

Non-Draconianness is an text/html cowpath as are unquoted attribute  
values.

> "Evolution Not Revolution",

SVG-in-text/html would be an evolutionary step for text/html and DOM- 
based SVG renderers.

> "Avoid Needless Complexity", and

Hence, as few special cases in the syntax/parser.

> "Solve Real Problems"?

I don't see what your suggested additional rules would solve.

> What true benefit does this confer?

Consistency with the rest of text/html including the resulting  
simplicity in the parser and teachable rules.

> I have been very active in the SVG community for 8 years, and while  
> some people have complained about namespaces, I have never heard a  
> complaint about having to quote attribute values.  Can you supply a  
> single piece of evidence that this is a problem?

That's the wrong question. The right question in the context of  
enabling SVG in text/html is: Can you supply evidence that using the  
same attribute tokenization rules throughout text/html is a problem.  
(You've already presented it as a problem, yes, but the problem you  
have presented doesn't get solved by your proposed solution.)

> After all, according to the "Priority of Constituencies", we need to  
> be more concerned with users over authors over implementors over  
> specifiers over theoretical purity.  This is sounding very much like  
> an issue of theoretical purity within the HTML5 spec.

You are arguing from XML theoretical purity point of view. How are  
authors hurt if fill=red actually gives a red fill?

> There are far more important and interesting problems to solve with  
> SVG in text/html.

I agree.

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

Received on Saturday, 15 March 2008 17:03:44 UTC