These are all going to be breaking changes wrt our published HTML spec.

Created T428212 for followup work.

I broke this originally when I introduced the ListTk compound token.

Huh, scratch that ... the CSS looks fine to me, and https://www.mediawiki.org/w/index.php?title=User:SSastry_(WMF)/Sandbox&oldid=8391831&useparsoid=1 confirms that. But, we could tweak the CSS to explicitly use the autonumber class instead of the :empty:after pseudo-selector.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/138617/2/resources/src/mediawiki.skinning/content.parsoid.less added CSS for autonumbered links but that CSS has bit-rotted with all the changes and needs to be adapted. And, we can document the info on wiki in cases individual wikis want to customize those.

We how have a basic REPL in place which meets the requirements of this phab task. Resolving this now - all future work here will be tweaks and improvements to what we have.

FWIW, given Parsoid will soon be used pretty much everywhere, we'll need Parsoid parser test runs to be included as part of the coverage since core parser tests will be disabled.

Yes, that works.

Okay, turns out that the second patch is the correct fix and the first one is now just a refactor.

Interestingly enough, in all the cases I've looked at so far (uk, ml, de, sl), mw:Param nodes are involved .. so, the 2nd patch will fix this on its own, but the first patch is also worth reviewing on its own.

I cannot reproduce both as logged in user and anonymous user. Was it something transient?

Copying my comment from the merged duplicated task: "April 26 is when I first see it in logstash (looking back at least 5 weeks)".

This and T426649 are from identical code sources. So, I'll just merge this with that. I most cases, $parts warning shows up first.

Looked back 6 weeks and first showed up April 30.

Low frequency error. Looked back 6 weeks and this has been showing up at least since April 14 if not from before that.

Looked back 6 weeks in Logstash and this first showed up May 10.

Looked back 6 weeks in logstash, and this first showed up May 2.

April 26 is when I first see it in logstash (looking back at least 5 weeks).

This has been around for at least 5 weeks if not longer (I looked back 5 weeks in logstash).

This has been around for at least 5 weeks if not longer (I looked back 5 weeks in logstash).

This was a fun one ... two old bugs with uncovered scenarios got triggered by code that went out on last week's train.

Looks like that patch only fixes the itwiki issue, not the enwiki issue.

Turns out this patch exposed an old bug that was hidden. This line is broken and for spans that wrap images and nothing else, this returns true. I added that helper in https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1194292 and it exploded with gerrit 1281440.

Looks like this is a regression from https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1281440.

Never mind .. looks like that is more an output format preference, not for input formats.

FWIW, https://x.com/trq212/status/2052809885763747935 from an anthropic engineer which I expect will trickle into other places.

@ihurbain added https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Instructions_for_editors#To_handle_rendering-transparent_elements_(%3Clink%3E,_%3Cmeta%3E,_%3Cstyle%3E)_in_template_output to help you all in tweaking your CSS.

Excellent. Resolving this ticket.

In T378906#11857398, @Izno wrote:

Thanks a lot for working on this!

In T378906#11856683, @ssastry wrote:

@Izno that patch now adds a span.mw-empty-elt around all the rendering-transparent-content. You should be able to use this specific span.mw-empty-elt selector to adapt the CSS.

I will try to take a look at this soon. And by soon I mean I'll need a deploy from Parsoid to some wiki or another. I will probably look on MediaWiki wiki since that's quiet enough compared to the several million transclusions of the ambox and navbox styles on English Wikipedia.

It looks fixed after Parsoid's wmf-2 tag rolled out.

With the deploy from about 30 mins back, this should now be fixed. Please verify.

In T425056#11880750, @Titore wrote:

Thank you @ssastry, I've just applied your workaround in the meantime!

Probably editing:

.divisa-calcio > div:first-child {
	height: 120px;
	left: 0;
	margin: 0 auto;
	padding: 0;
	position: relative;
	top: 0;
	width: 100px;
}

We have a potential fix merged, and we'll try to get it deployed Monday ... unless we can find a CSS fix for https://it.wikipedia.org/w/index.php?title=Template%3ADivisa_calcio/styles.css which we think is broken with the train. Let me play around with it a bit in my browser.

We debugged this and it is because the work from T378906 moves the <style> tag from outside the div tag into the div tag and in this case, since the style tag has CSS for the div tag that now swallows it (and as Isabelle noted: uses the :firstChild selector), CSS breaks. We'll fix it for next week's train at the latest.

@ihurbain Could be a breakage from T378906 work.

The pages in the description now render identically.

Alternatively, we override them in Mediawiki:Common.css of those wikis.

In other cases, maybe we need a counter-style provided where one doesn't exist right now. Examples: sewiki, gvwiki, bewwiki.

I looked at one of the wikis a bit more closely, and I suspect some of the issue stems from the fact that wikis might have diverged their backlink rendering since I originally had added custom css counters and those css counters have persisted through all the work WMDE has done. So, the fix would be to update the counter styles for all these wikis in the Cite repo. For starters, at least for those wikis, where the backlink rendering is now indo-arabic numerals (vs custom numerals), the fix might be to remove the custom counter styles added in the Cite repo. Seems to be the case for ext.cite.style.as.less and ext.cite.style.lo.less.

@Izno that patch now adds a span.mw-empty-elt around all the rendering-transparent-content. You should be able to use this specific span.mw-empty-elt selector to adapt the CSS. I just realized that you had previously said you preferred something more specific, but span.mw-empty-elt is the specific selector. mw-empty-elt has previously been used on p, tr, and li tags. There is no real semantic information being conveyed by the extra span wrapper beyond: this is just a convenient wrapper to hide a bunch of rendering-transparent (and effectively empty) content to get the out of the way of CSS selectors. So, span.mw-empty-elt seems reasonable enough.

I think this task can be closed as Declined.

This is because of use of curly quote chars instead of straight quote chars which Cite supports. So, the curly quote chars become part of the ref name attribute. Parsoid is correctly flagging the error. https://www.mediawiki.org/w/index.php?title=User:SSastry_(WMF)/Sandbox&oldid=8352103 demonstrates the issue.

See this report on mw:Parsoid/Feedback for screenshots.

I documented that last fix at https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Instructions_for_editors#Unnecessary_escaping_of_table_start/end_wikitext_with_templates

In T418268#11846587, @Ipr1 wrote:

• https://fi.wikipedia.org/wiki/Malline:Kirjaviite/ohje

This fiwiki issue is more T417705: Difference in table row closing when switching from html to wikitext syntax cells. This template uses html tr/td tags, but the template is embedded in this template which uses wikitext table syntax and that transition is handled different in the legacy parser and Parsoid. The legacy parser closes a table row whereas Parsoid correctly doesn't. We'll recommend possible template fixes for this case once we look into it a bit more.