41–50 of 109 posts
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.
Author here. 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.
Earlier quoted context omitted.
> If you gzip data over the line it's already compressed. So minifying your stuff will only help you a little. For small files you might be mostly correct, but for larger ones min+compress can product much better gains than compression alone. IIRC the algorithm used employs a rolling compression window, and can only match strings of tokens whose distance apart is smaller than that window. IIRC the default window is 8…
Most of the gains in there are from stripping out comments. That plus whitespace removal gets you most of the benefit. I don't think the parent was advocating for dropping minification completely, but investing massive effort when you're already at the crest of the curve.
Attempts at improvement don't hurt at all, and in some cases can help a ton.
Earlier quoted context omitted.
Scientific notation seems to be part of CCS3: https://www.w3.org/TR/css3-values/#numbers Which browser had problems with it?
"q" is also CSS3, incidentally, and its background is interesting[0]: it's a mostly japanese metric typographical unit[1], it replaces the point, and is slightly smaller: q is 0.25mm while pt is ~0.3528mm (precisely 1/72th of an inch which is 25.4mm). [0] http://tosche.net/2013/10/font-size-in-the-metric-system_e.h... [1] although non-japanese typographers like Otl Aicher have recommended its use it doesn't seem to h…
This looks like a fun project indeed! 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 J…
One massive thing minifying does is dead code elimination (slightly less applicable to CSS but it still applies using some build stacks) We can build a "prod" version of the app and the minifying process will drop all the debugging code as well as any unused or uncalled functions from the output.
I would have thought that understanding what functions of a dynamic language that can be safely removed would require parsing/AST analysis beyond those found in the typical minifier.
Also didn't know one could use counters already. Browser support is great. I thought it was still under approval.
Amazing stuff, thanks
The scientific notation one is a bug. Scientific notation isn't part of the CSS spec[1], and its not supported in all browsers. 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 t…
This has tripped me up many a time when I've created CSS colour strings (mostly for use) by concatenating Strings and Numbers in JavaScript. When a Number gets small enough, it ends up in scientific notation, and the CSS parser rejects it.
Earlier quoted context omitted.
One massive thing minifying does is dead code elimination (slightly less applicable to CSS but it still applies using some build stacks) We can build a "prod" version of the app and the minifying process will drop all the debugging code as well as any unused or uncalled functions from the output.
What JS Minifier do you know that does dead code elimination? I would have thought that understanding what functions of a dynamic language that can be safely removed would require parsing/AST analysis beyond those found in the typical minifier.
Earlier quoted context omitted.
"q" is also CSS3, incidentally, and its background is interesting[0]: it's a mostly japanese metric typographical unit[1], it replaces the point, and is slightly smaller: q is 0.25mm while pt is ~0.3528mm (precisely 1/72th of an inch which is 25.4mm). [0] http://tosche.net/2013/10/font-size-in-the-metric-system_e.h... [1] although non-japanese typographers like Otl Aicher have recommended its use it doesn't seem to h…
"q" seems to be doomed to failure. If I were that interested in moving away from points and ems, why would I adopt arbitrary fractions of a millimeter when I could just use plain old SI units that are universally understood? It doesn't even save a byte at typical font sizes: 20q == 5mm.
Typographers apparently use sub-millimeter precision for their sizes e.g. across 9 use cases Aicher had a single integral-millimiter font size[0]. The quarter-mm seems to have been the base multiplier suggested by DIN 16507-2, though it apparently also suggests 0.1 or 0.05mm when even more precision is necessary.