I am increasingly worried about the “smart” CSS solutions. The spec is already huge, the selectors are hard to read and google, the interplay between various features is devilishly complex. And the CSS community seems to be very fond of these smart hacks where people in the know say “Oh, that’s just Foo’s variation on Bar’s flex owl hammer” and you are left to study the CSS lore for hours to decrypt the two or three letters. I just wish we would value simplicity over cleverness.
The lines in question:<p><pre><code> .stack > * + * {
margin-block-start: 1.5rem;
}
</code></pre>
I got it immediately because I think I've been doing something similar for a while. I identified the problem it solves. I understand that if you haven't encountered the situation, it's probably hard to decipher.<p>It reads like: apply a top margin to all direct children that are not the first one.<p>I write it like this:<p><pre><code> .stack > :not(:first-child) {
margin-top: 1.5rem;
}
</code></pre>
I probably should start using -block-start. I'll keep my selector though I think.<p>I didn't know about the default value parameter of --var, I'll probably use it too.
We get so much power from just setting global scoped styles like this it's so strange to me that more of these patterns aren't common or included in minimal css frameworks.<p>With all the recent criticism of tailwind, css-in-js, and other bloated frameworks I truly feel like 90% of projects could get away with a handful of sensible global styles or "classless css" and then aggressive use of components with scoped styles. You hardly ever need anything else
It’s amazing that CSS has such advanced features that can do these things, but at the same time if you actually use them extensively and then I inherit your code, you kind of deserve a knifing.
Shout out to Andy and Heydon for their book <i>Every Layout</i>. It made CSS sensible to me.<p>By no means am I an expert, but I thoroughly enjoy writing CSS using techniques they teach in the book. Somehow, it helps me to think of CSS as a constraint programming system. Combinators are that --- layout constraint directives.<p>Architecturally, I really like the choice of pulling apart CSS in terms of structural definitions (Stack, Box, Switcher etc.), style definitions (applied to leaf nodes as far as possible), and global rules, ratios, and units (e.g. modular scale).<p>I think the system composes beautifully and lets me do a <i>lot</i> with a very small set of core definitions.<p>My personal site uses those techniques: <a href="https://www.evalapply.org/static/css/style.css" rel="nofollow">https://www.evalapply.org/static/css/style.css</a><p>edit: formatting
All these comments complaining about complexity of the selectors - if you haven't read the MDN page on selectors in the last 5 (10?) years, perhaps now is the time?<p>We were begging for these features for years and it was a nightmare waiting for enough browser support.
While this is clever, it's rather difficult to understand and maintain. Imagine having to sift through a CSS file full of > * + * and assorted symbols and figuring out what they mean (and seeing this article, it's clearly not that simple to explain in documentation either).
In case you had to look it up (I did), the lobotomised owl: <a href="https://alistapart.com/article/axiomatic-css-and-lobotomized-owls/" rel="nofollow">https://alistapart.com/article/axiomatic-css-and-lobotomized...</a>
I think that this sort of CSS is smart being put in some kind of reset.css, being a base for the design, rather than being used occasionally while developing. In both cases, it would be smart to have explicit comments describing what the snippets do.
Very nice. I like the elegance of owl selectors, particularly when describing the spacing relationships between adjacent siblings.<p>It helps avoid bleeding issues of space which used to require :last-child / :first-child / :only-child overrides.
Respectfully, I'm finding the value of this blog post extremely difficult to understand. The author's arguments against gap just don't make sense and I question the logic of their entire design philosophy - the author dismisses gap and says 'The parent is in complete control and the child elements have no say in what gap is at any given moment."<p>...but that's exactly how a sound design system SHOULD work. Structural components (containers etc) SHOULD be in complete control of child distribution. I simply cannot imagine what a nightmare having to manage margin at an atomic component level for everything would be instead of just spelling out a few container components for them all to live in.<p>Furthermore the resistance to using the two display types that utilise the gap property (flex + grid) is absolutely bizarre. No sane person would avoid these tools as web dev without them is messy and utterly maddening, so this resistance makes no sense at all.
As someone who decidedly likes CSS I think something like this is "too clever". There are some things that should be as boring as possible. Layouts themselves are already a complex matter, so even the most boring and readable css will not be totally boring.<p>When I was younger I also had a phase where I liked to do things like these because I could. Nowadays I do things in a way that doesn't waste my own (or other people's) time by being too clever