Re: [whatwg] Including HTML more directly into SVG

[Rik Cabanier]

On Wed, Jan 9, 2013 at 3:26 PM, Dirk Schulze  wrote:

>
> On Jan 9, 2013, at 2:18 PM, Rik Cabanier  wrote:
>
> > On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson  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*  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  with a , and
> >> style that.
> >>
> >> Your bigger problem is going to be positioning the lines on the other
> side
> >> of the /.
> >>
> >>
> >>> This would be a lot easier if I could somehow invoke the CSS box model
> >>> inside of SVG, but the  element doesn't allow that.
> >>
> >> That's what  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
> , 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  element and if it has a
border or a shadow, those should not be clipped.
Even a transform should be able to move the  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 
> 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.
> >>
> >>  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  >>> elements like , , or  into SVG, for
> the
> >>> same reasons you'd include them in HTML.
> >>
> >> Or MathML, indeed. Again, this seems reasonably easy with
> .
> >>
> >> Which you point out:
> >>
> >>> Right now, all three of the above *could* be done by using the
> >>>  element.
> >>
> >> Right. :-)
> >>
> >>
> >>> This is a horrible solution, though.  To use , 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
> >> i

Re: [whatwg] Including HTML more directly into SVG

[Dirk Schulze]

On Jan 9, 2013, at 2:18 PM, Rik Cabanier  wrote:

> On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson  wrote:
> 
>> On Mon, 10 Sep 2012, Tab Atkins Jr. wrote:
>>> 
>>> 1. Check out >> .
>>> 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*  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  with a , and
>> style that.
>> 
>> Your bigger problem is going to be positioning the lines on the other side
>> of the /.
>> 
>> 
>>> This would be a lot easier if I could somehow invoke the CSS box model
>>> inside of SVG, but the  element doesn't allow that.
>> 
>> That's what  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 , 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.

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  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.

Greetings,
Dirk

> 
> 
>> 
>> 
>>> 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.
>> 
>>  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 >> elements like , , or  into SVG, for the
>>> same reasons you'd include them in HTML.
>> 
>> Or MathML, indeed. Again, this seems reasonably easy with .
>> 
>> Which you point out:
>> 
>>> Right now, all three of the above *could* be done by using the
>>>  element.
>> 
>> Right. :-)
>> 
>> 
>>> This is a horrible solution, though.  To use , 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 , for what it's worth. (I
>> had an  for similar reasons). But any short name would do, e.g.
>> , or , or , or whatever.
>> 
>> 
>>> Another solution could be SVG inventing their own elements for these
>>> kinds of things.
>> 
>> That doesn't seem like a good pl

Re: [whatwg] Including HTML more directly into SVG

[Rik Cabanier]

On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson  wrote:

> On Mon, 10 Sep 2012, Tab Atkins Jr. wrote:
> >
> > 1. Check out  >.
> > 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*  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  with a , and
> style that.
>
> Your bigger problem is going to be positioning the lines on the other side
> of the /.
>
>
> > This would be a lot easier if I could somehow invoke the CSS box model
> > inside of SVG, but the  element doesn't allow that.
>
> That's what  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.


>
>
> > 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.
>
>  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  > elements like , , or  into SVG, for the
> > same reasons you'd include them in HTML.
>
> Or MathML, indeed. Again, this seems reasonably easy with .
>
> Which you point out:
>
> > Right now, all three of the above *could* be done by using the
> >  element.
>
> Right. :-)
>
>
> > This is a horrible solution, though.  To use , 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 , for what it's worth. (I
> had an  for similar reasons). But any short name would do, e.g.
> , or , or , 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  or  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  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, 

Re: [whatwg] Including HTML more directly into SVG

[Ian Hickson]

On Mon, 10 Sep 2012, Tab Atkins Jr. wrote:
> 
> 1. Check out .
> 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*  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  with a , and 
style that.

Your bigger problem is going to be positioning the lines on the other side 
of the /.


