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

You want enabling CSS selectors, not disabling ones

css-tricks.com

Post reply on HN
Print view View original

61–70 of 120 posts

Re: You want enabling CSS selectors, not disabling ones

#61

Post by serverholic »

extra88 wrote: post #55
serverholic wrote: post #44

If you're using react or another frontend framework then you really don't need css selectors. Just make plain css classes and dynamically append them to your components. So much simpler. We do this at my current job and it's honestly the easiest time I've ever had with CSS.

How do you solve the kind of problem the article is describing? How do you have a margin on the bottom of every except the last one? Is there a loop for cards with a conditional that doesn't add the margin? I think the declarative language solution they offer is better.

Yeah just use the index of the card. For example:

cards.map((card, i) => {

  const isLast = i === cards.length - 1

  const className = "card" + isLast ? '' : 'card-margin'

  return
)}

The nice thing about this is you have a full programming language at your fingertips. You could do something with every even card, ever prime number card, etc.

Re: You want enabling CSS selectors, not disabling ones

#62

Post by extra88 »

serverholic wrote: post #61
extra88 wrote: post #55

Earlier quoted context omitted.

How do you solve the kind of problem the article is describing? How do you have a margin on the bottom of every except the last one? Is there a loop for cards with a conditional that doesn't add the margin? I think the declarative language solution they offer is better.

Yeah just use the index of the card. For example: cards.map((card, i) => { const isLast = i === cards.length - 1 const className = "card" + isLast ? '' : 'card-margin' return )} The nice thing about this is you have a full programming language at your fingertips. You could do something with every even card, ever prime number card, etc.

Just because you can do everything in JavaScript doesn't mean you should. The equivalent CSS is a lot shorter and more performant.

> every prime number card

You got me, CSS alone can't select only primes.

Re: You want enabling CSS selectors, not disabling ones

#63

Post by sings »

dvaun wrote: post #6

I found the linked article "Axiomatic CSS and Lobotomized Owls" to be a decent read. I'm surprised that it hasn't been highly upvoted in the past despite having many submissions to HN. Article: https://alistapart.com/article/axiomatic-css-and-lobotomized... Prev. submissions: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I didn’t really understand why the sibling selector was introduced as a scoped version of the lobotomised owl, as if that was the canonical implementation. The sibling selector has always been underrated.

Re: You want enabling CSS selectors, not disabling ones

#64

Post by maccolgan »

jimkleiber wrote: post #29

Hmm, I visited the site on my phone and it seemed to be glitching out. A red background with white outlined large lettering blinking on and off so quickly I couldn't decipher the text. Looked like maybe a GA and some xxxxx after it. Viewing from an iPhone X using the iOS 14.7.1 on Firefox. Anyone else seeing this? Or am I 1) crazy and/or 2) admitting to having some crazy virus on my phone?

If it starts with GA and has random stuff after it, probably related to Google Analytics

Re: You want enabling CSS selectors, not disabling ones

#65

Post by extra88 »

chipotle_coyote wrote: post #56
juped wrote: post #50

Earlier quoted context omitted.

"and yet"? It's "and therefore". † The only problem is that the atrocious #fafafa on #050505 is made a whole lot worse because there aren't a bunch of even worse things distracting you from it.

Okay, I'll bite. Why is #050505 on #FAFAFA (not the reverse, as you stated) "atrocious"? Are we playing the "anything less than #000000 on #FFFFFF is grey text on a grey background and entirely unreadable" card?

I don't understand their complaint either. Some people have a hard time with absolute black on absolute white (and/or vice versa) so easing up a little can be helpful. It's a small difference, 19:52:1 vs. 21:1 contrast ratio. I've seen advice to avoid exceeding 18:1 in large areas, maybe #111 on #f9f9f9.

Re: You want enabling CSS selectors, not disabling ones

#66

Post by serverholic »

extra88 wrote: post #62
serverholic wrote: post #61

Earlier quoted context omitted.

