Implementing customized builtin elements. #88

joeldenning · 2017-04-01T00:15:27Z

See #42 for previous discussion about customized builtin elements.

Note that I was unable to run some of the html tests locally (I think related to this issue in wct), and because of that was also unable to add more tests to several files. Let me know what you want me to do about that. Also note that I'm not very well versed in Closure types and welcome any help with that.

Fixes https://github.com/webcomponents/custom-elements/issues/13

joeldenning · 2017-04-01T00:37:57Z

src/CustomElementInternals.js

@@ -4,7 +4,7 @@ import CEState from './CustomElementState.js';
 export default class CustomElementInternals {
  constructor() {
    /** @type {!Map<string, !CustomElementDefinition>} */
-    this._localNameToDefinition = new Map();
+    this._nameToDefinition = new Map();


For autonomous custom elements, the custom element name is the same as localName. But for customized builtin elements, the localName is different than the name of the custom element. I have changed this Map so that it looks thing up by name instead of localName, so that it works with both autonomous and customized builtin elements.

joeldenning · 2017-04-01T00:39:24Z

src/CustomElementInternals.js

+   * @param {!Node} node
+   * @return {!CustomElementDefinition|null}
+   */
+  nodeToDefinition(node) {


Getting the CE definition for a DOM element used to be as straightforward as looking things up by localName. But now it's a bit more complicated since you have to deal with customized builtins where the localName is not the same as the name.

Can we tweak the naming here to indicate that the definition returned isn't necessarily the definition that has been applied to that element (__CE_definition)?

Can do. What do you rthink of nodeToCustomElementDefinition? Since the return type is of CustomElementDefinition type

joeldenning · 2017-04-01T00:40:33Z

src/CustomElementInternals.js

+   * @return {!CustomElementDefinition|null}
+   */
+  nodeToDefinition(node) {
+    const name = typeof node.__CE_is === 'string' ? node.__CE_is : node.localName;


__CE_is is a new variable I have created on nodes that are customized builtin elements.

nit: const name = node.__CE_is || node.localName;

👍 will change.

When I wrote this, I was thinking somehow that __CE_is would not always be a string and that we wanted to ignore it in that case. But we should instead just ensure that __CE_is is always a string.

joeldenning · 2017-04-01T00:42:24Z

src/CustomElementInternals.js

+  nodeToDefinition(node) {
+    const name = typeof node.__CE_is === 'string' ? node.__CE_is : node.localName;
+    const definition = this.nameToDefinition(name);
+    if (definition && definition.localName === node.localName) {


It is possible that someone tries to apply a customized builtin element (via is="my-builtin") to a dom element that the customized builtin was never meant to extend. In that case, we should not upgrade the element to be the customized builtin.

This is why there is the definition.localName === node.localName check.

joeldenning · 2017-04-01T00:43:46Z

src/CustomElementInternals.js

@@ -208,6 +222,11 @@ export default class CustomElementInternals {
            this.patchAndUpgradeTree(importNode, visitedImports);
          });
        }
+      } else if (element.hasAttribute('is') || element.is) {


The is="" attribute should only be looked at when an element is being created, but never again. This function is run when innerHTML occurs, so it is when elements are newly created. So this is the only place we respect what is in the is attribute.

joeldenning · 2017-04-01T00:46:06Z

src/CustomElementRegistry.js

+    let localName = name;
+
+    if (options && options.extends) {
+      if (!this.enableCustomizedBuiltins) {


This is what puts customized builtins behind a flag.

joeldenning · 2017-04-01T00:47:03Z

src/CustomElementRegistry.js

+
+    let localName = name;
+
+    if (options && options.extends) {


See 6. and 7. in the spec for define

joeldenning · 2017-04-01T00:49:08Z

src/Patch/HTMLElementSubclasses.js

+/**
+ * @param {!CustomElementInternals} internals
+ */
+export default function(internals) {


Browsers currently throw errors if you try to subclass native DOM elements. So we patch each of the DOM element constructors so that they don't throw errors.

joeldenning · 2017-04-01T00:49:34Z

src/Patch/Native.js

@@ -28,4 +28,71 @@ export default {
  HTMLElement: window.HTMLElement,
  HTMLElement_innerHTML: Object.getOwnPropertyDescriptor(window.HTMLElement.prototype, 'innerHTML'),
  HTMLElement_insertAdjacentElement: window.HTMLElement.prototype['insertAdjacentElement'],
+  HTMLElement_subclasses: {


This is used when patching all the native elements.

joeldenning · 2017-04-01T00:49:58Z

src/custom-elements.js

@@ -35,6 +37,7 @@ if (!priorCustomElements ||

  /** @type {!CustomElementRegistry} */
  const customElements = new CustomElementRegistry(internals);
+  customElements.enableCustomizedBuiltins = priorCustomElements.enableCustomizedBuiltins;


If somebody set enableCustomizedBuiltins before the polyfill executes, we need to respect that.

I updated this to work with Closure's ADVANCED mode. It was mangling enableCustomizedBuiltins, but I fixed that.

This is why the tests were failing in the build. Shouldn't happen anymore

valdrinkoshi · 2017-04-01T01:00:18Z

src/CustomElementInternals.js

+        element.__CE_is = element.getAttribute('is') || element.is;
+        element.removeAttribute('is');
+        delete element.is;
+        elements.push(element);


You could limit the calls to hasAttribute, getAttribute, removeAttribute to have better perf. Also, avoid delete element.is as it's slow and all we need here is to unset it.

e.g.

} else { // if getAttribute returns an empty string consider it null. const is = element.is || element.getAttribute('is') || null; if (is) { element.__CE_is = is; element.is = null; element.removeAttribute('is'); } elements.push(element); }

Does the is attribute reflect to .is even if the element hasn't been upgraded?

@valdrinkoshi I realized that element.is is not actually a real property according to the spec. So I can avoid delete element.is and looking up element.is altogether.

Also I have removed the call to removeAttribute as suggested by @bicknellr in his comment above.

Finally I decided to combine the hasAttribute and getAttribute calls into just one getAttribute (hopefully maybe trading a little bit of speed for the memory required to store the temp variable)

bicknellr

Nice work! I left a handful of comments, PTAL.

I think __CE_is might be unnecessary since __CE_definition will contain name and localName in it. Although, maybe there are other places where we need to know the element's is value that I'm not thinking about?

bicknellr · 2017-04-03T23:21:40Z

src/CustomElementInternals.js

@@ -208,6 +222,11 @@ export default class CustomElementInternals {
            this.patchAndUpgradeTree(importNode, visitedImports);
          });
        }
+      } else if (element.hasAttribute('is') || element.is) {
+        element.__CE_is = element.getAttribute('is') || element.is;
+        element.removeAttribute('is');


I don't think we should remove it: if we're not actually telling the browser anything about any custom element definitions, then the browser shouldn't do anything special with is, right? Also, I think people will expect to be able to style their custom elements with rules containing attribute selectors for is ([is=my-element]) since it's the closest equivalent to styling with a raw tag name for autonomous custom elements.

Have you found a situation where setting the is attribute of an element (without registering the value of that attribute as an extension) causes distinct behavior?

bicknellr · 2017-04-03T23:28:44Z

src/CustomElementInternals.js

+        element.__CE_is = element.getAttribute('is') || element.is;
+        element.removeAttribute('is');
+        delete element.is;
+        elements.push(element);


Does the is attribute reflect to .is even if the element hasn't been upgraded?

bicknellr · 2017-04-03T23:30:38Z

src/CustomElementRegistry.js

@@ -47,7 +47,7 @@ export default class CustomElementRegistry {
     * @private
     * @type {!Array<string>}
     */
-    this._unflushedLocalNames = [];
+    this._unflushedNames = [];


bicknellr · 2017-04-03T23:38:10Z

src/CustomElementInternals.js

+   * @param {!Node} node
+   * @return {!CustomElementDefinition|null}
+   */
+  nodeToDefinition(node) {


Can we tweak the naming here to indicate that the definition returned isn't necessarily the definition that has been applied to that element (__CE_definition)?

bicknellr · 2017-04-03T23:46:56Z

src/CustomElementRegistry.js

+      const el = document.createElement(options.extends);
+      if (el instanceof window['HTMLUnknownElement']) {
+        throw new Error(`Cannot extend '${options.extends}': is not a read HTML element`);
+      }


I think this method of checking if a custom element exists is a bit strange, particularly if there is already a defined custom element with that name, which this check might produce an instance of.

'is not a read HTML element': Was read meant to be real? If so, could be reworded to be more clear about what a 'real' HTML element is?

👍 yeah that was a typo. Also I agree the wording could probably have been better so I have updated it.

The purpose of this check is to follow 7.2 in https://html.spec.whatwg.org/multipage/scripting.html#custom-elements-api. As far as I know, there is no way of checking the element interface of a localName without actually creating an element. If anyone knows of another way to check if the element interface of localName isHTMLUnknownElement, would love to know. But this was the only way I knew how to check.

bicknellr · 2017-04-04T00:39:38Z

src/Patch/HTMLElementSubclasses.js

+
+  function patchElement(elementName, NativeElement) {
+    if (!NativeElement) {
+      return;


Hmm, I wish this could throw but I'm guessing it's not just in case the element isn't implemented in the browser we're running in?

Yeah this happens when the browser doesn't implement a particular subclass of HTMLElement. The good news is that when that is the case, nobody will be trying to subclass that class anyway, so we don't need to patch it.

bicknellr · 2017-04-04T00:43:16Z

src/CustomElementInternals.js

@@ -208,6 +222,11 @@ export default class CustomElementInternals {
            this.patchAndUpgradeTree(importNode, visitedImports);
          });
        }
+      } else if (element.hasAttribute('is') || element.is) {
+        element.__CE_is = element.getAttribute('is') || element.is;


Add __CE_is to the externs added to Element (here).

👍 updated

bicknellr · 2017-04-04T00:44:13Z

src/CustomElementRegistry.js

@@ -110,6 +129,7 @@ export default class CustomElementRegistry {
    }

    const definition = {
+      name,


Add name: string to CustomElementDefinition (here).

👍 updated

bicknellr · 2017-04-04T00:46:35Z

src/Patch/HTMLElementSubclasses.js

+        // in ES5. Assuming the user keeps the default value of the constructor's
+        // prototype's `constructor` property, this is equivalent.
+        /** @type {!Function} */
+        const constructor = this.constructor;


I think you need to move the annotation so that it looks like a cast (/** @type {!Function} */ (this.constructor)) because closure is complaining that this.constructor might be null.

bicknellr · 2017-04-04T00:52:05Z

src/Patch/HTMLElementSubclasses.js

+          element.__CE_state = CEState.custom;
+          element.__CE_definition = definition;
+          internals.patch(element);
+          return element;


Closure is complaining about the type of element; any ideas? Admittedly, there are 5 closure warnings in master but I'd like to keep that number as low as possible. :)

I fixed the warning by changing it to /** @type {!HTMLElement} */ (element), similar to line 61.

The warning was that Native.Document_createElement returns a Node{....} instead of an HTMLElement like is expected.

madeleineostoja · 2017-04-06T16:27:33Z

Bump. Any update on this? Very keen to try it out across several elements on Simpla and Simple UI

joeldenning · 2017-04-06T22:22:57Z

@seaneking I've updated the pr yesterday to address all the comments, look forward to seeing what other thoughts @bicknellr has

avinoamr · 2017-04-14T12:45:15Z

@bicknellr Can we merge this in? Is there anything else missing here?

bicknellr · 2017-04-18T01:33:33Z

Sorry about the delay! We're still full steam ahead on hybrid porting stuff over in Polymer element land so I won't be able to give this a thorough review for a little bit. However, we're really close and I definitely want to see this landed so, once that's all settled, I'll be able to give this PR more attention.

joeldenning · 2017-05-12T21:04:17Z

ping

madeleineostoja · 2017-05-16T10:24:03Z

Pong?

Is there anything we (the community) can do to help this get merged? It's holding up a lot of us from migrating existing type-extended elements to WC v1 / Polymer 2.

notwaldorf · 2017-05-16T14:35:44Z

I am a little bit worried about this PR. My understanding is that is= isn't implemented on any browser right now, not even Chrome, which means you would force the polyfill in Chrome for your entire app, which pre-this PR it wouldn't be necessary. Secondly, Apple has been pretty clear they don't want to implement is=, which again means you would always have to force the polyfill. Forcing the polyfill makes me sad, because it's slower and more expensive than the native platforms :(

In Polymer 2 we've just worked with the assumption that is= is not available, and that you have to wrap all your native elements in a custom element for the same effect.

/cc @sorvell

prushforth · 2017-05-16T14:57:08Z

I guess the people who are waiting on this don't mind working with polyfills. Is Mozilla planning on implementing html imports? That will have to be polyfilled for the forseeable future, right? Is there any plan to remove customized builtins from the spec? For my purposes, wrapping a native element in a custom element doesn't give the same effect. I gather this holds for others, but I'll let them speak for themselves!

madeleineostoja · 2017-05-16T15:03:44Z

AFAIK customized builtins are in-progress in Chrome? There's also mentions in FF sourcecode about customized builtins, and Edge have said that they're 'basically okay' with them.

At the end of the day though is="" is in the spec, and since it's opt-in behind a flag in the polyfill I don't see the problem with supporting it. A polyfill shouldn't be opinionated.

Then it's up to developers to determine whether they need to use customized builtins, with the extra weight that may incur, rather than have that decision forced upon them upstream. Because there are still many use-cases that just aren't possible without extending builtins. If anything the type extension fiasco has forced some people away from web components into DSLs, which is what makes me sad.

Anyway, IMO if we stopped using something every time a vendor didn't ship it then we wouldn't have WC at all - case in point: following this reasoning shouldn't HTML imports be dropped from polyfills (and Polymer) since FF have refused to implement?

joeldenning · 2017-05-16T15:44:58Z

As the author of this pr, I know that there is real risk that Safari will never implement customized built-in elements, but believe that it is worth having the polyfill meet the spec. See #42 for previous discussion, also https://twitter.com/Joelbdenning/status/839241923139268608 for some of the discussion and thoughts as I was deciding about making this pr or not.

In the end, I believe that as long as users of the polyfill are aware of the risks associated with using customized builtins, that they should be able to. See https://github.com/webcomponents/custom-elements/pull/88/files#diff-04c6e90faac2675aa89e2176d2eec7d8R84 for where we warn the user in the Readme. Also note that I have built this feature behind a feature flag, as discussed in #42.

treshugart · 2017-05-16T16:25:02Z

As the author of this pr, I know that there is real risk that Safari will never implement customized built-in elements, but believe that it is worth having the polyfill meet the spec.

+1

I wonder if it would be more palatable if it were offered as an opt-in fill. Meaning, the consumer has to deliberately include a separate polyfill for customised built-ins (that assumes standard custom element support is provided).

I think Safari currently has around 10% market share. Considering that customised built-ins are extremely useful, it might be sane to add support for it, especially since the spec has it.

joeldenning · 2017-05-18T15:51:12Z

@treshugart Customized builtins already are opt-in in this pull request. You have to run customElements.enableCustomizedBuiltins = true in order to use them. The idea to have customized builtins be implemented as a whole separate file is one that was discussed briefly in #42 and #13, and it was decided that that was not necessary.

The only advantage I can think of to separating it into a different script is to try to reduce the bundle size for the polyfill for those who are not using customized builtins. Looking at the bundle size, though, the polyfill is 14.1kb right now and my pull request adds only 3.5kb. That difference is negligible, in my opinion, and not worth causing the extra nuisance of users having to include two separate files.

prushforth · 2017-05-18T20:57:12Z

If its part of the spec it should be built into the bundle. I'm not sure what advantage having to activate it would have, possibly speed for non-builtin sites? How much time would be saved I wonder. More switches and files causes more confusion DX.

prushforth · 2017-05-24T20:36:55Z

Ping! What is the process for this to go from here to Polymer 2? Looking forward to trying it out.

madeleineostoja · 2017-05-30T17:35:09Z

Any update on this? At least confirmation on consensus of whether this should be merged into mainline or not, or if the community should start investigating forking/splitting it out?

This is still a blocker for a lot of people in migrating to v1 specs / Polymer 2, would be great to have a final word either way from maintainers.

joeldenning · 2017-06-07T19:45:01Z

Status update

Last night we had a small discussion on twitter about what to do with this pr. It looks like I perhaps misunderstood the reasoning for splitting out the customized builtins into its own script. I thought it was to prevent people from using customized builtins accidentally without knowing the risks associated with this part of the spec. But it sounds like it also is motivated by a desire to use native custom element behavior for autonomous custom elements where possible (ie Chrome) and only use the polyfill code for customized builtins.

Question for the reviewers:

Am I understanding correctly what the motivation is for splitting out customized builtins into a separate script? To make it possible to only polyfill customized builtins but still use native autonomous custom elements?
Is that the primary reason for creating a separate bundle for customized builtins? Or is the risk (that webkit never implements customized builtins) also a reason to do so?

Implementation options:

Splitting things out into separate scripts creates some new implementation challenges. Specifically, in order for any type of custom element to be polyfilled, mutation observers must be set up and the window/DOM needs to be patched. So if we want two separate bundles (one for autonomous and one for customized builtins), a (maybe naive) implementation would create a situation where the mutation observers and window patching would happen twice if you used both scripts in your project. To me, that does not seem ideal.

With that said, here are the options I see for pulling off what we want:

Two separate bundles for autonomous and customized builtins, both setting up mutation observers and patching the window
One bundle for all of it (with only one set of mutation observers / window patches). But add some initialization logic that feature checks native implementations of custom elements to see if they support customized builtins. If the browser doesn't support it, use the polyfill for customized builtins while still using native for autonomous.

I lean towards 2) because feature checking native behavior before polyfilling is something that is expected from a polyfill, plus doing it that way avoids the double mutation observer situation.

Which option do you prefer? Are there other options I am missing?

joeldenning · 2017-06-07T19:48:58Z

cc @notwaldorf @justinfagnani. Would love to hear your response to the above comment!

madeleineostoja · 2017-06-23T06:56:09Z

Bump.

Hate to be a nag, but would be great to know final stance from maintainers on how this PR is going to be treated (re: @joeldenning's comment above), so that the developers who rely on it to migrate to v1 specs can plan their work.

Is there anything we can do to help move this along? Do you need usage/use-case data of customized builtins? Perf testing? Anything?

justinfagnani · 2017-06-26T17:44:35Z

@seaneking I haven't been the active maintainer here for a little bit, but in my mind we would ideally have three bundles/entrypoints:

Custom Elements w/o is=
Custom Element w/ is=
Only is=

This would allow libraries that depend on is= to document that they need the is= polyfill on Safari.

I would generally oppose adding is= directly to the main polyfill and only having one bundle, as I think it would encourage using is= without necessarily knowing that it required the full Custom Elements polyfill on Safari.

bicknellr · 2017-06-26T20:24:25Z

@justinfagnani, that sounds like a good idea; splitting the polyfill's entry point into (1) and (2) would make the choice more explicit than a flag and would add less overhead for authors that aren't using is=. However, I'm not sure if (3) is feasible: is there a reasonable way to get correct timing for interleaved upgrades between elements using and not using is=?

@joeldenning, maybe we should look into how we could refactor CustomElementInternals (poorly named, sorry) and CustomElementRegistry objects so that the stuff that would need to be changed to support is= could be written as overrides in an extending classes? I.e. the new entrypoint for is= support would import these new extensions in place of the regular ones (as custom-elements.js does here) and get the extra functionality without requiring explicit knowledge of this feature in the non-is= versions.

joeldenning · 2017-06-26T21:30:37Z

@bicknellr @justinfagnani that sounds good. Creating three different bundles for those use cases will be a fair amount of work, but I think that it will help. I'll start work on it, and yeah maybe subclassing CustomElementInternals and/or CustomElementRegistry will be a good solution for this.

madeleineostoja · 2017-06-26T21:49:34Z

I think it would encourage using is= without necessarily knowing that it required the full Custom Elements polyfill on Safari.

Isn't this what the customElements.enableCustomizedBuiltins flag (and its docs) is meant to communicate? My only concern is for users of webcomponents.js (which I assume wouldn't pull in is=), but if (3) is viable then its a moot point, extended components can just require that extra shim.

If is= requiring the whole polyfill is the primary blocker, would it make sense to ship this now and work on splitting out is= logic (and adding the extra bundles) as a non-breaking change in future (assuming they keep the flag)? Then affected devs can at least start migrating to v1 specs with current support.

bicknellr · 2017-06-27T02:38:28Z

Yes, the flag certainly communicates that but I think there are a couple of things that make splitting into two bundles more desirable: users that don't intend to use is= won't pay any cost (or very little) for extra logic in terms of performance and size and, if is= ends up being dropped from the spec at some later point, removing it will be simpler. [1]

I think (3), the separate is=-only polyfill, would be ideal but I'm concerned that it's not actually possible to use the browser's custom element implementation to handle the non-is= elements while the polyfill manages the elements using is=, without a significant loss of ordering fidelity for upgrades and reactions. It might be worth exploring but I don't think we need to get stuck on it. That's why I think refactoring things a bit so that we can properly expose the points where is= needs special behavior seems like a more promising route.

[1]: I'm trying to gather whatever information I can but I'm in the dark and the implementor actions I'm aware of seem balanced. How do you compare a strong no against two partial but recently dormant implementations?

madeleineostoja · 2017-06-27T07:04:46Z

If (3) isn't feasible, and we still made separate bundles, then would webcomponents.js pull in the one that included is= behind a flag? If not then I think the minor savings in weight are far offset by the extra complexity.

snuggs · 2017-06-27T09:19:03Z

Anyway, IMO if we stopped using something every time a vendor didn't ship it then we wouldn't have WC at all - case in point: following this reasoning shouldn't HTML imports be dropped from polyfills (and Polymer) since FF have refused to implement? - @seaneking

HTML imports IS (pun intended) "being dropped" somewhat conceptually (if i'm reading this properly). Is a topic of discussion in the next TPAC meeting. As @notwaldorf states... perhaps unfortunately. Concensus is 🔑 . We've come a long way to let this fall apart. /cc @bicknellr
WICG/webcomponents#641

snuggs · 2017-06-27T15:59:14Z

Also discussing here as well @seaneking @notwaldorf @bicknellr #StayWoke WICG/webcomponents#645

prushforth · 2017-08-03T22:06:07Z

Hopefully this is not forgotten in the Polymer Summit craziness.

tomalec · 2017-08-24T20:17:07Z

@bicknellr Do I understand correctly that you agree to merge implementation into the current code base/single bundle (behind the flag) once it will be somewhat separated internally and indicate clearly parts required only for is?

tomalec · 2017-08-24T20:18:44Z

@joeldenning are you working on this? I would be happy to help, to push it sooner than later :)

prushforth · 2017-09-27T09:30:14Z

I don't mean to be rude, and at the risk of getting banned: you people need to s**t or get off the pot. Customized built-in elements are part of the spec. The spec clearly recommends using them even in preference to autonomous elements. Let's get this done.

justinfagnani · 2017-09-27T14:26:23Z

"Getting this done" means locking some element users into the polyfill forever on Safari, and even Chrome for who knows how long. A polyfill that never goes away isn't really a polyfill. Getting off the pot, without creating a separate bundle with is= support, to me would simply mean closing this PR.

joeldenning · 2017-09-27T15:17:02Z

I apologize for my absence, the last while -- I hopefully will be able to work on this soon to create a separate bundle for is= support. @tomalec if you'd like to help out, let's collaborate! You can contact me on twitter at @joelbdenning.

fidelepalouki · 2018-05-05T19:56:09Z

Hi @joeldenning, is there any news about the customized built-in polyfill support?

idibidiart · 2018-05-31T13:50:14Z

Thank you for having invested time in this.

Chrome 67 ships with support for extending native elements. To leverage this feature in Chrome, we need to include this polyfill for other browsers.

Any behind-the-scenes progress on this?

dfreedm · 2019-06-10T19:33:27Z

This PR is very old, and now that we're moving to a monorepo, it has to be remade.

We have a tracking issue for this topic at webcomponents/polyfills#102, would you mind remaking the PR in the monorepo?

Thanks!

joeldenning · 2019-06-10T20:07:59Z

@azakus agreed - this PR is very old.

I am no longer able to put time into this, but welcome someone else taking the lead on it.

joeldenning added 8 commits March 31, 2017 17:44

Implementing customized builtin elements

81009a8

Readme

b7b6f39

Undoing changes to custom-elements.min.js

64e072c

Tabs -> spaces

acd7b88

Putting builtins behind flag

673c269

Tabs -> spaces

c02b1c1

Self review

881ce96

One more self review

3c53e49

joeldenning commented Apr 1, 2017

View reviewed changes

valdrinkoshi reviewed Apr 1, 2017

View reviewed changes

bicknellr reviewed Apr 4, 2017

View reviewed changes

Addressing feedback, fixing tests

fed4381

googlebot added the cla: yes label Apr 5, 2017

elementName -> constructorName

d9c59ae

madeleineostoja mentioned this pull request Jun 2, 2017

Port to WC v1 specs / Polymer simplajs/simpla-img#67

Open

noyainrain mentioned this pull request Jun 17, 2017

Upgrade to webcomponents.js 2 noyainrain/meetling#71

Closed

prushforth mentioned this pull request Jun 23, 2017

Upgrade to Custom Elements v1 Maps4HTML/MapML.js#68

Closed

snuggs mentioned this pull request Jun 27, 2017

Current Status of Webcomponents devpunks/snuggsi#71

Open

prushforth mentioned this pull request Jul 11, 2017

Lack of implementations of customized built-in elements is hurting Web Components WICG/webcomponents#648

Closed

tomalec mentioned this pull request Aug 28, 2017

Upgrade it to (async) CEv1 & update the test Juicy/imported-template#30

Closed

tomalec mentioned this pull request Sep 5, 2017

Run attributeChangedCallback synchronously WebReflection/document-register-element#106

Closed

web-padawan mentioned this pull request Oct 9, 2018

Support customized built-in elements webcomponents/webcomponentsjs#1027

Closed

web-padawan mentioned this pull request May 23, 2019

This polyfill does not work in IE11 webcomponents/webcomponentsjs#1088

Closed

dfreedm closed this Jun 10, 2019

Implementing customized builtin elements. #88

Implementing customized builtin elements. #88

Conversation

joeldenning commented Apr 1, 2017 • edited by TimvdLippe Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bicknellr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

madeleineostoja commented Apr 6, 2017

joeldenning commented Apr 6, 2017

avinoamr commented Apr 14, 2017

bicknellr commented Apr 18, 2017

joeldenning commented May 12, 2017

madeleineostoja commented May 16, 2017 • edited Loading

notwaldorf commented May 16, 2017

prushforth commented May 16, 2017 • edited Loading

madeleineostoja commented May 16, 2017 • edited Loading

joeldenning commented May 16, 2017

treshugart commented May 16, 2017

joeldenning commented May 18, 2017

prushforth commented May 18, 2017

prushforth commented May 24, 2017

madeleineostoja commented May 30, 2017 • edited Loading

joeldenning commented Jun 7, 2017 • edited Loading

Status update

Question for the reviewers:

Implementation options:

joeldenning commented Jun 7, 2017

madeleineostoja commented Jun 23, 2017

justinfagnani commented Jun 26, 2017

bicknellr commented Jun 26, 2017

joeldenning commented Jun 26, 2017

madeleineostoja commented Jun 26, 2017 • edited Loading

bicknellr commented Jun 27, 2017

madeleineostoja commented Jun 27, 2017 • edited Loading

snuggs commented Jun 27, 2017 • edited Loading

snuggs commented Jun 27, 2017 • edited Loading

prushforth commented Aug 3, 2017

tomalec commented Aug 24, 2017

tomalec commented Aug 24, 2017

prushforth commented Sep 27, 2017 • edited Loading

justinfagnani commented Sep 27, 2017

joeldenning commented Sep 27, 2017 • edited Loading

fidelepalouki commented May 5, 2018

idibidiart commented May 31, 2018

dfreedm commented Jun 10, 2019

joeldenning commented Jun 10, 2019

joeldenning commented Apr 1, 2017 •

edited by TimvdLippe

Loading

madeleineostoja commented May 16, 2017 •

edited

Loading

prushforth commented May 16, 2017 •

edited

Loading

madeleineostoja commented May 16, 2017 •

edited

Loading

madeleineostoja commented May 30, 2017 •

edited

Loading

joeldenning commented Jun 7, 2017 •

edited

Loading

madeleineostoja commented Jun 26, 2017 •

edited

Loading

madeleineostoja commented Jun 27, 2017 •

edited

Loading

snuggs commented Jun 27, 2017 •

edited

Loading

snuggs commented Jun 27, 2017 •

edited

Loading

prushforth commented Sep 27, 2017 •

edited

Loading

joeldenning commented Sep 27, 2017 •

edited

Loading