Minor issues on the TOC algorithm

[iherman]

Two minor (partially editorial) issues related to the TOC algorithm:

1. How to tell UA what to do when there is no label for a ToC item (null name property or placeholder name?)
2. At the moment, both the structure and the extraction algorithm are normative. Is it necessary to keep the structure normative or can it be informative?

[rdeltour]

• How to tell UA what to do when there is no label for a ToC item (null name property or placeholder name?)

I believe this depends on what we say about how UAs should/must render the ToC, in 6.3.3 (see also #146).

• At the moment, both the structure and the extraction algorithm are normative. Is it necessary to keep the structure normative or can it be informative?

I think keeping both sections as normative is more confusing that helpful, and can be a source of spec bugs. I would rather see the "recommended" content model description as an informative best practice; this structure section could be moved to after the algorithm description btw.

[iherman]

I believe this depends on what we say about how UAs should/must render the ToC, in 6.3.3 (see also #146).

I do not think the spec would say any MUST as part of the affordances. It may say SHOULD-s, though.

[mattgarrish]

I believe this depends on what we say about how UAs should/must render the ToC, in 6.3.3

Unless we expect the table of contents to be exposed to other applications, I think we should say that if the user agent requires a title, or a label for an unnamed branch, it should insert one as it is processing.

It doesn't make sense to process the toc nav and do nothing about the unspecified name properties, then have to inspect the names again when using the extracted toc for any purpose. Let the user agent fill in the info, like it does with the canonical manifest.

[mattgarrish]

I think keeping both sections as normative is more confusing that helpful, and can be a source of spec bugs.

Looking back on it, I don't think the content model is all that easy to understand. It worked for EPUB because EPUB is very strict about the tagging, but now that we're looking for a specific structure within a much more open structure, I'm not sure a content model is an effective way of explaining what we're looking for. I think people will mistake it for the EPUB model, or have difficulty reading that these rules are meant to exist within the nav content model.

I think any risk of bugs will remain even if we rewrite -- because both sections always have to be carefully edited -- but I'd like to try rewriting it to make it more descriptive of what the parsing algorithm is looking for.

[iherman]

Let the user agent fill in the info, like it does with the canonical manifest.

I agree with this, but I do not think the spec should prescribe what it should fill it with. It would actually be impossible to do so, in view of the different languages.

[mattgarrish]

but I do not think the spec should prescribe what it should fill it with.

Agree. I think we can just include a statement that if a branch does not have a name when exiting it, the user agent MAY supply one if it is needed for later rendering purposes. That still leaves the door open to leaving the property null and supplying a name later if there are good reasons why a user agent might prefer that method.

[iherman]

Can we agree on an approach whereby:

• the structure will be rewritten as a more 'descriptive' and informative text
• there should be a note somewhere at the end of the extraction algorithm (maybe simply in step 5) saying something like:

If a branch, or the toc itself, does not have an assigned name, the User Agent MAY insert a name of its own choosing.

(Or something like that.)

If so, we can change this issue as an editorial one, and can be solved when @mattgarrish does the editorial changes...

[TzviyaSiegman]

@mattgarrish OK to close?