Re: SVG in text/html, getting closer

Hi, Cam-

Cameron McCormack wrote (on 3/9/09 4:09 AM):
> 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?

Sure, we have to do something about it.  I'm just not sure what that is, 
yet, and haven't seen a solution that I think it satisfying.  I don't 
think that Henri's proposal would yield results that authors would 
expect (if they made a mistake).  My proposal of magically sniffing out 
that it's SVG and treating it as such has a whole different set of 
problems.  I'd be interested in hearing something more compelling.


>>  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)?

I don't see how there could be, of course.  But the solution that's 
decided upon may be affected by which case we're trying to address.  If 
we are trying to correct a mistake in how the file is presented, we may 
wish it to be treated as normal SVG, with SVG's parsing rules, while if 
we are trying to allow SVG-parsed-as-HTML as a use case, we would treat 
it elseways.  Obviously, I don't tend to favor the latter.

In either case, I don't think non-XML SVG should ever be conforming (as 
XML stands now)... it should simply have reported error correction 
applied to it in the text/html case.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Monday, 9 March 2009 08:21:55 UTC