You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2021. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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:
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 likedata.specifications
).polyfills
seems like a sensible bit of data to associate with a JS method, from a structured content point of viewOn 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.
The text was updated successfully, but these errors were encountered: