201–210 of 230 posts
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, flex…
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.
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.
Clever, but this smells like a performance anti-pattern. Adopting this means you could, at worst, add 4 spacer divs per component. While most sites may never really feel a sting, for complex apps where reusability is a larger concern you've doubled to quadrupled the size of an already large DOM and you will be hit a death-by-one-thousand-cuts situation. Now you've got more... - html over the wire - html to parse for…
I do agree generally, but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s. Nothing wrong with the suggestion, but it's just ironic that we seem to be coming full circle again. Next we'll probably have posts extolling components for layouts ;)
Time is a flat circle, and we're just going to be rehashing the same ideas endlessly every five years until the heat death of the universe.
We'll revisit old ideas from time to time after going the opposite extreme, but never in the same way.
I'd strongly advise learning what modern CSS can do thanks to grid, flex, column-count, gap, and rem units before bloating DOM tree diffs with empty div tags.
Clever, but this smells like a performance anti-pattern. Adopting this means you could, at worst, add 4 spacer divs per component. While most sites may never really feel a sting, for complex apps where reusability is a larger concern you've doubled to quadrupled the size of an already large DOM and you will be hit a death-by-one-thousand-cuts situation. Now you've got more... - html over the wire - html to parse for…
Why do you need to add spacer divs? As long as the child components accept classes as props then the styling comes from the parent but is still applied on the children.
I do agree generally, but it's funny that the suggested solution (spacers) are basically back to the old 1px transparent gif trick from the 90s/early 00s. Nothing wrong with the suggestion, but it's just ironic that we seem to be coming full circle again. Next we'll probably have posts extolling components for layouts ;)
Working at a boutique design shop back then, I remember trying endless combinations of the spacer tag along with spacer gifs to try to ship layouts that were at least semi (and hopefully mostly) consistent cross-browser.
Having lived through those web dev dark ages, I'm pretty baffled by the resurgence of 'markup as styling'.
Earlier quoted context omitted.
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
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
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
Earlier quoted context omitted.
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
> 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_.
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.