W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Re: SVG in text/html, getting closer

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 9 Mar 2009 19:09:24 +1100
To: Doug Schepers <schepers@w3.org>
Cc: public-svg-wg@w3.org
Message-ID: <20090309080924.GA9678@arc.mcc.id.au>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 March 2009 08:10:20 GMT