Live data from Hacker News

My favourite 3 lines of CSS

andy-bell.co.uk

51–60 of 87 posts

Re: My favourite 3 lines of CSS

#51
Shout out to Andy and Heydon for their book Every Layout. It made CSS sensible to me.

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.

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

I think the system composes beautifully and lets me do a lot with a very small set of core definitions.

My personal site uses those techniques: https://www.evalapply.org/static/css/style.css

edit: formatting

Re: My favourite 3 lines of CSS

#52

Mine's display: flex, flex-direction: row, justify-content: space-between

I was hoping this was addressed in the article, and it was, under "Why use margin and not gap?" A number of arguments are presented (including that, at the time, it wasn't an option) and the confluence of those make the owl compelling.

I think I'd probably opt to buy into flexbox/grids and gap for greenfields projects, but I do appreciate the notion of flow axioms and styling the space between adjacent items.

Re: My favourite 3 lines of CSS

#53
post #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…

Simply: gap wasn't an option when this was initially conceived.

> The author's arguments against gap

I don't think it's a argument against gap. It's that this technique is advantageous in some situations. It is stated later on that grid is his choice for bespoke layouts.

> 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

This is the essence of the technique. Specifying `* + *` allows controlling the layout of adjacent elements, rather than an atomic element. I think this would all make more sense after reading some of the precedent material: https://alistapart.com/article/axiomatic-css-and-lobotomized.... (It's actually pretty succinct, so rehashing it here wouldn't add anything.)

Re: My favourite 3 lines of CSS

#54
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 think you should keep writing it the way you are, I found it a lot clearer.

Re: My favourite 3 lines of CSS

#55
post #48

Earlier quoted context omitted.

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.

>The difference between fastest and slowest is only 43ms (0.043 seconds), and I saw around this difference between rendering the same css twice. I think it is best to go for whatever is most readable for you. Personally I find :first-child the most understandable at a glance.

https://www.reddit.com/r/web_design/comments/5u6e7b/comment/...

Re: My favourite 3 lines of CSS

#57
post #41
post #38

Earlier quoted context omitted.

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…

Specificity is the difference:

* + * is 0,0,0.

:not(:first-child) is 0,1,0.

:where(:not(:first-child)) would take it back to 0,0,0.

Re: My favourite 3 lines of CSS

#58
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 think CSS and the domain of laying out things in 2d (and responding to state changes) with code is actually inherently complex, so which ever layout system you use is going to have a steep learning curve.

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.

Re: My favourite 3 lines of CSS

#60
post #20

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.

Any developer describing this code as bad code has probably never seen bad code.

Bad code is innovative for no reason. Complex for no good reason. Hard to reason about (what does foo > * + * mean? and what happens when the writing is Chinese, exactly?).

These various CSS states would be much better expressed as named properties of React components. That way there would be explicit branches instead of allowing the CSS selector engine to do some implicit insanity.

Post reply on HN