This CSS was added in https://fr.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=202296328 following Parsoid Unification. We didn't really manage it ourselves. Can we safely remove it?

Hello @awight
Would you have any suggestions on how we could address this locally? It appears that this issue arises because we do not use brackets for our references. Our custom CSS might be conflicting with recent changes to the references.

Thank you for the detailed bug report—yes this was definitely a result of my recent change. I would recommend as a first step that you remove the custom CSS, if that's acceptable?

I'm unsure how to read the desired outcome, by the way. The bug description says that you *want* [1] but perhaps you would prefer to keep the footnote marker without the square brackets? I think the customization can be restored after some small changes to Cite-VisualEditor integration, if it's desired.

Change #1056168 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/Cite@master] [WIP] First attempt at customizable footnote marker

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

Change #1056448 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/Cite@master] Reading mode square brackets become customizable through CSS

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

Change #1056456 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/VisualEditor@master] Temporarily disable Cite-related test

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

Change #1056457 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/VisualEditor@master] Reenable Cite-related test

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

Change #1056456 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Temporarily disable Cite-related test

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

In T370512#10006398, @awight wrote:

Thank you for the detailed bug report—yes this was definitely a result of my recent change. I would recommend as a first step that you remove the custom CSS, if that's acceptable?

I'm unsure how to read the desired outcome, by the way. The bug description says that you *want* [1] but perhaps you would prefer to keep the footnote marker without the square brackets? I think the customization can be restored after some small changes to Cite-VisualEditor integration, if it's desired.

Yes, what struck us at first were the lonely 0s, but the actual issue is that we want to remove the brackets. This applies to decimal counters, as well as to alphabetic and Greek ones.

In T370512#10009993, @Escargot_rouge wrote:

Yes, what struck us at first were the lonely 0s, but the actual issue is that we want to remove the brackets. This applies to decimal counters, as well as to alphabetic and Greek ones.

Great, then I understand what to do.

My suggestion is to remove the custom CSS creating the "0", or make it more specific to Parsoid-generated output like so:

.mw-ref > a[ style~='mw-Ref' ]::after {
	content: counter(mw-Ref,decimal);
}

We're merging a patch https://gerrit.wikimedia.org/r/c/1056168 which should be deployed next week, and will add a new class to the square brackets which you can select directly:

.mw-ref .cite-bracket {
  display: none;
}

I would even recommend font-size: 0; instead of hiding, so that the square brackets do appear when copy-pasting.

Change #1056168 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] VE square brackets appear in a span

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

I'm confused by today's Tech News entry that link this task, which starts with:

Editors using the Visual Editor in languages that use non-Latin characters for number [...] may notice some changes in the formatting of reference numbers.

(Emphasis is mine.)

As this task's initial reports are from fr and es, I'm not sure the Tech News description is accurate for non-Latin numbers. :)

Ping @JStrodt_WMDE who added the entry in Tech News.

We have a few hours to fix the entry in Tech News if needed; but it might impact translations.

Ah, I think this might be my mistake? I must've read too fast, and seen the merged-duplicate which is about Arabic, and so I added this task's link to the draft thinking they were for the same entry. I've now removed that link again.

For next week's Tech News, how should this task be contextualized for an entry? Is there an action/edit that you want local editors/admins/interface-admins to do (or check if needed)? Thanks.

@Quiddity Thanks for the nudge—I've been concerned about the lingering bug here, as I can see that there are more wikis affected than I expected, and the workaround hasn't been applied anywhere yet.

There's some delay on my side because we need to consolidate the two approaches to numbering footnotes, see T370027: [Epic] Parsoid CSS counter reset footnote/backlink mechanism should be dropped in favor of plain text to follow that discussion. I would prefer to give site interface admins a single path forward rather than explain how to accomodate the two numbering approaches at the same time, or ask anyone to edit Common.css with a workaround now, and a final fix later. I'll update when I know more, hopefully within the next week.

In T370512#10024144, @Quiddity wrote:

Ah, I think this might be my mistake? I must've read too fast, and seen the merged-duplicate which is about Arabic, and so I added this task's link to the draft thinking they were for the same entry. I've now removed that link again.

Sorry for the noise, I got confused while reading. It is a similar task but not the right one. :/

For next week's Tech News, how should this task be contextualized for an entry? Is there an action/edit that you want local editors/admins/interface-admins to do (or check if needed)? Thanks.

I think we should add an entry explaining that we identified the issue and we are working on it.

Yes, thanks I'll make sure to send an update in this week's Tech News!

