-
-
Notifications
You must be signed in to change notification settings - Fork 400
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
Specificity management #234
Comments
Currently we can control it with attach/detach. But this is not how you should do it. This specificity problem needs to be solved once forever. I think the only specificity that needs to be used is the order of classes in the class attribute. Source order dependency should vanish. One possible way is #203 |
Also yes a priority option in createStyleSheet(styles, {priority}) could be a workaround, but I fear that this will be hard to manage. |
I also used the !important in such cases, but this is very bad. |
Actually #203 will not solve specificity problems, this will just move specificity problem from source order to declaration order within one sheet. At the end order still matters. Fuck specificity. |
The problem with manual priority definition is that one component needs to know about priority of the other, which is a broken encapsulation. |
@trusktr Can you please detail a little bit more why do you actually need this ? I'm asking because I can't imagine a scenario when this would be a healthy thing to do, since , with or without a priority attached to stylesheets the 2 components will be tightly coupled to each other. In general we seek encapsulation of the components but it would be helpful to see a realistic scenario when this would not be desirable. |
@gcazaciuc Well, I suppose I don't really need it anymore because I made sure that an extending class attaches an extending stylesheet second (using React mount/unmount lifecycle methods). If class B extends class A, then I simply make sure that the order of the super method calls guarantees that sheets are attached/detached in order (and someone extending class B would have to do the same). I now think that this programmatic approach is better than priority numbers, since it is explicit. |
I don't see what we can do except of advising not passing class names across the components, but passing styles instead. |
@kof Good idea! So, instead of inheriting a classname in a child class just create only an entirely new class name after extending the style in JS. Gotcha! I'll apply that in infamous. |
How do we control stylesheet priority (cascade)? Is it the order in which we call the
.attach()
methods, so that a stylesheet attached second can override the first?What if stylesheets had some sort of priority, so that regardless of when they are attached one can always override the other?
f.e.
In that example, although stylesheet2 is attached after stylesheet1, stylesheet1 still cascades over stylesheet2 due to a higher priority number. Default couldbe
0
.The reason I ask about this is because I have two classes that can be created in any order, but one class has a style sheet that always needs to override the other.
The text was updated successfully, but these errors were encountered: