New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict epub:type use on HTML header elements #1241
Comments
@Doktorchen raises a good point in w3c/epubcheck#986 that this would create another little backward incompatibility. I think I'd be more in favor of keeping this a note, and educate via best practices guidelines. |
I'd be interested to hear if anyone else has used it in that fashion, though, as it was an attempted workaround for the semantic enrichment attributes. It's not easily accomplished by the average author. There also aren't any semantics in the structural vocabulary for use in the header, and I can't confess to having seen any extensions of the vocabulary beyond a few attempts to integrate the richer Z39.98 vocabulary. Given the existing advice that you do it knowing it will result in nothing on the reading system end, adding a warning not to use seems more beneficial than harmful. |
If only we had access to usage data… 😁 |
Because book stores and distributors rely on epubcheck messages, this can result. I know of a view books already in stores using it, but my guess is, it is not often used. Usually many staff members of those stores or distributors do not really know, what they are doing. Without a new version number for EPUB such an incompatible changes is just a waste of time for authors and staff members of those shops or distributors. The initial drafts for the HTML:role attribute was closely aligned to the RDFa property, but the meaning changed over time to represent only ARIA, therefore not of much use for authors, producing only accessible documents right from the start. Ok, the XHTML:head element has not much substructure, but of course, it content can have semantic meaning, that is not sufficiently defined by HTML5, therefore additional attributes indicating the semantic meaning are relevant. For example Mozilla/Gecko or Pale Moon/Goanna expose meta data from the XHTML:head on demand. Extensions for them (Lucifox, EPUBReader 1.x) therefore expose this in the same way. |
And that's exactly why there is a distinction in EPUB between semantic inflection - done by epub:type - and semantic enrichment - done by RDFa and microdata. The mechanisms aren't interchangeable. |
I still think, it fits. http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-xhtml-semantic-markup : And of course, if EPUB 3.0 had allowed RDFa right from the start, epubcheck never reported errors about RDFa in books or even RDF containers both in SVG:metadata and in HTML5:head (what is ok according to HTML5 in the XML serialization: https://www.w3.org/TR/html5/dom.html#metadata-content-2 ), there would have never been a need to use OPS:type at all here or in other places in a document. And correction: Because metadata from other namespaces is allowed within HTML5:head |
There is no data model associated with the attribute; you don't create triples from it. It doesn't make any statement about the value of the carrying element. You want things to be true that simply aren't. |
The meta element itself creates already the triple by design. This applies as well for HTML5 does not define the meaning of the name value here. |
And the epub:type attribute does absolutely nothing, as it has no bearing on this model. It wasn't designed for this use in EPUB, and is entirely unrecognized for it, just as it is by HTML user agents. It was not added as an alternative to either RDFa or microdata. The only reason those weren't also in the initial 3.0 release is because, at that time, it wasn't clear what their futures were. It wasn't until 3.0.1 that we could reasonably reference them with some surety that we weren't going to be left with a dead technology (or two). As I've already mentioned, epub:type was designed to be a more flexible version of ARIA Even where it is allowed for use, if you were to try and coax a triple out of it, the semantic would be the object and the element that carries it the subject. A section is a chapter. An aside is a footnote. It is to more finely describe the structural roles elements play. Metadata describes aspects of the document; it doesn't define the structure. |
Can we restrict epub:type to flow elements? We might have to add |
As we decided to leave this be for now, how about we change this paragraph in the introduction:
to be a little more reflective of the reality of the attribute. So maybe:
|
@mattgarrish I feel a bit hesitant with your proposal. It is not completely true as some Reading System do provide interesting behavior based on epub:type. As foot-note popup. |
Indeed. But it was some sort of a brainstorming only, and nobody carried the torch since then (alas!, I would say). |
@iherman where is the torch, I will carry it ! |
The torch still has to be lit... One way, maybe, is to raise this issue on WCIG. It should be made clear that several communities need something like that (reaching out to the folks we were discussing this with at TPAC) not only a Web compatible version of EPUB/WPUB, that there should be some structure on how values to the attribute can/should be defined (some sort of a process is necessary to make this attribute fit the validator, for example), etc. But this goes probably beyond EPUB3, ie, should be discussed elsewhere... |
What I wrote doesn't kill anything, only acknowledges that the attribute has little real value outside of publisher workflows. We're almost ten years into EPUB 3 and all we have are a few undocumented implementations of pop-up footnotes. If it's not helping you internally, I think it's time to add some honesty that you're adding the semantics for no specific purpose. |
@mattgarrish not only does it serve better UX in some Reading Systems, but it also allows mapping to role attribute for accessibility. |
You're describing an internal workflow issue; it does nothing by itself. There were two primary reasons why we added epub:type in 2010: 1) was to allow for publishing semantics so epub 3 could be used in internal workflows in place of xml grammars; and 2) the idea that it would allow for accessibility without publishers having to do anything more. The latter has proved illusory, as none of the work was done to map the semantics to ARIA, or to ensure that they were applied logically, or to get every AT to support a brand new attribute. That only leaves the publisher workflow purpose. But what about the modified paragraph suggests there isn't any value for internal workflows, or to having the attribute? My point is that that is exactly where it is the most useful, not to the average author. We also know that reading systems are not stampeding to add behaviours based on the attribute, so saying that they
is just a reflection of reality. |
My feeling is that your second paragraph is too restrictive. |
The main applications I can see: if used inside the body element: At the beginning of this attribute it might have helped to provide a default stylesheet for books including styling for these attribute values to get a better adoption, because if it becomes visible for the average author, some really use it and developers of user-agents only have to copy the default stylesheet to get it implemented ;o) |
We're not going to add restrictions to epub:type. But as Matt mentioned, we have one single instance where it changes reading system behavior in the entire history of EPUB3. I see so many people putting so much thought and effort into epub:type, when that effort would be better spent on ensuring that HTML elements are being used correctly. I fully support adding Matt's proposed language to the spec. |
@dauwhe thanks. But why EPUBs should necessary loose all that semantic? |
I don't follow this assertion. Nobody has said we're getting rid of the attribute. The revised wording doesn't exclude a reading system from using the attribute or from providing behaviours. All it does is point out: a) that any behaviours are not standardized; and b) most semantics don't actually do anything. Leaving aside the specialized uses, which is not what the epub:type definition in content documents is about, all we're really doing is warning people not to expect any magic. The reality is that unless you have some purpose in mind that you can implement, layering your document with semantics is not adding much value in reading systems. That's not the same thing as saying the attribute has no value to anyone. But what if we tweak the first sentence slightly to make this clearer and then maybe we don't have to get into the poor support issue:
|
@mattgarrish thanks for the tweaking.
|
Closed via #1252 |
Per the specification, the attribute has to be ignored if used in the header:
But it's not clear why the attribute is allowed there at all. Also per the specification:
But what possible structural subclasses are there for header elements, as they aren't even exposed?
The attribute was originally modelled on ARIA role which is also technically allowed anywhere but is functionally restricted from use in the header because header elements have no explicit roles.
Allowing the attribute in the header only has the potential to confuse its use with semantic enrichment techniques like RDFa and microdata (or with native attributes).
It would probably be best just to make clear there are no applications for the attribute in the header and disallow it.
The text was updated successfully, but these errors were encountered: