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

71–80 of 87 posts

Re: My favourite 3 lines of CSS

#71

Post by EdSharkey »

jraph wrote: post #21
irrational wrote: post #13

Earlier quoted context omitted.

I had the exact same sentiment when the arrow function was added to JS. My mind has not been changed in the years since. Clear is always better than clever, arrow functions are not clear (despite the desperate cries to the contrary by complexity loving programmers).

Of all the JS features you are picking the arrow function? Is it the syntax, or the this binding thing that works differently than function expressions / statements you are complaining about? Because the syntax looks somewhat like the function notation in math, and a variation of it is also present in many programming languages, often functional, but also Java since version 8. It's quite widespread and not very bizar…

So that's how test.each works in jest!! Catharsis!

Re: My favourite 3 lines of CSS

#72

Post by xigoi »

jraph wrote: post #48
azhsetiawan wrote: post #45

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.

:not applies to almost every element, so it's not any better.

Re: My favourite 3 lines of CSS

#73

Post by xigoi »

ironmagma wrote: post #70
jraph wrote: post #67

Earlier quoted context omitted.

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

Maybe you wouldn't if you had to pay for all the electricity that's wasted by using React.

Re: My favourite 3 lines of CSS

#74

Post by xigoi »

personjerry wrote: post #8

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

You might as well complain that x = y + z is bad code because you have to figure out what the symbols mean.

Re: My favourite 3 lines of CSS

#75

Post by thiht »

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…

CSS is one of the languages that everyone shits on because they never bothered to learn it properly. When you learned your programming language of choice you probably read a formal tutorial, or followed a full fledged course. Well once you spend some time learning CSS, it becomes incredibly easy to do almost everything you want.

If you know your basic CSS selectors `.stack > * + *` is very easy to understand. I didn't know `* - *` was sometimes referred to as "lobotomized owl selector" but it doesn't matter, `>`, `*` and `+` are all basic selectors that everyone working with CSS should know from the top of their head. None of these are "clever". If you can't read `.stack > * + *`, you don't know CSS selectors. I'd even argue if you don't use mostly `>` instead of ` ` (space selector) your stylesheets are probably unmaintainable.

CSS hacks were a shit show 10 years ago because of browser compatibility, but the thing presented here is not a hack, it's just a useful rule.

Re: My favourite 3 lines of CSS

#76

Post by jraph »

EdSharkey wrote: post #71
jraph wrote: post #21

Earlier quoted context omitted.

Of all the JS features you are picking the arrow function? Is it the syntax, or the this binding thing that works differently than function expressions / statements you are complaining about? Because the syntax looks somewhat like the function notation in math, and a variation of it is also present in many programming languages, often functional, but also Java since version 8. It's quite widespread and not very bizar…

So that's how test.each works in jest!! Catharsis!

Ah, so it's actually used somewhere, and in a widespread tool above all? :-)

Re: My favourite 3 lines of CSS

#77

Post by ironmagma »

xigoi wrote: post #73
ironmagma wrote: post #70

Earlier quoted context omitted.

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.

Maybe you wouldn't if you had to pay for all the electricity that's wasted by using React.

Something tells me React uses less electricity than CSS `*` selectors.

Re: My favourite 3 lines of CSS

#78

Post by irrational »

jraph wrote: post #21
irrational wrote: post #13

Earlier quoted context omitted.

I had the exact same sentiment when the arrow function was added to JS. My mind has not been changed in the years since. Clear is always better than clever, arrow functions are not clear (despite the desperate cries to the contrary by complexity loving programmers).

Of all the JS features you are picking the arrow function? Is it the syntax, or the this binding thing that works differently than function expressions / statements you are complaining about? Because the syntax looks somewhat like the function notation in math, and a variation of it is also present in many programming languages, often functional, but also Java since version 8. It's quite widespread and not very bizar…

The syntax. I don’t see how prior use in mathematics or other languages has any bearing. JavaScript could have led the way by using a clear syntax instead of perpetuating complexity.

Re: My favourite 3 lines of CSS

#79

Post by psygn89 »

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…

It is one of those things as an outsider you think that something is overly complex, and then you learn it, and understand that it's complex because the issue it is tackling is dynamic which often requires a level of complexity to apply over.

I had the same thought with Regex before learning it. Now I can read it like css selectors, and you'll notice that the complex patterns are that way because they have to cover dynamic situations (using ranges, lookbehind/lookahead, etc).

Re: My favourite 3 lines of CSS

#80

Post by the_other »

ironmagma wrote: post #68
the_other wrote: post #63

Earlier quoted context omitted.

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

I detect a pungent "code smell", and probably a design bug via your example selector.

Does the designer really want such a specific edge case to an edge case? Can they explain or justify it according to the design patterns they laid down? Why are we using such a general ".container" to specify a ".button", and whilst we're at it why do we have a "button" AND a ".button". Our codebase was going off the rails long before we reached this (admittedly scary-looking) selector. There was a better way to do what we're doing, several iterations ago, and people who cared about the ux+information design and the CSS should have caught it sooner. Go back to them and fix the problem there rather than let this horrible selector pass code review.

We wouldn't stand for this in the TS/JS codebase. Why do we put up with it in the CSS?

To be honest, I was never on board with the "classes everywhere" approach. IDs are fine when they identify a single item on the page. We lost something when we stopped using the language as it was designed.

Post reply on HN