On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. <jackalm...@gmail.com>
wrote:

> 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
<!DOCTYPE HTML>
<svg>
<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).

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

Reply via email to