-
Notifications
You must be signed in to change notification settings - Fork 402
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
Add basic support for HTML custom elements #932
Comments
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. 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. |
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.
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. |
Nope, unfortunately EPUBCheck won't catch this. It won't evaluate the JS, so it will only check the "static" HTML documents. |
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. |
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 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). |
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. |
That's still cheating... ;) But if you think it's an easy adaptation, it would be nice to keep pace. |
- add an `isCustomElement` method in `HTMLUtils`. - pre-process custom elements in `XMLParser` to put them in the proprietary namespace used by the Nu Html Checker schemas to treat them distinctively. - add a simple test case. Fix #932
- add an `isCustomElement` method in `HTMLUtils`. - pre-process custom elements in `XMLParser` to put them in the proprietary namespace used by the Nu Html Checker schemas to treat them distinctively. - add a simple test case. Fix #932
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:
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.The text was updated successfully, but these errors were encountered: