The scientific notation one is a bug. Scientific notation isn't part of the CSS spec[1], and its not supported in all browsers.<p>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 <i>different</i> browser due to the out-of-spec CSS. The whole adventure left me feeling like I'd travelled back in time.<p>[1] <a href="https://www.w3.org/TR/CSS21/syndata.html#numbers" rel="nofollow">https://www.w3.org/TR/CSS21/syndata.html#numbers</a>
Author here.<p>Wow. #1 on HN. Wow.<p>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.<p>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.
> I'm guessing that at nine nines that is pretty much a one anyway and it would not even change a single pixel on the screen.<p>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.
This looks like a fun project indeed!<p>Unfortunately every time I read something about minifiers I got the feeling that people are optimizing the wrong problem.<p>If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little.<p>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.
Don't mean to squash any enthusiasm, but these types of 1byte optimization savings don't really have real-world benefits due to over-the-wire compression like gzip and Brotli.<p>A more interesting problem to solve, I think, is that of optimising CSS rules for browser rendering.
Here's the same author's earlier post on this subject, "The missed chances: What minifiers leave behind", from last week:<p><a href="https://luisant.ca/css-opts-survey" rel="nofollow">https://luisant.ca/css-opts-survey</a>
crass is doing some really wonderful stuff here -- I'm impressed!<p>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 <i>real</i> value in doing that notwithstanding.)
I have a slightly-related question for those of you familiar with Webpack, css modules (css-loader/style-loader), and perhaps React as well: is there any reason not to use the 'default' approach where the styles for the components are simply inserted in a <style> (with unique, generated classnames)?<p>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.<p>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.<p>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.<p>Am I missing some drawback to the above-mentioned approach?
Didn't know about all of those units. q, mm, cm… scientific notation?!<p>Also didn't know one could use counters already. Browser support is great. I thought it was still under approval.<p>Amazing stuff, thanks
If folks tend to use some higher level abstraction (isn't that what SASS and LESS are?) maybe it makes sense to provide a new way to encode the information in CSS. Similar to how WASM is supposed to be easier to parse than JavaScript, right?
<i>I'm for hire now. Le Sigh. Email's in the footer.</i><p>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.