Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. <>

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

I think we should actually figure this out.

I'm not an expert on the HTML parser, but it seems to me there's already
some support for what we need. E.g. given
<span id="s"></span>
<div id="i"></div>
the elements "s" and "i" are put in the HTML namespace already.

For layout, we could do this:
1) When an HTML element is a child of an SVG element, perform CSS layout of
the HTML element treating the nearest SVG viewport as the containing block.
Its user-space width and height become the width and height of the
containing block in CSS pixels.
2) Treat such HTML elements as "position:relative".
3) Add "x" and "y" attributes to HTMLElement and have them map to "left"
and "top" CSS properties. (There's a crazy legacy compat issue for
HTMLImageElement.x/y but we can hack around that.)
4) Add a "transform" attribute to HTMLElement and have it map to the
"transform" CSS property.

#3 and #4 are optional, there are pros and cons to having them. Using the
nearest SVG viewport in #1 is because other SVG container elements don't
have a defined size (and we can't use getBBox because that depends on the
layout of the children).

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Tuesday, 24 June 2014 03:26:09 UTC