On Jun 24, 2014, at 5:25 AM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> 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.) We will have the x, y properties. No need to map to left and right. > 4) Add a "transform" attribute to HTMLElement and have it map to the > "transform" CSS property. In this case we should think about making transform a presentation attribute in general for HTML and SVG. > > #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). Greetings, Dirk
