Custom elements and remote resources

[mattgarrish]

Now that we reference the WHATWG HTML spec, custom elements will become valid in EPUB 3.3, which are kind of the nightmare scenario for epubcheck since they aren't evaluated until documents load.

But putting aside the general inability to enforce rules on them, @rdeltour asked in w3c/epubcheck#1288 about their impact on the remote resource rules.

While I believe the underlying requirements remain valid, it's not easy to check how the resources will be used not knowing what the custom element extends or translates to from epubcheck.

So the possible options are:

1. Scrap the explicit restrictions and rely on media type checking and whatever heuristics epubcheck has for determining what are legitimate remote resources
2. Add another bullet that allows any of the four types of exempted resources to be referenced from custom elements

I tend to lean toward the first option for pragmatic reasons -- it's probably what the second is going to force epubcheck to do anyway -- but if we want to keep the current specificity we could go with the second option.

[dauwhe]

I'm a bit wary here. Using custom elements for audio and video, aside from any other issue, is likely to be bad for accessibility. We removed the capability of doing custom audio/video controls from EPUB.

Is there an existing reading system where a custom element with some sort of functionality would actually work?

[mattgarrish]

Using custom elements for audio and video, aside from any other issue, is likely to be bad for accessibility.

I don't know that it would be, since underlying the custom element is either a literal audio/video element or a direct inheritance from those elements.

I haven't experimented with them much, but my understanding is that either the custom element is replaced by the contents of a template element (which would hold straight html), the HTML to render is written via script, or the audio/video element inherits whatever extra functionality the author has defined via the is attribute.

That's why there's a sort-of/almost way of finessing the requirement into custom elements, along the lines that when referenced from a custom element, the resource must still be used as defined in the restrictions. But there's no way to enforce that and I didn't have much luck trying to turn it into a sensible requirement.

Custom elements are well supported in browser cores, so I expect that means reading system support is a mess. 😄

We can't really get rid of them now, though.

[dauwhe]

Custom elements are well supported in browser cores, so I expect that means reading system support is a mess. 😄

Partly true... Safari doesn't support extending native elements with is.

I'm going to try to see if I can get a test working.

[iherman]

We can't really get rid of them now, though.

I think that is the crucial point: custom elements are there to stay. I am wary of creating too much deviation from the HTML standard. On the long term, we should "simply" take HTML as is.

We do have some "discouraged constructs", and we may even add the custom elements to this list (using the same arguments than discouraged embed) but that is just discouraging and not forbidding.

B.t.w., if there are accessibility issues with custom elements, I presume that is an issue for the HTML WG to solve.

[iherman]

The issue was discussed in a meeting on 2021-12-03

List of resolutions:

• Resolution No. 1: Merge PR 1943 and not 1949.
• Resolution No. 2: Close issue 1913 once PR 1943 is merged..

View the transcript

1. Custom elements and remote resources (issue epub-specs#1913)

See github issue epub-specs#1913.

Dave Cramer: first few issues are about remote resources.

See github pull request epub-specs#1949.

See github pull request epub-specs#1943.

Dave Cramer: all of our previous conclusions are complicated by custom elements in HTML.
… mgarrish tries to phrase our existing requirements in a way that fits with custom elements.
… but this makes things impossible for epubcheck, which won't know what is actually there until scripts have run.

Matt Garrish: right, there are 2 PRs, this one tries to find language that still works with our past intent, the other PR more specifically address the existence of custom elements.
… there is really little we can do to check for this, people will try to work around it. It will ultimately be down to RS to decide whether to even support custom elements.

Dave Cramer: i made a test book for this, it worked in Apple and ADE, Kindle previewer failed because it doesn't support js, didn't work in Thorium.

Ivan Herman: what you tested tells me that custom elements are here, it would be foolish of us to try to restrict them. They are part of the element that we have to deal with.
… I'm in favor of the first PR, which removes restrictions. The second PR which tries to keep restrictions is harder to check anyway.

Ivan Herman: +1 to matt.

Matt Garrish: the simpler solution might be just to say that RS should not render remote resources in iframes.

Dave Cramer: worried that people would then work around that by using a custom element to effectively make an iframe.

Matt Garrish: there's more awareness of how to handle that at the RS level than at checking, because you have the DOM.

Brady Duga: when it comes to scripting, it kind of the wild west. It'll be impossible to test whether scripts are being used to do something malicious.
… there's utility to having everything be in the package (interop, archival), and if people don't care about that then there's little we can do.
… our main concern in making these exceptions for resources are for size.
… should the restriction be based on size then.

Ivan Herman: to be clear, custom elements mostly means scripting. As soon as RS allows scripting, any restriction on custom elements is meaningless. The real restriction is on scripting.
… the first PR simplifies that.

Dave Cramer: there are 2 types of custom elements. First inherents from existing HTML element (i.e. "is" attribute). This type doesn't work in webkit, and will probably be limited in epub world..
… this is a can of worms that we can't really do much about.

Proposed resolution: Merge PR 1943 and not 1949. (Wendy Reid)

Dave Cramer: +1.

Ivan Herman: +1.

Ben Schroeter: +1.

Brady Duga: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Masakazu Kitahara: +1.

Charles LaPierre: .

Charles LaPierre: ].

George Kerscher: +1.

Dan Lazin: +1.

Charles LaPierre: +1.

Resolution #1: Merge PR 1943 and not 1949.

Bill Kasdorf: +1.

Proposed resolution: Close issue 1913 once PR 1943 is merged.. (Wendy Reid)

Ben Schroeter: +1.

Brady Duga: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Masakazu Kitahara: +1.

Ivan Herman: +1.

Bill Kasdorf: +1.

Dave Cramer: +1.

Dan Lazin: +1.

Matt Garrish: +1.

Charles LaPierre: +1.

Resolution #2: Close issue 1913 once PR 1943 is merged..

Dave Cramer: I would warn everyone to be wary of custom elements, because it's easy to miss things related to a11y. HTML elements take care of a lot of that thinking for you.

Ivan Herman: that's not really our fight, leave for WHAT WG.

Dan Lazin: we use custom elements quite a bit in my day job, and there are more a11y friendly ways of doing it, but yes, beware.