Andrea Giammarchi

> This would be useful for polyfilling custom elements polyfills for custom elements already work and are either based on MutationObserver or DOMNodeInserted/DOMNodeRemoved with a lookup for registered elements in...

@rniwa what you described looks more like a `blur` related bug (either browser or specs) but I'm happy you found a concrete use case. Another one I have these days...

@smaug you're right, that example is not directly related but it's something I can do already and it's based on MutationObserver. The `onconnected` is just a hint, imagining a list...

Yet another winning case for [built-in extends](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements-customized-builtin-example): ```js customElements.define( 'js-highlighted', class extends HTMLScriptElement { connectedCallback() { console.log('There you go!'); } }, {extends: 'script'} ); // try it document.head.innerHTML = '';...

ShadowDOM you a needed only to sandbox styling or protect the content from undesired access, it’s a specification a part, not something strictly related to custom elements. So with builtin...

worth mentioning, and AFAICT from devtools, Blink itself represents inputs and others through internal Shadow DOM, so I am not sure why only browsers internals should be able to do...

As much as I love the XPath solution, the TreeWalker already has this kind of filtering, right?

Again, the TreeWalker already offers this possibility and more, combining multiple types at once. The whole proposal could be basically just: ```js const getNodesByType = function* (typeValue) { const type...

P.S. the `NodeFilter.SHOW_ALL` value is `-1`, not `0` ... please, let's reuse the already defined platform constants.

How is a native DOM API esoteric, if I might ask? regarding -1 vs 0, is that there are polyfillys on the Web, and usually these stick with standard documentation....