Drop exact duplicate declarations from output CSS within a style rule #18809
+123
−18
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 #18178
When someone writes a utility like
after:content-['foo']
it'll produce duplicatecontent: var(--tw-content)
declarations. I thought about special casing these but we already have an optimization pass where we perform a full walk of the AST, flattening some rules (with the&
selector), analyzing declarations, etc… We can utilize that existing spot in core to analyze and remove duplicate declarations within rules across the AST.The implementation does this by keeping track of declarations within a style rule and keeps the last one for any exact duplicate which is a tuple of
(property, value, important)
. This does require some additional loops but preseving the last declaration is important for correctness with regards to CSS nesting.For example take this nested CSS:
It expands to this:
If you remove the last rule then a
<div class="foo bar">…</div>
will have green text when its supposed to be red. Since that would affect behavior we have to always preserve the last declaration for a given property.We could go further and eliminate multiple declarations for the same property but this presents a problem: every property and value must be understood and combined with browser targets to understand whether or not that property may act as a "fallback" or whether definitely overwrites its previous value in all cases. This is a much more complicated task that is much more suited to something light Lighting CSS.