3) :is(...), before you had to write :not(:not(...)).
4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
As a tip - most LLMs are unaware it exists due to either knowledge cutoff or not having enough training data for it.
As a recommendation, include some examples of it in your AGENTS.md. Here's what I use:
--------------------------------------
## CSS nesting (required)
When writing CSS (including component `css()` strings and `soci-frontend/soci.css`), *use modern CSS nesting* where it improves readability and reduces repetition.
- Prefer nesting with the `&` selector for pseudo-classes / pseudo-elements and compound selectors.
- Avoid duplicating the parent selector when nesting can express it once.
- Reference: [MDN `&` nesting selector](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...)
Mine is text-box: trim. Twenty years of trying to explain to graphic designers why it’s next to impossible possible to get the top of a capital letter to a box, I feel free like a bird.
Why/how do you grep selectors? Seems overly optimistic to be able to guess the particular rule pattern that is applying a style. Browser tools are much more reliable.
Let's say you're thrown into a website you've never worked on before and asked to fix a styling problem. You can look in the browser tools, but the website will only be running the compiled production version, and if the team knows what they're doing there won't be source maps available.
So you've now found selectors in DevTools that you think are causing the problem, and you want to find them in the source code. In the case of many projects, that means searching through hundreds of small CSS files.
That's why you grep selectors, and where the pain comes. You have to start with the most specific rules that you found in DevTools, then start deleting parts from them until you find a non-nested rule that's in the source, yet still specific enough that you haven't got hundreds of matches to go through.
It would be great if something like ast-grep could take a CSS rule copied from DevTools and search for nested CSS that would compile to match it.
Min-max + alpha-beta pruning is the backbone of the chess engines. I think 2KiB or even 1KiB might be enough (I guess the last one would be a very challenging squeeze). But what separates the best engines from average ones, is the heuristics. Heuristics is the most complicated one, and I doubt it's possible to fit it into a single-digit kilobyte memory (even 2-digit). For heuristics, engines like Stockfish also use neural networks, in addition to hand crafted algorithms. Also huge tables are used for endgames, etc.
I'm a millennial, but I share some feelings. I also think modern programming careers often feel like factory jobs where most of the time you must be compliant with some BS. You often find the true joy only in personal projects.
> "The author clearly hasn't a clue about hardware, how memory is implemented."
I'm the author. Actually I'm quite familiar how memory addressing works, including concepts related to virtual memory / memory paging. Yes, I'm not a "low-level nerd" with deep knowledge in OS, hardware or machine code / assembly, but I know enough basics. And yes, I already mentioned that binary addressing makes more sense in RAM (and most of the hardware), and yes, I would not expect 4000-byte memory pages or disk clusters.
My main points are:
1) Kilo, mega, etc. prefixes are supposed to be base 10 instead of base 2, but in tech industry they are often base 2.
2) But this isn't the worst part. While we could agree on 1024 magnitude for memory, the problem is that it's still used inconsistently. Sometimes kilobyte is 1024 bytes, sometimes it's 1000. And this causes a confusion. In some contexts, such as RAM stick or disk cluster, you can assume base 2, but in some other contexts, such as file size, it's ambiguous. For example, would it be good if Celsius meant different things? I don't think so, it would certainly complicate things.
"byte" doesn't even remotely resemble any decimal prefix, so it's okay. The problem is that prefixes "kilo", "mega", etc. are supposed to be decimal prefixes, but are used as binary. And what's worse, they aren't used consistently, sometimes they really mean decimal magnitudes, sometimes they don't.
That's why I said "usually acceptable depending on the context". In spoken language I also don't like the awkward and unusual pronunciation of "kibi". But I'll still prefer to write in KiB, especially if I document something.
Also If you open major Linux distro task managers, you'll be surprised to see that they often show in decimal units when "i" is missing from the prefix. Many utilities often avoid the confusing prefixes "KB", "MB"... and use "KiB", "MiB"...
1) Nested selectors.
2) :has(...).
3) :is(...), before you had to write :not(:not(...)).
4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
reply