-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
What is recommendation for body
modifications
#17
Comments
Current status. Source CSS :.block {
:is(body.is-guest-mode) & {}
} This is invalid (in this rule) because it doesn't start with The autofix option can handle this case and transforms to :.block {
&:is(:is(body.is-guest-mode) &) {}
} This is overly complicated and too verbose. Simpler source :.block {
body.is-guest-mode & {}
body.is-guest-mode * {}
body.is-guest-mode .block {}
} autofixed to : .block {
&:is(body.is-guest-mode &) {} /* still a warning */
&:is(body.is-guest-mode *) {}
&:is(body.is-guest-mode .block) {}
} This is where you notice that the stylelint plugin doesn't try to interpret your selector. Some thoughts :
If I recall correctly I mostly wanted to avoid this : .foo {
:is(&:does-not-exist, .bar) {}
} In this example But this pattern is made invalid by requiring a top level
The current rule says :
Maybe better to actually do this :
This relaxed version does bring back a lot of complexity:
But it doesn't break the core principle of the coding style. I don't know if this relaxed version can have sane autofixing and I really like the current autofixing. |
.block {
body.is-guest-mode & {}
} becomes : .block {
&:is(body.is-guest-mode *) {}
} This is a better autofix because it preserves the specificity of the original and matches the same elements. This is still not allowed by this rule : .block {
:is(body.is-guest-mode) & {
}
} For now I want to try the currently allowed patterns. |
|
We (at Mr. Henry) don't write any nested CSS today because we only use features that are implemented in at least two engines. In the past we did write nested CSS but this made code reviews much harder. Because we are starting from a point where none of our CSS is nested it's easier for us to start with a really strict coding style and relax later where needed. If we start with something too lax and discover that nesting is harming code reviews again we will need to spend time on refactoring past work. Long way of saying : we don't have a current code style for I really like the pseudo's (
But we need to try this out over the coming months to have a better feel for what works well and what doesn't.
Yes, these are the same :) .block { &:is(body.is-guest-mode *) {} }
.block { body.is-guest-mode *& {} }
.block:is(body.is-guest-mode *) {} both desugared -> body.is-guest-mode *.block {}
|
Sometimes I code like this:
For me, it is like
@media
and I write it by CSS nesting:Here is a real world example.
Should we allow it in nesting rule?
The text was updated successfully, but these errors were encountered: