NOTE: The current preferred location for bug reports is the GitHub issue tracker.
Bug 994 - Needs option to parse as iframe srcdoc document or higher-level protocol
Needs option to parse as iframe srcdoc document or higher-level protocol
Status: NEW
Product: Validator.nu
Classification: Unclassified
Component: General
HEAD
All All
: P2 normal
Assigned To: Nobody
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-04-15 12:32 CEST by chocolate.camera
Modified: 2014-04-15 12:32 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chocolate.camera 2014-04-15 12:32:51 CEST
A missing title element should produce a warning, not an error.

Besides, In order to programmatically/batch validate without false errors being reported, an option to specify that "the document is an iframe srcdoc document or title information is available from a higher-level protocol" is necessary, then.

This is because the HTML spec states:

> The title element is a required child in most situations, but when a higher-level protocol provides title information, e.g. in the Subject line of an e-mail when HTML is used as an e-mail authoring format, the title element can be omitted.

and consequently the validator currently reports a missing title in an (X)HTML5 document as an error with a note explaining that it actually may not be such under special circumstances:

> XHTML element head is missing a required instance of child element title.
From line 9, column 4; to line 9, column 10
css"/>↩   </head>↩   <b
>
> Content model for element head:
>> If the document is an iframe srcdoc document or if title information is available from a higher-level protocol: Zero or more elements of metadata content, of which no more than one is a title element and no more than one is a base element.
>> Otherwise: One or more elements of metadata content, of which exactly one is a title element and no more than one is a base element.

I report this in the context of validating XHTML5 documents contained in an EPUB3 container, where while the author may have provided a title element for each contained XHTML5 that forms up the book, each one of those usually (but not necessarily nor hinted by the spec) matching a chapter, reading systems (i.e. ereaders) usually do not expose it to the user, and instead either:

1. expose the title of the chapter the document belongs to, as declared by a combination of two external documents: the Package Document (http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-spine-elem) which declares the reading order position of the XHTML5 document inside the ebook (among other things), and the EPUB Navigation Document (http://www.idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-nav-def-types-toc) which declares the title for each chapter in the form of a Table of Contents (among other things).
2. expose the title of the whole book, as declared in the Package Document mentioned above (http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-opf-dctitle).
3. expose no title at all associated to a particular XHTML5 document in an ebook.

Note that the EPUB 3 spec does not mentions in any way what are reading systems to do with the title element in XHTML5 documents inside an ebook, or if they are expected to have one or not at all.