Remove categories of select/optgroup/option element inner content elements#12568
Conversation
…ments. This removes the categories: * select element inner content elements * optgroup element inner content elements * option element inner content elements in order to simplify the specification a bit. It does so by making the div content model rules that use these concepts instead use the transparent content model concept, which works for these cases and is perhaps also more clear. This is a followup to whatwg#12504 and also has the goal of simplifying the content model changes we will need in whatwg#12011. (I think whatwg#12011 may also need the concept of limiting this transparency to certain close descendants but not all descendants, but I don't think that concept is needed for the select content models.)
| <dd><span><code>option</code> element inner content elements</span>.</dd> | ||
| <dt><span data-x="concept-element-contexts">Contexts in which this element can be used</span>:</dt> | ||
| <dd>Where <span>flow content</span> is expected.</dd> | ||
| <dd>As a child of a <code>dl</code> element.</dd> |
There was a problem hiding this comment.
Add the following:
As a descendant of an option element, an optgroup element or select element
There was a problem hiding this comment.
Agreed, but some nits:
As a descendant of an option element, an optgroup element, or a select element.
There was a problem hiding this comment.
Added. (I assume you meant in the "Contexts" <dt>.)
| <span data-x="Palpable content">palpable</span></td> | ||
| <td><span data-x="Phrasing content">phrasing</span>; | ||
| <span><code>option</code> element inner content elements</span>*</td> | ||
| <span>transparent</span></td> |
There was a problem hiding this comment.
Does it make sense to say that the Parents can be transparent? Just phrasing might suffice here?
There was a problem hiding this comment.
Yeah, I don't think it does. Removed. (I admit I find editing these tables to be somewhat difficult, and have also noticed they don't seem all that well-maintained as a result...)
On the other hand, I think (given the other thread) I think this pointed out that I should add select/optgroup/option to the parents entry of the table for div.
There was a problem hiding this comment.
That seems right. AI found some more cases including that this should probably list div* as well, because you can have select > div > div > option.
If my latest commit looks good to you I suggest we merge this.
dbaron
left a comment
dbaron
left a comment
There was a problem hiding this comment.
I think your latest commit looks good modulo the comments below:
| <td><span data-x="Flow content">flow</span></td> | ||
| <code>optgroup</code>; | ||
| <code>select</code>; | ||
| <code>div</code>*</td> |
There was a problem hiding this comment.
I think listing div* as a parent of div doesn't make sense, both because * doesn't make sense in the Parent column and because it's already accounted for with flow above.
There was a problem hiding this comment.
There is precedent for * in the Parent column. But I agree that div is redundant in all these cases.
| <code>optgroup</code>; | ||
| <code>select</code>; | ||
| <code>div</code>*</td> | ||
| <td><span data-x="Flow content">flow</span>*</td> |
There was a problem hiding this comment.
There seems to be roughly a 50/50 split over whether a * follows "flow" or "phrasing" in the "Children" column. Probably worth making this consistent one way or the other in a followup. I guess the change here is fine although I might also just leave as-is until the followup.
| <td><span data-x="text content">text</span>*; | ||
| <code>div</code>*; | ||
| <span data-x="Phrasing content">phrasing</span></td> | ||
| <span data-x="Phrasing content">phrasing</span>*</td> |
There was a problem hiding this comment.
I'm ok with this, but there's a lot more like it (see my comment on the 50/50 split above).
…ual criteria are more involved)
3 participants
This removes the categories:
It does so by making the div content model rules that use these concepts instead use the transparent content model concept, which works for these cases and is perhaps also more clear.
This is a followup to #12504 and also has the goal of simplifying the content model changes we will need in #12011. (I think #12011 may also need the concept of limiting this transparency to certain close descendants but not all descendants, but I don't think that concept is needed for the select content models.)
(Sorry, I wrote this last week right after landing #12504, but I forgot to actually create the PR!)
/dom.html ( diff )
/form-elements.html ( diff )
/grouping-content.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/scripting.html ( diff )