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