Live data from Hacker News

My favourite 3 lines of CSS

andy-bell.co.uk

31–40 of 87 posts

Re: My favourite 3 lines of CSS

#31
post #22

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.

[deleted]

Re: My favourite 3 lines of CSS

#32
post #22
post #9

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…

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.

It will explain anything immediately. Correctly, not necessarily. Did you check the explanation holds water? Seems like it's back to googling anyhow.

Re: My favourite 3 lines of CSS

#33
post #9

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…

> I am increasingly worried about the “smart” CSS solutions.

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

#34

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).

It might help to read the original article that was published nearly 10 years ago [1].

[1]: https://alistapart.com/article/axiomatic-css-and-lobotomized...

Re: My favourite 3 lines of CSS

#35
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."

...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

#36
post #15
post #4

Earlier 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.

For me, your approach makes the CSS harder to maintain. Pages have loads of repetition and patterns. I’d hope to find a good balance between DRYing up patterns that benefit from it, and leaving space for special cases. I find code patterns like the owl/.flow shown in the OP help greatly with that.

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
The 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) {
      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

#38
post #37

The 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…

I haven't done CSS in about 6 years. So I don't understand why you'd ever use OP's version over yours?

Re: My favourite 3 lines of CSS

#39
post #7

Here are my favorite 4 lines of CSS: *, *::before, *::after{ box-sizing: border-box; overflow-wrap: break-word; }

Personally, I dislike it.

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

#40
post #15
post #4

Earlier 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.

That’s kind of the opposite problem that the article mentions though — if every component has its own specific CSS, then you don’t really have CSS, you just have SS. You miss out on the cascading.

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

Post reply on HN