Re: [whatwg] Including HTML more directly into SVG

n Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> ...
>>
>> This would be a lot easier if I could somehow invoke the CSS box model
>> inside of SVG, ...
>
> This tightly binds the list of element names in SVG to HTML, and also
> breaks assumptions inside SVG DOM that HTML5 may depend upon. Indeed
> SVG already has elements like <title>, <a> and <style>.
>
> <svg>
>   <a><a>
>   <title></title>
>   <section></section>
> </svg>
>
> The <title> and <a> elements are SVGTitleElement and SVGAElement
> respectively and not HTMLElements.
> The section element is an SVGElement, not an HTMLElement. This isn't
> actually defined yet, but gives SVG authors some flexibility with
> unknown elements when embedded in HTML5.
>
> It would be really unfortunate if the SVG folks were prevented from
> using logical names like <content> or <section> because we parse them
> into HTML.

Actually, that's intentional.  We should never introduce more naming
conflicts between SVG and HTML.  They harm our ability to use the
languages together, across the platform.


>> Another solution could be SVG inventing their own elements for these
>> kinds of things.  For example, #1 could be solved with an <svg:span>
>> or <svg:p> element.  Having duplicate elements in multiple namespaces
>> is regarded as an antipattern, ...
>
> SVG has a totally different font and styling model,

No it doesn't.

> different kinds of
> animations, filters, etc.

All of these are intentionally being harmonized with CSS as we speak.

> The paragraph and span concept in SVG
> wouldn't be the same thing so it's not an antipattern. You would have
> to specify some kind of x/y coordinate and the width since SVG doesn't
> have a flow concept so there would be nothing to size or place
> against.

No, all you have to do is define SVG positioning as being a slight
diff from absolute positioning.  Then all the sizing just falls out.

> Even if you could use HTML in the flow chart example it's not enough
> to use <p> since that wouldn't make the green <rect> any larger as SVG
> doesn't have a concept of nesting text inside a rect,

The point is to replace the <rect>/<text> combo with something that
uses the CSS box model, so I can use borders and backgrounds on a box
full of text.

> and if you moved
> the <rect> to be a <div> now you have the problem of making sure the
> lines that come out of the box still connect with the sides of box.

That's fine.  I can easily do it without measuring anything, and even
if I have to measure something, it'll still be easier for this
specific use-case (and plenty of other uses where I've wanted this
definitely don't need any measurement).

> You'd also have problems like losing access to the <font>'s you
> defined in the SVG world in the embedded HTML world.

That's only a problem if you're using SVG fonts, and *not* using
@font-face to expose them to CSS proper.  It's not significant.

> Might be nice to add an <html> element with x/y width/height
> attributes to make <foreignObject> easier though!

Having to pre-measure the HTML content so I know what width/height to
set it to defeats the entire point.  It removes the verbosity, but
doesn't improve the functionality.

~TJ

Received on Tuesday, 11 September 2012 16:10:13 UTC