-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Don't prefix arbitrary classes in peer
/group
variants
#11454
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thecrypticace
force-pushed
the
fix/no-prefix-group-peer
branch
from
June 19, 2023 13:39
464c152
to
9fd458f
Compare
thecrypticace
force-pushed
the
fix/no-prefix-group-peer
branch
from
June 28, 2023 14:08
a29b748
to
48535a1
Compare
thecrypticace
force-pushed
the
fix/no-prefix-group-peer
branch
from
June 28, 2023 14:40
48535a1
to
1b651fc
Compare
Then add the `NoPrefix` feature to the variant itself, which will skip prefixing any other class in the generated selector (because we already took care of prefixing `.group` and `.peer`). We are using an internal symbol such that: - We can keep it as a private API - We don't introduce a breaking change
RobinMalfait
force-pushed
the
fix/no-prefix-group-peer
branch
from
June 28, 2023 16:05
4341237
to
504fd19
Compare
We will still use a symbol as an internal/private marker, but the data itself will be a simple object for now. If we want to refactor this (and more) in the future using bitflags then we can refactor that in a separate PR.
thecrypticace
added a commit
that referenced
this pull request
Jul 13, 2023
* Refactor * Don’t prefix classes in arbitrary values for group and peer * use `foo` instead of `lol` * handle the prefix inside the group/peer variants Then add the `NoPrefix` feature to the variant itself, which will skip prefixing any other class in the generated selector (because we already took care of prefixing `.group` and `.peer`). We are using an internal symbol such that: - We can keep it as a private API - We don't introduce a breaking change * refactor to simple object instead We will still use a symbol as an internal/private marker, but the data itself will be a simple object for now. If we want to refactor this (and more) in the future using bitflags then we can refactor that in a separate PR. --------- Co-authored-by: Robin Malfait <[email protected]>
thecrypticace
added a commit
that referenced
this pull request
Jul 13, 2023
* Refactor * Don’t prefix classes in arbitrary values for group and peer * use `foo` instead of `lol` * handle the prefix inside the group/peer variants Then add the `NoPrefix` feature to the variant itself, which will skip prefixing any other class in the generated selector (because we already took care of prefixing `.group` and `.peer`). We are using an internal symbol such that: - We can keep it as a private API - We don't introduce a breaking change * refactor to simple object instead We will still use a symbol as an internal/private marker, but the data itself will be a simple object for now. If we want to refactor this (and more) in the future using bitflags then we can refactor that in a separate PR. --------- Co-authored-by: Robin Malfait <[email protected]>
thecrypticace
added a commit
that referenced
this pull request
Jul 13, 2023
* Refactor * Don’t prefix classes in arbitrary values for group and peer * use `foo` instead of `lol` * handle the prefix inside the group/peer variants Then add the `NoPrefix` feature to the variant itself, which will skip prefixing any other class in the generated selector (because we already took care of prefixing `.group` and `.peer`). We are using an internal symbol such that: - We can keep it as a private API - We don't introduce a breaking change * refactor to simple object instead We will still use a symbol as an internal/private marker, but the data itself will be a simple object for now. If we want to refactor this (and more) in the future using bitflags then we can refactor that in a separate PR. --------- Co-authored-by: Robin Malfait <[email protected]>
This was referenced May 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #11384
This PR stops us from prefixing selectors in the
group
andpeer
variants.For example, given the following HTML:
The generated selector would contain
.tw-foo
instead of.foo
as the user intended:Whereas this should be the selector that is generated
The reason this happens is because of the design of the
addVariant
andmatchVariant
APIs. We build up a one or more selectors that are used to "modify" the resulting utility selector in your CSS. After we've build up the final list of "changes" to a given utility, taking into account all it's variants, we then add prefixes to all classes in the selector (for example,group
becomestw-group
,dark
becomestw-dark
,underline
becomestw-underline
, etc…). The problem with this approach is, at this point, there's no information about what data was derived from arbitrary values and thus no mechanism by which we can say "prefix class.a
but not.b
" or "prefix.a
but not in this one instance".How is it that we don't know? After all, aren't we matching against the utility?
Take for example this very simplified version of the group variant:
When matching the utility
group-[.bar]:flex
and building its rule we then process thefoo
variant and generate a selector. We place the value.bar
in for thevalue
parameter and the function returns.group.bar &
.This is almost as if we had written this:
You'll notice here there are no prefixes present yet — this is because, in general, this is handled later in the pipeline for variants.
Now, we explicitly call
prefix
function for thegroup
class and disable prefixing later in the pipeline for this variant only. This effectively treats the variant as if it were defined like so:In which case no prefixing is done after building the variant selector because it includes prefixes already.
Now, given that existing user plugins may be defining variants AND those variants have their classes prefixed we can't just disable it wholesale and expect it to be handled in the variant. Additionally, since there's no information about what data was derived from arbitrary values (AND don't even have to be selectors!), to preserve backwards compat while also fixing this we've updated the
group
andpeer
variants specifically such that:group
,peer
,group/name-here
,peer/name-here
, etc… classes are prefixed inside the variant function that generates the selector.respectPrefix
— much like therespectPrefix
flag present inaddUtilities
,matchUtilities
,addComponents
, etc…This flag is left as internal for now as we want to be sure of the API before we expose it to user-land, work on documentation, etc…