I got it immediately because I think I've been doing something similar for a while. I identified the problem it solves. I understand that if you haven't encountered the situation, it's probably hard to decipher.
It reads like: apply a top margin to all direct children that are not the first one.
I write like yours more often and avoid using * selector as much as possible in my CSS. Using :not(:first-child) is more obvious for me and my co-workers who will read that CSS selector.
avoid using * selector as much as possible in my CSS
So do I, I am somehow wired to think "* is going to be very bad for performance because now the rendering engine will need to apply this bunch of rules to any and every element on earth, which might not be only overkill, but which also might have undesirable side effect."
It might not really apply here but the feeling is present.
The difference between fastest and slowest is only 43ms (0.043 seconds), and I saw around this difference between rendering the same css twice. I think it is best to go for whatever is most readable for you. Personally I find :first-child the most understandable at a glance.
Actually, the only two comparable / equivalent options exposed in this page related to this discussion, ul > * + * vs li:not(:first-child), are 50.8ms vs 40.9ms (respectively) for 10 page loads. The browser is not named, so I would guess Chrome. I'm not convinced the difference is not proven significant, we need more data points than that to know for sure, but it seems insignificant. So yes, readability should be the determining factor here.
Other browsers might see different results, especially Firefox which has a very fast / efficient CSS engine.
ps: a difference of 43 ms for one page load would be huge indeed. By comparison, a frame in a 30 fps video is 33 ms.
For * + * versus :not(:first-child), I guess it's a matter of style. Maybe they are a bit different in the specificity of the rule, I don't know.
margin-block-* and margin-inline-* (versus margin-{top,right,bottom,left}) are more generic and take into account the writing-mode, direction, and text-orientation.
Notably, for instance, if you want to support both rtl and ltr languages, margin-inline-start (instead of margin-left) will behave correctly and put the margin at the correct side.
If you ask me, it's a step towards specifying/conveying the intent and not hard-coding the look.
Comments
The lines in question:
I got it immediately because I think I've been doing something similar for a while. I identified the problem it solves. I understand that if you haven't encountered the situation, it's probably hard to decipher.It reads like: apply a top margin to all direct children that are not the first one.
I write it like this:
I probably should start using -block-start. I'll keep my selector though I think.I didn't know about the default value parameter of --var, I'll probably use it too.
I write like yours more often and avoid using * selector as much as possible in my CSS. Using :not(:first-child) is more obvious for me and my co-workers who will read that CSS selector.
So do I, I am somehow wired to think "* is going to be very bad for performance because now the rendering engine will need to apply this bunch of rules to any and every element on earth, which might not be only overkill, but which also might have undesirable side effect."
It might not really apply here but the feeling is present.
https://www.reddit.com/r/web_design/comments/5u6e7b/comment/...
43ms is quite a slowdown isn't it? Handful of joules at least.
Actually, the only two comparable / equivalent options exposed in this page related to this discussion, ul > * + * vs li:not(:first-child), are 50.8ms vs 40.9ms (respectively) for 10 page loads. The browser is not named, so I would guess Chrome. I'm not convinced the difference is not proven significant, we need more data points than that to know for sure, but it seems insignificant. So yes, readability should be the determining factor here.
Other browsers might see different results, especially Firefox which has a very fast / efficient CSS engine.
ps: a difference of 43 ms for one page load would be huge indeed. By comparison, a frame in a 30 fps video is 33 ms.
:not applies to almost every element, so it's not any better.
very true indeed!
I haven't done CSS in about 6 years. So I don't understand why you'd ever use OP's version over yours?
For * + * versus :not(:first-child), I guess it's a matter of style. Maybe they are a bit different in the specificity of the rule, I don't know.
margin-block-* and margin-inline-* (versus margin-{top,right,bottom,left}) are more generic and take into account the writing-mode, direction, and text-orientation.
https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inli...
Notably, for instance, if you want to support both rtl and ltr languages, margin-inline-start (instead of margin-left) will behave correctly and put the margin at the correct side.
If you ask me, it's a step towards specifying/conveying the intent and not hard-coding the look.
Specificity is the difference:
* + * is 0,0,0.
:not(:first-child) is 0,1,0.
:where(:not(:first-child)) would take it back to 0,0,0.
I think you should keep writing it the way you are, I found it a lot clearer.