Re: [WICG/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

@trusktr the idea is not terrible but it raised a few concerns:
  * the fact the API mimics CE but needs a suffix parameter as element is a bit yack
  * accessors (get/set behavior properties) can't access the element (*target*), unless such target is assigned in the constructor once
  * because of the previous 2 points, I'd rather vote for `this.target` as getter so that it can be accessed at any time in the behavior
  * while I initially thought it'd be confusing for developers to distinguish a behavior from a CE, the fact the definition doesn't extend `HTMLElement`, or any other, helps disambiguating that, but as soon as one behavior extends a base behavior, it's easy to think that class definition is for a CE, not a behavior
  * as this is based on MutationObserver, I guess everything is inevitably asynchronous, which leads to unexpected sequence of events (the CE polyfill with MO has the same gotcha more than a developer felt with)
  * because of the previous point, I wonder if mimic the CE API is, actually, a good idea at all, as in projects such as *wickedElements* or *hookedElements* these kind of expectations are less obvious ... 

My last points regard the fact that `connectedCallback` might be called when `disconnectedCallback` also happened (quick add node and remove it before MO triggers) ... so that expectations, compared to Custom Elements that have synchronous invokes, might be well explained.

However, this last point is more about a polyfill limitation, not exactly how behaviors should be defined.

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

Received on Tuesday, 23 March 2021 08:09:44 UTC