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] examples are not convincing #38

Open
annevk opened this issue Jan 31, 2015 · 3 comments
Open

[css-extend-rule] examples are not convincing #38

annevk opened this issue Jan 31, 2015 · 3 comments

Comments

@annevk
Copy link

annevk commented Jan 31, 2015

It would help if this clarified why using .serious.error and .super.serious.error are not the obvious solutions they seem to be to the trivial problems from the examples.

@tabatkins
Copy link
Owner

If that was such a simple solution, Sass wouldn't have latched onto @extend. ^_^ I can grab more examples from the Sass community which shows it more obviously.

@tabatkins
Copy link
Owner

A few reasons:

  1. Naming isn't always so obvious. For example, the later %media-block examples wouldn't benefit from such naming - you'd have to spam "media-block" into the class attribute of the elements.
  2. The "state management" issue I bring up in the spec. You have to remember to remove all such "linked" classes when removing any. If you select all the .error elements and remove their class, you have to remember that some of them might also have a .serious and .super that you have to remove. If you mess this up, you leave a dangling class around that might mess things up later (such as when you add back .serious.error, intending it to just be a serious error, but it's styled as a super-serious one).
  3. Naming clashes. When you're using adjective classes like that, it's easy to accidentally create two things that both user ".super" as a modifier, for example, and mess up your styling when one part of the code base intends an element to be a "super foo" and the other intends it to be a "bar", but it gets styled as a "super bar".
  4. Specificity. Two or three classes instead of one means specificity is different. Whether this is good or bad is up to the authors, but it's definitely different, and it makes things a little more complicated.

@annevk
Copy link
Author

annevk commented Feb 1, 2015

To be clear, I'm not disputing the feature. It was just that when I read the examples my initial thought was that you could have just used a couple classes.

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

No branches or pull requests

2 participants