-
Notifications
You must be signed in to change notification settings - Fork 187
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
Added support for nesting #368
base: master
Are you sure you want to change the base?
Conversation
CLA signature looks good 👍 |
@Sibz thanks for the PR. Can you add some tests for this change? Also, I'm curious if this only handles a single level of nesting or multiple levels? |
Multiple levels is supported. I am very busy at the moment so writing tests isn't something I can do right away. I was able to whip up a merge request because it was basically sitting right there ready to hit create pull request :) Also writing tests isn't my strong point. |
No rush, but this should have tests. You have a couple of test cases already in your commit message. I'm not very familiar with this repo, but I'm sure there are already some tests for media queries that we could build off of. |
I found a test for custom handler in generate_test.js that could be used as a starting point, see https://github.com/Khan/aphrodite/blob/master/tests/generate_test.js#L336-L350. |
I'm no longer a maintainer of this repository, so I don't have final say, but in designing aphrodite, we intentionally did not support this, because if you define two descendant selectors like this, then the order those styles are injected will affect the final result, which can lead to really confusing results. The README contains an explanation of why this is important: https://github.com/Khan/aphrodite#overriding-styles The same issue is explored as a caution when adding extensions into aphrodite: https://github.com/Khan/aphrodite#advanced-extensions This specific problem was exactly why we wanted descendent selectors to be handled by extensions rather than it being part of core, since it's very easy to end up with really surprising behaviour depending on what order styles are injected into the page, and we want that surprising behavior to be opt-in, rather than a part of aphrodite core. As it stands, AFAIK, without extensions, Aphrodite guarantees that the order of style injection will not affect what style is finally applied. |
Yeah I tend to agree with @jlfwong. It's probably best left for extensions to avoid confusing behaviour out of the box. |
@jlfwong thanks for calling this out. Maybe we can include this in the package in an extensions folder. That would make it easier for people to opt in to this functionality if they want. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Request that this be changed to an extension.
Enabled targeting of descendants, i.e.:
.myForm_ae213c .my-descendant-class
For all descendants of class my-descendant-class in myForm_ae213c
.myForm_ae213c > .my-descendant-class
For all immediate child descendants of class my-descendant-class in myForm_ae213c
Closes#319