If you know your basic CSS selectors `.stack > * + *` is very easy to understand. I didn't know `* - *` was sometimes referred to as "lobotomized owl selector" but it doesn't matter, `>`, `*` and `+` are all basic selectors that everyone working with CSS should know from the top of their head. None of these are "clever". If you can't read `.stack > * + *`, you don't know CSS selectors. I'd even argue if you don't use mostly `>` instead of ` ` (space selector) your stylesheets are probably unmaintainable.
CSS hacks were a shit show 10 years ago because of browser compatibility, but the thing presented here is not a hack, it's just a useful rule.
I'm not worried.
> The spec is already huge, the selectors are hard to read and google, the interplay between various features is devilishly complex.
Actually things are getting less complex due the fact we don't need to use all of the hacks, work-arounds and polyfills that were once just what pretty much every web developer did not that long ago. And of course, the original sin of the misuse of HTML tables for layout.
Sure, it wasn't fun to deal with new specs coming out while trying to maintain existing code and attempting to understand when (or if) we can use the new stuff. Sometimes is was like trying to fly a plane while the plane is being retrofitted with new features.
The irony: many of the techniques described in the article is how we should have been doing things for along time. Hayden's article [1], which is the basis for this, was published nearly 10 years ago—these concepts aren't new.
[1]: https://alistapart.com/article/axiomatic-css-and-lobotomized...
Hardly a sin - there were no alternatives at the time (1996 - 1998) if you wanted a tabular or grid layout.
The first edition of Zeldman’s seminal book Designing with Web Standards [1] was released in 2003; two additional editions were released in 2007 and 2009.
[1]: https://en.wikipedia.org/wiki/Designing_with_Web_Standards
This isn't to say those hacks were good, mind you - just that their existence was never really a problem insofar as ability to understand them if you dealt with it once.
Having said that, I also knew what it did immediately upon reading it, and I am not a CSS expert. One you know a little bit about selectors, then you should be able to decode this one rather easily.
I still can’t remember how to horizontally and vertically center an element but CGPT sure can.
Many of the newer CSS features prevent you using JavaScript to achieve the same thing, which is better as it results in better performance and easier to understand code.
I would rather have newer standardised selectors than see the same pattern re-implemented with JS differently in every codebase.
Because the syntax looks somewhat like the function notation in math, and a variation of it is also present in many programming languages, often functional, but also Java since version 8. It's quite widespread and not very bizarre / specific to JS.
You'd have mentioned tagged templates [1], I'd have to bow.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
It counts, because it makes it familiar to many people.
Had JS introduced this syntax without it being anywhere else I would be completely with you: it would just be weird and unnecessarily complicated.
I find this syntax very clear too (though I still prefer function () { ... } for most functions). It has the merit to make some code using small functions, often somewhat functional, lighter to read. But this is a matter of taste, of course.
And let's face it… to understand the example code you only need understand what > + * do in CSS
Using intrinsic sizing, and the sorts of approaches Andy Bell suggests reduces the volume of CSS enormously and can often get rid of media queries and huge numbers of selectors that get repeated across viewport sizes
I'd really encourage you to watch this talk by Andy https://www.youtube.com/watch?v=5uhIiI9Ld5M
I had the same thought with Regex before learning it. Now I can read it like css selectors, and you'll notice that the complex patterns are that way because they have to cover dynamic situations (using ranges, lookbehind/lookahead, etc).