What's the value in doing this?

It's easy to understand that script/template is allowed anywhere (modulo HTML parser behavior). This is an unnecessary exception.

But they're not allowed anywhere. There's lots of exceptions.

Yeah, that's why I filed lots of bugs. :-P I don't see a technical reason for this exception to exist.

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

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.

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

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

OK. What do you think <picture>'s content model should be?

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.

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!

(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]);
  }
}

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

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

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

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

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

Let’s re-raise this in the GitHub issue tracker if necessary.