Custom Elements v1

[webreflection]

Custom Elements v1

[WebReflection]

dear all, please give https://github.com/WebReflection/document-register-element/blob/v1/build/document-register-element.max.js a shot and tell me how it goes.

It's V1 for browsers that haven't fully implemented specs yet, and it's based on V0 which is battle-tested.

It's also backward compatible with V0 to help migrating between versions.

Caveat

Having upgrades within classes constructors is basically impossible to do via vanilla JS.
Accordingly, the constructor should return an upgraded version of itself when some initialisation is needed.

The easiest way I've found is compatible with both ES6 native classes and good old ES3 functions.
The hack is straight forward:

class MyElement extends HTMLElement {
  constructor(self) {
    // upgrade the context
    self = super(self);
    // initialise through `self` instead of `this`
    // overwrite the default returned context
   return self;
  }
}

Being not elegant but working way better than a pointless, potentially error-trigger call like done in current webcomponentjs, it's also possible to "beautify" the pattern through extends.

// our new base class
class HTMLCustomElement extends HTMLElement {
  constructor(_) { return (_ = super(_)).init(), _; }
  init() { /* override as you like */ }
}

// create any other class inheriting HTMLCustomElement
class MyElement extends HTMLCustomElement {
    init() {
        // any initialization logic
        this.setAttribute('test', 'OK');
    }
}

Native extends supported

I don't care about WebKit stubborn position on native extends (actually I do and I've patched it indeed) but these should be fully supported in my V1.

class MyLink extends HTMLAnchorElement {}
customElements.define('my-link', MyLink, {extends: 'a'});
var a = new MyLink();
a.href = 'http://google.com/';
a.textContent = 'search stuff';
document.body.appendChild(a);
// <a is="my-link">search stuff</a>

Please let me know what you think so I can eventually publish and bump to v1.0.0 sooner than later.

Best Regards

[WebReflection]

OK ... when I've created this poly I thought things were OK and I bet on public specs.
It looks like things aren't even finished yet ... I'm not sure I want to repeat the same mistake twice.

Can anyone confirm the current status is the one that everyone agreed about?
I'd rather wait than ship yet another intermediate API that won't be available cross browsers.

This stuff reminds me the flex-box story, we're changing methods instead of prefixes 😆

[WebReflection]

It's already working, like tests show. WebKit should listen to users (their customers) and read specs, which is what I've done as polyfill author.

If they'll decide to never implement the is attribute, then WebKit will switch to hybrid mode: simple extends will be based on native customElements and native extends with the is attribute will be polyfilled.

Everybody wins ;-)

[FND]

As I understand it, the major changes are listed in WICG/webcomponents#405.

From a user's perspective, it seemed like the API changes were fairly limited:

• Uses defineElement instead of registerElement

• Removed createdCallback

[…]

should construct the element using its constructor

However, a brief conversation with Domenic suggests there's more stuff going on under the hood:
http://logs.glob.uno/?c=freenode%23whatwg&s=1+Jun+2016#c996899

That's about the extent of my own understanding right now, but I'd certainly be interested in a lightweight v1 polyfill.

[trusktr]

Uses defineElement instead of registerElement

It's actually now

window.customeElements.define('foo-bar', { ... })

Here's the latest (with some examples): https://w3c.github.io/webcomponents/spec/custom/

[WebReflection]

since you're asking, I guess you know it better than me, since I thought this one was the v1 already.

Do you think V1 can be built on top of this one?

Do you know what are major differences between V1 and this one?

I'm not into "polyfills" that much lately so any quick help to speed up decisions and provide an ETA would help.

Thanks

[justinfagnani]

The v1 implementation is coming along over at the webcomponentsjs repo: https://github.com/webcomponents/webcomponentsjs/tree/v1/src/CustomElements/v1

I just added Shadow DOM v1 support last night. We have lots of testing to do, and I need to go over the spec again with a fine toothed comb (which I haven't yet done since it was merged into the HTML and DOM specs), but it should be fairly complete at this point. The whole polyfill weighs in at 1.7k gzipped.

[trusktr]

Do you think V1 can be built on top of this one?

Yeah, I think so. Some ideas around that were mentioned here: skatejs/skatejs#563

[FND]

From the aforementioned conversation with Domenic:

<FND> can WICG/webcomponents#405 be considered final?

<Domenic> FND: yes; custom elements have been upstreamed into HTML (and parts into DOM). See https://html.spec.whatwg.org/multipage/scripting.html#custom-elements.

[lin7sh]

+1 for implementing v1
All the browser vendors is actively working on it(except for Edge)
Safari
Chrome
Firefox

[WebReflection]

I guess we summarized @justinfagnani solution in here:
https://mobile.twitter.com/WebReflection/status/743936414895702016

feel free to use his effort in case you don't care about other browsers supported in here that never made it on Polymer

[zeitiger]

Related discussion WICG/webcomponents#509

[jessehattabaugh]

I want to +1 this, and offer any help that is needed.

[WebReflection]

Update I previously forgot to push latest changes, which I've done now.
I've also tested against all previously supported devices for real, they are all green.

Here you can find the Custom Elements V1 live test page

[WebReflection]

I've published V1 which fixes this issue

[zeitiger]

short question @WebReflection about Webkit native extends. Do I understand it right, that you polyfill the is="custom-element" attribute for Webkit?