5 ms·

It's a little bit away from the domain of config files, but I think CSS is the most graceful example of handling this as a generalised problem. Style configurat

It's a little bit away from the domain of config files, but I think CSS is the most graceful example of handling this as a generalised problem. Style configurations cascade, and the last one read is the one that gets applied. There are overrides to that flow, but you have to very overtly add a piece of syntax to the overriding line like `!important`. Two overlapping overrides revert back to the "last read" approach. The approach is so fundamental to CSS that the entire language is named after it, so there's no ambiguity or forwards compatibility concerns in this regard whatsoever.

masklinn 3y ago
You might want to read on specificity because it’s a huge spanner in your assumptions.
- lioeters 3y ago
  > Specificity is the algorithm used by browsers to determine the CSS declaration that is the most relevant to an element, which in turn, determines the property value to apply to the element. The specificity algorithm calculates the weight of a CSS selector to determine which rule from competing CSS declarations gets applied to an element. https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity#how_is_specificity_calculated https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity...
lavela 3y ago
The rules of CSS specificity are a bit more involved than '!important' or not, and I frequently see beginners trip there, but apart from that I agree that the CSS rule set might be worth incorporating.
yard2010 3y ago
Fun trick to use if you use a css post processing (less, sass, etc.) is "&&&", it will resolve to a very specific rule which overwrites the other rules
blowski 3y ago
I’m sure you know this, but for readers who don’t, it’s much more complex than “last defined wins with a few override options”. Based on “specificity”, rules based on the selector used. Some examples: 1. #mydiv overrides .mydiv - IDs are more specific than classes 2. .outerdiv .innerdiv overrides .innerdiv - nested selectors are more specific 3. .mydiv overrides div - classes are more specific than elements And a lot of other rules. I can’t imagine I’d want this level of complexity in config files.
- deleted 3y ago
  [deleted]
- masklinn 3y ago
  Nesting is not actually more specific. Rather specificity is a triplet of (ids sub-selectors, class sub-selectors, element sub-selectors). When attributes conflict, the one whose rule has the more specific selector wins. The specificities of the rules you wrote out are (1,0,0), (0,1,0), (0,2,0), (0,1,0), (0,1,0), and (0,0,1). In-line attributes (@style) beat out out-out-of line ones except if they’re !important. Specificity also disambiguates between !important attributes.
  - blowski 3y ago
    Thank you for the clarification, I hadn't realised that.
- tobr 3y ago
  > I can’t imagine I’d want this level of complexity in config files. Lots of people don’t want it in their CSS either. It’s generally considered good practice to make everything the same specificity and avoid !important.
  - lavela 3y ago
    > avoid !important Sure, haven't seen that in a while in well structured code bases. > make everything the same specificity How would you achieve same specificity on everything? Only use either ids or classes? No type selectors / pseudo-classes / pseudo-elements / multiple selectors? I can't imagine how that would be feasible and am not aware of anyone recommending this.
fit2rule 3y ago
[dead]
wildrhythms 3y ago
Not true at all. There is a very much non-intuitive weighting system applied to CSS selectors which is what ultimately determines which gets applied: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
cesarb 3y ago
> Two overlapping overrides revert back to the "last read" approach. IIRC, there's an important (heh) exception to that: user stylesheets. Without the "!important" override on the user stylesheet, the site stylesheet wins; with the "!important" override on the user stylesheet, the user stylesheet wins, even if the site stylesheet also had an "!important" for that rule.
cerved 3y ago
The domain of style and configuration are very, very different. I'm not sure what works okay for displaying a website in different layouts on vastly different unknown devices share a lot of the same concerns of configuring programs on a machine

masklinn 3y ago

You might want to read on specificity because it’s a huge spanner in your assumptions.

lioeters 3y ago
> Specificity is the algorithm used by browsers to determine the CSS declaration that is the most relevant to an element, which in turn, determines the property value to apply to the element. The specificity algorithm calculates the weight of a CSS selector to determine which rule from competing CSS declarations gets applied to an element. https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity#how_is_specificity_calculated https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity...

lavela 3y ago

The rules of CSS specificity are a bit more involved than '!important' or not, and I frequently see beginners trip there, but apart from that I agree that the CSS rule set might be worth incorporating.

yard2010 3y ago

Fun trick to use if you use a css post processing (less, sass, etc.) is "&&&", it will resolve to a very specific rule which overwrites the other rules

blowski 3y ago

I’m sure you know this, but for readers who don’t, it’s much more complex than “last defined wins with a few override options”. Based on “specificity”, rules based on the selector used. Some examples: 1. #mydiv overrides .mydiv - IDs are more specific than classes 2. .outerdiv .innerdiv overrides .innerdiv - nested selectors are more specific 3. .mydiv overrides div - classes are more specific than elements And a lot of other rules. I can’t imagine I’d want this level of complexity in config files.

deleted 3y ago
[deleted]
masklinn 3y ago
Nesting is not actually more specific. Rather specificity is a triplet of (ids sub-selectors, class sub-selectors, element sub-selectors). When attributes conflict, the one whose rule has the more specific selector wins. The specificities of the rules you wrote out are (1,0,0), (0,1,0), (0,2,0), (0,1,0), (0,1,0), and (0,0,1). In-line attributes (@style) beat out out-out-of line ones except if they’re !important. Specificity also disambiguates between !important attributes.
- blowski 3y ago
  Thank you for the clarification, I hadn't realised that.
tobr 3y ago
> I can’t imagine I’d want this level of complexity in config files. Lots of people don’t want it in their CSS either. It’s generally considered good practice to make everything the same specificity and avoid !important.
- lavela 3y ago
  > avoid !important Sure, haven't seen that in a while in well structured code bases. > make everything the same specificity How would you achieve same specificity on everything? Only use either ids or classes? No type selectors / pseudo-classes / pseudo-elements / multiple selectors? I can't imagine how that would be feasible and am not aware of anyone recommending this.

fit2rule 3y ago

[dead]

wildrhythms 3y ago

Not true at all. There is a very much non-intuitive weighting system applied to CSS selectors which is what ultimately determines which gets applied: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

cesarb 3y ago

> Two overlapping overrides revert back to the "last read" approach. IIRC, there's an important (heh) exception to that: user stylesheets. Without the "!important" override on the user stylesheet, the site stylesheet wins; with the "!important" override on the user stylesheet, the user stylesheet wins, even if the site stylesheet also had an "!important" for that rule.

cerved 3y ago

The domain of style and configuration are very, very different. I'm not sure what works okay for displaying a website in different layouts on vastly different unknown devices share a lot of the same concerns of configuring programs on a machine