Comments (13)
"ignoreLonghands": ["text-decoration-thickness"]
This is indeed very useful as an escape hatch when user notice that their CSS is altered in incorrect ways.
But it does expect users to notice. I fear that most will assume that Stylelint knows best and will get frustrated when they eventually find that Stylelint is breaking their code.
We could have automation/signals to help us update this rule more quickly (@webref/css
has data for longhands, shorthands, logical groups, ...)
Ultimately this is also an upstream issue :)
Adding constituents to a shorthand or making a longhand into a shorthand is a breaking change in CSS itself. So it also breaks downstream tools (e.g. Stylelint)
from stylelint.
At the minimum add
"ignoreLonghands": ["text-decoration-thickness"]
.
I think this will not resolve the fundamental problem with this rule. First of all, we should discuss if this rule should be present the shared config.
from stylelint.
Aside:
Wanted to say that none of this is feedback on the hard work that so many people have been putting into this rule :)
It is a really complicated subject that is non-trivial to get right and maintain.
This is mostly an illustration of how complexity cascades. Shorthands are significant complexity in CSS itself and any tooling that touches on shorthands will also encounter complexity.
from stylelint.
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.
from stylelint.
@romainmenke Thanks for opening the discussion. Your thought is very interesting for me, especially:
The issue here is not
text-decoration
itself, but that changing longhands to shorthands is a very impactful source code change.
Currently, we have turned on this rule in our standard config:
https://github.com/stylelint/stylelint-config-standard/blob/3c610c147cc6c20b9e24292ff002b4637d55d3bc/index.js#L55
But, considering recent bugfix reports, it seems that we should remove the rule from the shared config at least.
For this point, @Mouvedia may have any thoughts.
from stylelint.
Concerning #7232, I have introduced an option with the fix so that the impact can be mitigated.
Concerning large scale impacts, I have advised to update stylelint/stylelint-config-standard
with "ignoreLonghands": ["text-decoration-thickness"]
as a fail-safe in this comment.
changing longhands to shorthands is a very impactful source code change
I think I did my due diligence in that issue to explain the impact in minute details and introducing a secondary option with the fix.
This issue intended for discussion around this topic and to make sure that this aspect of this rule is in line with the overal goals of Stylelint core rules.
Should this be moved to discussions?
If so can it be made public?
I personally don't have access to it.
For this point, @Mouvedia may have any thoughts.
I think the policy should be to introduce changes if the support reaches a certain threshold.
In the case of text-decoration-thickness
it's above 95% according to caniuse.
In that regard I think the discussion we had on stylelint/stylelint-config-standard#301 is relevant.
i.e. IMHO it's much more impactful for stylelint/stylelint-config-standard
and stylelint/stylelint-config-recommended
From a maintainer stand point, it's a matter of being careful about that type of changes.
e.g. not accepting a fix without an ignore option already available
from stylelint.
Should this be moved to discussions?
This has already the needs discussion
label, right?
from stylelint.
Should this be moved to discussions?
This has already the
needs discussion
label, right?
I was talking about https://docs.github.com/en/discussions
from stylelint.
I was talking about docs.github.com/en/discussions
We don't run GitHub Discussions since we've managed discussions by the label so far. This will not change in the future.
from stylelint.
The problem here is not only specific properties (e.g. text-decoration-thickness
), but also essentially difficult to handle transformation between longhands and shorthands.
If we can't easily resolve the problem, we should remove the rule from our shared config and even leave a warning in the rule doc, at least until the rule would become enough mature.
from stylelint.
When seeing the rule's implementation, custom logic for some properties have increased. Such a logic will be more, as new properties are added to CSS.
EDIT: If we had enough human resources, maturing the rule would be possible. However, as you know, there are a few people who can often work on this product. 😢
from stylelint.
But, considering recent bugfix reports, it seems that we should remove the rule from the shared config at least.
If we can't easily resolve the problem, we should remove the rule from our shared config and even leave a warning in the rule doc, at least until the rule would become enough mature.
At the minimum add "ignoreLonghands": ["text-decoration-thickness"]
.
Apart from #7610, I consider the other two missing autofixes minor inconveniences that wouldn't warrant the removal.
That's why I was so eager to fix it myself.
from stylelint.
But it does expect users to notice. I fear that most will assume that Stylelint knows best and will get frustrated when they eventually find that Stylelint is breaking their code.
Ah, this seems likely to me... We may need to even suspend the rule's autofix.
from stylelint.
Related Issues (20)
- CLI doesn't seem to work as expected. HOT 2
- [16.4.0] Cannot suppress `selector-max-universal` HOT 4
- Add regex support to `value-no-vendor-prefix` secondary option
- Provide links to message HOT 3
- Fix `shorthand-property-no-redundant-values` false negatives for `var()` HOT 10
- Add flags/options to set custom exit codes depending on the severity HOT 10
- TypeScript reports "Type 'CosmiconfigResult' is not generic" HOT 1
- Release 16.5.0 HOT 5
- Stylelint --fix does not fix two problems at the same time: the order/properties-order property, and the removal of extra empty lines. HOT 4
- no-missing-end-of-source-newline false positive after upgrade to v16.4.0 (from 15.11.0) HOT 1
- SCSS: Issue with double slash comment HOT 1
- DeprecationWarning: fs.Stats constructor is deprecated HOT 6
- Node.js API should allow fixing a list of files in-place HOT 3
- Rule idea: `declaration-prefer-shorthand` HOT 2
- Fix `selector-type-no-unknown` false positive for `model`
- Release 16.6.0 HOT 11
- Missing semicolon in JSON file HOT 5
- Fix `no-descending-specificity` false positives for nested selectors HOT 2
- Release 16.6.1 HOT 5
- breaking changes for `property-no-vendor-prefix` HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stylelint.