custom name of a customized built-in element is unreachable

[gullerya]

Use-case:
Framework working on DOM elements needs to process undefined custom elements only when defined.
For the regular custom element it is simple:

if (!element.matches(':defined') {
    customElements.whenDefined(element.localName).then(() => { ... do something ... });
}

But for customized built-in element this is not possible, since element.localName is just a standard DOM element's name and there is no way right now to reach the extended name provided in is property:

let element  = document.createElement('input', { is: 'custom-input' });
//   value of 'is' goes into internals and 'custom-input' becomes not reachable anymore

BTW, when the same element is being added as below, is handled as an attribute and is reachable:

someElement.innerHTML += '<input is="custom-input"/>';
someElement.firstChild.attributes.length === 1;                     // true
someElement.firstChild.getAttribute('is') === 'custom-input';       // true

Proposal:

• when customized built-in element is created programmatively, preserve is value as an attribute in a symmetric to HTMLish syntax. As proposed by someone (see refs below) it should probably be readonly IDL attribute
• unify behavior of is to be the same either provided from createElement JS API or coming from HTML's attribute

Appendix:

• relevant SO thread: https://stackoverflow.com/questions/39196503/how-to-wait-for-custom-element-reference-to-be-upgraded/52420195#52420195
• relevant Chromium issue: https://bugs.chromium.org/p/chromium/issues/detail?id=886991&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

[annevk]

I proposed this in #3402 (comment) but we didn't have a concrete use case then.

cc @whatwg/components

[gullerya]

Read through the thread, having is getter would give an answer, from my POV,
Thanks.

[mfreed7]

I just found this issue and asymmetry with the "is" content attribute. It causes issues when trying to use selectors. See this simple example (taken from actual production code) - the desire is to be able to style (from light DOM) elements of the customized type only:

<style>
p[is="my-p"] { background-color: green; }
p:not([is="my-p"]) { background-color: red; }
</style>

<p is="my-p">This retains the "is" attribute</p>

<script>
customElements.define('my-p',class extends HTMLParagraphElement {}, {extends: 'p'});
const foo = document.createElement('p', {is:'my-p'});
foo.appendChild(document.createTextNode('This does NOT retain the "is" attribute'));
document.body.appendChild(foo);
</script>

Is there a recommended better way to do this? It can obviously be overcome pretty easily like this:

const foo = document.createElement('p', {is:'my-p'});
foo.setAttribute('is', 'my-p');

but that seems very hacky, given the declarative version doesn't need this, and the imperative version serializes as <p is="my-p">.

[annevk]

There's not I think, but with Safari not willing to add is I'm not sure how comfortable I am with further entrenching it.

[gullerya]

I must say that since that time as till now I've completely abandoned support for a customized built-ins due to both, a seemingly not-yet-well-baked spec as well as quite a strong objection of WebKit guys to provide that part.
So in essence - same as @annevk I'd refrain from any investment around this as of now.