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
declaration-block-no-redundant-longhand-properties
needs to be value type aware
#7631
Comments
Extra disclosure : I don't use this rule and actually actively push team members to use longhands over shorthands. I want this rule to work well for those who want to use it, but I am not attached to or invested in it. |
@romainmenke Thanks for opening the discussion. This issue is related to #7630 from the point of view of:
|
Yes, indeed related but distinct aspects :) Edit: there might be other implementation issues, these two are the ones that stand out for me personally. |
Regarding value type awareness for autofixes, I knew that the rule lacked it. I don't consider it major for 2 reasons:
Would not autofixing because the values are invalid be a breaking change?
❤️ |
I wonder if the tools (
Largest concern with such a direction is that |
I already voiced the fact that at least one of the core maintainers of stylelint should be able to merge PRs on csstree/csstree.
Again at what cost?
|
Yes, any extra parsing implies a performance cost.
I see it not as an enhancement but more a potential building block. If we stick with the While Expanding the type from Can it do the inverse? |
Concerning worthy refactors, I would consider the autofix with optional longhands missing a priority.
Now we are getting somewhere. Offloading the responsibility to a dependency which is well maintained by formatting the raw into a compatible input would be interesting if it had the additional benefit of validating the values; I agree.
#7609 is relevant in that regard. |
declaration-block-no-redundant-longhand-properties
large operates on value order and doesn't consider value types.Converted to :
https://stylelint.io/demo/#N4Igxg9gJgpiBcICGACYAdAdugLjmAHjgLSyQBOSOAlhJsQM44CeANjPClBHjFANxZc+IqRgUqteq2qYOKcn0HZeoshEo06xSKw2cArpljkZc5QF8hmAEZohqkus1TGLdp268BDkU-Eaktpm8kYmIcrChP4SWvS6+gpKWBYgADQgAGbU7ABySAC2cIiEhQAO7AB0YAwM6eB02QDmCCAYmCgo6CDRMMYM3ZwA2lidnd1MbDBmJJCYzW5IxkjkUN2jKAC6KfVzzQBiGgVUrQBWDHT1sGV1iO3jIJPsM4NdIKxUMEzdaRsT7tNZLNGtQmotlqtXt0PvhviAdhYgA
Or even more exotic :
Converted to :
https://stylelint.io/demo/#N4Igxg9gJgpiBcICGACYAdAdugLjmAHjgLSyQBOSOAlhJsQM44CeANjPClBHjFANxZc+IqRgUqteq2qYOKQdl6iyESjTrFIrNZwCumWORlyU5PooC+IADQgAZtXYA5JAFs4iQu4AO7AHRgDAy24HSOAOYIIBiYKCjoIIT4hgyJnADaWPHxiUxsMCYkkJiRjDhIhkjkUInZKAC6WNZ2JZEAYmpuVNEAVgx0obA+IYixuSD57EXpCSCsVDBMiTb1eSzTssXh1BHllVDVtQhzC-jLIM0glkA
You could argue that in this case the input is bogus, so that the output is unexpected is fine but this does surface the underlying flaw in the implementation.
Longhand to shorthand conversion needs to fully analyze property and value pairs, check that they are valid and effectively calculate something more similar to the computed value for all longhands.
Only when this passes for all known constituents properties would it be safe to combine these.
The issue here is not
text-decoration
itself, but that the implementation is not sufficiently sturdy to be reliable in most cases.An implementation that is resilient to issues of this nature will be much more complex.
I don't know if this is desirable or worth it.
The text was updated successfully, but these errors were encountered: