Re: [webcomponents] ES5 consideration for custom elements (#423)

Does this mean that custom elements v1 will not be compatible with ES5 style "classes"?

For example the [custom tag example](https://w3c.github.io/webcomponents/spec/custom/#custom-elements-custom-tag-example) could **NOT** be written as the following with custom elements v1:

````
var FlagIcon = function () {
  HTMLElement.call(this)
  this._countryCode = null
}

FlagIcon.prototype = Object.create(HTMLElement.prototype)
FlagIcon.prototype.contructor = FlagIcon

FlagIcon.prototype.observedAttributes = function () {
  return ["country"]
}

FlagIcon.prototype.attributeChangedCallback(name, oldValue, newValue) {
  // name will always be "country" due to observedAttributes
  this._countryCode = newValue
  this._updateRendering()
}

FlagIcon.prototype.connectedCallback() {
  this._updateRendering()
}

Object.defineProperty(FlagIcon.prototype, "country", {
  get: function () {
    return this._countryCode
  },
  set: function (v) {
    this.setAttribute("country", v)
  }
});

FlagIcon.prototype._updateRendering() {
    // Left as an exercise for the reader. But, you'll probably want to
    // check this.ownerDocument.defaultView to see if we've been
    // inserted into a document with a browsing context, and avoid
    // doing any work if not.
  }
}
````

If it is the case that custom elements v1 will not support ES5 style classes I am concerned that it will make it **unnecessarily difficult** for many applications that want to begin the process of migrating to custom elements.

Assuming a developer wants to incrementally support modern browser features (using tools like transpilers and polyfills), the following scenarios come to mind:

1. Browser is a fairly modern HTML5, ES5 browser:
    requires a custom element v1 polyfill (the polyfill would support ES5 style "classes")
    requires a ES6 class transpiler that will create ES5 style classes

2. Browser is a modern HTML5, ES5 and partial ES6 browser:
    requires a custom element v1 polyfill (polyfill would support ES6 classes and ES5 style "classes")
    does not require ES6 class transpiler

3. Browser is a bleeding edge HTML5, ES6 browser:
    does not require a custom element v1 polyfill
    does not require ES6 class transpiler

As a developer who wants to support custom elements in a way that is forward looking and yet compatible with modern browsers, I can choose to write in ES6 classes against the custom elements v1 api. For deployment, I transpile ES6 classes to ES5 style "classes" and include a custom element v1 polyfill.

In the ideal situation, browsers that support custom element v1 natively will not utilize the custom element v1 polyfill and consume the ES5 style "classes" with the native custom element v1 api. 

However, if ES6 style classes are required, then deployment becomes much more complex. One option would be to use feature detection to selectively serve two versions of all elements (one version with ES6 classes to the bleeding edge browsers and one version with ES5 style "classes" to the broad-base). Or even worse, create a single build that utilizes the polyfill in browsers that do not support custom element v1 and **force the polyfill on bleeding edge browsers as well**. The later scenario seems to be the more likely outcome because of the significantly reduced difficulty of distributing a single build while simultaneously adopting a larger user base.

If the idea is that requiring ES6 classes is an acceptable migration burden for early adopters utilizing custom elements v0 and for new users of the platform, I believe this decision will unnecessarily punish new adopters and encourage non-native and non-spec compliant polyfill implementations. Considering that custom elements behavior is so foundational to the whole idea of api interoperability between web components and frameworks consuming web components, encouraging adoption of spec compliant implementations should be a high priority.

Alternatively, I am completely off the rails and have misinterpreted both the current drafts of the [custom element v1 specification] (https://w3c.github.io/webcomponents/spec/custom/) and this Github issue. If that is the case and ES5 style "classes" are to be supported then some of the phrasing such as:

> A parameter-less call to super() must be the first statement in the constructor body... 

is a bit unclear and I can file a separate issue for those cases. If you made it this far, thank you for taking the time to read this post and I look forward to your thoughts.


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/423#issuecomment-199603435