Is this also related to T51346: Cite CSS should be adjusted by wikis to set a non-standard rendering style (e.g. 1.0, 1.1 / a,b,c, removing brackets, etc.) and associated tasks?

The CSS in https://github.com/wikimedia/integration-visualdiff/blob/master/lib/parsoid.custom_styles.yaml is a good start. It now has entries for over 20 wikis. Most are ready to go, and some might need some tweaking. In couple of cases, we need to figure out how to replicate existing styling.

In T156351#3130019, @ssastry wrote:

The CSS in https://github.com/wikimedia/integration-visualdiff/blob/master/lib/parsoid.custom_styles.yaml is a good start. It now has entries for over 20 wikis. Most are ready to go, and some might need some tweaking. In couple of cases, we need to figure out how to replicate existing styling.

Note: PDFLink no longer exists on en.WP.

I'm also not entirely sure why many of these rules would be loaded with Cite, anyway. Some/many of them appear outside of citations for dedicated templates or non-citation content.

Change 849738 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/services/parsoid@master] [Read Views Migration Tooling]: Programmatically generate cite CSS

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

Change 849738 merged by jenkins-bot:

[mediawiki/services/parsoid@master] [Read Views Migration Tooling]: Scripts to generate cite CSS

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

Change 885031 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.17.0-a13

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

Change 885031 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.17.0-a13

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

Parsoid is trying to encourage wikis to rely on CSS for customizing Cite output instead of site messages.

Why? It feels a lot messier to have 30 lines of code no one would remember what are for and that would likely not be copied to new wikis for years vs a neat 1 line ns8 message.

Hi, I'm here regarding the change that was made on nowiki (presumably also on several other wikis) linking to this task.

Will this change work for mobile (MinervaNeue & the mobile apps) too? Asking since Minerva doesn't load MediaWiki:Common.css.

In T156351#8647465, @Base wrote:

Parsoid is trying to encourage wikis to rely on CSS for customizing Cite output instead of site messages.

Why? It feels a lot messier to have 30 lines of code no one would remember what are for and that would likely not be copied to new wikis for years vs a neat 1 line ns8 message.

• Creating new wikis is a 1-time thing. There are a lot of things that need to happen when new wikis are created. We can update documentation about how to customize Cite rendering.
• i18n messages are meant to be used for localizing *strings* and text and Cite is abusing those to replace HTML strings. So, it feels hacky, even if a very neat hack.
• Parsoid intends to change how i18n and l10n is done for page views. Parsoid will generate a language-agnostic canonical HTML for a page and store it in the cache where the i18n messages are marked up as per a spec. Then, on a page view request, this cached HTML is processed to replace the i18n placeholders with l10n strings. This improves server performance by eliminating the need to parse an entire page just to generate a localized version of a page for different user language preferences. This performance optimization gets messy if the strings contain HTML in them.
• Editing clients like VisualEditor (or any other editing client that lets users edit HTML) can rely on browser CSS to refresh rendering when citations are edited on a page. Otherwise, when a citation is added, removed, moved, or edited, (a) either these clients will have to issue a server request to recompute the numbering and localization -- which is performance-inefficient and also makes for a glitchy UX (b) OR let the citations be a combination of localized and non-localized numbering which is also not the greatest experience.UX-wise.

In T156351#8665454, @jhsoby wrote:

Hi, I'm here regarding the change that was made on nowiki (presumably also on several other wikis) linking to this task.

Will this change work for mobile (MinervaNeue & the mobile apps) too? Asking since Minerva doesn't load MediaWiki:Common.css.

Good question. dewiki and enwiki also flagged this for us. We don't have any smart solutions at this time besides needing to copy over this CSS to Mobile.css as well. Some wikis like dewiki (and possibly svwiki) use gadgets for common CSS across platforms. But, without that, I was planning to copy over the CSS to Mobile.css in a separate pass. But, now that I've added the CSS to your wiki already, feel free to make this copy yourself and note it on this page.

Creating new wikis is a 1-time thing. There are a lot of things that need to happen when new wikis are created. We can update documentation about how to customize Cite rendering.

Yes, but code maintenance isn't a 1 time thing and people would have to remember what that code is for. For individual ns8 messages there is often documentation on MWW available. For CSS code in the wild there isn't.

These backports that you are doing across many Wikimedia projects, if they are needed, should be in the core, not in many individual CSS files. With this and figure CSS migration, I am struggling to see why Parsoid team has a knack for making these decisions.

