Re: [whatwg] SVG cloning elements from HTML5

On Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Jun 24, 2014, at 5:25 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. <jackalmage@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.

Yeah, this is part of the general SVG/CSS convergence effort, already
approved and under way.

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

That's effectively what it would do, yes.

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

Yes, using the nearest <svg> was my plan as well.

~TJ

Received on Tuesday, 24 June 2014 05:51:29 UTC