Re: SVG in HTML (was: Minutes, SVG WG Brussels f2f day 4 (Monday))

On Jun 2, 2010, at 01:46, Robert O'Callahan wrote:

> On Wed, Jun 2, 2010 at 10:35 AM, Doug Schepers <schepers@w3.org> wrote:
>> For their SVG and X/HTML implementation, Patrick casually mentioned that the IE Team considered (but did not implement) mixed-language cases like:
>> 
>> <div>
>>  <p>This is a paragraph.</p>
>>  <circle cx="75" cy="25" r="20" fill="orange" stroke="red" />
>>  <p>Did the circle above render?</p>
>> </div>
>> 
>> and
>> 
>> <g>
>>  <rect x="5" y="55" width="40" height="40" fill="orange" stroke="blue" />
>>  <p>This is some HTML text without a foreignObject parent.</p>
>>  <video .../>
>>  <circle cx="75" cy="25" r="20" fill="orange" stroke="red" />
>> </g>
>> 
>> These are cases that a reasonable person might try to do... that is, interleave SVG and HTML without the roots or special container elements.  So, my open question was, how firm is the existing behavior in HTML5?  Shipping browser implementations restrict how much can be changed (assuming that any changes are required at all).
>  
> I don't think shipping an HTML5-spec parser is going to constrain us from supporting stuff like the above as a future extension. The real constraints are existing content and obvious spec issues. For example, the SVG tags that have the same names as HTML tags can't be disambiguated outside an <svg> container. We may find significant tag-soup HTML containing tags that have the same names as SVG tags, where interpreting them as SVG breaks the page.

The HTML5 parsing algorithm is designed to be resilient against real-world legacy content like http://junkyard.damowmow.com/339 . Changing this would fundamentally change the compatibility risks associated with shipping the SVG-in-text/html feature and would invalidate a year of real-world compatibilty testing by mozilla-central nightly testers.

Also, I think the SVG WG is rather late considering the mixing of SVG and HTML markup without the <svg> and <foreignObject> container elements. The SVG WG had years to define a how containerless namespace mixing worked with XHTML and SVG--but it hasn't. Now it's not really feasible to put implementations about to ship on hold until containerless mixing is figured out.

While in principle I like the attitude shift from Draconian failure to seeking to support cases that "a reasonable person might try to do", I think getting rid of the <svg> and <foreignObject> containers isn't worthwhile regardless of release schedules. When you put a single circle in the middle of HTML, adding an <svg viewBox='...' width='...' height='...'>...</svg> wrapper looks like a lot of cruft in proportion to the circle element. However, as the graphic becomes more complex, there's more and more need for the graphic to live its own coordinate space so all the coordinates within the graphic don't need to be rewritten to the coordinates of the CSS formatter to e.g. scale the graphic, so soon you'll find a need for a transform container at which point you might as well have had an <svg> container. 

Likewise, when you have multiple HTML elements inside SVG, you'll want to have a clear containing block for the CSS purposes so that consecutive elements participate in the same CSS flow. If you remove <foreignObject> only to have authors add a <div>, nothing is won but specification and implementation complexity has been incurred.

And lastly, on the XML side where Namespaces take care of disambiguation, you'd lose compatibility with deployed software by removing the containers. Authors are more likely to prefer compat over relatively minor syntactic sugaring, so the speccing and implementation complexity probably wouldn't buy much in terms of getting used.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 3 June 2010 07:56:08 UTC