In T156351#8665645, @ssastry wrote:

Good question. dewiki and enwiki also flagged this for us. We don't have any smart solutions at this time besides needing to copy over this CSS to Mobile.css as well. Some wikis like dewiki (and possibly svwiki) use gadgets for common CSS across platforms. But, without that, I was planning to copy over the CSS to Mobile.css in a separate pass. But, now that I've added the CSS to your wiki already, feel free to make this copy yourself and note it on this page.

Mobile.css doesn’t load on page load, so this will contribute to page jumps if this is implemented as is. I am seriously asking you to reconsider.

In T156351#8726473, @stjn wrote:

These backports that you are doing across many Wikimedia projects, if they are needed, should be in the core, not in many individual CSS files.

We would be more than happy to have it all be in core and not on wikis. But, wikis have traditionally controlled customization of Cite rendering. If we want all future Cite customizations to go through gerrit and WMF code approval paths, that needs a bit more care -- we cannot simply change it as part of switching to Parsoid.

With this and figure CSS migration, I am struggling to see why Parsoid team has a knack for making these decisions.

Are you asking why we are making this particular change? The reasoning for Cite CSS change is simply because Parsoid generates HTML that needs to serve editing clients. See T156351#8665643 above. But, to repeat, It would be a horrible editing experience in VE if you had localized output and then when you edited them, you suddenly see uncustomized english rendering mixed with it. This is probably less of an issue of latin language wikis, but Imagine this for RTL wikis like hebrew, arabic, etc. CSS based customization allows for a seamless handling of customization based on browser support. The alternative would be for VE to make a server request each time an editor made an edit that somehow impacts references -- that would also make it a bad editing experience.

But, at a higher level, Parsoid now has to support not just reading, but also editing. It is not possible to maintain two different wikitext engines for them. We are close to shifting away to render both read HTML as well as edit HTML with Parsoid based on a single copy of canonical HTML that is stored in cache. There are good technical reasons for our decisions. If you questions about the decisions or need clarifications, please feel free to ask. But, be mindful of making blanket statements about our knack for doing something or the other - that is not helpful to either you or us.

In T156351#8726479, @stjn wrote:

In T156351#8665645, @ssastry wrote:

Good question. dewiki and enwiki also flagged this for us. We don't have any smart solutions at this time besides needing to copy over this CSS to Mobile.css as well. Some wikis like dewiki (and possibly svwiki) use gadgets for common CSS across platforms. But, without that, I was planning to copy over the CSS to Mobile.css in a separate pass. But, now that I've added the CSS to your wiki already, feel free to make this copy yourself and note it on this page.

Mobile.css doesn’t load on page load, so this will contribute to page jumps if this is implemented as is. I am seriously asking you to reconsider.

Thanks for flagging this. But, yes, we are aware of this. Most of the citation customization is for the references section usually which tends to be at the bottom of the page which reduces the likelihood of Flash-Of-Unstyled-Content (FOUC) changes. The customization for ref superscript numbering is typically language counters which are already handled via CSS files that come from core. That said, we are going to evaluate the impacts and if we do see serious FOUC issues, we have several implementation possibilities. One of the "simplest" ones is to make this a Cite gadget on all wkis. The other is to make Mobile.css render blocking as in T190083 (after evaluating possible performance impacts of doing so). There are other more complicated solutions available but we expect we don't have to go there.

In T156351#8726549, @ssastry wrote:

Are you asking why we are making this particular change?

My mostly rhetorical question is in regards to why both here and in T314318: Disable wgParserEnableLegacyMediaDOM on all wikis, from the outside, Parsoid team seems to make things more complicated without a proper consultation. I understand the need for performance optimisation, of course, but in this case it seems like instead of making improvements in, say, making so that some messages in MediaWiki can be language-agnostic and be used in every language, we went the complicated path of making 200+ language versions have to do (for now at least) two versions of Cite syntax, and silently removed any other customisation.

In T156351#8726549, @ssastry wrote:

Most of the citation customization is for the references section usually which tends to be at the bottom of the page which reduces the likelihood of Flash-Of-Unstyled-Content (FOUC) changes.

Not exactly as I understand it, references like [lower-alpha 1] are going to appear anywhere on the page, so if https://ru.wikipedia.org/?diff=128793901 this change is anything to go off of, it would be affecting (just on the first visit hopefully) even the first screen of some articles (https://ru.wikipedia.org/wiki/Россия for example) when Parsoid changes move from just VE to everywhere.

