You want enabling CSS selectors, not disabling ones • Hacker News Board

Re: You want enabling CSS selectors, not disabling ones

#51

Post by extra88 » Wed, Sep 01, 2021, 1:56 AM UTC

ljm wrote: post #33

I think CSS is approaching the point where it's equivalent to assembly because it's impossible to keep up and write good CSS. It's no longer easy to do it by hand which is why there is a whole ecosystem of tooling that handles CSS. Not to mention that CSS is essentially platform-specific due to differences between chrome, safari and firefox.

Some tooling is for managing the complexity caused by complexity of the site/app.

Some tooling is managing the complexity of managing component-centered design (particularly scoping); it's a very positive approach to design but it's not without its problems.

Some tooling is to help developers avoid having to actually learn the CSS language well and/or to force it into JavaScript.

> CSS is essentially platform-specific due to differences between chrome, safari and firefox.

That's an exaggeration. Consistency of implementations between browsers is better than its every been. There are still some vendor-prefixed properties to care about, especially if one is generous in one's support for older browsers, but that's another reason CSS tooling exists, to write only standard CSS and let the tool fill in the older variants.

Re: You want enabling CSS selectors, not disabling ones

#52

Post by eyelidlessness » Wed, Sep 01, 2021, 1:56 AM UTC

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.

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

Re: You want enabling CSS selectors, not disabling ones

#53

Post by chrismorgan » Wed, Sep 01, 2021, 1:59 AM UTC

jontro wrote: post #2

I don't see why 0 should be treated as special value. Initial should be used if meant to "disable" it. What if you want margin: 5px as the general rule and margin: 10px on the last element. Is 10px a disabling selector?

> Initial should be used if meant to "disable" it.

`initial` isn’t any better than 0 for this sort of purpose. `unset` and `revert` are probably less bad; I’d tend to choose `unset`.

Re: You want enabling CSS selectors, not disabling ones

#54

Post by eyelidlessness » Wed, Sep 01, 2021, 2:04 AM UTC

ArchieMaclean wrote: post #21

politician wrote: post #19

Is there a language that compiles to CSS but excludes the decades of cruft that have accumulated in CSS? Something that just exposes a few key primitives and jettisons the rest even if that means it doesn't handle some extreme edge cases?

I think the hard part with this is that because CSS properties are so context-dependent, the compiler would have to somehow figure out a way to translate your simple property into the correct one, without knowing how your HTML is structured. For example: .thing { topgap: 10 } .other { topgap: 10 } Would have to compile to different things if .thing was in a flexbox and .other was in a grid or a box. Since a lot of HT…

This is a case where build tools surprisingly shine. Example: if you use Fela (CSS-in-JS atomic style library), but build statically, it has all the context it needs to determine optimal order of rules and which rules are actually in use… but you can pipe the styles wherever you want at build time and eliminate the runtime for anything static.

(I use this on my site. It’s suboptimal for build and could use a mountain of refactor. But the source is up on my GH if anyone’s curious)

Re: You want enabling CSS selectors, not disabling ones

#55

Post by extra88 » Wed, Sep 01, 2021, 2:06 AM UTC

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.

Re: You want enabling CSS selectors, not disabling ones

#56

Post by chipotle_coyote » Wed, Sep 01, 2021, 2:07 AM UTC

juped wrote: post #50

leephillips wrote: post #35

Earlier quoted context omitted.

That site is black on white¹, and has no other colors, images, fancy borders, nor any other obvious “design”—and yet it is remarkably pleasant to look at, even beautiful. The site sells the authors’ ideas; they obviously know something. (Plus no doorslams, cookie warnings, or other annoyances. And an RSS feed.) [1] Really very dark grey on very light grey.

"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?

Re: You want enabling CSS selectors, not disabling ones

#57

Post by tenaciousDaniel » Wed, Sep 01, 2021, 2:08 AM UTC

politician wrote: post #19

Is there a language that compiles to CSS but excludes the decades of cruft that have accumulated in CSS? Something that just exposes a few key primitives and jettisons the rest even if that means it doesn't handle some extreme edge cases?

I've been in the process of designing exactly such a language. It's nowhere near ready, but my goal is to create a design tool that can edit this language either using a figma/sketch like GUI or by editing the code directly.

Re: You want enabling CSS selectors, not disabling ones

#58

Post by extra88 » Wed, Sep 01, 2021, 2:17 AM UTC

mewpmewp2 wrote: post #24

It might be subjective, but I disagree, for me it would be easier to reason, read and maintain the first way, preferably with scss, so you nest the last child. Maybe it is because that's the pattern I have most faced, though. And I think definitely avoid li + li. It wouldn't be immediately obvious at all for me if I saw that, what the intention is.

> I think definitely avoid li + li. It wouldn't be immediately obvious at all for me if I saw that, what the intention is.

Nothing unfamiliar is obvious. As with any language, get to know the capabilities of CSS better and it will feel familiar. The article is right that for spacing, the `gap` property on the parent makes more sense but hasn't been around long enough, we need some more older browsers to age out (especially when used with Flexbox).

Re: You want enabling CSS selectors, not disabling ones

#59

Post by Brendinooo » Wed, Sep 01, 2021, 2:25 AM UTC

extra88 wrote: post #47

politician wrote: post #19

Is there a language that compiles to CSS but excludes the decades of cruft that have accumulated in CSS? Something that just exposes a few key primitives and jettisons the rest even if that means it doesn't handle some extreme edge cases?

> decades of cruft that have accumulated in CSS Like what? I assume there's some CSS that doesn't have a use anymore but thinking about layout, we don't need floats for page layout but that was basically a hack, float is still useful for its original purpose. Basically, the CSS spec isn't full of cruft but there are a lot of CSS practices that are no longer needed.

Was just thinking about this the other day. Once aspect-ratio gets Safari support, that will take away the need for the height:0/padding-bottom: 66% thing, which is one of the last hacky bits of CSS that I use regularly. Container queries will fill another huge hole, but I don't polyfill/do hacky things for that in the meantime.

CSS really does do pretty much everything you need these days.

Re: You want enabling CSS selectors, not disabling ones

#60

Post by extra88 » Wed, Sep 01, 2021, 2:27 AM UTC

poniko wrote: post #4

yes but no .. seems like a weird rule that makes it harder to understand and read. A flow of default, exception, exception is easier to follow. And What if you have odd even, every third etc etc ..

> What if you have odd even, every third etc

The solution is the same. `:nth-child(3n)` selects every third so you add the :not(:last-of-child) to the end to prevent it from being matched by the rule.

    .card:nth-child(3n):not(:last-of-child) {
      /* styles for every third card, not the last card */
    }

What's less clear to me is why `.card + .card` would be better for applying a style to all but the first card than `.card:not(:first-child)`. I think there are reasons for not using `*:not(:first-child)` and preferring the "lobotomized owl" `* + *` but my hunch is they don't apply when styling classes.