- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Wed, 11 Mar 2009 11:48:08 +0100
- 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). Jonathan
Received on Wednesday, 11 March 2009 10:48:46 UTC