25552 2014-05-05 16:22:13 +0000 Shouldn't <figure> also allow intermixed script-supporting elements (before/after the <figcaption>)? 2017-07-21 17:43:08 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED WONTFIX https://www.w3.org/Bugs/Public/show_bug.cgi?id=25555 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25549 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25553 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25547 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25550 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25551 http://www.whatwg.org/specs/web-apps/current-work/#the-figure-element P3 normal Unsorted 25547 25550 25551 25553 1 contributor ian ian mike zcorpan contributor oldest_to_newest 105053 0 contributor 2014-05-05 16:22:13 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#the-figure-element Complete: http://www.whatwg.org/c#the-figure-element Referrer: Comment: Shouldn't <figure> also allow intermixed script-supporting elements (before/after the <figcaption>)? Posted from: 2a00:801:e0:30:d9c4:c34f:b530:6023 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 OPR/21.0.1432.48 (Edition Next) 105085 1 ian 2014-05-05 21:31:07 +0000 What's the value in doing this? 105238 2 zcorpan 2014-05-06 21:12:42 +0000 It's easy to understand that script/template is allowed anywhere (modulo HTML parser behavior). This is an unnecessary exception. 105331 3 ian 2014-05-07 18:36:07 +0000 But they're not allowed anywhere. There's lots of exceptions. 105403 4 zcorpan 2014-05-08 07:50:56 +0000 Yeah, that's why I filed lots of bugs. :-P I don't see a technical reason for this exception to exist. 105463 5 ian 2014-05-08 17:54:03 +0000 The idea is that all the elements whose content model are essentially "a fixed element, then a hole where you can fill whatever you want" would only accept things like <script> and <style> in the hole, since that makes all the logic around the fixed element easier in tools that only have to deal with conforming content. 105711 6 zcorpan 2014-05-12 12:01:25 +0000 I don't understand why "a fixed element with a hole" should be different from "a fixed element without a hole" (e.g. <ol>, <dl>, <table>). Doesn't the easier logic argument apply equally to those? 105735 7 ian 2014-05-12 17:54:20 +0000 Well if there's a hole, you can still do everything you need to, you just put the content in the hole. If there's no hole, then it depends what you're trying to do. For example, in <ol> and <dl> you could easily imagine wanting a <template> that you stamp out, and putting it in the element seems like a logical place for it. In <table> we already have to allow crazy stuff for legacy reasons. 105931 8 ian 2014-05-13 23:25:14 +0000 Regardless of the decision here, the same decision will apply to the following cases also: <details>/<summary> (bug 25550) <fieldset>/<legend> (bug 25551) <video>/<audio>/<source>/<track> (bug 25547) <object>/<param> (bug 25553) See also bug 25555 (ruby) and bug 25549 (datalist). 109534 9 ian 2014-07-29 23:53:38 +0000 IMHO the current state (now that bug 25549 and bug 25572 are fixed) is pretty internally consistent (modulo some weird constraints due to legacy, like not having <script> in <colgroup>). I don't see much value in changing the content models to allow script and template to be put before summary, legend, figcaption, source, track, param, and style (or after figcaption). 109836 10 zcorpan 2014-08-04 14:42:55 +0000 OK. What do you think <picture>'s content model should be? 109841 11 ian 2014-08-04 17:37:09 +0000 I don't think <picture> should exist. If it exists, I don't think it should reuse <source>. But more generally, for elements that take specific children, like <select>, <optgroup>, <dl>, and company (i.e. elements that don't take arbitrary flow or phrasing children), I think the design thinking should be: 1. Figure out what elements are going to be required at all times in the element. (Generally, it's bad design if something is required at all times, since you should just use the parent element instead.) 2. Figure out what elements are going to be zero-or-more or one-or-more children. If it's zero-or-more, then allow them to be replaced by template or script (i.e. "script-supporting elements). If it's one-or-more, only allow them to be replaced by "template". Allowing zero-or-more is strongly encouraged. 3. Figure out if the required elements, if any, are to be placed in any particular location, or if it doesn't matter. 111223 12 ian 2014-09-08 23:57:04 +0000 zcorpan, I'm reassigning this to you per comment 10 and comment 11; please feel free to reassign this to me if you think there's more for me to do (e.g. if you disagree with comment 9). Thanks! 111261 13 zcorpan 2014-09-09 13:04:42 +0000 (In reply to Ian 'Hixie' Hickson from comment #5) > The idea is that all the elements whose content model are essentially "a > fixed element, then a hole where you can fill whatever you want" would only > accept things like <script> and <style> in the hole, since that makes all > the logic around the fixed element easier in tools that only have to deal > with conforming content. I don't see why it's easier in tools to only support conforming content. Let's take <video> for example, and the tool wants the <source> elements. In both cases you need to check if the given element is a <source> element. // any content function getSources(video) { return [].filter.call(video.children, function(child) { return child instanceof HTMLSourceElement; }; } // only conforming content function getSources(video) { var children = video.children; var rv = []; for (var i = 0; i < children.length; ++i) { if (!(children[i] instanceof HTMLSourceElement)) { return rv; } rv.push(children[i]); } } 111262 14 zcorpan 2014-09-09 13:16:33 +0000 (In reply to Ian 'Hixie' Hickson from comment #7) > Well if there's a hole, you can still do everything you need to, you just > put the content in the hole. Not really for <figure>. If I want to use <script> at the end of a <figure> to paint on the <canvas> and fill something in in the <figcaption>, I think that should be allowed regardless of if the <figcapion> is before or after the <canvas>. The current rule basically means I have to put the script after the </figure> which is just wasting the author's time. 111263 15 zcorpan 2014-09-09 13:25:54 +0000 (In reply to Ian 'Hixie' Hickson from comment #11) > But more generally, for elements that take specific children, like <select>, > <optgroup>, <dl>, and company (i.e. elements that don't take arbitrary flow > or phrasing children), I think the design thinking should be: > > 1. Figure out what elements are going to be required at all times in the > element. > (Generally, it's bad design if something is required at all times, since > you > should just use the parent element instead.) > > 2. Figure out what elements are going to be zero-or-more or one-or-more > children. > If it's zero-or-more, then allow them to be replaced by template or > script (i.e. > "script-supporting elements). If it's one-or-more, only allow them to be > replaced by "template". Allowing zero-or-more is strongly encouraged. > > 3. Figure out if the required elements, if any, are to be placed in any > particular > location, or if it doesn't matter. So <picture> has zero-or-more <source>s followed by one required <img>. If I understand correctly, this would mean that <picture>'s <source>s can be replaced by script/template, but not intermixed, and no script/template after the img. Valid: <picture><script></script><img></picture> <picture><source><img></picture> Invalid: <picture><script></script><source><img></picture> <picture><source><script></script><img></picture> <picture><img><script></script></picture> Is that right? 111264 16 zcorpan 2014-09-09 13:28:21 +0000 (In reply to Ian 'Hixie' Hickson from comment #9) > I don't see much value in changing > the content models to allow script and template to be put before summary, > legend, figcaption, source, track, param, and style (or after figcaption). I disagree. I think disallowing them is waste of author time when the validator complains at them for using a <script> somewhere that does exactly what they wanted. 111458 17 ian 2014-09-12 18:43:44 +0000 (In reply to Simon Pieters from comment #13) > > I don't see why it's easier in tools to only support conforming content. Because you start at the top of the element, and stop when you reach something that's not a source. function handleVideo(video) { var source = video.firstElementChild; // first handle the video's sources while (source && source instanceof HTMLSourceElement) { // do whatever... source = source.nextElementSibling; } // then handle the video's tracks while (source && source instanceof HTMLTrackElement) { // do whatever... source = source.nextElementSibling; } } It gets much more messy if you have a content model that allows mixing stuff around, interleaving scripts, or whatever. (In reply to Simon Pieters from comment #14) > > If I want to use <script> at the end of a <figure> to paint on the <canvas> > and fill something in in the <figcaption>, I think that should be allowed > regardless of if the <figcapion> is before or after the <canvas>. The > current rule basically means I have to put the script after the </figure> > which is just wasting the author's time. The script here is not part of the transparent part of the figure, the "figure per se", for lack of a better term. In the case of figcaption being at the start, it looks like you can do it, because then the script is "reaching out" of the figure to affect the caption. But really it's not supposed to be in the figure at all, since it's affecting the figcaption. I suppose we could allow <script> to be interleaved into <figure>, <hgroup>, and so on, not as a replacement but just because scripts can go more or less anywhere. But this makes the connection between <script> and <template> much more tenuous, makes the content models much more complicated, and generally makes things less consistent and coherent, IMHO. And I still think it'd be bad in the <video> case, for the reason given above. 111671 18 zcorpan 2014-09-17 08:00:20 +0000 (In reply to Ian 'Hixie' Hickson from comment #17) > Because you start at the top of the element, and stop when you reach > something that's not a source. I see. I'm not convinced it's much more messy to support any order, though. function handleVideo(video) { var source = video.firstElementChild; while (source) { // handle the video's sources if (source instanceof HTMLSourceElement) { // do whatever... } // handle the video's tracks if (source instanceof HTMLTrackElement) { // do whatever... } source = source.nextElementSibling; } } Also, if the tool is supposed to work with arbitrary Web content, it can't assume that it is valid anyway. If the tool only works with content that is known to have a particular structure, it doesn't need the spec requiring that particular structure. So I think it's not a convincing argument. > The script here is not part of the transparent part of the figure, the > "figure per se", for lack of a better term. In the case of figcaption being > at the start, it looks like you can do it, because then the script is > "reaching out" of the figure to affect the caption. But really it's not > supposed to be in the figure at all, since it's affecting the figcaption. That's... really obscure. I really don't think authors are going to think in those terms. They will just put their scripts where they please and have it do whatever they need to do. > I suppose we could allow <script> to be interleaved into <figure>, <hgroup>, > and so on, not as a replacement but just because scripts can go more or less > anywhere. Yes. > But this makes the connection between <script> and <template> much > more tenuous, makes the content models much more complicated, and generally > makes things less consistent and coherent, IMHO. So allow <template> where <script> is allowed. 128769 19 mike 2017-07-21 17:43:08 +0000 Let’s re-raise this in the GitHub issue tracker if necessary.