Re: [whatwg] SVG cloning elements from HTML5

On Jun 18, 2014 6:00 AM, "Robert O'Callahan" <robert@ocallahan.org> wrote:
>
> I just discovered
> https://svgwg.org/svg2-draft/embedded.html
> This looks very problematic. It ties SVG and HTML5 together in
> uncomfortable ways. For example, SVGIframeElement as specced has two
> "width" attributes. It's unclear how to keep this making sense as SVG and
> HTML5 evolve, e.g. as new attributes get added to HTML5 elements. It will
> be easy to change HTML5 in ways that break this SVG spec (and possibly
vice
> versa). "SVGIframeElement implements HTMLIFrameElement" creates a multiple
> inheritance situation that I don't think any engine would really want to
> implement, even if it made sense, which I don't think it does. I'm pretty
> sure no-one who actually works on HTML5 has approved of this. Yes, it's
> only in a draft, but people are already taking that as a cue to start
> implementing. I think we need to take a step back from this, figure out
> what the goals are and then work together on solving them the right way.
>
> It seems to me that if we possibly can, we should solve this by reusing
the
> actual HTML elements so much less spec synchronization is needed. We
> probably should find a way to support actual HTML elements as direct
> children of SVG elements with no intervening <foreignObject>. We should
> make sure the parser can handle that too, at least for a whitelisted set
of
> elements.

Yes, increasing the set of name-alikes between html and svg is absolutely
not something we'll support. (I've unfortunately been out of the loop with
the svgwg for a while, or else I would have prevented this from showing up
in the first place.)

Allowing html directly in svg is definitely the right answer. Parsing
shouldn't be too hard, and defining the layout model would be pretty
trivial.

~TJ

Received on Wednesday, 18 June 2014 16:33:39 UTC