Earlier quoted context omitted.
The bit about googling is correct. But I posed it to ChaTGPT and it explained it immediately. 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.
Maybe save us all the trouble and either copy-and-paste the robot's explanation, or share your own.
My favourite 3 lines of CSS
31–40 of 87 posts
Re: My favourite 3 lines of CSS
#32I 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…
The bit about googling is correct. But I posed it to ChaTGPT and it explained it immediately. 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.
Re: My favourite 3 lines of CSS
#33I 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…
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...
Re: My favourite 3 lines of CSS
#34While 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).
[1]: https://alistapart.com/article/axiomatic-css-and-lobotomized...
Re: My favourite 3 lines of CSS
#35...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.
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.
Re: My favourite 3 lines of CSS
#36Earlier quoted context omitted.
Worst thing is the comment (if there's any) is probably something like /* lobotomized owl typography*/
Well at least you can google it… But it certainly doesn’t help. I keep my css specific to each class and try to be as explicit as possible to avoid any weird consequences.
Your approach, redefining all the properties per class, echoes avoiding using parent+subclass relationships in OO style code. Sometimes you benefit from the generalisation of a class hierarchy, sometimes you don’t. A hard rule in either direction gets in everyone's way.
Re: My favourite 3 lines of CSS
#37 .stack > * + * {
margin-block-start: 1.5rem;
}
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.It reads like: apply a top margin to all direct children that are not the first one.
I write it like this:
.stack > :not(:first-child) {
margin-top: 1.5rem;
}
I probably should start using -block-start. I'll keep my selector though I think.I didn't know about the default value parameter of --var, I'll probably use it too.
Re: My favourite 3 lines of CSS
#38The lines in question: .stack > * + * { margin-block-start: 1.5rem; } 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. It reads like: apply a top margin to all direct children that are not the first one. I write it like this: .stack > :not(:first-child) { m…
Re: My favourite 3 lines of CSS
#39Here are my favorite 4 lines of CSS: *, *::before, *::after{ box-sizing: border-box; overflow-wrap: break-word; }
Firstly, it’s too general. Most boxes don’t care which sizing model is being applied. I have found that I want explicit control more often. To be fair, I learned web development when I had no choice but to work with both models so I don’t find the switching much of a burden.
Second, I’ve seen * { box-sizing: border-box; } cause whole areas of the screen to disappear due to a bug in Chrome. This was years ago, so those bugs have probably been fixed, but it was such a significant problem to the layout and caused by such a generally applied rule, that it’s put me off.
Re: My favourite 3 lines of CSS
#40Earlier quoted context omitted.
Worst thing is the comment (if there's any) is probably something like /* lobotomized owl typography*/
Well at least you can google it… But it certainly doesn’t help. I keep my css specific to each class and try to be as explicit as possible to avoid any weird consequences.
I develop things at work similarly to you. JSS where every component has its own style, but you have a common `theme` file so that you can reuse the common styles via a library.
But I have a certain romantic feeling about… what if we could do 90%+ of our styling using these global-per-page rules, and overriding when necessary. The simplicity is really appealing