W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

Re: [whatwg] SVG cloning elements from HTML5

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 24 Jun 2014 04:35:49 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>
Message-ID: <FEF8847D-5C1B-4ACB-81B2-D4888E57E19B@adobe.com>
Cc: www-svg <www-svg@w3.org>, WHATWG List <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>

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

Received on Tuesday, 24 June 2014 04:36:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC