- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 23 Jun 2014 22:50:44 -0700
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, www-svg <www-svg@w3.org>, WHATWG List <whatwg@whatwg.org>
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:33 UTC