Yeah just use the index of the card. For example: cards.map((card, i) => { const isLast = i === cards.length - 1 const className = "card" + isLast ? '' : 'card-margin' return )} The nice thing about this is you have a full programming language at your fingertips. You could do something with every even card, ever prime number card, etc.

Just because you can do everything in JavaScript doesn't mean you should. The equivalent CSS is a lot shorter and more performant. > every prime number card You got me, CSS alone can't select only primes.

The performance difference is negligible. If you add a new card to the list then react is going to add/remove a couple CSS classes. Completely negligible.

Plus you're going to need this approach anyway if you want to do any more advanced logic like maybe you have a list of users and you want to color them based on some status.

With this method you have the above logic all in one place and in one language. After having used traditional CSS with selectors vs this method I really can't go back.

Re: You want enabling CSS selectors, not disabling ones

#67

Post by extra88 »

serverholic wrote: post #66
extra88 wrote: post #62

Earlier quoted context omitted.

Just because you can do everything in JavaScript doesn't mean you should. The equivalent CSS is a lot shorter and more performant. > every prime number card You got me, CSS alone can't select only primes.

The performance difference is negligible. If you add a new card to the list then react is going to add/remove a couple CSS classes. Completely negligible. Plus you're going to need this approach anyway if you want to do any more advanced logic like maybe you have a list of users and you want to color them based on some status. With this method you have the above logic all in one place and in one language. After havin…

You may need the .map() for styling based on status but

  const isLast = i === cards.length - 1
  const className = "card" + isLast ? '' : 'card-margin'
Seems funny to argue for JavaScript's simplicity while using .map() and an anonymous callback function; a good ol' for loop would make it more clear what's happening.

> all in one place and in one language

That seems like the real reason, keeping to one language.

I think following the rule of least power [0], having HTML semantics do what it's good at, CSS what its good at, and JavaScript for the rest is best for robust and performant outcomes.
I only have a little experience with React and that was a while ago, can you not have the Card typed as an Element to use `Card.classList.add(className)`?

[0] https://en.wikipedia.org/wiki/Rule_of_least_power

Re: You want enabling CSS selectors, not disabling ones

#68

Post by wruza »

thorin1 wrote: post #27
jordwest wrote: post #23

This selector has saved me an inordinate amount of time hacking together UIs quickly: .vertical-stack > :not(:last-child) { margin-bottom: 8px } Just add the class to a parent and all the children will have spaced between, but no spacing around the edges. It’s then easy to add padding to the parent: Heading Paragraph Paragraph

I am always using negative margins on container for this.

And then you can’t nest one container into another, because there is only one “margin” rule and they don’t add up. You start to wrap children into separate containers only to find out that it breaks more and more “nice and simple css tricks” you used before. Eventually you end up with half-broken bootstrap/etc clone that even supports component design if looked at from afar. After few weeks it starts to feel like not using components at all would be much less of a maintenance. Css “tricks” are full of these situational traps.

Re: You want enabling CSS selectors, not disabling ones

#69

Post by wruza »

eyelidlessness wrote: post #52
thorin1 wrote: post #27

Earlier quoted context omitted.

I am always using negative margins on container for this.

If you want to keep doing this, it’ll save you a whole lot of heartache if you also wholesale prevent margin collapsing. In fact, some people recommended that as a baseline default (I personally find it great for layout but surprisingly mixed for typography).

If only we had (or display:sizer) element that could expand, disappear on wrap and not count as a regular child (sort of like a space in a text node)… But that would be so '90s.

Re: You want enabling CSS selectors, not disabling ones

#70

Post by wruza »

sfink wrote: post #26

I think rule-followed-by-exception is clearly superior because it's more flexible and generalizes better to future additions. Except when it isn't superior. Like when the exception is pages of code below the rule. Which means that precise (enabling) selectors are more robust since you don't have to worry about future CSS additions (or even whether to look for exceptions). Which means that in general, general rules do…

This stems from the incorrect (but popular) idiom of doing a container’s job by invading child properties. One can’t make it non-leaky neither to layout around, nor to a developer. These gaps are ones of the parent, not of a child, and anything else will leak.
Post reply on HN