[roman-holovin]

That's very reductionist approach. Sure, margin is a sharp tool and you need to use it responsibly.

I avoid putting margins on "first"-level selector.

So instead of

    .button {
      margin-left: 16px
    }

I do

    .parent > .button {
      margin-left: 16px
    }

Difference is that I can reuse '.button' elsewhere without modifications.

Another point to consider is that margin is not the only CSS property that affects layout. Both grid, flexbox and 'position' properties should be used with same care. And approach I highlighted above is usually good enough.

For margin specifically there is also a "owl" selector that makes is a bit easier to manage

    .parent > * + * {
      margin-top: 16px; // OR
      margin-left: 16px;
    }

[goldenkey]

I hadn't heard of the owl selector for selecting :not(:first-child). Thank you for teaching me something new!

[extra88]

The term was coined by Heydon Pickering [0]. He's great, also responsible for the useful site Inclusive Components [1] and one of the authors of Every Layout [2].

[0] https://alistapart.com/article/axiomatic-css-and-lobotomized...

[1] https://inclusive-components.design

[2] https://every-layout.dev

[Kavelach]

Note that the owl selector is pretty slow when it comes to being processed by browsers. If you use it sparingly, it shouldn't be so bad, but leave it all over the place, and you'll see the impact

[y4mi]

Ha, when I first learned about it I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version.

Its performance was not just measurably worse, it was obvious as soon as I opened the revision on my phone.

Lesson learned: it's important to think twice before using most pseudo selectors

[Kavelach]

> I remade a pretty interesting navigation menu purely with :not :checked :focused :hover etc, so pure html and css, thinking it would be more performant then my previous JS version.

That sounds so cool! Do you have a version somewhere that I can take a look at? I always like fiddling with clever CSS, even if it is too clever for its own sake, as you managed to find out

And keep in mind, that pseudo selectors are not created equal. Things like :checked or :focused usually don't have that much of a performance impact

[y4mi]

Sadly no, I tried for a while until I finally threw in the towel at some point.

I think you're overestimating what I did though, the basic idea is this recreation.

https://codepen.io/wohlben/pen/gOGKejv

it was just a lot more elements in the navigation with subcategories etc, but basically the same methods

(remember to check the mobile view, as thats the one thats using most selectors. Though the desktop view is arguably better)

this recreation is probably very confusing though, as the only hint that there are more links hidden for the category are the missing corners - and there is nothing hinting you have to click the category names to show these hidden options. and i skimped on proper accessibility for this mockup, so the hidden options can't be selected without touch/mouse

The JS just emulates what opening the page would have done. It was SSR

[the_other]

> owl selector is pretty slow when it comes to being processed by browsers

I'm sure this hasn't been relevant for about 15 years. CSS rendering is _fast_.

[Kavelach]

As I mentioned above - one or two clauses like that won't hurt performance, but I have seen situations, when bad CSS (a lot of *'s, too long selectors, a lot of dead and unused clauses) actually had a measurable impact on websites' performance.

This especially comes into play, if you deal with a lot of nested HTML elements or when you modify the site's HTML a lot.

[the_other]

That sounds like a different problem from using the owl selector. That sounds like bad coding and app design.

[goldenkey]

Is there a place to see css benchmarks on modern browsers, like jsperf used to be for JS?

It seems like > *+*, *:not(first-child), *:nth-child(1+n) and *:last-child { ...revert... } are all equivalent. I would be curious to know which is most efficient.

[edoceo]

How can one even test the performance of these selector? I've been have a few pages that feel slow, and have some exotic selectors, but I've no clue what tools to uses. And searches for CSS performance tell me lame things like: minimize and use a CDN. I have the XY problem.

[mst]

Try adding 'browser' and/or 'layout' as keywords for your searches - that seems to surface stuff about the relevant sort of performance.

(this semi helpful advice brought to you by mst's complete lack of front-end chops meaning concrete help will have to come from somebody else ;)

[the_other]

You have the same understanding as the OP. The difference is that the OP is working on a component-based framework. In such a framework, it makes sense to declare the rule defining child margins *in* the parent component's code, not in the child's code.

[city41]

But why do it with extra elements? The child should accept a class or possibly styles and the parent decides what those are.

Child directly styles itself with color, font, internal layout, etc

Parent positions child with flex box, grid, margin or absolute positioning. Spacer elements are not needed at all.

[the_other]

I think I see what you’re saying now. You are wondering why have dedicated layout components when you could “simply” get any component to define styles on its children?

You could do it that way too. However, when you reply on your component system to help assemble a UI, the components take on the encapsulation role you’d use rich selectors for in other situations. A layout component performs the same function as a utility css class, but is more idiomatic.

[city41]

The article is about spacer elements. As in an empty div that takes up space so things next to it get moved into place. I'm arguing that isn't necessary, as css has plenty of tools for laying things out. I have no issue with components that focus on layout, that is fine. A div that uses say flex box to layout a set of children is quite common. I'm arguing that parent div does not need spacer elements, you can always accomplish the layout you need with standard css such as flexbox, grid, margin, etc.

[mizzao]

Is there a easy way to do this with a utility framework like tailwind? It just makes it so tempting to throw the margin on a component.

[roman-holovin]

This is one reason I'm not really into utility frameworks. They are able to deal with "appearance" part of the CSS just fine, but layout part is too rigid and inflexible.

You can use plain old CSS for layout purposes and mix it with utility classes for appearance.

You can do:

    <div class="actions">
        <button class="h-10 px-6 font-semibold rounded-md bg-black text-white" type="submit">
          Buy now
        </button>
        <button class="h-10 px-6 font-semibold rounded-md border border-gray-200 text-gray-900" type="button">
          Add to bag
        </button>
      </div>

And then:

    .actions {
        display: flex;
        justify-content: flex-end;
        align-items: center;
    }

    .actions > * + * {
        margin-left: 16px; // or better use var from tailwind to set sizes consistently.
        @apply: ml-5; // or do this https://tailwindcss.com/docs/reusing-styles#extracting-classes-with-apply
    }

This should combine those techniques, but I haven't used it in practice. And I'm sure in this case you will be labeled as heretic by both people who don't use utility frameworks and those who do ;)

[deergomoo]

Tailwind has gap-[0] for flex and grid, and space-[0] for the “owl selector” approach.

[0]: https://tailwindcss.com/docs/gap

[1]: https://tailwindcss.com/docs/space