HTML Custom Elements Polyfill
npm install @onsenui/custom-elementsA polyfill for the custom elements
v1 spec.
Include custom-elements.min.js at the beginning of your page, before any code that
manipulates the DOM:
``html`
1. Install and build
``
npm install
npm run build
npm i && gulp
(Or, , if gulp is installed globally.)
1. Test
``
npm run test
wct
(Or, , if installed
globally.)
API which might trigger custom element reactions in the DOM
and HTML specifications are marked with the
CEReactions extended attribute.
- adoptedCallback is not supported.CEReactions
- Changing an attribute of a customizable (but uncustomized) element will not
cause that element to upgrade.
- Only DOM API is patched. Notably, this excludes API from the HTML spec marked
with the extended attribute.Element
- Unpatched API from the DOM spec:
- Setters on for id, className, and slot.DOMTokenList
- (element.classList)NamedNodeMap
- (element.attributes)Attr
- (element.attributes.getNamedItem('attr-name'))new
- The custom element reactions stack
is not implemented.
- Typically, DOM operations patched in this polyfill gather the list of
elements to which a given callback would apply and then iterate that list,
calling the callback on each element. This mechanism breaks down if an
element's callback performs another DOM operation that manipulates an area
of the tree that was captured in the outer operation's list of elements.
When this happens, the callbacks from the inner DOM operation will be called
before those of the outer DOM operation (typically, depending on the patch
implementation), as opposed to a spec-compliant implementation where the
callbacks are always run in the order they were inserted into each
particular element's reaction queue.
- Custom elements created by the UA's parser are customized as if they were
upgraded, rather than constructed.
- These elements are only learned about after they have been constructed,
and typically after their descendants have been constructed. When these
elements are constructed, their children are visible and editable *even
though they would not yet exist and manipulating them would throw in a
spec-compliant implementation of custom elements!*
- The requirements for custom element constructors
are not enforced.
- These requirements are not generally enforcable in user script because of
the ability to use the operator on a custom element constructor. ThisParentNode
means there is no way to know when a call to a constructor has begun or
finished.
- Methods of the and ChildNode interfaces do not supportDocumentFragment
s as arguments.constructor
- Your custom element constructor's prototype must have a property named
which is that constructor.F
- By default, for every constructable function , F.prototype.constructor === F.F
If you replace the prototype of your constructor , you must make sureF.prototype.constructor === F
that remains true. Otherwise, the polyfill
will not be able to create or upgrade your custom elements.
The custom elements v1 spec is not compatible with ES5 style classes. This means
ES2015 code compiled to ES5 will not work with a native implementation of Custom
Elements.[0] While it's possible to force the custom elements polyfill to be
used to workaround this issue (by setting (customElements.forcePolyfill = true;
before loading the polyfill), you will not be using the UA's native
implementation in that case.
Since this is not ideal, we've provided an alternative:
native-shim.js.
Loading this shim minimally augments the native implementation to be compatible
with ES5 code. We are also working on some future refinements to this approach
that will improve the implementation and automatically detect if it's needed.
[0] The spec requires that an element call the HTMLElement constructor.HTMLElement.call(this)
Typically an ES5 style class would do something like tosuper()
emulate . However, HTMLElement must be called as a constructor andReflect.construct(HTMLElement, [], MyCEConstructor)
not as a plain function, i.e. with ,
or it will throw.
By default, the polyfill uses a MutationObserver to learn about and upgradeMutationObserver
elements in the main document as they are parsed. This isdocument
attached to synchronously when the script is run.MutationObserver
- If you attach a earlier before loading the polyfill, that
mutation observer will not see upgraded custom elements.
- If you move a node with descendants that have not yet been inserted by the
parser out of the main document, those nodes will not be noticed or upgraded
(until another action would trigger an upgrade).
Note: Using polyfillWrapFlushCallback disconnects this MutationObserver.
tl;dr: The polyfill gets slower as the size of your page and number of custom
element definitons increases. You can use polyfillWrapFlushCallback to prevent
redundant work.
To avoid a potential memory leak, the polyfill does not maintain a list of upgrade
candidates. This means that calling customElements.define causes a synchronous,localName
full-document walk to search for elements with s matching the newCustomElementRegistry
definition. Given that this operation is potentially expensive and, if your page
loads many custom element definitions before using any of them, highly redundant,
an extra method is added to the prototype -polyfillWrapFlushCallback.
polyfillWrapFlushCallback allows you to block the synchronous, full-documentdefine
upgrade attempts made when calling and perform them later. CallpolyfillWrapFlushCallback with a function; the next time customElements.define
is called and a full-document upgrade would happen, your function will be called
instead. The only argument to your function is another function which, when
called, will run the full-document upgrade attempt.
For example, if you wanted to delay upgrades until the document's ready state
was 'complete', you could use the following:
`javascript`
customElements.polyfillWrapFlushCallback(function(flush) {
if (document.readyState === 'complete') {
// If the document is already complete, flush synchronously.
flush();
} else {
// Otherwise, wait until it is complete.
document.addEventListener('readystatechange', function() {
if (document.readyState === 'complete') {
flush();
}
});
}
});
Once your wrapper function is called (because the polyfill wants to upgrade the
document), it will not be called again until you have triggered the
full-document upgrade attempt. If multiple definitions are registered before you
trigger upgrades, all of those definitions will apply when you trigger upgrades -
don't call the provided function multiple times.
Promises returned by customElements.whenDefined will not resolve until a
full-document upgrade attempt has been performed after the given local name
has been defined.
`javascript
let flush;
customElements.polyfillWrapFlushCallback(f => flush = f);
const p = customElements.whenDefined('c-e', () => console.log('c-e defined'));
customElements.define('c-e', class extends HTMLElement {});
// p is not yet resolved; flush is now a function.
flush(); // Resolves p.`
You can't remove a callback given to polyfillWrapFlushCallback. If thedocument.readyState
condition your callback was intended to wait on is no longer important, your
callback should call the given function synchronously. (See the example above.)
**Calling polyfillWrapFlushCallback disconnects the MutationObserver watchingdocument.readyState !== 'loading'
the main document.** This means that you must delay until at least to be sure that all elements in the main
document are found (subject to exceptions mentioned in the section above).
You can call polyfillWrapFlushCallback multiple times, each function given
will automatically wrap and delay any previous wrappers:
`javascript
customElements.polyfillWrapFlushCallback(function(flush) {
console.log('added first');
flush();
});
customElements.polyfillWrapFlushCallback(function(flush) {
console.log('added second');
setTimeout(() => flush(), 1000);
});
customElements.define('c-e', class extends HTMLElement {});
// 'added second'
// ~1s delay
// 'added first'
// The document is walked to attempt upgrades.
``