1475332 - Custom Elements Builtins w/out is=""

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect, P2)

Description

[Andrea Giammarchi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15

Steps to reproduce:

class MyDiv extends HTMLDivElement {}
customElements.define('my-div', MyDiv, {extends: 'div'});

console.log((document.body.appendChild(
  document.createElement('div', {is: 'my-div'})
)).outerHTML);

console.log((document.body.appendChild(
  new MyDiv
)).outerHTML);


Actual results:

In Firefox and Firefox Nightly the procedural way shows the attribute but the `new MyDiv` doesn't.

<div is="my-div"></div>
<div></div>

This is very bad for features detection/polyfills purposes.


Expected results:

In Chrome 67+ that produces:

<div is="my-div"></div>
<div is="my-div"></div>

Comment 1

[Andrea Giammarchi]

> This is very bad for features detection/polyfills purposes.

That is actually very bad for CSS [is="my-div"] too.

Please normalize the behavior with regular classes too or it's impossible to understand if FF can actually use builtins inherited classes.

Thank you.

Comment 2

[Kanchan Kumari QA]

I could reproduce this issue on 
User Agent     Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0

I am placing this under Core:DOM so someone from this team can look into this and provide you proper info. Thanks!

Comment 3

[Andrea Giammarchi]

Thanks a lot Kanchan, apologies for not having chosen the right team right away but I do hope this gets some priority before Custom Elements will ever ship without the flag or it'll potentially break the Web (or worse, polyfills will keep patching Firefox unable to understand if it's a capable browser).

I'm the author of the document-register-element polyfill used also by Google AMPHTML Project so please don't hesitate to ask me more r ping me again if needed.

Best Regards

Comment 4

[Andrew Overholt [:overholt]]

Edgar said he'd take a look. Thanks for the report, Andrea.

Comment 5

[Edgar Chen [:edgar]]

Bug 1440382 should cover this issue. Kanchan, could you try recent nightly? Thank you.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Creating elements using JS should not add 'is' attribute.
Looks like Chrome is doing wrong here.

Comment 7

[Andrea Giammarchi]

(In reply to Olli Pettay [:smaug] (vacation Jul 15->) from comment #6)
> Creating elements using JS should not add 'is' attribute.
> Looks like Chrome is doing wrong here.

that makes no sense. How is CSS based on `[is="my-component"]` going to work with procedurally created nodes?

and why wouldn't developer be able to easily inspect nodes appended through `new MyComponent` ?

if this is a bug, it looks more like a specifications one, not a Chrome one, IMO, wouldn't you agree?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

If you think the spec should be changed (back), please file a spec bug.

See
https://html.spec.whatwg.org/#custom-elements-customized-builtin-example
"Note that when creating a customized built-in element programmatically, the is attribute will not be present in the DOM, since it was not explicitly set."

But as of now, this is invalid.

Comment 9

[Andrea Giammarchi]

(In reply to Olli Pettay [:smaug] (vacation Jul 15->) from comment #8)
> If you think the spec should be changed (back), please file a spec bug.

done: https://github.com/whatwg/html/issues/3833

> 
> "Note that when creating a customized built-in element programmatically, the
> is attribute will not be present in the DOM, since it was not explicitly
> set."
> 

I've explained why this makes no sense. The constructor is invoked even with elements already available on the DOM so that needing to set the attribute is either redundant / useless or error prone if a dev forgets about it.

Please don't close until it's clear what's the best way to go, because all we have now is inconsistency between the browser that shipped Custom Elements before any other and the soon new comer in the game.

Thanks.

Comment 10

[Andrea Giammarchi]

So, it looks like `outerHTML` serialization should show up the `is="..."` attribute regardless, hence make Firefox feature detectable: https://github.com/whatwg/html/issues/3833#issuecomment-406451917

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Could you upload a minimal testcase using Add an Attachement link.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: ce_outer.html

This testcase shows is= being serialized in both cases.
Am I missing something?

Comment 13

[Andrea Giammarchi]

I see in console the output I've described in here:
https://codepen.io/WebReflection/pen/JBEYQQ?editors=0011

That is:

<div is="my-div"></div>
<div></div>

Comment 14

[Andrea Giammarchi]

I can confirm even your attached page shows that output.

Comment 15

[Andrea Giammarchi]

Attachment: Screen Shot 2018-07-20 at 18.50.00.png

this screenshot shows the issue.

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

And I'm testing very latest Nightly built from mozilla-inbound and see 
<div is="my-div"></div> twice.

Comment 17

[Andrea Giammarchi]

Good, so somebody resolved this bug, but I read RESOLVED INVALID up there so thanks to whoever resolved it, not sure why ti's been flagged as invalid though.

Best Regards

Comment 18

[Andrea Giammarchi]

Attachment: Screen Shot 2018-07-20 at 19.03.09.png

FYI latest Firefox Developer Edition still shows the issue here.

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Dev edition is not Nightly. And the code for web components in the current dev edition won't be shipping. Would be better to test Nightly.