How to link to polyfills?

[teoli2003]

Hi all!

There is a consensus to remove polyfills from MDN: the UI is terrible, we have not checked the correctness of these (they mostly come from the wiki era, and we don't have the bandwidth to maintain/add them. Nevertheless, polyfills are a valuable tool for developers that need a feature that is not (yet) ubiquitous, so we would like to link to them, when possible.

OpenWebDocs (OWD) is interested to fix them on mdn.

What I propose is the following:

• Create a new YAML header: polyfill that is one link, or an array of links to polyfills, hosted externally.
• Modify the {{Compat}} macro to add (below the compat table):
  A polyfill is available if you need to use it on browsers that don't support this feature.

That way we can remove the polyfills and add them to the metadata of a page and display it if needed. Also, we will have only minor changes to do to the macros, so that could be done even with the current limited devs bandwidth.

Any thoughts?
cc/ @wbamberg, @Rumyra, @sideshowbarker, @Elchi3

EDIT: Note that @zloirock and @Rudxain are about to restructure the location of the numerous polyfills hosted on zloirock/core-js. We will have to update the links on MDN, so there is an opportunity here for some synergy: doing the work once. (See mdn/content#17561)

[sideshowbarker]

Adding a new polyfill frontmatter key sounds fine to me — but it seems also worth mentioning that, alternatively, a new polyfill key could be added to BCD. Not saying that would be better — or even necessarily good — but just putting it out there as another possibility. cc @queengooborg

[teoli2003]

Polyfills are also important for cases where no browser supports a new feature. In such cases, bcd won't have the information.

Note that we can do both: looking in bcd, and, if not, in the local yaml. (Somewhat like spec-urls).

[sideshowbarker]

Polyfills are also important for cases where no browser supports a new feature. In such cases, bcd won't have the information.

ah, good point

Note that we can do both: looking in bcd, and, if not, in the local yaml. (Somewhat like spec-urls).

To me at least that’d seem like make overkill in this case. So I think it’d be best to limit it just to being a frontmatter key.

[teoli2003]

Yes, I'm not convinced we should add more things into bcd. Anyway once it is in a YAML header, it is easily scriptable if we want to add it to bcd later.

I mean: if we can keep PRs self-contained, it is simpler to do. (Moving to bcd will mean 2 PRs for each polyfill, which adds complexity)

[zloirock]

That looks great - for example, polyfills links will be standardized and pages in all languages will contain data about polyfills from BCD immediately after adding, without awaiting translation. However, I hope that polyfills will not be lost on pages after that and will be easy enough to find.

[teoli2003]

The current proposal is to add a sentence about them right below the compat table. (Always at the same place, right before the See also section they are in).

We could add a whole section (H2 or H3) but I'm not sure it is necessary, we'll see.

[Rumyra]

I think this sounds like a great plan actually - an available polyfill seems more like page data rather than a 'See also' and would fit really well with (underneath) bcd tables

[teoli2003]

Yes, and it will have a predictable position in the page (right before the See also heading)

[wbamberg]

I think this is a good idea, of course. Thank you for getting this thing moving again @teoli2003 !

A couple of questions:

• will we want to restrict this new key only to certain page types (JS only?)
• will we want to restrict its value only to certain URLs (I imagine we will have a very short list of recommended sources for polyfills)?
• should the key be optional (omitted if there isn't a polyfill) or mandatory, and get a special value ("none") if we don't have one? The latter is more explicit.

[teoli2003]

* will we want to restrict this new key only to certain page types (JS only?)

We should start with JS. I don't think we should hardcode the restriction in the macro ({{Compat}}), because I think we should little by little open the YAML header to every feature (WebAPIs, CSS, …)

* will we want to restrict its value only to certain URLs (I imagine we will have a very short list of recommended sources for polyfills)?

I think we should only accept trusted sources. We can either:

• have guidelines for the reviewers
• enforce sites in the macro.
  I have no strong feelings here, but for security reasons, I think we should be conservative and therefore have an allow-list enforced. (The macro will not display the text, and raise a flaw, if the url is not in it)

* should the key be optional (omitted if there isn't a polyfill) or mandatory, and get a special value (`"none"`) if we don't have one? The latter is more explicit.

I don't think we do this for other keys at the moment, and I don't think it is worth the extra work. No strong feelings here too.