[whatwg] Including HTML more directly into SVG
Tab Atkins Jr.
jackalmage at gmail.com
Tue Sep 11 09:09:16 PDT 2012
n Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn <esprehn at gmail.com> wrote:
> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. <jackalmage at 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
More information about the whatwg
mailing list