Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favourite 3 lines of CSS

andy-bell.co.uk

Post reply on HN
Print view View original

41–50 of 87 posts

Re: My favourite 3 lines of CSS

#41

Post by jraph »

CWIZO wrote: post #38
jraph wrote: 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?

For * + * versus :not(:first-child), I guess it's a matter of style. Maybe they are a bit different in the specificity of the rule, I don't know.

margin-block-* and margin-inline-* (versus margin-{top,right,bottom,left}) are more generic and take into account the writing-mode, direction, and text-orientation.

https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inli...

Notably, for instance, if you want to support both rtl and ltr languages, margin-inline-start (instead of margin-left) will behave correctly and put the margin at the correct side.

If you ask me, it's a step towards specifying/conveying the intent and not hard-coding the look.

Re: My favourite 3 lines of CSS

#42

Post by xialvjun »

woahitsraj wrote: post #5

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

That requires the program itself to be well designed, without exceptions everywhere.

Re: My favourite 3 lines of CSS

#43

Post by jraph »

the_other wrote: post #39
grishka wrote: 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. T…

There have been countless times when I was fighting with some margin / size issues, only to notice a * { box-sizing: border-box; } was breaking my expectations.

I learned CSS with the W3C / standard box model, in a time where we had to deal with the buggy IE behavior which was essentially box-sizing: border-box. Now, we have the choice of specifying which box model to use and is seems many people prefer box-sizing: border-box. I'm definitely used to the standard/default one more but odds are someone overridden this.

I don't know which one is better but now we have two existing box models, and depending on the project you work on, the default one depends on what was decided when starting it. It's weird, before it was depending on the browser in use, not the project :-)

I'm not sure how this interacts with libraries / components you import that might not expect such a global setting. I guess you have to be very defensive about this when writing a component. And it seems the expectation is that the component writer should be defensive rather than the website / app builder be careful not to break stuff with global rules. Which is also weird to me.

The spirit of the cascading styles was that you could style and customize everything and that stuff you import would adapt to your styling, but we are rejecting this idea by going out of our ways fool-proofing everything and making nothing customizable. I understand why (it's hard to support everything and ensure no breakage), but this still feels backwards to me.

Re: My favourite 3 lines of CSS

#44

Post by lucas_codes »

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?

We were begging for these features for years and it was a nightmare waiting for enough browser support.

Re: My favourite 3 lines of CSS

#45

Post by azhsetiawan »

jraph wrote: 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 write like yours more often and avoid using * selector as much as possible in my CSS. Using :not(:first-child) is more obvious for me and my co-workers who will read that CSS selector.

Re: My favourite 3 lines of CSS

#46

Post by grishka »

the_other wrote: post #39
grishka wrote: 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. T…

I'm first and foremost an Android developer and I only started serious web development several years ago. My expectation from the Android view system is that padding is inside the box. The CSS default of it being outside makes no sense to me and I can't think of any use cases where it would be beneficial. The overflow-wrap is also obvious — there are no sane use cases where I would want the text to sometimes overflow the element bounds.

Re: My favourite 3 lines of CSS

#47

Post by lelanthran »

alwillis wrote: post #33
zoul wrote: 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 co…

> And of course, the original sin of the misuse of HTML tables for layout.

Hardly a sin - there were no alternatives at the time (1996 - 1998) if you wanted a tabular or grid layout.

Re: My favourite 3 lines of CSS

#48

Post by jraph »

azhsetiawan wrote: post #45
jraph wrote: 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 write like yours more often and avoid using * selector as much as possible in my CSS. Using :not(:first-child) is more obvious for me and my co-workers who will read that CSS selector.

> avoid using * selector as much as possible in my CSS

So do I, I am somehow wired to think "* is going to be very bad for performance because now the rendering engine will need to apply this bunch of rules to any and every element on earth, which might not be only overkill, but which also might have undesirable side effect."

It might not really apply here but the feeling is present.

Re: My favourite 3 lines of CSS

#49

Post by nzoschke »

mickeyp wrote: post #22
zoul wrote: 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.

Asking ChatGPT to write html / css / tailwind is my favorite application so far.

I still can’t remember how to horizontally and vertically center an element but CGPT sure can.

Re: My favourite 3 lines of CSS

#50

Post by woahitsraj »

xialvjun wrote: post #42
woahitsraj wrote: post #5

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

That requires the program itself to be well designed, without exceptions everywhere.

I think exceptions are fine and that is what you could use inline or scopes styles for. Exceptions everywhere is problematic but having this sort of pattern could encourage better design
Post reply on HN