> This would be a lot easier if I could somehow invoke the CSS box model 
> inside of SVG, but the  element doesn't allow that.

That's what  is for.


> 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.

 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  elements like , , or  into SVG, for the 
> same reasons you'd include them in HTML.

Or MathML, indeed. Again, this seems reasonably easy with .

Which you point out:

> Right now, all three of the above *could* be done by using the 
>  element.

Right. :-)


> This is a horrible solution, though.  To use , 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 , for what it's worth. (I 
had an  for similar reasons). But any short name would do, e.g. 
, or , or , 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  or  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  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  tag at the start of their page with no 
> matching , as including the HTML directly in the  element 
> would suppress their rendering.  However, with my suggested change, 
> t

Re: [whatwg] Including HTML more directly into SVG

[Tab Atkins Jr.]

On Tue, Sep 11, 2012 at 12:37 PM, Elliott Sprehn  wrote:
> On Sep 11, 2012 11:35 AM, "Tab Atkins Jr."  wrote:
>> On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn 
>> wrote:
>> > On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. 
>> > wrote:
>> >> ...
>> > Also, how does your proposal address
>> > flowing text inside of a ?
>>
>> That's a good question!  Presumably you mean that, for example, one
>> might want to have emphasized text in a text-along-a-path flow?  I
>> suppose it should be as easy as making them children of a ,
>> and setting "display:svg" to make them obey SVG rendering rules rather
>> than the CSS box model.
>
> I mean if you look at the svg flow spec there's an example of text inside a
> polygon or even text flowing inside of large bubble letters.
>
> Similar concept as CSS exclusions, but it doesn't make sense to specify the
> polygon twice to use that.

The SVG flow spec was never implemented by browsers, to my knowledge.

I don't understand the relevance of this question.  Presumably one
could just use CSS Exclusions.


>> > A strawman of the JSON spec rewritten with your proposal would be
>> > useful.
>>
>> I don't understand this request.
>
> Sorry its not the JSON spec, it just had a similar theme (my confusion). I
> meant could you rewrite the railroad svg from your original email to show
> how this is better?
>
> http://www.xanthir.com/etc/railroad-diagrams/example.html

It wouldn't be *significantly* changed in my diagram - I'll still need
to measure things, because I need to attach lines to the edges and
make other parts respond to the width.  My diagram would just benefit
from being able to draw a single element rather than a +
pair.

However, some of my other examples from my original post would be
significantly simplified.  Anything that needs text-wrapping, or which
is simply positioning the text somewhere without needing much
coordination with other elements (like some text on or around a
graph).

~TJ

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Sep 11, 2012 11:35 AM, "Tab Atkins Jr."  wrote:
>
> On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn 
wrote:
> > On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. 
wrote:
> >> ...
> > Also, how does your proposal address
> > flowing text inside of a ?
>
> That's a good question!  Presumably you mean that, for example, one
> might want to have emphasized text in a text-along-a-path flow?  I
> suppose it should be as easy as making them children of a ,
> and setting "display:svg" to make them obey SVG rendering rules rather
> than the CSS box model.

I mean if you look at the svg flow spec there's an example of text inside a
polygon or even text flowing inside of large bubble letters.

Similar concept as CSS exclusions, but it doesn't make sense to specify the
polygon twice to use that.

>
> > A strawman of the JSON spec rewritten with your proposal would be
useful.
>
> I don't understand this request.
>

Sorry its not the JSON spec, it just had a similar theme (my confusion). I
meant could you rewrite the railroad svg from your original email to show
how this is better?

http://www.xanthir.com/etc/railroad-diagrams/example.html

- E

Re: [whatwg] Including HTML more directly into SVG

[Tab Atkins Jr.]

On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn  wrote:
> On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr.  wrote:
>> ...
>>
>>> 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.
>
> Can you explain this? I don't understand how we decide the width of an
> html element as the containing block is the  element. Are you
> saying we default to shrink wrap?

