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

61–70 of 87 posts

Re: My favourite 3 lines of CSS

#61

Post by ironmagma »

the_other wrote: post #36
ImaCake wrote: post #15

Earlier quoted context omitted.

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

The 'C' in CSS was a mistake. Consider that specificity is even a thing, and then consider that the ordering of your declarative CSS code matters. IDK, it does seem necessary to make the language workable, but there are far too many stylesheets out there with specificity hacks and !important.

Re: My favourite 3 lines of CSS

#62

Post by [deleted] »

lelanthran wrote: post #47
alwillis wrote: post #33

Earlier quoted context omitted.

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

[deleted]

Re: My favourite 3 lines of CSS

#63

Post by the_other »

ironmagma wrote: post #61
the_other wrote: post #36

Earlier quoted context omitted.

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

The 'C' in CSS was a mistake. Consider that specificity is even a thing, and then consider that the ordering of your declarative CSS code matters. IDK, it does seem necessary to make the language workable, but there are far too many stylesheets out there with specificity hacks and !important.

It's almost like you're saying: because people use CSS without learning it or the problem domain it tries to solve, CSS is wrong.

The "C" is an attempt to make it easy to have a mixture of generic rules that apply across the whole page/site, and specific rules for alternatives and edge cases. CSS and particularly the C make it really easy to say:

button { border-radius: 20%; background-colour: teal; color: white; }

button.cta { background-colour: blue; colour: yellow; }

What's wrong with that? How would you do it otherwise? In a way that generalises to any HTML or XML element? Without changing HTML or XML? It's essentially a syntactic formulation of multiple inheritance. I accept that multiple inheritance is frowned upon and difficult, but it's not without precedent or practicality.

Re: My favourite 3 lines of CSS

#64

Post by majou »

rofrol wrote: post #55
jraph wrote: post #48

Earlier quoted context omitted.

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

43ms is quite a slowdown isn't it? Handful of joules at least.

Re: My favourite 3 lines of CSS

#65

Post by jraph »

majou wrote: post #64
rofrol wrote: post #55

Earlier quoted context omitted.

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

43ms is quite a slowdown isn't it? Handful of joules at least.

Actually, the only two comparable / equivalent options exposed in this page related to this discussion, ul > * + * vs li:not(:first-child), are 50.8ms vs 40.9ms (respectively) for 10 page loads. The browser is not named, so I would guess Chrome. I'm not convinced the difference is not proven significant, we need more data points than that to know for sure, but it seems insignificant. So yes, readability should be the determining factor here.

Other browsers might see different results, especially Firefox which has a very fast / efficient CSS engine.

ps: a difference of 43 ms for one page load would be huge indeed. By comparison, a frame in a 30 fps video is 33 ms.

Re: My favourite 3 lines of CSS

#66

Post by youngtaff »

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…

They're not that complex if you understand CSS

And let's face it… to understand the example code you only need understand what > + * do in CSS

Using intrinsic sizing, and the sorts of approaches Andy Bell suggests reduces the volume of CSS enormously and can often get rid of media queries and huge numbers of selectors that get repeated across viewport sizes

I'd really encourage you to watch this talk by Andy https://www.youtube.com/watch?v=5uhIiI9Ld5M

Re: My favourite 3 lines of CSS

#67

Post by jraph »

ironmagma wrote: post #60
pictur wrote: post #20

Earlier quoted context omitted.

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.

> what does foo > * + * mean?

To be fair, this is the first time I see this but I immediately got it. So might not be as hard / innovative for no reason. I believe someone working often with CSS should be able to parse *+*, and if not, take the time it takes once to understand it. It's nothing that implicit.

Anyway please please don't pull off a React to avoid CSS, just comment your CSS instead, or find a clearer way to write it if you prefer (:not(:first-child)).

This styles documents (puts margins on paragraphs), we don't want an app for this. And even for a React app, we have a nice language to style stuff at our disposal that our browsers are incredibly efficient at evaluating, I don't think reinventing CSS in React is a good thing.

React will die before CSS anyway.

Re: My favourite 3 lines of CSS

#68

Post by ironmagma »

the_other wrote: post #63
ironmagma wrote: post #61

Earlier quoted context omitted.

The 'C' in CSS was a mistake. Consider that specificity is even a thing, and then consider that the ordering of your declarative CSS code matters. IDK, it does seem necessary to make the language workable, but there are far too many stylesheets out there with specificity hacks and !important.

It's almost like you're saying: because people use CSS without learning it or the problem domain it tries to solve, CSS is wrong. The "C" is an attempt to make it easy to have a mixture of generic rules that apply across the whole page/site, and specific rules for alternatives and edge cases. CSS and particularly the C make it really easy to say: button { border-radius: 20%; background-colour: teal; color: white; } b…

In response to "How would you do it otherwise?", like I said, it kind of seems like the language is just what it has to be in order to be workable. In other words, it seems like it designed itself to some extent. And you're right, CSS has practicality. But with almost any pre-built solution, those selectors would look something like `button.cta.xl-2-large:not(:is(.container > .button))`. At that level of complexity, which is not uncommon, you're better off just coming up with a unique ID for every situation and styling things by ID rather than trying to make them "semantic" with the selectors. That's the other problem is the mixture of selectors trying to be both semantic but also their increased expressivity changing the specificity. So if you change a selector, you might need to reorder your CSS or change a bunch of other selectors to match, which becomes untenable the more CSS you have.

Re: My favourite 3 lines of CSS

#69

Post by [deleted] »

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…

[deleted]

Re: My favourite 3 lines of CSS

#70

Post by ironmagma »

jraph wrote: post #67
ironmagma wrote: post #60

Earlier quoted context omitted.

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.

> what does foo > * + * mean? To be fair, this is the first time I see this but I immediately got it. So might not be as hard / innovative for no reason. I believe someone working often with CSS should be able to parse *+*, and if not, take the time it takes once to understand it. It's nothing that implicit. Anyway please please don't pull off a React to avoid CSS, just comment your CSS instead, or find a clearer way…

Please do. I'd much rather see a system built in React with explicit logic, math, and names, than an implicit pile of obfuscated rules that are impossible to tweak without causing a cascading failure.
Post reply on HN