- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 10 Sep 2012 16:59:47 -0700
- To: WHATWG <whatwg@whatwg.org>
This is a continuation of a discussion started in the #whatwg IRC room, so I'll start somewhat abruptly. 1. Check out <http://www.xanthir.com/etc/railroad-diagrams/example.html>. See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* <rect> element behind it, so that it *looks* like there's a box with text inside of it. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the <text> element doesn't allow that. Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. 2. Unfortunately I don't remember the name of the product I'm about to describe, so I can't link to it, but there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides "here is text". It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using <tspan style="font-style:italic;> and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. It would be pretty nice if you could use <em> or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. 3. Related to the above, it seems useful to be able to embed "special" elements like <input type=date>, <video>, or <details> into SVG, for the same reasons you'd include them in HTML. Right now, all three of the above *could* be done by using the <foreignContent> element. This is a horrible solution, though. To use <foreignContent>, you need to specify a width and height (and we're back to measuring or guessing at the dimensions...) and specify a namespace. This is a lot of weight to put into a document when all you want to do is include some simple text. 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, however. Having elements which are duplicates save for their tagname is just as bad - less "chameleon namespace" problems, more gratuitous and needless naming differences between components of the web platform. My preferred solution is to simply include HTML directly into SVG. This solves #1 perfectly - all that needs to be done is to specify the SVG rendering model in terms of the CSS box model (it's simple, just a slight diff on position:absolute), then <span> or <p> works great. This solves #2 as well - you get <em> and the gang coming along for free, not to mention the block-level elements like <hn>, lists, etc., all of which can reasonable be used inside of something which is mostly SVG, like a diagram. Finally, it solves #3 just as cleanly, by letting us just use the languages together in a nice, friendly way without duplication or lots of boilerplate wrapper. This requires some minor parsing changes in HTML. Specifically, in http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inforeign (section 12.2.5.5 "The rules for parsing tokens in foreign content"), the rule that makes any HTML element pop the stack of open elements until it closes the SVG element would need to be removed. I'm aware that this was put in place to avoid breaking a few pages that, seemingly for no reason, include an <svg> tag at the start of their page with no matching </svg>, as including the HTML directly in the <svg> element would suppress their rendering. However, with my suggested change, these pages would continue working, albeit probably with a slightly different rendering. If this is unacceptable, it's acceptable to me to require a small, simple wrapper element that accomplishes the same thing as <foreignContent>, but automatically places its contents in the HTML namespace and auto-sizes itself, and have the parser key off of that. This should be avoided if possible, though, as it's annoying for authors with no direct benefit to them. ~TJ
Received on Tuesday, 11 September 2012 00:00:38 UTC