ungap/custom-elements

Mistake in source code

Closed this issue · 15 comments

do you have any specific problem though? I think current state works with both old and newer Safari and the fix went in and it got tested to work everywhere ... I am saying this because while I fully agree there is a typo, I don't know enough of their internal changes to be sure if I change that, we'll have new issues on Safari.

No I have nothing to say more :) just that it's a bug waiting to happen, probably.

AFAIK so far no browser complained, but I hear you ... although things work now. I will eventually fix this and push major (or minor, if I am still behind 0) so let's hope that won't crash the world once that happens.

Unfortunately I recently canceled my browserstack subscription. Do you know you can ask them to give this project free open source subscription ?

I have one already, that's why I've said, everything is fine.

Since epiphany-browser is kind of webkit, I gave it a try...
@ungap/custom-elements 1.2.0 works there, but not version 1.3.0.

Imagine I use GNOME Web as my daily driver

Well then that's odd. I'm diffing v1.2.0 / v1.3.0 to see what broke my setup

Ha damn again it's a problem on my side. I'm loading the polyfill somewhat too late.

FWIW my issue was that I was detecting the need to load the customElement polyfill using this code:

'customElements' in window && (function() {
 try {
  const BR = class extends HTMLBRElement {};
  const is = 'extends-br';
  customElements.define(is, BR, { extends: 'br' });
  return document.createElement('br', {is}).outerHTML.indexOf(is) > 0;
 } catch(e) {
  return false;
 }
})()

Which makes the corresponding detections fail in @ungap/custom-element, because extends-br is already registered.
This code should really clean after itself. EDIT: WICG/webcomponents#754 it cannot.

I was detecting the need to load the customElement polyfill using this code:

The best way to run this polyfill for Safari or WebKit only is to stick this inline script as the first one on any page (within the <head>, of course):

<script>
if (!(self.chrome || self.netscape))
  document.write('<script src="https://cdn.jsdelivr.net/npm/@ungap/custom-elements/es.js"></'+'script>');
</script>

arguably you can use the same trick to bring in just https://cdn.jsdelivr.net/npm/@webreflection/custom-elements-builtin/es.js without even needing to feature-detect as it's clear at this point Apple won't ever implement builtin extends.

Thanks for the additional infos. However I'm loading a bunch of other polyfills (mostly from polyfill.io's detectSource fields) before actually executing my library. It's a bit convoluted but it avoids user-agent detection, and all polyfills are equal :)

I haven't used user agent sniffing, I've used proprietary fields per browser ... I am not parsing a string, I am checking the env 😉

Like I've said, that is the best way to land this poly for Safari only and no network request even ever happens in Chrome or Firefox ... the CDN caches that too so it's irrelevant for your users.

In short, do what you want, but the best wayfor this polyfil is the one I've suggested there, actually the CodePen example is even better because it doesn't trash any entry in the customElements registry at all so it never conflicts, not even if other projects embed this polyfil as the polyfil will pass the feature detection after the first patch so ... it's all good.