Repository navigation
"head" elements semantics? #2377
Description
The RS specification says, in §6.1.1.2
In addition to the requirements in 10. Processing structural semantics, a reading system MUST ignore semantics expressed on the [html] head element or its descendants.
I am not sure what this requirement aims to achieve. The Structural Semantics section in the RS contains MAY statements, it is a bit strange to restrict the HTML standard with such an optional set of statements. Also, this seems to suggest that, for example, the <title> element in the <head> must be ignored, which becomes very convoluted for an RS running in a browser. Finally, an alternative to semantics described by RDFa is to add a datablock (using a <script> element in the head) containing RDF metadata in JSON-LD (this is one of the proposed approaches to add schema.org metadata to an HTML file), and this restriction seems to disallow this for EPUB.
My proposal is to remove that section altogether.
Activity
OriKuttner commentedon Jul 28, 2022
mattgarrish commentedon Jul 28, 2022
How so? The section is about the
epub:typeattribute. If you express it on atitle, then whatever semantic you put on it must be ignored, not the title itself.The head element doesn't contain structural markup, only metadata, so it makes no sense to allow
epub:typeexpressions on its elements.We could probably try to generalize it and move it into section 10, though, since it's not exclusive to HTML. Maybe add a fourth bullet like:
mattgarrish commentedon Jul 28, 2022
No, reading systems are not expected to ignore it. Reading systems apps typically won't announce it, but browser-based reading systems usually load the content documents in iframes so the title does get announced.
If there isn't a title, that means AT users get a file name or some other weirdness announced to them. It's the same reason HTML requires a title. The exception is only when the title is provided by a higher-level protocol, but that doesn't exist for EPUBs.
iherman commentedon Jul 28, 2022
Ah. I think I know where things went wrong in my understanding. If I read
my mind switched to the HTML spec and was looking at the semantics that are expressed by bona fide HTML elements like
<meta>,<script type="application/ld+json">or indeed<title>. And if I take it this way, one could deduce that, indeed, the<title>element should be ignored. Which is of course not what was meant. I believe what was meant is that anepub:typeattribute on aheadelement and its descendants is disallowed and the RS must ignore it.I believe we should make modifications on the specs to avoid misunderstandings:
epub:typeshould make it clear that this attribute MUST NOT be used on the<head>element and its descendants. Currently, it is defined as a Global attribute which says that it can be specified on all HTML elements. I am not sure how to accommodate with the SMIL head element there.WDYT?
(I still do not know how I would test this. Is there an observable effect of epub:type in AT land?)
mattgarrish commentedon Jul 28, 2022
No, most header info isn't rendered anyway, let alone done in some meaningful way with semantics, so there's no way to prove whether the epub:type is being ignored or not.
The restriction was put in to stop people from treating epub:type like a metadata expression mechanism. There were people asking to be able to express authors using epub:type, for example, but that's not structural information.
For reading systems, it's probably enough to say that they should ignore semantics expressed on non-structural elements if that avoids a test. It's not like we're opening the door to anything nefarious given how widely the semantics are ignored anyway.
iherman commentedon Jul 28, 2022
But this should be clearly stated in the content spec as well, not only in the RS.
mattgarrish commentedon Jul 28, 2022
Right, it sounded like you agreed that a restriction in s. 10 would be better than having the html section. I don't think the authoring and RS requirements have to exactly match, though. We can tell authors they must not do it while only recommending RSes ignore them. I'm sure we have similar statements elsewhere.
iherman commentedon Jul 28, 2022
@mattgarrish I just try to avoid parallel work? It sounds like you have some ideas to handle #2378, do you want me to take a stab against this one?
iherman commentedon Jul 28, 2022
Trying to find a precise categorization of the restriction in terms of the HTML spec goes. Would it be fair to say that (in the content document) that
That would exclude
head,meta,link,title,script,style(ie, would cover the head and its descendants) but it would also exclude things liketemplate, and probably others which are not really relevant. We could then put this into the content document spec (let epubcheck deal with it:-), remove subsection from the html section, and extend §10.mattgarrish commentedon Jul 28, 2022
Sorry, I was all over the map this morning. If you're going to break down where it's allowed, then that probably makes the most sense for HTML. SVG is going to be the weird case to define.
Looks like media overlays never made it a global attribute, and there is no defined metadata.
I see you've already got a pull request open, so I'll take a look at it when I have a minute.