-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Enable manual polyfill #256
Conversation
✅ Deploy Preview for anchor-position-wpt canceled.
|
✅ Deploy Preview for anchor-polyfill ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
I'm okay with this approach. I wonder if we want to accept an array of elements, and we could also support <link>
tags as well as <style>
? Basically using the same functionality as the existing polyfill, but allowing users to opt into a specified list of CSS sources.
I think an array that supports This does omit inline styles- could we add another boolean flag It would be nice to have a demo, but that's a bit of a challenge in the existing single page setup. |
Thanks for the comments. I'll add them in.
Sounds good. I'll pass in the element array into both |
I updated the code and it's ready for review:
Also, maybe I should rename "imperative" to "manual"? Let me know if "manual" sounds better and less confusing. |
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.
Excellent work, this is quite helpful! A couple quick notes-
- It looks like there are a few linting issues, you can run
npm run lint
to fix or surface. - I do prefer
manual
overimperative
slightly, but it's not a blocker. - Is it a legitimate use case for people to pass in explicit
<style>
or<link>
elements but want to polyfill all inline styles automatically? If so, that currently isn't possible. - If you click the imperative button, and then apply the polyfill to the whole page, the polyfill crashes. This is somewhat related to [BUG] Polyfill fails if a
<link>
fails to load or returns non-CSS content #255 as well as applying the polyfill to dynamic elements #91, so I'm not concerned here. - Do you have any concerns about running this on 2 discrete sets of elements separately? It seems like it should work, as long as there aren't references between the 2 sets of elements.
Overall, thanks for the contribution!
I think that's a valid use case. I'll add this. My only concern is, if the
Yeah this should work, and this is our intended use since multiple components in our library would need to manual polyfill separately. I also added some test coverage: 912c553. The only caveat though, is that, if the elements in different sets rely on the same |
Added |
I have a slightly different thought on how this could work that may make it more clear (either way, documentation will be useful). We could call it Would that be simpler for users? |
Yeah agreed, this would align better with when there's no argument passed in. But maybe we can name the option as |
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.
I love this set of changes -- thanks again for the contribution!
Looks like there are two failing tests. I left mostly minor nit comments, and one question/suggestion for expanding the options API.
I'm seeing this too. I think it relates to #253, as the error I see seems to be when the polyfill tries to fetch the already-polyfilled style:
I'm not sure if there's an easy way to read/fetch a blob url, or whether we should explicitly just skip those links? |
Not quite a fix but this would at least let other styles be polyfilled: try {
// fetch css and add to array
const response = await fetch(data.url.toString());
const css = await response.text();
return { ...data, css } as StyleData;
} catch {
return { ...data, css: ''} as StyleData;
} |
@jamesnw @jgerigmeyer Thanks for the reviews, both. Have addressed all comments. Ready for another round :) |
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.
Not quite a fix but this would at least let other styles be polyfilled:
try { // fetch css and add to array const response = await fetch(data.url.toString()); const css = await response.text(); return { ...data, css } as StyleData; } catch { return { ...data, css: ''} as StyleData; }
I think this might already be fixed by #258? Regardless, I don't think we need to address that in this PR.
Thanks again for this contribution! 🎉
Co-authored-by: Jonny Gerig Meyer <[email protected]>
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.
Description
This change provides an alternative way for authors to apply polyfill: instead of letting the polyfill to lookup stylesheets and
apply the polyfill, the second argument takes a
<style>
element and the function can apply polyfill based on its content.This is particularly useful for components like custom elements, as often the stylesheets are added dynamically to the document, and the currently "auto" polyfilling makes it challenging to apply the changes at the right time.
Related Issue(s)
#228