In T156351#8726576, @stjn wrote:

... in this case it seems like instead of making improvements in, say, making so that some messages in MediaWiki can be language-agnostic and be used in every language, we went the complicated path of making 200+ language versions have to do (for now at least) two versions of Cite syntax, and silently removed any other customisation.

I can quickly respond to this one before I switch off for the weekend.

Once Parsoid is the default, Cite messages will not be used anymore. CSS on wikis will be the sole mechanism for customization.

Note that our goal here has been NOT to break rendering and customizations that wikis have made (there are a handful of cases on some wikis where CSS may cause some minor changes). So, making messages in MW language-agnostic would need to move the customizations somewhere else. So, one way to look at our Cite CSS changes is that we are moving the large number (100s) of wiki cutomizations from messages to 130+ wiki customizations to CSS and the many 10s of language-specific counters in the Cite repo. With that change, all messages become identical for all wikis and hence can be removed altogether.

In T156351#8726549, @ssastry wrote:

Most of the citation customization is for the references section usually which tends to be at the bottom of the page which reduces the likelihood of Flash-Of-Unstyled-Content (FOUC) changes.

Not exactly as I understand it, references like [lower-alpha 1] are going to appear anywhere on the page, so if https://ru.wikipedia.org/?diff=128793901 this change is anything to go off of, it would be affecting (just on the first visit hopefully) even the first screen of some articles (https://ru.wikipedia.org/wiki/Россия for example) when Parsoid changes move from just VE to everywhere.

Agree, hence I said: "Most" :-) ... lower-alpha or other such counters are not commonly used on pages. The question here is tradeoffs. This is a solution that works on a vast majority of pages on all wikis. But, as I noted above, we are open to solutions to address and mitigate any FOUC issues. We haven't rolled out Parsoid read views everywhere yet. So, there is time to tweak all this. So, this is how we are approaching this. Think of this as an incremental approach.

After SSastry (WMF) changes, the selector @counter-style is now marked as error and each time I trying to save the page it give me an alert message. It possible to fix this issue?

In T156351#8983447, @Andriy.v wrote:

After SSastry (WMF) changes, the selector @counter-style is now marked as error and each time I trying to save the page it give me an alert message. It possible to fix this issue?

This is caused by T217775: CodeEditor does not recognized the @counter-style rule

In T156351#8726595, @ssastry wrote:

Agree, hence I said: "Most" :-) ... lower-alpha or other such counters are not commonly used on pages. The question here is tradeoffs. This is a solution that works on a vast majority of pages on all wikis. But, as I noted above, we are open to solutions to address and mitigate any FOUC issues. We haven't rolled out Parsoid read views everywhere yet. So, there is time to tweak all this. So, this is how we are approaching this. Think of this as an incremental approach.

The problem is, Efn seems like a proper standardisation path for all different kind of non-reference comments on pages, and now it going to be essentially a worse one in comparison to <ref group="comment."> because the CSS you are adding across wikis doesn’t load immediately on mobile and will not load immediately on mobile for another 10 years unless something changes in the WMF priorities on this.

While Page Views are not currently a thing, they are going to become a thing at some point, and I assume mobile styles being loaded asynchronously isn’t going to be a blocker for the Parsing team even while it adds styles that require synchronous loading.

One of the reasons I haven't yet updated CSS on Mediawiki:Mobile.css on wikis is so we evaluate how we want to approach this. So, we'll do our best to fix this right for mobile -- including checking if we can address the render-blocking issue for mobile css. Since Parsoid HTML isn't live everywhere yet, we may do the CSS updates for mobile.css first and tackle the render blocking issue separately. But, we are separately investigating some other cite rendering issues ( T328695 ) and what we do there might have a bearing here for mobile.

@ssastry these styles can now be added to MediaWiki:Minerva.css for mobile support.

In T156351#9635062, @Jdlrobson wrote:

@ssastry these styles can now be added to MediaWiki:Minerva.css for mobile support.

I don't really think that resolves the primary problem to me of needing to have the same block in both Common.css and in Mobile-now-Minerva.css. (Though it's nice that Minerva.css exists now.)

Are the styles identical for each project?
If so perhaps we could use the new module proposed in T360386 ?

In T156351#9643437, @Jdlrobson wrote:

Are the styles identical for each project?
If so perhaps we could use the new module proposed in T360386 ?

No, each specific wiki will have different customizations here.