I should at least clarify my suggested temporary workaround, to be fair to anyone watching this task.

These are the wikis which seem to be affected: https://global-search.toolforge.org/?q=mw-ref%5B+%3E%5D%2Ba%3A%3Aafter&regex=1&namespaces=8&title=Common.css

• arwiki
• bhwiki
• eswiki
• eswiktionary
• hiwiki
• itwikisource
• vecwikisource

Expected impact is that a redundant "[0]" now appears after every ref while visual editing.

What they should do is to disable or delete the rule looking like this,

.mw-ref > a::after { content: counter( mw-Ref, decimal ); }

There should be no damage to Parsoid, since this is already the default rendering for footnote markers in the article. If the counter is being overridden to specify another counter digit style (I didn't see any obvious cases of this) then there would be some damage, as the footnotes would revert to rendering in Arabic "decimal".

I'm linking T156351: Add wiki-specific CSS styles for Parsoid Cite output so that it renders exactly like core Cite output here as a FYI, as it is documented at es.wp as the reason for the addition of .mw-ref > a::after to the CSS file.

Given the number of wikis impacted, I think we can safely edit the local CSS ourselves. If you think it is a good idea, I can do it.

Change #1056448 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Reading mode square brackets become customizable through CSS

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

Removing tag, per Benoît's plan.

Change #1056457 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Reenable Cite-related test

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

I commented .mw-ref > a::after { content: counter( mw-Ref, decimal ); } on all wikis listed in T370512#10033810.

@Trizek-WMF @Quiddity @awight Thanks to all three of you for handling this. I only just came back from vacation.

The issue described in the task is resolved because we removed the custom CSS, but this CSS was originally used to remove brackets on references.
Currently, we cannot remove these brackets for references in a group.

In T370512#10209722, @Escargot_rouge wrote:

The issue described in the task is resolved because we removed the custom CSS, but this CSS was originally used to remove brackets on references.
Currently, we cannot remove these brackets for references in a group.

Yes, thanks for that note. We'll need to solve that issue a bit differently now. There's already note about it in this tracking ticket T376296: Cite regressions in Parsoid Read Views due to WMDE refactoring for subreferences so we don't forget about it.

@Escargot_rouge Glad you mentioned that this is still unsolved: we did leave a new mechanism which I should explain more thoroughly. If you look at the HTML you'll see a new class, which can be customized as follows:

To make the square brackets disappear in reading and editing mode, add this CSS:

.reference .cite-bracket {
  display: none;
}

If you want a slightly different behavior (which I prefer personally) that hides the brackets, but makes them show up in copy-pasted content, please use this snippet instead:

.reference .cite-bracket {
  font-size: 0;
}

This CSS has already been added on frwiki and it does remove brackets on regular references, but not in the case of references in a group (in the Visual Editor, for example https://fr.wikipedia.org/w/index.php?title=Call_of_the_Night&section=8&veaction=edit).
But it seems to be due to the fact that these references in a group are still done the old way, using a counter. Maybe I should add back the old styling for this case.

In T370512#10213601, @Escargot_rouge wrote:

This CSS has already been added on frwiki and it does remove brackets on regular references, but not in the case of references in a group (in the Visual Editor, for example https://fr.wikipedia.org/w/index.php?title=Call_of_the_Night&section=8&veaction=edit).
But it seems to be due to the fact that these references in a group are still done the old way, using a counter. Maybe I should add back the old styling for this case.

The link was helpful! There are multiple layers to this onion, indeed: when a template is rendered in VE, what we get is an in-between situation which is caused by the template contents coming from Parsoid, but the footnotes directly included in the page are rendered differently, by VE. This is the cause of all sorts of problems, for example the footnote numbers just don't fit into the rest of the document, the footnotes can't be edited or reused directly by VE, and in your case, the rendering style is slightly different.

I don't have a good suggestion at the moment, I expect that T376717: Find a solution for Parsoid read views on projects that prefer `1` over `[1]` can be solved in a way that's compatible with the non-Parsoid rendering so I think the safest bet is to plan on the CSS above eventually solving the Parsoid case as well. There was a bit of discussion about T370027: [Epic] Parsoid CSS counter reset footnote/backlink mechanism should be dropped in favor of plain text which finally resulted in a decision to move away from the way Parsoid currently uses CSS counter-reset.

Change #1082732 had a related patch set uploaded (by Awight; author: Awight):

[mediawiki/extensions/Cite@master] Parsoid: configurable .cite-bracket square brackets

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

Change #1082732 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Parsoid: configurable .cite-bracket square brackets

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