-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Launch Custom Elements v1 Polyfill #25141
✨ Launch Custom Elements v1 Polyfill #25141
Conversation
There don't seem to be any errors. Let's launch!
Hey @rsimha, these files were changed:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great Justin, nice work!
For future reviewers reference, this puts us on the path to removing the polyfill for modern browsers too!
|
This is great. One question: are we utilizing the browser's native CustomElement support (with module-no-module)? |
No, we still always polyfill. We weren't confident that our use of Custom Elements matched the spec, so we decided to always polyfill. We can now begin experiments with using native CEv1. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice! build-system/
changes LGTM.
/cc @keithwrightbos @jeffkaufman FYI, once merged it will be in RC next Tuesday. Please keep an eye on ads dashboard. |
IE11 doesn't have `"[native code]"`, instead it returns `"[object HTMLElement]"`. Well, if there's no CE, then we obviously need to polyfill anyways.
IE11 puts the `innerHTML` accessor on `HTMLElement.prototype`, not `Element.prototype`. And we've already replaced `HTMLElement` with our polyfill class. That polyfill class directly inherits from the native `HTMLElement`, so we can access it via the `__proto__` field.
* Launch Custom Elements v1 Polyfill There don't seem to be any errors. Let's launch! * Always use customElements registry * Fix isPatched check IE11 doesn't have `"[native code]"`, instead it returns `"[object HTMLElement]"`. Well, if there's no CE, then we obviously need to polyfill anyways. * Fix IE11 innerHTML overwrite IE11 puts the `innerHTML` accessor on `HTMLElement.prototype`, not `Element.prototype`. And we've already replaced `HTMLElement` with our polyfill class. That polyfill class directly inherits from the native `HTMLElement`, so we can access it via the `__proto__` field.
* Launch Custom Elements v1 Polyfill There don't seem to be any errors. Let's launch! * Always use customElements registry * Fix isPatched check IE11 doesn't have `"[native code]"`, instead it returns `"[object HTMLElement]"`. Well, if there's no CE, then we obviously need to polyfill anyways. * Fix IE11 innerHTML overwrite IE11 puts the `innerHTML` accessor on `HTMLElement.prototype`, not `Element.prototype`. And we've already replaced `HTMLElement` with our polyfill class. That polyfill class directly inherits from the native `HTMLElement`, so we can access it via the `__proto__` field.
* Launch Custom Elements v1 Polyfill There don't seem to be any errors. Let's launch! * Always use customElements registry * Fix isPatched check IE11 doesn't have `"[native code]"`, instead it returns `"[object HTMLElement]"`. Well, if there's no CE, then we obviously need to polyfill anyways. * Fix IE11 innerHTML overwrite IE11 puts the `innerHTML` accessor on `HTMLElement.prototype`, not `Element.prototype`. And we've already replaced `HTMLElement` with our polyfill class. That polyfill class directly inherits from the native `HTMLElement`, so we can access it via the `__proto__` field.
There don't seem to be any errors. Let's launch!
Note, we're still always polyfilling. But this gets us one step closer to using native Custom Elements v1 when supported (either via ES6 classes, or a minimal wrapper polyfill instead of a full polyfill).