Re: SVG in text/html, getting closer

Doug Schepers:
> To clarify: I don't see a compelling use-case for doing this  
> *purposefully*.  Situations where the server is misconfigured, where the  
> author accidentally gave the file an "*.html" extension instead of  
> "*.svg", etc. are a different matter that I am inclined to treat more  
> sympathetically.

OK.  So you’d be open to having this <svg>-as-root as non-conforming but
working?

> Henri was pretty clear that he wasn't trying to solve the borken case,  
> as we discussed, but rather to propose some new behavior. [1]  And even  
> he didn't claim to be advocating for it, just noodling out a possible  
> solution.

Acknowledged.  But would there be any difference in behaviour between
catering for the mistakenly- and the deliberately-served-as-text/html
cases (apart from conformance)?

>>>  and tying ourselves to a drastic solution like Henri proposed seems
>>>  like it will make it more difficult to code cleanly in XML-next, with
>>>  more permissive error recovery.
>>
>> Could you elaborate?
>
> No.
>
> :)
>
> Or rather, I just don't see the benefit in doing this on purpose, so I'm  
> not particularly eager to invest energy catering to that case.
>
> I guess my thought are vaguely along the order of... if something is  
> codified in HTML5, and down the pipe the XML community changes XML to be  
> permissive-but-not-identically-to-HTML5 (as I think is likely), but  
> there is already some sort of established back-door practice where  
> people just use HTML5 algorithms for parsing SVG, then SVG is forked in  
> multiple incompatible ways.  Or something.

I see.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Monday, 9 March 2009 08:10:02 UTC