-
-
Notifications
You must be signed in to change notification settings - Fork 929
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
Rule options where users set selectors #7557
Comments
@romainmenke Thank you for opening the discussion. I think your concern absolutely makes sense. With the modern syntaxes or components (e.g. nested selectors, At this point, the ignoring behavior of each rule depends on the selector parser mostly. |
To make an informed choice we need a list of all the rules which are affected by the
Without that list I can't tell which route is better, sorry. I have added this issue to the Nesting sublist of #7396. |
Depending on the rules, resolving nested selectors is valid or not.
I'm curious, how do you think specifically? |
The But what users maybe want is to disallow specific properties on certain DOM elements. When disallowing These would error p { width: 100px; }
p.foo { width: 100px; }
.foo p { width: 100px; }
:is(h5, p) { width: 100px; }
p:has(a) { width: 100px; } These would not error p .foo { width: 100px; }
p ~ h2 { width: 100px; }
:not(p) { width: 100px; }
div:has(p) { width: 100px; } The proposed mechanic:
The edge case that won't be caught: <p class="foo"></p> .foo { width: 100px; } I am ignoring how complex this would be to create. |
A completely different strategy (and simpler to implement) is to have a well known way to normalize selectors.
leaving it vague what Setting the correct options would be easier for a wider range of selectors. |
That sounds ideal.
Incremental improvement is also a possibility.
If the way contradicts what our rules are doing currently, it would be a breaking change. |
@romainmenke @Mouvedia Thank you for your feedback. I also believe the suggestions for During the process of such steps in implementation, we could discover many ideas or improve the current implementation or documentation. I basically welcome such attempts toward modern CSS, although we have to care about compatibility! |
I am purposefully ignoring compatibility for now in this issue, not because I do not think it is important, but because I first wanted to see if this direction is something we want to pursue at all :) For me compatibility is mostly about communication and planning. If we don't want it anyway (not all ideas are good ideas), then we don't even need to discuss how to handle potential breaking changes. If it isn't feasible for technical reasons, then we also don't need to think about the compat issues :) I have a couple of technical concerns with this idea:
This would dramatically slow down these rules.
|
Since new features have entered the CSS world today, I predict people will want more accurate parsing.
For performance, we need to actually measure new implementations, right? We might be able to provide opt-in and experimental options to see actual performance or users' evaluation, for example. |
Since the parsed result is never mutated and only used for analysis we could also cache this. Then each unique selector string would only need to be parsed once, instead of every selector needing to be parsed for every rule. So even if measurements indicate that is is really slow, we might still have options :) |
It seems that you are slowly coming to a resolution yourself. |
Opening a new issue to discuss this separate from any individual bug report or refactor because I am first looking for some guidance on which direction is more favorable.
Examples :
rule-selector-property-disallowed-list
: disallow specific properties when a selector matches a patternselector-disallowed-list
: disallow a list of selectorsIt used to be relatively fine to treat selectors as strings and to use tools like regex but I don't think this works well anymore.
With nesting it is ambiguous if users want to match the resolved or unresolved string.
Even when they agree they want to match the resolved string they might not agree on the method (sass like or following the spec).
But that is not the only bit of complexity.
:not()
is a negation, so should:not(input) { width: 100% }
error when disallowingwidth
for/input/
?:has()
matches elements when other elements match a selector, not when it itself is something. Same as before, should this error:has(input) { width: 100% }
?The underlying issue is that string matching can only go so far and that the outcome will always be surprising to some users.
I personally think that there should be an effort to use a more semantic approach.
Alternative we could embrace that these rules operate on strings and that they are agnostic of parent rules, nesting, selector matching mechanics,...
Any rule that enforces something onto tags, classnames, types, attributes will be unaffected by this. They already target specific selector parts.
A concrete example is : #7488
This rule treats selectors as strings and doesn't consider their semantic meaning or which elements they would match.
Updating that rule so that nested selectors are resolved would be surprising as it can radically change what does or doesn't give errors.
Note
Keep in mind that nesting has an implicit
&
so
.foo { input {} }
would resolve to.foo input
and would no longer match"input"
as a plugin option.That alone would be a breaking change.
But the same rule would also be really helpful if it was implemented differently.
It could look at selectors in the same way browsers do and only disallow properties when the right most compound selector would be a semantic match.
I think that handling this case by case always favors the current bug reporter as we all want to help people :) This might mean that we accidentally end up somewhere that is worse instead of better.
So I am looking for input here as I don't know what others think is the better solution here.
The text was updated successfully, but these errors were encountered: