Repository navigation
Spec recommends documenting custom attributes, but zero documented in 5 years #1602
Description
https://w3c.github.io/epub-specs/epub33/rs/#sec-xhtml-custom-attributes says: To facilitate interoperability of custom attributes across Reading Systems, vendors are strongly encouraged to document any extensions they implement in [AttributeExtensions].
That links to https://idpf.github.io/epub-extensions/attributes/, dated October 2016, which says No custom attributes have been defined at this time.
I think we should either document all known custom attributes (on behalf of the vendors), or should remove this recommendation. In the current form it's a frustrating experience and looks embarrassing.
Activity
mattgarrish commentedon Apr 2, 2021
The registries are still to be figured out in W3C, but dropping this one is high on my wish list. We added the ability to define custom attributes for a specific vendor and then I don't believe they ever used them.
I'd love to abandon the other two registries, too, as it's highly unlikely we're also ever returning to custom publication or collection types. We can leave informative links to them but indicate they are no longer maintained.
dlazin commentedon Apr 2, 2021
For archaeology / others' reference, what are the other registries?
mattgarrish commentedon Apr 2, 2021
The role registry is at http://www.idpf.org/epub/registries/roles
The role registry should be referenced in the RS spec but it looks like the reference was left behind when the collection element requirements were pulled out. (Don't hesitate to note anything that lacks context to you as the RS spec is a new creation ripped from the authoring requirements.)
The publication types are at http://www.idpf.org/epub/vocab/package/types
I don't believe there any requirements for reading systems related to these. At the time we were creating various extensions we were using
dc:typeto identify them.iherman commentedon Apr 16, 2021
The issue was discussed in a meeting on 2021-04-15
List of resolutions:
View the transcript
3. Getting rid of registries
See github issue #1602.
Dave Cramer: we said that vendors may define custom attributes, and then we setup a custom registry to track these
… HTML has quite a few ways for users to add attributes
… it seems to me a that it would be a great benefit to remove something that was never used, and which takes as further from HTML
Dan Lazin: why would this be bad for HTML?
Dave Cramer: name space attributes create issues for us in future because we can't use them in HTML serialization
Dan Lazin: so proposal here is to remove entire section on custom attributes?
Dave Cramer: yes
Dan Lazin: for clarity, when I reported that as bug, I thought that vendors WERE using this, but just not reporting into the registry
Dave Cramer: no, don't think that is the case
mattgarrish commentedon Jul 8, 2021
Re-opening this issue because even though our registry was a bust, I think removing the ability to use custom attributes may have gone a step too far. Apple, for example, allows the use of ibooks:* attributes for controlling certain read aloud functionality. See https://help.apple.com/itc/booksassetguide/en.lproj/static.html#apd8044f072d5c54
iherman commentedon Jul 8, 2021
You're right.
Looking at the text of the defunct subsection (in an earlier version of the draft spec) we could indeed, without any harm, keep that text except for the note that triggered this issue. It would then make sense that using custom attributes that are not aimed at any interoperability; it is shamelessly aimed at the requirements and usage of a specific RS.
A (distant) analogy is the HTML data attribute, whose spec includes:
maybe we could be inspired by this and reinstate the defunct section without the note and, instead, add something like:
WDYT?
mattgarrish commentedon Jul 9, 2021
That's fine with me, but I'd maybe skip on the microdata part. If all reading systems are supposed to use an extension, it should be defined in the spec. Maybe it means using microdata, but not separately from a formal definition.
iherman commentedon Jul 9, 2021
Agree to skip microdata.