- From: Robin Berjon <robin@w3.org>
- Date: Tue, 11 Sep 2012 10:32:53 +0200
- To: Elliott Sprehn <esprehn@gmail.com>
- Cc: WHATWG <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On 11/09/2012 10:15 , Elliott Sprehn 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 Which isn't that big of a problem. It's a simple matter of staying in sync with the SVG WG, which isn't so hard. > and also > breaks assumptions inside SVG DOM that HTML5 may depend upon. Indeed > SVG already has elements like <title>, <a> and <style>. Which is breakage worth looking into. In SVG 2, I think it would make sense to just align <a> and <style> on HTML (and a few others). <title> is somewhat different, but it's not as if it couldn't be handled in Tab's model. It's hard to use SVG without bumping into the sort of issue that Tab describes. And foreignObject was always unpleasant. Welding SVG and HTML more tightly makes a lot of sense, if we can do it with minimal change we should. > 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. I don't think that the SVG WG wants to create new element names that conflict with HTML. In fact, last I looked they were even talking about dropping the namespace. > SVG has a totally different font and styling model, different kinds of > animations, filters, etc. 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. That's precisely what Tab's proposal fixes. > You'd also have problems like losing access to the <font>'s you > defined in the SVG world in the embedded HTML world. No, you wouldn't, there's no reason they can't be shared. > Might be nice to add an <html> element with x/y width/height > attributes to make <foreignObject> easier though! I'm not sure how that would help. However, <foreignObject size=auto> would do the trick IMHO (I'm concerned that making it more automatic might have nasty corner cases). We could even make a new, less horrible name for it, like <css>. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 11 September 2012 08:33:31 UTC