Interesting question. Should we disallow sections inside <li>s or <dd>s? Currently we've assumed that they should be allowed, but it's true that it may be a bit weird.

Are there good use cases for an <li> or <dt> — or indeed <td> — to contain a sectioning element or headings (I guess other than <aside> or <nav>, for which use cases seem reasonable)?

Is there any harm in list items having subsections? It might screw up the outline algorithm (<li> and <dd> aren't sectioning roots), but maybe that's worth fixing separately? You could only have a list start in one section and end in a section of higher rank if you weren't using <aside>/<article>/<nav>, so at least you know it's all within the same kind of section...

I know some people use headings in <li> to give a heading to a nested list, which seems reasonable.

As specified right now, that also gives a heading to later content and in fact splits the list into spanning two sections. Maybe we should make them sectioning roots...? Though that seems a bit heavy-handed...

It would be good to get more opinions on this.

1. I thought html5+ was supposed to be backwards-compatible with the existing
   web. The existing web allows this. I also thought html5+ was supposed
   to specify what's implemented by browsers.
   It should be trivial to turn an html4/xhtml1 document into an html5 one.
   Editors should not have to check if the list items of a given html4/xhtml1
   document have to be modified for html5.

2. all existing content editors, wysiwyg or not, allow flow content inside li;
   that is enough for me to ask to close with bug as wontfix.

3. all existing browsers not only allow flow content inside li but render it
   perfectly.

4. I confirm a lot of authors use headers inside list items. I don't see why
   a div containing a long quote from another document (including headers
   and section) could not be listed.

5. it's still perfectly possible to use CSS to make a div act as a list item
   with all the model of flow content applying. There is then no technical
   blocker here. The fact it's possible to use a div and CSS is not a good
   enough reason to change li's model. If having headers and sections inside
   a list-item'd div is conceptually ok, I fail to see why it should be nok
   for li.

6. this bug asks a question but does not suggest how to tweak the content
   model of li if it's not based on flow content.
   It seems to me that most elements in flow [1] definition do make sense
   inside li. Forking flow model into two versions, one for non-listitems
   and one for listitems seems to me totally overkill.

I therefore strongly recommend a WONTFIX, as you probably predicted.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#flow-content

I don't see concrete enough benefit from disallowing headings inside list items that it would outweigh the annoyance to authors who have a reason to have headings inside list items. That is, I'd WONTFIX this.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: see diff below
Rationale: Fair enough. I've added a note about the semantics of this.

Checked in as WHATWG revision r6925.
Check-in comment: Add a note about <li><h1>.
http://html5.org/tools/web-apps-tracker?from=6924&to=6925