by remy_luisant on 4/5/17, 6:57 AM with 108 comments
by josephg on 4/5/17, 7:49 AM
I learned this one the hard way a few months ago. We ran into a flexbox bug in one browser which we worked around by adding some-rule: 0.0000001px instead of 0px. However, our minifier collapsed that using scientific notation, which triggered a rendering issue in a different browser due to the out-of-spec CSS. The whole adventure left me feeling like I'd travelled back in time.
by remy_luisant on 4/5/17, 7:51 AM
Wow. #1 on HN. Wow.
I'd usually hang around a bit more, but I'm really tired. I posted this past my midnight. 00:51 now, and I'm fading fast.
Thanks for all the love, everyone. I'll come over tomorrow (12 hours from now, or so) to answer any questions or to pick up any corrections.
by cornedor on 4/5/17, 11:49 AM
There used to be a bug with flex-wrap: wrap; where an element would wrap to the next line while it should have fit. You could fix it by instead using width: 25%; use width: 24.999999%; so it would be 25% on the screen but it would fix the problem so it didn't wrap to the next line. So you should look out with this.
by pasta on 4/5/17, 8:02 AM
Unfortunately every time I read something about minifiers I got the feeling that people are optimizing the wrong problem.
If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little.
The problem is on the client side. You can compress what you like but if the browser starts dropping frames because it has to compile/handle a ton of Javascript and CSS then minifying doesn't help the end user.
by replete on 4/5/17, 11:21 AM
A more interesting problem to solve, I think, is that of optimising CSS rules for browser rendering.
by Silhouette on 4/5/17, 10:39 AM
by ovao on 4/5/17, 7:58 AM
It's very interesting, however, that no one minifier is a consistent winner in these test cases, and that running CSS through multiple minifiers is actually, potentially, not all that crazy. (The very debatable real value in doing that notwithstanding.)
by mercer on 4/5/17, 10:13 AM
To be clear: I don't mean philosophical reasons. I personally love letting javascript deal with the 'cascading' part and I don't have a problem with the idea of having styling embedded in the final page.
What I'm curious about is if this has any kind of negative impact on performance, bandwidth, etc. Because the CSS is loaded on the component level, and because Webpack 2 does tree shaking, the page will be guaranteed to only contain CSS for the components that are on the page. And if I'd 'lazy-load' parts of the app, I'd get that benefit for my CSS as well with no extra effort.
On the other hand, any benefits of having a compiled (and hopefully cached) bundle.css are offset by the need for an extra request for the css file, as well as the very likely situation that there'll be a bunch of unused css in that bundle.
Am I missing some drawback to the above-mentioned approach?
by tambourine_man on 4/5/17, 12:18 PM
Also didn't know one could use counters already. Browser support is great. I thought it was still under approval.
Amazing stuff, thanks
by fleetfox on 4/5/17, 8:31 AM
by wyldfire on 4/5/17, 1:12 PM
by buster on 4/5/17, 10:13 AM
by WhitneyLand on 4/5/17, 12:19 PM
by bgrohman on 4/5/17, 7:13 PM
by cperciva on 4/5/17, 7:20 AM
Remy: I'd suggest posting a CV and linking to it from this post. I looked and couldn't find one anywhere on your site; you'll get a lot more qualified interest if people can find out more about you than just a few blog posts.