Sectioning Root Element is no longer defined

[wareid]

See Pub-manifest issue 255 for more background.

The processing algorithm and HTML appendix in the Publication Manifest references a now-undefined feature of the HTML specification.

This reference was in regards to the table of contents processing algorithm skipping certain sectioning elements (blockquote, body, details, dialog, fieldset, figure, and td).

Based on this change, we likely need to decide on whether we keep a similar restriction for TOC processing, define something new, or let all non-sectioning elements fall through. (Thanks to @mattgarrish for summarizing this so well).

[iherman]

@wareid, does this problem affect other specs than just the Publ. Manifest? Because if not, it might be better transfer this issueto the document's repo from here...

[mattgarrish]

If we want to avoid a class 3 change at this time, we could probably just inline the list of elements. We wouldn't be changing the existing normative requirements, only accounting for the lack of an external reference.

For example, change the problematic reference to:

A small set of elements are ignored when the parsing table of contents to avoid misinterpretation. These are the [html] sectioning content elements and what were previously defined as <dfn>sectioning root elements</dfn> -- blockquote, body, details, dialog, fieldset, figure, and td.

And then link the two general references to sectioning root elements to this new definition.

The list of elements is kind of haphazard, but it is what it is. The purpose of having these exclusions was to avoid capturing any content that might adorn the table of contents (making the toc less rigid than epub's), but what realistically are people going to add? I'm pretty sure the fact that most form elements are allowed by this definition doesn't mean we're actually going to find anyone using them. Same for iframe, dl, and other elements that seem like they should be accounted for.

If we're going to restrict elements, it would be helpful to have an idea what people are commonly using. That might take a longer term investigation, as I doubt there's enough real world implementation to go by.

[mattgarrish]

Another thought on this is it might make sense to define a method that allows authors to exclude what they don't want parsed, rather than try and prohibit elements. We could define a data-toc-exclude attribute, for example, and have it behave like hidden content.

[iherman]

I like the approach in #3 (comment), @mattgarrish. As an aside, it is really not a very spec friendly approach to simply remove such anchors from the HTML spec, but I guess that is what you get with a living standard... :-(

I am not sure about the extra attribute. For the moment, we have no user request for something like that, so I do not think we should do it.

[mattgarrish]

I am not sure about the extra attribute.

Me, either. It'd be a class 4 change. I was just throwing it out as a less headache-inducing solution than trying to proscribe elements you can use.

I figure we can leave the broader issue of what to do with this list open and just solve the referencing problem.