Skip to content
This repository has been archived by the owner on Sep 7, 2021. It is now read-only.

Should polyfill be an ingredient in some JS recipes? #449

Open
wbamberg opened this issue May 21, 2020 · 0 comments
Open

Should polyfill be an ingredient in some JS recipes? #449

wbamberg opened this issue May 21, 2020 · 0 comments

Comments

@wbamberg
Copy link

Many of the JS method pages include an H2#Polyfill. At the moment we treat these as just a custom prose section, permitted under prose.*. Since they are a common feature of the docs, we should consider making them an explicit ingredient.

Reasons for doing this:

  • we would guarantee that they always appear in the same spot in the page
  • if we made them data.polyfills we could have some constraints on them. We might want them to be literal code in the page, or we might want them to be a link out to some trusted polyfill source (a bit like data.specifications).
  • polyfills seems like a sensible bit of data to associate with a JS method, from a structured content point of view

On the other hand, we don't currently have a good story about polyfills. When this was discussed on Discourse people voted for https://github.com/Financial-Times/polyfill-service/. But my understanding of this is that it's done as a service: you say effectively: "I need to support these browsers" and it gives you the polyfills you need. So the model doesn't really map to the idea that a JS method page "supplies a link to its polyfills" or something like that. Maybe that model is still helpful, but I don't think we understand enough about user needs to know whether it is.

So I think we're not ready to define this yet, and should do some research about how, if at all, we can help web developers here, and use that to help us specify the content structure, if there is going to be one.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant