Add basic support for HTML custom elements

[JayPanoz]

Hi,

Out of curiosity, I’ve been playing with custom elements v1 a little bit (so this is the HTML spec). Support isn’t necessarily bad in real life and well, although I’m not advising anyone to use that in production, I could probably see workflow/internal use cases – especially as an app that is using a WebView that supports that, supports that.

So I’m wondering… is this something epubcheck has to align with? I am currently getting the following error:

ERROR | RSC-005 | /OEBPS/Text/002_otf.xhtml (line 19, col 12) | Error while parsing file 'element "dink-us" not allowed here; expected the element end-tag, text or element "a", "abbr", "address", "area", "article", "aside", "audio", "b", "bdi", "bdo", "blockquote", "br", "button", "canvas", "cite", "code", "command", "datalist", "del", "details", "dfn", "div", "dl", "em", "embed", "epub:switch", "epub:trigger", "fieldset", "figure", "footer", "form", "h1", "h2", "h3", "h4", "h5", "h6", "header", "hgroup", "hr", "i", "iframe", "img", "input", "ins", "kbd", "keygen", "label", "link", "main", "map", "mark", "menu", "meta", "meter", "nav", "ns1:math", "ns2:svg", "object", "ol", "output", "p", "pre", "progress", "q", "ruby", "s", "samp", "script", "section", "select", "small", "span", "strong", "style", "sub", "sup", "table", "textarea", "time", "u", "ul", "var", "video" or "wbr" (with xmlns:ns1="http://www.w3.org/1998/Math/MathML" xmlns:ns2="http://www.w3.org/2000/svg")'.

It is my understanding this could be more of a parsing error, probably because of the dash, but I could be wrong.

On a related note, you can add contents and attributes with connectedCallback() (cf. this demo for instance) so I’m not sure how you can handle that if you don’t check for markup added with JS already – sorry, didn’t bother to try that.

[rdeltour]

With EPUB 3.2 now pointing to the "unversioned" (i.e. latest) reference to W3C’s HTML spec, yes custom elements should totally be allowed.

That they are rejected in the latest version of EPUBCheck (v4.1.0 as we speak) is not a surprise, given that the HTML schemas have not been updated in a while. You'll see that other "recent" HTML elements (e.g. picture) are not supported either.

We're in the process of fixing this for v4.2.0, which will be the first version to support EPUB 3.2. See also #892.

[JayPanoz]

Thanks for the answer.

Out of curiosity again, cf. last paragraph of my OP, what happens if an author screws XHTML markup in JS? e.g.

this.innerHTML = `<p>bla bla bla`;
this.innerHTML = `<b>bla bla bla<b>`;
this.innerHTML = `<video controls>…</video>`;
etc.

Is this even something epubcheck catches? And if not, is this even in its scope?*

* will raise an error in the browser anyway but hey, last-minute changes + bad days happen.

[rdeltour]

what happens if an author screws XHTML markup in JS?
Is this even something epubcheck catches?

Nope, unfortunately EPUBCheck won't catch this. It won't evaluate the JS, so it will only check the "static" HTML documents.

[mattgarrish]

In regards to this issue, we don't inherit support for custom elements from the NU schemas, so this might be a problem to leave until we fully integrate. (It's also not "officially" arriving until HTML 5.3 becomes a recommendation, although hopefully one day soon we'll get out of this dueling specs conundrum.)

If we wanted to "rough-in" support, though, the hack would be to allow any lowercase element names so long as they have a hyphen (namespace) - minus a few restricted names. The specific construction rules are defined here: https://www.w3.org/TR/html53/semantics-scripting.html#requirement-for-all-custom-elements

I don't see how we could pull this off with relaxng alone, though. The only thing that springs to mind would be to intercept errors about elements not being allowed and suppress them if the element being reported matches the custom element name pattern...

I can't think of another approach that wouldn't make a total mess of the validation reports, at any rate.

Given the generally limited JS validation we do, I'm not sure how much we could do, or would want to try, in terms of ensuring the elements have been wired up properly. I believe there always needs to be a customElement.define call for each element, but hunting those down might only lead to false reports of problems.

[rdeltour]

Thanks for looking into this @mattgarrish.

I had a further look at how validator.nu handles this, and in fact they do support custom elements via their RelaxNG schema: they associate custom elements to a proprietary namespace at parsing time with a custom SAX handler, which allows to handle these elements as part of their own name class in the web-components.rnc RelaxNG schema.

Since we're using the same schemas, we could possibly use the same parse-time trick to assign this proprietary namespace to custom elements. I'll try and see if this is easily doable, which would get us a reasonable level of support already! (i.e. EPUBCheck would not choke on custom elements).

[JayPanoz]

So yeah this is part of the “webthing webthing extensible” and I can confirm JS + CSS could become pretty tricky to handle in the longer term.

If you take a look at CSS only, you’ll find yourself with user-agent properties, CSS extensions and Houdini.

Wouldn’t say this is short term but more of a foreseeable future. I’m not expecting EPUB authors to use such options in the say 5 next years, but I’ve been keeping an eye on this just in case some did for ReadiumCSS and I thought it was also worth mentioning to others impacted, like you.

[mattgarrish]

they associate custom elements to a proprietary namespace at parsing time

That's still cheating... ;)

But if you think it's an easy adaptation, it would be nice to keep pace.