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

Hi, Folks-

I see from reading the minutes that the context of some of the 
SVG-in-HTML discussion at the Brussels SVG F2F was not very clear, so 
I'd like to set the record straight.

(First, it should be noted that we were on the last hour of the last day 
of 8 straight days of working long hours, at the F2F and the Libre 
Graphics Meeting, so we were not especially coherent.)

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

The syntax and parsing is only part of the story with mixed-namespace 
documents, of course... there are various interactions that probably 
need clarifying, like the focus chain, viewport overlap, etc.  Some of 
this needs discussion with the CSS WG, and there are bits that would be 
best to sort out with the HTML WG.

A few clarifications inline...


Chris Lilley wrote (on 5/31/10 4:52 PM):
>
> SVG+HTML
>
> shepazu: MSIE considered novel syntax... HTMl5 is some way from being
> done and the parsing algo has only 1 implementaitn thats incomplete
> ... from W3C process perspective its far from done
>
> jwatt: the strategy to ship first is a problem
>
> ChrisL: its shipped and not finalised at the same time
>
> ;)
>
> ed_work: there's 2 impkementations
>
> shepazu: there maybe 2, but 'we shipped libhtml5' doesn't conut
>
> s/conut/count

s/count/coconut/

I meant that shipping libhtml5 is not as hard a constraint as the parser 
shipped in the browser.  If someone disagrees with this, please educate me.



> <AlexD>  Are there any tests for HTMl5 parsing conformance?
>
> pdengler: MSIE 9 hsa no plans for this, its for later. first we need
> to rationalise and unionise many things ... i could throw out some
> idea on default inlining SVG... putting an XY coordinateon a div in
> svg, that wont hold unless you ge tthe other stuff sorted ... we have
> to nail the union of the 2 specs
>
> shepazu: if its ships its too late (?)
>
> pdengler: it requires cooperation with the HTML group. when do they
> close the spec?
>
> jwatt: its open for some time
>
> pdengler: right
>
> jwatt: once something ships, if we both ship HTML5 parses...
>
> pdengler: is this a parsing problem? if so, raise them, but i wont
> thikn what they might be, i look at what people want to do
>
> <AlexD>  Given how long it will take HTML5 to mature (i.e. PREC) then
> perhaps SVG needs to take some lead in an HTML(4)+SVG integration
> profile... HTML5 is a bit of vapourware right now really.

As Alex mentioned, this is his opinion, not that of the SVG WG, and not 
mine in particular.  Note that he was only attending via IRC, so he 
didn't necessarily hear what was being said in the meeting room.  As 
mentioned in another email, IRC logs and minutes aren't very high fidelity.

I think it's probably necessary to test out the parser in the real world 
as early as possible, but I do think it's risky... I hope that early 
adopting implementers stay flexible about any changes that need to be 
made (not necessarily to SVG parts, just in general).



> shepazu: these are coupled, yes. ... say you want serverside stuff,
> and we can imagine a html6 parser being different. parsers determine
> what syntax is allowed
>
> pdengler: can a div work in a co ordinate space/ ... when do we
> decide this is a div/ ... like a div within SVG ... what does it mean
> to have HTML not as a foreign object in SVG? ... we are yet to
> dicover what people expet and how they will use SVVG in HTML ...
> remove the idea of forign object..?
>
> jwatt: is this in scope of html5? ... they are only looking at parser level
>
> shepazu: to draw this to a close, we need to go backto html5 group
> and say, we got these use cases.... ... how productive will itbe at
> this point?

What I was trying to say is that, as mentioned above, there are 
reasonable use cases that may be handled in a different way, and that 
there are other details to work out.  Some of this may be beyond the 
HTML5 timeframe, and they may turn up in the course of defining SVG 2.0, 
so I don't know when the best time to discuss these are, and how can we 
best document the desired behavior.


> <AlexD>  There is a difficult line to tread here. Parsers may define
> what syntax is allowed but HTML and tag-soup has allowed all sorts of
> non-spec compliant to try to render something. SVG has tried to be
> more strict. When we join them, what will the author expect and what
> should we mandate?
>
> jwatt: parsing thing, its more the CSS WG to talk to ... existing
> specs its not well done ... look at draft cSS spec ... need to look
> at CSS2.1
>
> ChrisL: intended to bedeon thi yar
>
> shepazu: we should consider what the WGs did
>
> <scribe>  ACTION: pdengler to talk to MSIE team about HTML5+SVG tests
> [recorded in http://www.w3.org/2010/05/31-svg-minutes.html#action05]
>
> <trackbot>  Created ACTION-2794 - Talk to MSIE team about HTML5+SVG
> tests [on Patrick Dengler - due 2010-06-07].

I hope that clarifies the context for readers of this list.


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

Received on Tuesday, 1 June 2010 22:35:40 UTC