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

Specificity management #234

Closed
trusktr opened this issue May 14, 2016 · 9 comments
Closed

Specificity management #234

trusktr opened this issue May 14, 2016 · 9 comments
Labels
question Documentation is not good enough.

Comments

@trusktr
Copy link

trusktr commented May 14, 2016

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.

stylesheet1.attach(5)
stylesheet2.attach(0)

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.

@kof kof added the enhancement No kittens die if we don't do that. label May 14, 2016
@kof
Copy link
Member

kof commented May 14, 2016

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

@kof kof added the bug It went crazy and killed everyone. label May 14, 2016
@kof kof changed the title stylesheet priority Source order dependency May 14, 2016
@kof
Copy link
Member

kof commented May 14, 2016

Also yes a priority option in createStyleSheet(styles, {priority}) could be a workaround, but I fear that this will be hard to manage.

@kof
Copy link
Member

kof commented May 14, 2016

I also used the !important in such cases, but this is very bad.

@kof
Copy link
Member

kof commented May 14, 2016

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.

@kof kof changed the title Source order dependency Specificity management May 14, 2016
@kof
Copy link
Member

kof commented May 14, 2016

The problem with manual priority definition is that one component needs to know about priority of the other, which is a broken encapsulation.

@kof kof removed the bug It went crazy and killed everyone. label May 15, 2016
@gcazaciuc
Copy link

@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.

@trusktr
Copy link
Author

trusktr commented May 24, 2016

@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.

@kof
Copy link
Member

kof commented May 27, 2016

I don't see what we can do except of advising not passing class names across the components, but passing styles instead.

@kof kof closed this as completed May 27, 2016
@kof kof added question Documentation is not good enough. and removed enhancement No kittens die if we don't do that. labels May 27, 2016
@trusktr
Copy link
Author

trusktr commented May 27, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Documentation is not good enough.
Projects
None yet
Development

No branches or pull requests

3 participants