- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 26 Jun 2014 09:35:39 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-svg <www-svg@w3.org>, WHATWG List <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 24 Jun 2014, Robert O'Callahan wrote: >> >> <!DOCTYPE HTML> >> <svg> >> <span id="s"></span> >> <div id="i"></div> >> the elements "s" and "i" are put in the HTML namespace already. > > As siblings of the <svg> element, though, not descendants. > > This was required to get some level of compatibility with deployed content > while still allowing <svg> in HTML. There was content out there that, for > reasons that defeat me, had <svg> start tags (but not end tags). If we had > not introduced this limited trap door out of the foreign lands (it's a > hard-coded list of tag names that bail out in this way), it would have > caused the pages to be blank from the <svg> start tag to the end. That's assuming that HTML content doesn't render in SVG (or that the html tagnames are parsed as unknown SVG elements). Under the proposals for defining an SVG layout model that integrates properly with the other CSS layout models, the content would be displayed. (The current proposal would place all the direct HTML children of SVG elements on top of each other, similar to abspos, but grandchildren would render normally, in a CSS layout model.) ~TJ
Received on Thursday, 26 June 2014 16:36:24 UTC