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

Re: SVG in text/html, getting closer

From: Jonathan Watt <jwatt@jwatt.org>
Date: Wed, 11 Mar 2009 11:48:08 +0100
Message-ID: <49B796E8.2020703@jwatt.org>
To: public-svg-wg@w3.org
On 3/9/09 4:17 AM, Doug Schepers wrote:
> Hi, Cam-
> Cameron McCormack wrote (on 3/2/09 7:24 PM):
>>    * Should prefixed svg elements work (be put in the proper namespace)?
>> I don’t think we need to try to support such content in HTML.
> It's legal in XHTML, though I don't know how common in general that 
> practice is.  Ideally, SVG in text/html would not be too far off from 
> SVG in XHTML.  What are the constraints that make permitting this 
> troublesome (other than the general distaste for XML Namespaces)?
> This is not a critical issue to me, but I'd like to see some evidence 
> that it's a real problem, rather than an arbitrary decision.

We may not want to support prefixed SVG elements it HTML just now, but I don't
think we should unnecessarily preclude a post-HTML5 version of HTML supporting
them. See my concerns in the March 9 telcon minutes.

>>    * How do we fix our suggestion that about not generating implied
>>      <html>  and<body>  open tags when the<svg>  open tag is the first one
>>      encountered?
>> Not sure yet.
> Flag the MIME Type as an error for the console, and parse it as XML? 

I don't think that will fly. Generally "security reasons" have made browser
vendors (other than IE [in the past?]) take a strong line on making the HTTP
specified content-type trump everything else.

> This would be problematic if the person wanted to have SVG as the root 
> with some text/html in <foreignObject>... But in that case, they could 
> simply make the root <html>.
> I don't see a real use-case here, 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.

So maybe the HTML5 proposal should not be changed for this?

 a) I'm skeptical that servers default to text/html. Don't they generally
    default to text/plane? (In which case we're not "helping" anyone by
    making this change.)

 b) If authors really want to "write SVG with HTML's error tolerance", then
    they can still serve SVG markup as text/html with a CSS rule

      html, body { height: 100% }

    Essentially we'd then just not be encouraging them to, and we could
    try and get a non-XML media type registered for SVG at the same time
    as registering image/svg+xml (yes, server's then need to catch up, but
    at least years down the line authors could serve error tolerant SVG
    without a bogus content-type header).

Received on Wednesday, 11 March 2009 10:48:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC