Skip to content
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

Spike what PostCSS custom properties may offer for supporting older browsers #4907

Closed
1 task done
Tracked by #3663 ...
romaricpascal opened this issue Mar 28, 2024 · 3 comments
Closed
1 task done
Tracked by #3663 ...
Assignees

Comments

@romaricpascal
Copy link
Member

romaricpascal commented Mar 28, 2024

What

See how we might use PostCSS custom properties to provide fallback for older browser that don't understand custom properties.

Would be good to understand if/how it would work for more complex things like having variables in media queries.

Why

Not all browsers support custom properties, so we need to find a plan for providing users a decent experience in those. The plugin looks promising but we need to understand exactly what it provides and where the pitfalls would be, if any.

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

  • We've set up PostCSS custom properties on a branch, explored its used and documented how helpful it is and where it falls short.
@owenatgov
Copy link
Contributor

I've added the postcss-custom-props plugin to a branch: https://github.com/alphagov/govuk-frontend/tree/spike-css-custom-properties-postcss. Works as expected, adds extra color attribute containing the actual colour of the custom prop. I haven't tested this on an old browser just yet.

My findings so far solely on difference in filesize of the minified CSS:

Whilst not preserving adds a nice little filesize win, I'm not sure it's worth it as it would mean we lose runtime benefits of custom props.

@owenatgov
Copy link
Contributor

I've tested this briskly on IE11. Initially the foundational colours and fonts weren't coming through in the review app, which was because the review app itself wasn't post-processing it's CSS so I needed to add the plugin to the review app as well.

I'm concerned this means that in order to reap the benefits of the plugin, users need to install the plugin into their build process. My hope is that this is just a result of how we process the review app. I'm going to test this further by creating a preview release and porting it to the design system website.

@romaricpascal romaricpascal removed the awaiting triage Needs triaging by team label Apr 4, 2024
@owenatgov
Copy link
Contributor

From creating a release preview in the design system, unfortunately it looks like my concern was true. Postcss doesn't apply to users of the design system unless they're specifically using the minified CSS.

Something we could potentially explore to get around this is having a sass mixin that does this for us, meaning that the problem is solved at the pre-processing level and more users benefit from it.

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

No branches or pull requests

2 participants