Re: [whatwg] Including HTML more directly into SVG

On Wed, Jan 9, 2013 at 3:26 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jan 9, 2013, at 2:18 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> > On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> >> On Mon, 10 Sep 2012, Tab Atkins Jr. wrote:
> >>>
> >>> 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.
> >>
> >> Well, you can just put the text in a <foreignObject> with a <div>, and
> >> style that.
> >>
> >> Your bigger problem is going to be positioning the lines on the other
> side
> >> of the <rect>/<foreignObject>.
> >>
> >>
> >>> 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.
> >>
> >> That's what <foreignObject> is for.
> >>
> >
> > I agree.
> > When we discussed this a couple of months ago, people did not like the
> name.
> > Why is HTML considered 'foreign'?
> >
> > Also, browser have identified multiple security issues with
> foreignObject.
> > AFAIK the SVG spec doesn't mention any of them.
> >
> > I think a new tag in SVG is needed that just support inclusion of HTML.
> > In addition, it needs to define the security model and allow the HTML to
> > draw outside of its box.
>
> I guess you mean things like shadows and filter output should not be
> clipped? In this case the new element would not interact as some kind of
> <iframe>, but as an integral part of SVG, allowing to better mix SVG and
> HTML. I think this is a good way to go and should be implementable.
>

Yes, if the embedded HTML is just a single <p> element and if it has a
border or a shadow, those should not be clipped.
Even a transform should be able to move the <p> box without it being
clipped.


>
> The reason why it is not so easy to allow HTML elements to be embedded
> into SVG directly are the different kind of concepts. HTML elements
> contribute to the CSS Boxing Model with relative positioning and layout.
> SVG elements need information about the coordinates and dimension. While I
> could imagine that SVG elements can contribute to the CSS Boxing Model when
> they would be put into HTML content without surrounding them with an <svg>
> elements, the other way around is more difficult. Turning a relative
> positioned, layout based element into a coordinate, size based context is
> not so easy. A new element as you both describe it here can help a lot.
>
> I agree. This is why the new element (just like foreignObject) will need a
width and height so the UA can do layout in that area.


>
> >
> >
> >>
> >>
> >>> 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.
> >>
> >> <foreignObject> does that too.
> >>
> >>
> >>> [...] 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.
> >>
> >> How common is it for text in a diagram to be emphasised to the point
> where
> >> you definitely need a clear indication in a speech-synthesis rendering
> >> done in conjunction with a visual display? It seems like it'd be rare
> >> enough that the mere visual indication of italics would make it pretty
> >> obvious to the user what was going on...
> >>
> >>
> >>> 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.
> >>
> >> In the cases where you need this, isn't <foreignObject> enough?
> >>
> >>
> >>> 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.
> >>
> >> Or MathML, indeed. Again, this seems reasonably easy with
> <foreignObject>.
> >>
> >> Which you point out:
> >>
> >>> Right now, all three of the above *could* be done by using the
> >>> <foreignContent> element.
> >>
> >> Right. :-)
> >>
> >>
> >>> 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.
> >>
> >> You don't have to specify a namespace in text/html, but agreed about the
> >> width and height. Even worse, IMHO, is having to use the name
> >> "foreignObject", which is highly unwieldy. It would definitely be nice
> to
> >> have an element in SVG with a short name that introduced an HTML context
> >> in text/html, and that was shrink-wrap enabled. Even better would then
> to
> >> be able to reference the dimensions from other elements, so that you
> >> wouldn't have to measure the element anyway (e.g. to position the line
> in
> >> your example above).
> >>
> >> I would recommend calling this element <svg:div>, for what it's worth.
> (I
> >> had an <xbl:div> for similar reasons). But any short name would do, e.g.
> >> <html>, or <block>, or <flow>, or whatever.
> >>
> >>
> >>> Another solution could be SVG inventing their own elements for these
> >>> kinds of things.
> >>
> >> That doesn't seem like a good plan, as you point out.
> >>
> >>
> >>> My preferred solution is to simply include HTML directly into SVG.
> >>
> >> I presume you don't mean duplicating the elements in both namespaces,
> but
> >> making the text/html parser detect which elements are where?
> >>
> >>
> >>> 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.
> >>
> >> I'm not entirely convinced that that makes sense, but I'll leave that to
> >> www-style and www-svg to figure out.
> >>
> >>
> >>> This requires some minor parsing changes in HTML.
> >>
> >> I don't think they are minor in consequences, as others (e.g. Elliott
> >> Sprehn) discussed in this thread (not quoted here for brevity).
> >>
> >> However, even if they were, I don't see why this would be better than
> >> introducing a better version of <foreignObject> that shrink-wraps. Doing
> >> that wouldn't require any changes to CSS or SVG or HTML except adding a
> >> single new element to SVG with a simple-ish processing model, and a
> minor
> >> change to the HTML parser.
> >>
> >>
> >>> 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.
> >>
> >> Dramatically different rendering. The entire remainder of the page would
> >> end up stacked on top of itself, if I'm understanding what you're
> >> describing correctly (treat all the children of <svg> as pos:abs).
> >>
> >>
> >>> 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.
> >>
> >> I think that's a far simpler and clearer solution, both for specs,
> >> implementors, and most importantly, authors.
> >>
> >>
> >> For context, consider word processing programs like Pages or Word. They
> >> tend to have two modes -- one where there is flow text with floating or
> >> overlapping objects (SVG blobs, in our world), and one where everything
> is
> >> positioned and if you want text you put in a text box (<foreignObject>,
> in
> >> our world). I don't know of any markup language or graphics system where
> >> paragraphs are conceptual siblings with paths and shapes.
> >>
> >> --
> >> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> >> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
> ,.
> >> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> >>
>
>

Received on Wednesday, 9 January 2013 23:40:43 UTC