#244: HTML General Review: Custom Elements

Visit on Github.

Opened Apr 17, 2018

Hello TAG！

This issue is part of the TAG's larger effort to review the HTML spec in its entirety--please see the original issue https://github.com/w3ctag/design-reviews/issues/174 for a summary of all the break-out issues.

The "Sections" are all the sections of the WHATWG HTML spec that should be reviewed as part of this issue. Where the spec section has associated Web Platform Tests, the specific WPT path is noted. While the primary focus of the review is the specification text, it can be helpful to review the related tests to help clarify algorithms or see interoperability conformance issues (or find issues with the tests).

The "Features" are just a sample of what you will encounter as part of this spec section, it's not meant to be exhaustive.

Here are some example suggestions for what to look for during the review, but don't limit to only these suggestions!

  • Look for any APIs that could be 'modernized' according to current design practices.
  • Look for things that could require permissions that aren't modelled in the permissions API at the moment.
  • Look for areas of the platform that contain UA 'magic' (aren't possible for JavaScript programs to emulate due to missing primitives in the platform). These are candidates for future Extensible Web archeology.
  • Look for areas of the spec that describe "wishful thinking" (e.g., that describe a feature that is implemented by no one). Such features should at least have implementor commitments, or they might be candidates for removal from the spec.
  • Look for cryptic and hard-to-follow algorithms that could be improved with extra explanatory text or improved prose. E.g., sometimes adding a "developer note" (green box) can add the needed clarity to understand the intent/purpose or outcome of a complex concept.
  • Look for concepts that are meant to be used together, but where this is not spelled out or explained clearly
Sections WPT path Features
3.2.3 custom-elements/htmlconstructor
4.13 custom-elements <my-element>

Please provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

2018-08-21

Minutes

KC: It's shipping... Some feedback around the term callback suffix on all the APIs.

AR: Additional areas of feedback:

  • Lack of integration with forms (prevents ability to have custom input type)--we can encourage them to address this in the future.
  • Synchronous upgrades
  • Sub-registries - large apps would like to scope custom-elements to certain parts of the tree.

PL: Q from chaals about what attribute names should be valid for CE?

DB: WHATWG and W3C specs disagree.

AR: How do they differ?

DB: particular attribute names.

SM: Might be WHATWG has restriction on what names are allowed, but implementations don't follow that? (W3C doesn't have the restriction?)

AR: I wouldn't use CE if I had to prefix. Yuck. CE authors define their attributes locally (to the element).

TL: Is there a conflict with a future "custom attribute"?

AR: Potential issue is whether some new global attribute creates a new processing model for something that wasn't defined before.

PL: Imagine a new 'class' or 'id' global attribute that gets introduced later... the system for processing this might override or have a side effect that is unexpected. Only safe path here is to prefix custom element's attributes.

AR: ...or you have to exembpt custom elements from the processing logic.

PL: like providing a way for the system to query for a custom attribute without conflict.

AR: or have a way of opt-ing the attributes in/out of the global processing. We probably can't have a opt-in, but maybe and opt-out?

AR: Prefixing is a pain and probably web-incompatible at this point. So, we can't recommend this, but we can recommend a way to add defensiveness to the custom-element iatnstead.