declaration-block-no-redundant-longhand-properties is not forwards compatible

[romainmenke]

Forwards compatibility means that future CSS can be used in a (slightly) older version of Stylelint.

I don't expect this to be true for large syntax changes.
But I expect Stylelint to not break my code each time a new constituent is added to a shorthand.

A concrete example is the introduction of text-decoration-thickness in text-decoration.
The syntax was updated:

• from <'text-decoration-line'> || <'text-decoration-style'> || <'text-decoration-color'>
• to <'text-decoration-line'> || <'text-decoration-thickness'> || <'text-decoration-style'> || <'text-decoration-color'>

See :

https://stylelint.io/demo/#N4Igxg9gJgpiBcICGACYAdAdugLjmAHjgLSyQBOSOAlhJsTgBbVgDWmMAzp-CgEwAHAgG4sufEVIwKVWvU44AngBsYvKBDwwoo7FslkIlGnWLLqHXgFdMscuY67xhEoeNzikZUd7ltugF8QABoQADNqVQA5JABbOERCOIFVADowbhDwOgiAcwQQDEwUFHQQFxhbTjLeAG0sEpKyhRUYBxJITDziBSRbJHIoMoaUAF0sINDOvIAxI1iqAoArTjos2AFOAqKmkBbVdprSkGUqLhwy4JHmpQOLDpzqXJ6cPqgBoYRj0-wFYcwggEgA

a {
	text-decoration-thickness: 2px;
	text-decoration-style: dotted;
	text-decoration-line: underline;
	text-decoration-color: red;
}

Is changed to

a {
	text-decoration-thickness: 2px;
	text-decoration: underline dotted red;
}

Which erases text-decoration-thickness.

Updates can be made to teach Stylelint about the updated syntax but this implies a significant maintenance burden.

This is different from other kinds of unknown syntax or CSS aspects as many CSS authors will not have memorized exactly which longhands are constituents of which shorthands and might not even notice the destructive changes Stylelint makes in these cases.

---

The issue here is not text-decoration itself, but that changing longhands to shorthands is a very impactful source code change.

Longhands and shorthands are simply not the same in CSS.

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.

[romainmenke]

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.

[ybiquitous]

@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.

[Mouvedia]

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

[ybiquitous]

Should this be moved to discussions?

This has already the needs discussion label, right?

[Mouvedia]

Should this be moved to discussions?

This has already the needs discussion label, right?

I was talking about https://docs.github.com/en/discussions

[ybiquitous]

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.

[ybiquitous]

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.

[ybiquitous]

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.

stylelint/lib/rules/declaration-block-no-redundant-longhand-properties/index.mjs

Line 28 in 9afaa08

const customResolvers = new Map([

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. 😢

[romainmenke]

"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)

[Mouvedia]

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.

[ybiquitous]

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.

[ybiquitous]

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.

[romainmenke]

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.