Closed brandondees closed 7 years ago
@brandondees i'm currently at this phase at a current project. Have just read some stuff on using brotli for css as well. Looks like a good move. There is much in my bubletape
project that answers these questions. I'll do some investigating.
yeah brotli pre-compression should work on any static files, and the on-the-fly compression should probably work for anything else.
@brandondees found postcss-custom-properties Seems to have a { preserve: true }
option that yields the following:
This seems to satisfy your constraints. However, there is one caveat. Does not work well with media queries. Could be a deal breaker. if this doesn't work then I would have to say we'd need to contribute to the plugin library or build our own from a fork.
Please advise so we can update this issue.
thanks for finding that, @snuggs that project shipped a while back with some weird compromises in place to account for it but with some sensible defaults at the base level I and caution, I think it can work out nicely. what we wound up doing to patch IE is to media query on some ms-specific feature and then just override any rules there as needed, and I think a lot of the custom props may have wound up being replaced with scss vars there too, which kinda works the same as this, just messier.
I'll take it for a spin when I get a chance and let you know how it plays out.
I'm working on a project and using some custom css properties / vars based on some stuff @snuggs showed me, but now that i've plugged it into webpacker's default postcss pipeline, the css custom properties are not behaving the same as they do natively. the values are being calculated at compile time and substituted instead of computed dynamically like the real vars will do on the browser, so this means unless I jump through a bunch of hoops to make everything play nice with that expectation, I'm going to have dramatically inconsistent scaling if i switch between browser-support transpilation and native. If we had a PostCSS plugin that provides a best of both worlds approach by keeping the native --vars in the output but providing a "less pretty but works" fallback rule for non-compliant browsers, I could probably be happy with that. Right now I think I may either have to encode those rules and fallbacks by hand and bypass transpilation (annoying because that means I lose other productive features) or I'll code everything to make the non-native plugin output render as intended, and then have to re-do all the same styles when the time comes to remove the transpilation /polyfill step.
I'm also looking for solid patterns for organizing an entire project's stylesheets and media queries, since I'm currently running into some friction on the way I thought would be nice.
Browsers I'm targeting are all latest/supported versions of Chrome, Safari, FF, Edge, IE11.