Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-extend-rule] Selectors specificity #40

Open
AndySky21 opened this issue Apr 9, 2015 · 1 comment
Open

[css-extend-rule] Selectors specificity #40

AndySky21 opened this issue Apr 9, 2015 · 1 comment

Comments

@AndySky21
Copy link

Hi Tab!
I was directed to your proposal about the @extend rule by François Remy as an answer to another user asking about custom "classes", I admit I had never heard of it.
While I find it quite intriguing, there are some issues I'm not fully convinced about.

  1. The way you solve specificity conflicts is counter-intuitive: in your model, when two rulesets A1 and A2 are @extended by another ruleset B, A1's and A2's specificities are not taken into account to determine which rule prevails. Only the ruleset's position accounts. But I think that authors are used to deal with that subject and the outer ruleset's specificity should be used to resolve it. See below.
  2. I also add that, in your scenario, mixing @extended rules and natural rules leads to confusing results:
    .red-text { color: red; border: 1px red solid;}
    .blue-text { color: blue; border: 1px blue dashed}
    #sidebar { @extend .red-text; border-width: 2px;}
    div { @extend .blue-text; border-style: dotted;}
    So, color specified in div block prevails, but I'm trying to overwrite the style of border and I'm not allowed to do so, because tag specificity is lower than class. On the other hand, id selector specificity is superseded, because its extension rule is overridden, but the rule about border width prevails over both extension declarations because it's part of an id-based ruleset. In larger scenarios it worsens exponentially.
  3. I would propose this: dropping the possibility of using "real" selectors in @extend and keeping the part about %placeholders would solve every problem. If 2 rulesets need the same rule, well, they will simply extend the same placeholder, while one of them can overwrite or expand on it.
    Also, placeholders need no specificity on their own in my opinion: their rules should receive the specificity of the block that @extends them, so that if an author wants to partially overwrite it, all s/he has to do is specify a rule "correction" after the placeholder call:
    %red-text { color: red; border: 1px red solid;}
    #sidebar { @extend %red-text; border-width: 2px;}
    div { @extend %red-text; border-style: dotted;}
    Here both declarations about border properties would overwrite the %red-text placeholder, just because they follow it and not because of specificity (also note that in this case you would use @extend only for placeholders, so you could find a more compact syntax for @extending %placeholders, namely #selector {(%placeholder); ...})

Please let me know if this is technically feasible, and also whether I tried too hard with this "issue". And thank you for your invaluable work.

@jonathantneal
Copy link
Contributor

I was about to write nearly the same issue with less eloquence. Think you could fork the .bs file, make these changes, and submit it back as a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants