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

Top level selector #10

Closed
iefserge opened this issue Apr 4, 2016 · 3 comments
Closed

Top level selector #10

iefserge opened this issue Apr 4, 2016 · 3 comments

Comments

@iefserge
Copy link
Contributor

iefserge commented Apr 4, 2016

Thank you, this module is awesome!

Wrapping selectors into class scope works well, but I haven't found a way to add styles at the top-level, i.e. to the scope directly.

Would it be a good idea to add support for a top-level & selector that resolves directly to the scope?

like

& {
  color: red;
}
.selector {
  color: green;
}

transforms into:

.scope {
  color: red;
}
.scope .selector {
  color: green;
}
@pazams
Copy link
Owner

pazams commented Apr 4, 2016

@iefserge , this would be a great feature.
Using the ampersand chartacher (&) is tricky since it's SASS/LESS syntax rather than pured css, and this plugin has to assume valid css.
Top level scope is still a good feature to add. Need to find the proper interface for it.
Perhaps- add a replace option. users will pass in a class for that option, and scopify will know to:

  1. do not add scope.
  2. replace the class with the scope.

thoughts?

@iefserge
Copy link
Contributor Author

iefserge commented Apr 6, 2016

@pazams replace option would work, but it feels a bit hacky. My thinking is that unscoped css should work exactly the same as scoped version within its scope. How about using body as a top level selector? The idea is that body can refer to the body of a component i.e. the scope itself.

so body { color: red; } transforms into .scope { color:red; }.

@pazams
Copy link
Owner

pazams commented Apr 8, 2016

@iefserge after re-thinking this through, I second my "valid css" assumption and therefore your initial suggestion seems to be the best solution.
I've seen you already coded and tested the solution in a fork,
so please send it as PR
tnx

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