Restore the custom attribute sections

[mattgarrish]

Also adds @iherman's suggested text about rs-specific nature of the attributes. I've made this a note, though, as it's more describing future process.

Only other change was to use "domain" instead of "authority component" in the part about the restricted strings so we can reference the URL standard instead of RFC3186.

Fixes #1602

• Reading Systems preview
• Reading Systems diff

---

Preview | Diff

[iherman]

I just wonder whether, for reasons of symmetry, we should not make a similar section (or factor out a common section) for SVG, too. After all, an RS may decide to have a RS-specific attribute in SVG content, too.

(I realize this is probably a technical purity issue of the spec rather than reflecting real usage out there, so I am o.k. if you decide to ignore this...)

[mattgarrish]

After all, an RS may decide to have a RS-specific attribute in SVG content, too.

We don't have this issue with SVG: https://www.w3.org/TR/SVG2/struct.html#ForeignNamespaces

HTML is more restrictive, so we had to explicitly allow foreign attributes.

[mattgarrish]

I guess we should wait on a formal WG nod before merging this one, since it's undoing an earlier resolution.

[dauwhe]

I think we should be more clear about what a custom attribute is (it's not quite a standard term in HTML). As far as I can tell, what EPUB has historically allowed is attributes in namespaces other than xhtml or epub. Just adding a foo attribute won't validate.

[iherman]

I think we should be more clear about what a custom attribute is (it's not quite a standard term in HTML). As far as I can tell, what EPUB has historically allowed is attributes in namespaces other than xhtml or epub. Just adding a foo attribute won't validate.

The proposed text says:

To facilitate this experimentation, vendors MAY define custom attributes for use in XHTML Content Documents provided they are from a foreign namespace, which is defined as a namespace [ XML-NAMES ] that does not incorporate either of the following strings in its domain [ URL ]:

• w3.org
• idpf.org

For me, that makes it explicit that just foo won't be acceptable because it would not be in a foreign namespace.

[dauwhe]

Ah, I guess I hope there would be some explanation about the namespaces in the authoring spec as well as the reading system spec. I fear content authors will see this as a license to use <p foo="bar"> and will then wonder why it fails EPUBCheck.

[iherman]

The issue was discussed in a meeting on 2021-08-13

List of resolutions:

• Resolution No. 2: Merge PR 1756

View the transcript

3. Custom Attributes

See github pull request #1756.

Dave Cramer: we took out the custom attributes section, but it turns out there are RS that use these
… so now we want to put it back

Dan Lazin: can we get some documentation on what exists in terms of custom attributes? So people can make use of them in their books?

Dave Cramer: we can see about including some examples

Proposed resolution: Merge PR 1756 (Wendy Reid)

Dave Cramer: +1

Wendy Reid: +1

Dan Lazin: +1

Matthew Chan: +1

Ivan Herman: +1

Charles LaPierre: +1

Ben Schroeter: +1

Brady Duga: +1

Masakazu Kitahara: +1

Resolution #2: Merge PR 1756

Dave Cramer: okay, thanks everyone!

---

[iherman]

Ah, I guess I hope there would be some explanation about the namespaces in the authoring spec as well as the reading system spec. I fear content authors will see this as a license to use <p foo="bar"> and will then wonder why it fails EPUBCheck.

@dauwhe I do not think the normative statements should be changed. But I have added an extra note right after the list of domains, as follows:

Note that this restriction also disallows the usage of custom attributes without a namespace prefix
(e.g., <p foo="">…</p>). Indeed, such attributes are considered to be part of
the default namespace, i.e., either the XHTML or SVG namespaces, which are both in the w3.org domain.

[iherman]

@dauwhe are you o.k. with #1756 (comment)? We could then close this PR