Re: [whatwg] Including HTML more directly into SVG

[Rik Cabanier]

On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@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.




  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 

Re: [whatwg] Including HTML more directly into SVG

[Dirk Schulze]

On Jan 9, 2013, at 2:18 PM, Rik Cabanier caban...@gmail.com wrote:

 On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@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.

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.

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

Re: [whatwg] Including HTML more directly into SVG

[Rik Cabanier]

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


 On Jan 9, 2013, at 2:18 PM, Rik Cabanier caban...@gmail.com wrote:

  On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@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 

Re: [whatwg] Including HTML more directly into SVG

[Ian Hickson]

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.


 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 

Re: [whatwg] Including

[Robin Berjon]

On 14/11/2012 00:04 , Mark Nottingham wrote:

On 14/11/2012, at 4:37 AM, Ian Hickson i...@hixie.ch wrote:

(For what it's worth, inclusion in HTML is done using iframe seamless.)


Ah. Does that work with older browsers (from the 2005 era onwards)?


Nope. But if you want something that's future-enabled you could 
transition your library into being a shim for seamless iframes.


That involves more than inclusion though (see 
http://benvinegar.github.com/seamless-talk/) so you should probably 
double-check that seamless is what your use case calls for.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [whatwg] Including

[Mark Nottingham]

On 15/11/2012, at 3:15 AM, Robin Berjon ro...@w3.org wrote:

 On 14/11/2012 00:04 , Mark Nottingham wrote:
 On 14/11/2012, at 4:37 AM, Ian Hickson i...@hixie.ch wrote:
 (For what it's worth, inclusion in HTML is done using iframe seamless.)
 
 Ah. Does that work with older browsers (from the 2005 era onwards)?
 
 Nope. But if you want something that's future-enabled you could transition 
 your library into being a shim for seamless iframes.
 
 That involves more than inclusion though (see 
 http://benvinegar.github.com/seamless-talk/) so you should probably 
 double-check that seamless is what your use case calls for.

Thanks, Robin - very helpful.

The upside of the seamless approach seems to be that it does the right thing 
WRT the included content's type, etc. (as Ian mentioned). However, making it 
work in older browsers looks a lot more involved. Turning my library into a 
shim for seamless would require code both in the including context and included 
content, AIUI.

If there's interest in specifying an 'include' tag, I'd be willing to do the 
work (spec and code), but otherwise it sounds like leaving things as-is is the 
right thing to do.

Cheers,


--
Mark Nottingham   http://www.mnot.net/

Re: [whatwg] Including

[Ian Hickson]

On Tue, 13 Nov 2012, Mark Nottingham wrote:
 
 I've maintained a little library for a while that does inclusion:
   https://github.com/mnot/hinclude
   http://mnot.github.com/hinclude/
 
 It's used in a few different places, and is now part of Symfony 
 http://symfony.com, apparently.
 
 Besides the obvious issue of should HTML5 have an inclusion tag?, 
 something else has come up.

(For what it's worth, inclusion in HTML is done using iframe seamless.)


 Right now, hinclude uses an XML namespace (hx:) to introduce a new tag. 

In application/xhtml+xml (XML), this is and has always been non-conforming 
HTML (in the same sense that any non-HTML vocabulary is not HTML), and 
will continue to work exactly as it does today indefinitely.

In text/html, this is and has always been non-conforming (in the same 
sense that any bogus syntax or tag name is non-conforming), and will 
continue to work exactly as it does today indefinitely.

Note that in XML and HTML these conformance errors are treated very 
differently (in particular, the element ends up in the HTML namespace in 
text/html, and in its own namespace in XML).


 This was pretty widely tested to be interoperable way back, but AIUI 
 that option is going away (whatever that means) in HTML5.

Nothing is changing in terms of how it is to be interpreted by browsers.

It's definitely not a recommended syntax, though, as it results in such 
divergent DOMs depending on whether it's used in HTML or XML.

(Another dodgy part of this feature, from a conformance perspective, is 
the include files themselves. They seem to be in a proprietary format 
derived from HTML, not HTML, which has all kinds of implications on where 
hinclude can be used and where it can't and what would happen with 
handling any errors in the includes, and so forth. Also, the script 
completely ignores the Content-Type of these files.)


 It's been suggested https://github.com/mnot/hinclude/issues/13 that a 
 data-* attribute on div could be used here, but reading the description 
 there, I'm not so sure:
 
 [T]hese attributes are intended for use by the site's own scripts, and 
 are not a generic extension mechanism for publicly-usable metadata.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes
 
 hinclude is intended to be visible to software beyond the site's own 
 scripts.

What else is it intended to be used by?


 So, what's the appropriate thing to do here? Keep on using hx:include 
 (after all, it works)? use data-include or similar? Or?

Appropriate in what sense?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Including

[Tab Atkins Jr.]

On Mon, Nov 12, 2012 at 10:41 PM, Mark Nottingham m...@mnot.net wrote:
 I've maintained a little library for a while that does inclusion:
   https://github.com/mnot/hinclude
   http://mnot.github.com/hinclude/

 It's used in a few different places, and is now part of Symfony 
 http://symfony.com, apparently.

 Besides the obvious issue of should HTML5 have an inclusion tag?, something 
 else has come up.

 Right now, hinclude uses an XML namespace (hx:) to introduce a new tag. This 
 was pretty widely tested to be interoperable way back, but AIUI that option 
 is going away (whatever that means) in HTML5.

Namespaces have always been and will always be fine in the XHTML
serialization.  They have never been and will never be fine in the
HTML serialization.  Fake namespace prefixes work to some extent in
the HTML serialization, but you're better off using a dash instead of
a colon - you'll get more or less the same DOM, but saner, and it'll
work the same between the two serializations.

 It's been suggested https://github.com/mnot/hinclude/issues/13 that a 
 data-* attribute on div could be used here, but reading the description 
 there, I'm not so sure:

 [T]hese attributes are intended for use by the site's own scripts, and are 
 not a generic extension mechanism for publicly-usable metadata.

 http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes

 hinclude is intended to be visible to software beyond the site's own scripts. 
 So, what's the appropriate thing to do here? Keep on using hx:include (after 
 all, it works)? use data-include or similar? Or?

No, if it's included in the page, it's the site's own scripts.  That
line is meant to exclude data-* attributes from being used to pass
information to crawlers/browsers/extensions/etc, so that the use of
data-* is guaranteed to always be safe for a site author, without any
unintended side effects.

If you intend this to be parsed by server-side software, you move into
grayer territory.  If it's really personal scripts, fine.  If it's
meant to be an Apache extension, not fine, for the same reason as
above.

~TJ

Re: [whatwg] Including

[Mark Nottingham]

On 14/11/2012, at 4:37 AM, Ian Hickson i...@hixie.ch wrote:

 On Tue, 13 Nov 2012, Mark Nottingham wrote:
 
 I've maintained a little library for a while that does inclusion:
  https://github.com/mnot/hinclude
  http://mnot.github.com/hinclude/
 
 It's used in a few different places, and is now part of Symfony 
 http://symfony.com, apparently.
 
 Besides the obvious issue of should HTML5 have an inclusion tag?, 
 something else has come up.
 
 (For what it's worth, inclusion in HTML is done using iframe seamless.)

Ah. Does that work with older browsers (from the 2005 era onwards)?


 This was pretty widely tested to be interoperable way back, but AIUI 
 that option is going away (whatever that means) in HTML5.
 
 Nothing is changing in terms of how it is to be interpreted by browsers.

Ack; thx.


 It's definitely not a recommended syntax, though, as it results in such 
 divergent DOMs depending on whether it's used in HTML or XML.

I see.


 (Another dodgy part of this feature, from a conformance perspective, is 
 the include files themselves. They seem to be in a proprietary format 
 derived from HTML, not HTML, which has all kinds of implications on where 
 hinclude can be used and where it can't and what would happen with 
 handling any errors in the includes, and so forth. Also, the script 
 completely ignores the Content-Type of these files.)

Yes. 


 It's been suggested https://github.com/mnot/hinclude/issues/13 that a 
 data-* attribute on div could be used here, but reading the description 
 there, I'm not so sure:
 
 [T]hese attributes are intended for use by the site's own scripts, and 
 are not a generic extension mechanism for publicly-usable metadata.
 
 http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes
 
 hinclude is intended to be visible to software beyond the site's own 
 scripts.
 
 What else is it intended to be used by?

Mumble. The intent was that browsers would be able to process it directly 
without the JS, and that (for example) search engine spiders would be able to 
recognise and process it (since it's uniquely identified by the namespace). 
However, that was in ~2005; now, it's obvious that JS is pretty much required 
for browsing, and search engines just use a headless browser. 

Some people might also want to process it server-side or in intermediaries (a 
la ESI - http://en.wikipedia.org/wiki/Edge_Side_Includes), which is used 
surprisingly often.


 So, what's the appropriate thing to do here? Keep on using hx:include 
 (after all, it works)? use data-include or similar? Or?
 
 Appropriate in what sense?


Well, it works now, so I'm happy to leave it as is. However, if there were an 
argument to move to a different syntax that improved interoperability / forward 
compatibility, I'd probably add a mode where it worked that way too.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Re: [whatwg] Including

[Ian Hickson]

On Wed, 14 Nov 2012, Mark Nottingham wrote:
 On 14/11/2012, at 4:37 AM, Ian Hickson i...@hixie.ch wrote:
  On Tue, 13 Nov 2012, Mark Nottingham wrote:
  
  (For what it's worth, inclusion in HTML is done using iframe 
  seamless.)
 
 Ah. Does that work with older browsers (from the 2005 era onwards)?

No, it doesn't reliably work in today's browsers, even.


  hinclude is intended to be visible to software beyond the site's own 
  scripts.
  
  What else is it intended to be used by?
 
 Mumble. The intent was that browsers would be able to process it 
 directly without the JS, and that (for example) search engine spiders 
 would be able to recognise and process it (since it's uniquely 
 identified by the namespace).

If it's intended to be implemented by user agents, then it should just be 
part of HTML (either specced in the HTML spec, or a separate spec, e.g. 
the way that the HTML Editing APIs are specified in a separate spec). No 
need for prefixes or anything.


 However, that was in ~2005; now, it's obvious that JS is pretty much 
 required for browsing, and search engines just use a headless browser.

If it's only intended for scripts in the page, then data-* attributes are 
the intended framework for the solution.


 Some people might also want to process it server-side or in 
 intermediaries (a la ESI - 
 http://en.wikipedia.org/wiki/Edge_Side_Includes), which is used 
 surprisingly often.

If it's not exposed to the client, then it should just be a language on 
top of HTML, like PHP or SSIs, which is irrelevant to HTML clients.


  So, what's the appropriate thing to do here? Keep on using hx:include 
  (after all, it works)? use data-include or similar? Or?
  
  Appropriate in what sense?
 
 Well, it works now, so I'm happy to leave it as is. However, if there 
 were an argument to move to a different syntax that improved 
 interoperability / forward compatibility, I'd probably add a mode where 
 it worked that way too.

If it works, then I'd just leave it.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Including HTML more directly into SVG

[Tab Atkins Jr.]

On Tue, Sep 11, 2012 at 12:37 PM, Elliott Sprehn espr...@gmail.com wrote:
 On Sep 11, 2012 11:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn espr...@gmail.com
 wrote:
  On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
  ...
  Also, how does your proposal address
  flowing text inside of a path?

 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 textPath,
 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 rect+text
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

[Robin Berjon]

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

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

Re: [whatwg] Including HTML more directly into SVG

[Benjamin Hawkes-Lewis]

On Tue, Sep 11, 2012 at 9:32 AM, Robin Berjon ro...@w3.org wrote:
 foreignObject size=auto

Bikeshedding: @seamless (q.v. iframe)

--
Benjamin Hawkes-Lewis

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 mtext (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

[Tab Atkins Jr.]

On Tue, Sep 11, 2012 at 1:23 AM, Elliott Sprehn espr...@gmail.com wrote:
 On Tue, Sep 11, 2012 at 1:15 AM, Elliott Sprehn espr...@gmail.com wrote:
 On Mon, Sep 10, 2012 at 4:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

...

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

[Elliott Sprehn]

On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com 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 svg element. Are you
saying we default to shrink wrap? Also, how does your proposal address
flowing text inside of a path?

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 11:29 AM, Elliott Sprehn espr...@gmail.com wrote:
 On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com 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 svg element. Are you
 saying we default to shrink wrap?

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

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

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 textPath,
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 Sep 11, 2012 11:35 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Tue, Sep 11, 2012 at 11:29 AM, Elliott Sprehn espr...@gmail.com
wrote:
  On Tue, Sep 11, 2012 at 9:09 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
  ...
  Also, how does your proposal address
  flowing text inside of a path?

 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 textPath,
 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 output in form submissions

[Bjartur Thorlacius]

On Feb 24, 2012, at 12:18 AM, Michael Gratton wrote:

But in general, I recommend against this. Anything that can be  
computed
should be computed on the server to obtain the canonical value,  
otherwise

you open yourself up to attackers sending you inconsistent data.


While for applications where trust is an issue one clearly needs to
check calculations server-side. When it is not however, this would  
be a

welcome addition.
The principle of least authority applies. In general, neither the  
client nor the link he communicates over should not be trusted  
unnecessarily.

Re: [whatwg] including output in form submissions

[Nils Dagsson Moskopp]

Bjartur Thorlacius svartma...@gmail.com schrieb am Fri, 24 Feb 2012
09:30:21 +:

 In general, neither the  
 client nor the link he communicates over should not be trusted  
 unnecessarily.

Since I had difficulties parsing that, I'll try rephrasing without using
a triple negative: You wanted to assert that one should not trust the
client or the link it communicates over. Right?

-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net

Re: [whatwg] including output in form submissions

[Michael Gratton]

[Resending to the list]

Le 22/02/12 09:48, Ian Hickson a écrit :
 On Tue, 13 Sep 2011, Michael Gratton wrote:
 This can be remedied by allowing the value of output elements to be 
 submitted. That is, include the output element in the submittable 
 form-associated element category.

 I initially thought that this was precisely what the output element 
 existed for - it was rather surprising when I tried using them but none 
 of the values were appearing in the submission.
 
 You can work around this by just assigning the value to a hidden input 
 when you assign it to the output control.

Yes, this is what I do at the moment, However as I have argued elsewhere
on this tread, it a burdensome kludge for a limitation in the spec.

 But in general, I recommend against this. Anything that can be computed 
 should be computed on the server to obtain the canonical value, otherwise 
 you open yourself up to attackers sending you inconsistent data.

While for applications where trust is an issue one clearly needs to
check calculations server-side. When it is not however, this would be a
welcome addition.

 On Wed, 14 Sep 2011, Michael Gratton wrote:
 [As an aside, it just occured to me that it would also be helpful if 
 output supported the type attribute, for most of the same values as 
 input now does in HTML5, for much the same reason as it makes sense 
 for input.]

 It makes sense for input because it lets the browser know what interface 
 to give to the user to let the user change the value... How does that make 
 sense for output?

The same argument that applies to supporting extended type values for
input applies to output. My take on it is:

The input not only allows a user to enter a value, it also displays
its value to the user. For improved usability, some UAs will format or
replace the value of an input element rather than displaying the raw
string (some obvious candidates for this are: file, month, tel, date,
number, and colour). For consistency, these UAs should also display
calculated values - the values of output elements - in the same way.
To do this, the element needs its type declared.

At the moment, web authors must use the same kinds fall-backs as used
currently for HTML4 input elements when displaying calculated values for
these types, increasing the authorship burden and resulting in
inconsistent display with input elements.

//Mike

-- 
⊨ Michael Gratton.
⚙ http://mjog.vee.net/

Re: [whatwg] including output in form submissions

[Cameron Jones]

On Tue, Feb 21, 2012 at 10:48 PM, Ian Hickson i...@hixie.ch wrote:
 On Tue, 13 Sep 2011, Michael Gratton wrote:

 HTML5 does not provide a means of submitting form content that is
 otherwise rendered as normal text, i.e. not as a form control. The use
 cases for this are the same as for the output element, but when it is
 also desirable for the result of a calculation to be sent to the server
 when the form is submitted.

 Currently, the only way to implement this is to maintain two copies of
 the value, one the child text of an output element (or something
 similar, for example a td or span) and once in the value of an
 input type=hidden element, using appropriate scripting to keep the
 two in sync. This is error prone and places an additional burden on the
 web page author.

 This can be remedied by allowing the value of output elements to be
 submitted. That is, include the output element in the submittable
 form-associated element category.

 I initially thought that this was precisely what the output element
 existed for - it was rather surprising when I tried using them but none
 of the values were appearing in the submission.

 You can work around this by just assigning the value to a hidden input
 when you assign it to the output control.

 But in general, I recommend against this. Anything that can be computed
 should be computed on the server to obtain the canonical value, otherwise
 you open yourself up to attackers sending you inconsistent data.


This is based on the assumption of same origin web forms. If a request
is being generated from a 3rd party web site to an open public web
service, the 3rd party may choose to represent the input using methods
or calculations unknown to the target web service and irrespective to
the required request format.

If a nefarious script has access to the DOM they are capable of doing
anything, including changing input values on submit, or submitting
whole new requests with whatever data they like.

Updating output as form submittable element is included in a
proposal to enhance http request processing under a w3c issue:

http://www.w3.org/html/wg/tracker/issues/195

And proposal: (Note: changes pending, see issue thread)

http://www.w3.org/wiki/User:Cjones/ISSUE-195

 On Wed, 14 Sep 2011, Michael Gratton wrote:

 [As an aside, it just occured to me that it would also be helpful if
 output supported the type attribute, for most of the same values as
 input now does in HTML5, for much the same reason as it makes sense
 for input.]

 It makes sense for input because it lets the browser know what interface
 to give to the user to let the user change the value... How does that make
 sense for output?

 --
 Ian Hickson               U+1047E                )\._.,--,'``.    fL
 http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

The type attribute is a discriminator over an otherwise
indistinguishable text value which enables machine processing which
would otherwise not be possible or be more error prone. It has value
for input, output and data as recommended in a
alternative-proposal to w3c issue to add data element:

http://www.w3.org/html/wg/tracker/issues/184

And proposal:

http://www.w3.org/wiki/User:Cjones/ISSUE-184

Thanks,
Cameron Jones

Re: [whatwg] including output in form submissions

[Jukka K. Korpela]

2012-02-22 19:30, Cameron Jones wrote:


Updatingoutput  as form submittable element is included in a
proposal to enhance http request processing under a w3c issue


This sounds like a pointless attempt at enhancing a pointless element.

Instead of output, authors can use, and have been able to use since 
rather early days, input if the data is to be submitted as part of 
form data, and any non-form-field element, like div, otherwise. (Well, 
in the very early days, it had to be input anyway, but that was long ago.)


output is just for looking semantic for semantics' sake. There is 
nothing illogical in using input for data that is generated (not 
directly user-supplied) client-side. It's input to form handlers, 
client-side or server-side, anyway.


And there's nothing particularly semantic (i.e., as relating to meaning) 
about saying that some content is the output of some calculation. If a 
value is 42, its being in output does not indicate its meaning in any way.


output has _some_ effects: it confuses authors, if they wish to be 
serious about new specifications.


So please drop output.

Yucca

Re: [whatwg] including output in form submissions

[Cameron Jones]

On Wed, Feb 22, 2012 at 6:01 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
 2012-02-22 19:30, Cameron Jones wrote:

 Updatingoutput  as form submittable element is included in a
 proposal to enhance http request processing under a w3c issue


 This sounds like a pointless attempt at enhancing a pointless element.

 Instead of output, authors can use, and have been able to use since rather
 early days, input if the data is to be submitted as part of form data, and
 any non-form-field element, like div, otherwise. (Well, in the very early
 days, it had to be input anyway, but that was long ago.)

 output is just for looking semantic for semantics' sake. There is nothing
 illogical in using input for data that is generated (not directly
 user-supplied) client-side. It's input to form handlers, client-side or
 server-side, anyway.

 And there's nothing particularly semantic (i.e., as relating to meaning)
 about saying that some content is the output of some calculation. If a value
 is 42, its being in output does not indicate its meaning in any way.

 output has _some_ effects: it confuses authors, if they wish to be serious
 about new specifications.

 So please drop output.

 Yucca


It does provide a greater degree of integration with the browser
though. This results in a less scripting being required and allows for
inline scripting to be more concise which aids readability and keeps
things together. It's also possible for it to be styled using a
different interface instead of elements targeted at capturing
information. The 'disabled' state doesn't provide this for input

Cam

Re: [whatwg] including output in form submissions

[Jukka K. Korpela]

2012-02-22 20:13, Cameron Jones wrote:


It [the output element]

 does provide a greater degree of integration with the browser though.

Is this a requirement, or just assumed features of implementation? Which 
of the assumed benefits could not be achieved by adding a new value for 
the type attribute (input type=output), or a new parameter (input 
output), or otherwise retaining the use of input (which would degrade 
well)?



This results in a less scripting being required and allows for
inline scripting to be more concise which aids readability and keeps
things together.


This would need to be illustrated by real examples, and you would still 
have the question why this could not be achieved using libraries, 
without making pages break on old browsers.



It's also possible for it to be styled using a
different interface instead of elements targeted at capturing
information. The 'disabled' state doesn't provide this for input


If you wish to show results of calculation visibly _and_ pass them along 
with the form data, you can use _both_ a normal element like div, p, 
or span _and_ an input type=hidden. The resulting duplication is 
irrelevant; you have the result in a variable, or should have, and just 
put it into two places.


Yucca

Re: [whatwg] including output in form submissions

[Cameron Jones]

On Wed, Feb 22, 2012 at 6:26 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
 2012-02-22 20:13, Cameron Jones wrote:

 It [the output element]

 does provide a greater degree of integration with the browser though.

 Is this a requirement, or just assumed features of implementation? Which of
 the assumed benefits could not be achieved by adding a new value for the
 type attribute (input type=output), or a new parameter (input output),
 or otherwise retaining the use of input (which would degrade well)?


I'm referring to the for attribute on output which ties its value
to the elements which went into the calculation. This would otherwise
have to be done using event attributes.

 This results in a less scripting being required and allows for
 inline scripting to be more concise which aids readability and keeps
 things together.


 This would need to be illustrated by real examples, and you would still have
 the question why this could not be achieved using libraries, without making
 pages break on old browsers.


See above for less scripting. Old browsers won't be broken by the
output element, they will function ina  degraded state though. It's
just as applicable to fix them using libraries.

 It's also possible for it to be styled using a
 different interface instead of elements targeted at capturing
 information. The 'disabled' state doesn't provide this for input


 If you wish to show results of calculation visibly _and_ pass them along
 with the form data, you can use _both_ a normal element like div, p, or
 span _and_ an input type=hidden. The resulting duplication is
 irrelevant; you have the result in a variable, or should have, and just put
 it into two places.

 Yucca


This is imposing more and more on scripting and is a far more removed
from declarative markup which is easier to understand and less error
prone. I think the output element is conceptually simple, especially
for authors with little or no programming experience.

This also doesn't address the ability to style these elements in a
separate and distinguishable way from input.

Cam

Re: [whatwg] including output in form submissions

[Jukka K. Korpela]

2012-02-22 20:38, Cameron Jones wrote:


I'm referring to the for attribute onoutput  which ties its value
to the elements which went into the calculation. This would otherwise
have to be done using event attributes.


I don't see how that is supposed to simplify things. It's supposed to 
designate dependencies, but you still need to do just the same coding as 
without it, won't you?



Old browsers won't be broken by the
output  element, they will function ina  degraded state though.


Certain old browsers won't recognize the output element at all.


If you wish to show results of calculation visibly _and_ pass them along
with the form data, you can use _both_ a normal element likediv,p, or
span  _and_ aninput type=hidden. The resulting duplication is
irrelevant; you have the result in a variable, or should have, and just put
it into two places.

Yucca



This is imposing more and more on scripting


No, it's nothing in addition to what is currently done. And if you 
calculate something in scripting, you need to write it somehow into an 
element. Writing it twice, when needed, is very trivial.



and is a far more removed
from declarative markup which is easier to understand and less error
prone.


I don't see how it would be less error prone. And I don't see anything 
declarative with output. It's declarative markup to say this is a first 
level heading (which we can say with h1) or this is a person's name 
(which we can't say in HTML), but it's not declarative to say this is 
something written / to be written by a client-side script.



I think the output  element is conceptually simple, especially
for authors with little or no programming experience.


So why the discussions about including output in form submission?


This also doesn't address the ability to style these elements in a
separate and distinguishable way from input.


You don't need a new element (unsupported by old browsers) to do 
styling. You can use classes, or other attributes. And you don't need to 
use input. You can use span or whatever you like, and/or input 
type=hidden, which normally causes no rendering issues.


Yucca

Re: [whatwg] including output in form submissions

[Ian Hickson]

On Tue, 13 Sep 2011, Michael Gratton wrote:
 
 HTML5 does not provide a means of submitting form content that is 
 otherwise rendered as normal text, i.e. not as a form control. The use 
 cases for this are the same as for the output element, but when it is 
 also desirable for the result of a calculation to be sent to the server 
 when the form is submitted.
 
 Currently, the only way to implement this is to maintain two copies of 
 the value, one the child text of an output element (or something 
 similar, for example a td or span) and once in the value of an 
 input type=hidden element, using appropriate scripting to keep the 
 two in sync. This is error prone and places an additional burden on the 
 web page author.
 
 This can be remedied by allowing the value of output elements to be 
 submitted. That is, include the output element in the submittable 
 form-associated element category.
 
 I initially thought that this was precisely what the output element 
 existed for - it was rather surprising when I tried using them but none 
 of the values were appearing in the submission.

You can work around this by just assigning the value to a hidden input 
when you assign it to the output control.

But in general, I recommend against this. Anything that can be computed 
should be computed on the server to obtain the canonical value, otherwise 
you open yourself up to attackers sending you inconsistent data.


On Wed, 14 Sep 2011, Michael Gratton wrote:
 
 [As an aside, it just occured to me that it would also be helpful if 
 output supported the type attribute, for most of the same values as 
 input now does in HTML5, for much the same reason as it makes sense 
 for input.]

It makes sense for input because it lets the browser know what interface 
to give to the user to let the user change the value... How does that make 
sense for output?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Including FLAC output in Audio Specs

[Ian Hickson]

On Wed, 12 Oct 2011, Charles Pritchard wrote:

 Currently, PNG and the Canvas tag set a solid precedent for including a 
 lossless file format in media APIs. The PNG format, at its most basic, 
 simply compresses a bitmap using deflate.
 
 I'd like to see the same precedent followed in some of the new media 
 APIs. FLAC provides a lossless audio format which can be used to package 
 audio data from items like the MediaStream .record method.
 
 How would we go about adding this into specifications?
 
 I'll point out that many vendors support JPEG in addition to PNG, but 
 that's not part of the specs, and it is a lossy format. It'd be nice to 
 see something like Speex supported by vendors on audio APIs, but like 
 JPEG, it's something that should remain a lesser priority to supporting 
 a lossless format.
 
 MediaStream record seems like it could accept a mime type, much as 
 toBlob / toDataURL do on Canvas. That's one possible point of entry.
 
 Does anyone have feedback on this issue? Is there any push-back out 
 there on supporting FLAC as a baseline format for audio input and 
 output? Obviously, it is bandwidth heavy, as is PNG.

Since the MediaStream API has moved to the WebRTC WG, I recommend raising 
this there instead.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] including output in form submissions

[Michael Gratton]

Hi Mat,

Thanks for the response.

On 13/09/11 18:41, m...@matcarey.co.uk wrote:
 Hi Mike, I've got some concerns with that:
 
 HTML5 does not provide a means of submitting form content that is
 otherwise rendered as normal text
  
 I believe this is the job of CSS rather than HTML - I would say that anything
 due to be submitted to the server is semantically an input even if it's 
 styled
 as plain text.  

An input represents a typed data field, usually with a form control
to allow the _user_ to edit the data. (emphasis mine). Thus using an
input readonly to represent the output of a calculation, styled to
look like plain text, is semantically incorrect. This is doubly the case
now there is an element that as you note specifically exists to
represent this.

[As an aside, it just occured to me that it would also be helpful if
output supported the type attribute, for most of the same values as
input now does in HTML5, for much the same reason as it makes sense
for input.]

In any case, there are several other elements that are not input but
are submittable: button, keygen, object, select and textarea.
Note especially keygen and object, the former's value is the result
of a calculation and the latter's could be pretty much anything. Both of
these can be included in a form submission, and do not (necessarily)
represent user input.

 Currently, the only way to implement this is to maintain two copies
 of the value
 
 I disagree that it's the only way

Yes, that was way too strong a claim.

Perhaps a better claim would be: Currently, there is no semantically
correct, non-error-prone, straight-forward way to implement this.

 This can be remedied by allowing the value of output elements to be
 submitted.
  
 I would say that this is not helpful - the spec at
 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element
 states The output element represents the result of a calculation and the
 example provided is a calculation between two text fields.  The use-case in 
 the
 documentation would work fine without JS because the two numbers which are 
 added
 together are inputs and would be submitted even though the answer wouldn't 
 be
 - this way you can calculate on the server-side directly based on the user's
 input (proper semantic usage of input) and the output (semantically 
 output)
 is not important to the server.

You've demonstrated including output values in a form submission is
not strictly necessary, we both agree on that, but you have not
demonstrated it would not be helpful. Whether or not it is helpful will
depend on the application/use case.

In an application with the same use case for output as you quote
above, but also requires the value to be included in the form
submission, it would be helpful. Specifically because the web page
author (/me waives) would not need to resort to kludges to include the
values of the output elements in the form submission. While this does
not apply to all applications, it would include any application where
the client can be trusted.

 I would also say that it's specifically unhelpful to send back additional 
 fields
 as this will cause cross-browser inconsistencies while it's rolled out (and in
 legacy browsers) and cause extra data bloating POST bodies or Query Strings 
 for
 what seems to me to be a feature which is not required in what I would see as
 the majority of uses of the output element.

For transition, the usual detection methods (e.g. that are currently
needed for HTML5's extended input types) could be employed to prevent
duplicating data in submissions.

 a) Using CSS to style the input in an environment where it's semantically
 correct to use input (if this plain text rendering is truly an input to be
 changed by the user)

As noted above, this is semantically incorrect.

 b) Using JS to replace/replicate specific output elems with input
 type=hidden on the form submit.

This requires additional effort on the part of the application
developer, and without care would be easy to get wrong. For example,
think of a naive implementation that does not take into account the user
can cause a form submission to occur more than once.

Note this tack can be taken against most of HTML5's form improvements in
general — something like input type=date can be already implemented by
splashing some JavaScript around, so why bother with it?

 c) Assuming you're accepting user input, then displaying the calculated 
 summary
 in an ouptut tag, then you can re-calculate the summary on the server-side
 based on the user's input - NOTE: this would be dangerous if the example is
 much more complicated than the documented example.

This is exceptionally prone to error due to the code duplication that
would be required, thus should be avoided whenever possible.

//Mike

-- 
⊨ Michael Gratton.
⚙ http://mjog.vee.net/

Re: [whatwg] including output in form submissions

[m...@matcarey.co.uk]

Hi Mike, I've got some concerns with that:

 HTML5 does not provide a means of submitting form content that is
 otherwise rendered as normal text
 
I believe this is the job of CSS rather than HTML - I would say that anything
due to be submitted to the server is semantically an input even if it's styled
as plain text.  

 Currently, the only way to implement this is to maintain two copies
 of the value

I disagree that it's the only way - you could easily use a javascript event
handler on the submit of the form which would go through all output elements
and create input type=hidden  elements within the form - this way you're
capturing the 'real output value' at the point of submitting which seems like
it's exactly what you're after.  It's worth noting that I'm not much of a fan of
JS workarounds, but I don't see this as a concern because the output value
sounds like it would be created by JS, so a non-JS user would (presumably) not
have any output elems which need converting (in your specific use-case) so
they'd hit your normal server-side fallback for non-JS users.

 This can be remedied by allowing the value of output elements to be
 submitted.
 
I would say that this is not helpful - the spec at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-output-element
states The output element represents the result of a calculation and the
example provided is a calculation between two text fields.  The use-case in the
documentation would work fine without JS because the two numbers which are added
together are inputs and would be submitted even though the answer wouldn't be
- this way you can calculate on the server-side directly based on the user's
input (proper semantic usage of input) and the output (semantically output)
is not important to the server.
 
I would also say that it's specifically unhelpful to send back additional fields
as this will cause cross-browser inconsistencies while it's rolled out (and in
legacy browsers) and cause extra data bloating POST bodies or Query Strings for
what seems to me to be a feature which is not required in what I would see as
the majority of uses of the output element.
 
To meet your use-case I would recommend one of the following:
 
a) Using CSS to style the input in an environment where it's semantically
correct to use input (if this plain text rendering is truly an input to be
changed by the user) e.g.
 
!DOCTYPE HTML
meta charset=UTF-8/
style
    input, p{
    background: transparent;
    border: 0 none;
    font-family: sans-serif;
    color: #333;
    font-size: 14px;
    }
    input.smallNumber{
    width: 1.5em;
    display: inline-block;
    text-align: center;
    }
/style
form action=/
    pThere are input name=textInput class=smallNumber type=text
value=5/ people/p
/form
 
(note: @class smallNumber is a 'small number' (not too large) rather than a
'small field containing a number') 

b) Using JS to replace/replicate specific output elems with input
type=hidden on the form submit.
c) Assuming you're accepting user input, then displaying the calculated summary
in an ouptut tag, then you can re-calculate the summary on the server-side
based on the user's input - NOTE: this would be dangerous if the example is
much more complicated than the documented example.
 
Mat Carey 
 

On 13 September 2011 at 07:29 Michael Gratton m...@vee.net wrote:


 Hi there,

 HTML5 does not provide a means of submitting form content that is
 otherwise rendered as normal text, i.e. not as a form control. The use
 cases for this are the same as for the output element, but when it is
 also desirable for the result of a calculation to be sent to the server
 when the form is submitted.

 Currently, the only way to implement this is to maintain two copies of
 the value, one the child text of an output element (or something
 similar, for example a td or span) and once in the value of an
 input type=hidden element, using appropriate scripting to keep the
 two in sync. This is error prone and places an additional burden on the
 web page author.

 This can be remedied by allowing the value of output elements to be
 submitted. That is, include the output element in the submittable
 form-associated element category.

 I initially thought that this was precisely what the output element
 existed for - it was rather surprising when I tried using them but none
 of the values were appearing in the submission.

 //Mike

 --
 ⊨ Michael Gratton.
 ⚙ http://mjog.vee.net/