You just explained it.  The containing block is the nearest ancestor
 element.  Everything else works as normal.

> Also, how does your proposal address
> flowing text inside of a ?

That's a good question!  Presumably you mean that, for example, one
might want to have emphasized text in a text-along-a-path flow?  I
suppose it should be as easy as making them children of a ,
and setting "display:svg" to make them obey SVG rendering rules rather
than the CSS box model.

> A strawman of the JSON spec rewritten with your proposal would be useful.

I don't understand this request.

~TJ

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr.  wrote:
> ...
>
>> 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.

Can you explain this? I don't understand how we decide the width of an
html element as the containing block is the  element. Are you
saying we default to shrink wrap? Also, how does your proposal address
flowing text inside of a ?

A strawman of the JSON spec rewritten with your proposal would be useful.

- E

Re: [whatwg] Including HTML more directly into SVG

[Tab Atkins Jr.]

On Tue, Sep 11, 2012 at 1:23 AM, Elliott Sprehn  wrote:
> On Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn  wrote:
>> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr.  wrote:
>>
>>...
>>>
>>> Another solution could be SVG inventing their own elements for these
>>> kinds of things.  For example, #1 could be solved with an 
>>> or  element.  Having duplicate elements in multiple namespaces
>>> is regarded as an antipattern, ...
>>
>> 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.
>>
>
> See also http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html

There is a reason why nobody implemented 1.2.  Reinventing inline
layout with a subtly different model is one of them.

~TJ

Re: [whatwg] Including HTML more directly into SVG

[Tab Atkins Jr.]

n Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn  wrote:
> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr.  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 ,  and 

Re: [whatwg] Including HTML more directly into SVG

[David Carlisle]

On 11/09/2012 09:32, Robin Berjon wrote:

.


MathML has similar issues of course (but simpler probably as it doesn't 
have the separate font and layout issues that svg has). In its html(5) 
incarnation, as well as annotation-xml (which is the traditional mathml 
element for foreign stuff (cf svg's foreignContent) we directly allow
(most) inline html to be directly contained in  (mathml's inline 
text element).  MathML has also always avoided html element names in the 
hope of eventual unification:-)


A general aim of making the markup for html/svg/mathml as natural as 
possible with mixing allowed wherever it makes sense would be a good thing.


David



The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 

Re: [whatwg] Including HTML more directly into SVG

[Benjamin Hawkes-Lewis]

On Tue, Sep 11, 2012 at 9:32 AM, Robin Berjon  wrote:
> 

Bikeshedding: @seamless (q.v. )

--
Benjamin Hawkes-Lewis

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 1:32 AM, Robin Berjon  wrote:
> On 11/09/2012 10:15 , Elliott Sprehn wrote:
>>
>> ...
>
>> 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.
>

Perhaps I don't understand, but I don't see how Tab's proposal
addresses what to size against. If I add a  element, there's
nothing to size it against except the containing  element.

ex.



  
  
  Some text goes here.



Tab, What controls the width and x/y of the  ?

>
>
>> Might be nice to add an  element with x/y width/height
>> attributes to make  easier though!
>
>
> I'm not sure how that would help. However,  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 .

SVG also has CSS though, I don't understand how  implies "now
you're in HTML mode".

- E

Re: [whatwg] Including HTML more directly into SVG

[Robin Berjon]

On 11/09/2012 10:15 , Elliott Sprehn wrote:

On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr.  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 ,  and 

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn  wrote:
> On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr.  wrote:
>
>...
>>
>> Another solution could be SVG inventing their own elements for these
>> kinds of things.  For example, #1 could be solved with an 
>> or  element.  Having duplicate elements in multiple namespaces
>> is regarded as an antipattern, ...
>
> 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.
>

See also http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html

Re: [whatwg] Including HTML more directly into SVG

[Elliott Sprehn]

On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr.  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 ,  and