@MarcoSwart That fix was deployed. I purged a few pages that included the template and they no longer have duplicate id errors.

@RolandUnger T393982 is deployed and I purged a few pages to confirm it fixed the issue

Change #1147810 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1147810

Change #1147810 had a related patch set uploaded (by Jgiannelos; author: Jgiannelos):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.22.0-a3

https://gerrit.wikimedia.org/r/1147810

@RolandUnger Thanks for reporting. This should be fixed by T393982 rolling out next week

In T393982#10815110, @ihurbain wrote:

This is probably what was reported in https://phabricator.wikimedia.org/T200517#10785684, correct?

In T200517#10785684, @MarcoSwart wrote:

On nl.wiktionary, this template generates the Lint error for duplicate IDs, even though it doesn't assign HTML IDs. Could this result from using the same subheadings within the template? If so, why should this be an error? HTML does not preclude using the same header several times.

Change #1144689 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Don't emit duplicate id lint errors from mw:FallbackId spans

https://gerrit.wikimedia.org/r/1144689

This is probably what was reported in https://phabricator.wikimedia.org/T200517#10785684, correct?

Change #1144689 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Don't emit duplicate id lint errors from mw:FallbackId spans

https://gerrit.wikimedia.org/r/1144689

From https://en.wikipedia.org/wiki/Wikipedia_talk:Linter#c-Zinnober9-20250509155800-ABreault_(WMF)-20250508190400

At the last engineering offsite, we decided that putting lints into ParserOutput was the future direction here. I'm going to close this as a dupe of T393717: Put lints in ParserOutput/RefreshLinksJob to reflect this consensus.

We decided at the last engineering offsite that Lints are going to be put into ParserOutput, and that we'll move the DB maintenance to RefreshLinksJob, although not until RLJ is powered by Parsoid (T393716). I'm going to close this as a duplicate of T393717: Put lints in ParserOutput/RefreshLinksJob to reflect this consensus.

Thanks for these answers, even though they are dissatisfying. I would hope that the parser could check the actual output for compliance with having both a color: and a background-color: specified, since that is the underlying concern.

Sorry yes. Amended my comment above to be less confusing.

Here color: inherit; should be added to the inline style to fix it

The lint is working as designed. The expectation is that you do not mix inline styles with TemplateStyles. Here color: inherit; should be added to the inline style to fix it, or the style should be completely moved into a rule for legend-color as the default.

The check is alas on the source string and unfortunately not on what gets resolved for the node,

In T370624#10783473, @cscott wrote:

@Ladsgroup what's the status of this task? Is there something that still needs to be done?

In T368722#10763188, @ABreault-WMF wrote:

In T368722#10757169, @Bugreporter wrote:

Empty headings is currently used in Chinese Wikipedia DYKN page: https://zh.wikipedia.org/wiki/Wikipedia:%E6%96%B0%E6%9D%A1%E7%9B%AE%E6%8E%A8%E8%8D%90/%E5%80%99%E9%80%89

Can you say a bit more about how it's being used and why it's necessary?

On nl.wiktionary, this template generates the Lint error for duplicate IDs, even though it doesn't assign HTML IDs. Could this result from using the same subheadings within the template? If so, why should this be an error? HTML does not preclude using the same header several times.