5 ms·

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 inst

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 5y ago
I hadn't heard of the owl selector for selecting :not(:first-child). Thank you for teaching me something new!
- Kavelach 5y ago
  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
  - goldenkey 5y ago
    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.
  - y4mi 5y ago
    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 5y ago
      > 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 5y ago
        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 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
  - edoceo 5y ago
    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 5y ago
      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 5y ago
    > 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 5y ago
      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 5y ago
        That sounds like a different problem from using the owl selector. That sounds like bad coding and app design.
- extra88 5y ago
  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-owls/ https://alistapart.com/article/axiomatic-css-and-lobotomized... [1] https://inclusive-components.design https://inclusive-components.design [2] https://every-layout.dev https://every-layout.dev
mizzao 5y ago
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 5y ago
  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 5y ago
  Tailwind has gap-[0] for flex and grid, and space-[0] for the “owl selector” approach. [0]: https://tailwindcss.com/docs/gap https://tailwindcss.com/docs/gap [1]: https://tailwindcss.com/docs/space https://tailwindcss.com/docs/space
the_other 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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.

goldenkey 5y ago

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

Kavelach 5y ago
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
- goldenkey 5y ago
  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.
- y4mi 5y ago
  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 5y ago
    > 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 5y ago
      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 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
- edoceo 5y ago
  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 5y ago
    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 5y ago
  > 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 5y ago
    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 5y ago
      That sounds like a different problem from using the owl selector. That sounds like bad coding and app design.
extra88 5y ago
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-owls/ https://alistapart.com/article/axiomatic-css-and-lobotomized... [1] https://inclusive-components.design https://inclusive-components.design [2] https://every-layout.dev https://every-layout.dev

mizzao 5y ago

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 5y ago
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 5y ago
Tailwind has gap-[0] for flex and grid, and space-[0] for the “owl selector” approach. [0]: https://tailwindcss.com/docs/gap https://tailwindcss.com/docs/gap [1]: https://tailwindcss.com/docs/space https://tailwindcss.com/docs/space

the_other 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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.