RT-testing regression script shows no regressions.

I actually went ahead and did it -- https://www.mediawiki.org/wiki/Specs/HTML/2.8.0#[DRAFT]:_DOM_Ranges .. so going to close this ticket now. Feel free to tweak the language or poke us on slack if something is unclear and we'll update the docs.

Yes, we plan to update the docs -- @cscott and I chatted about a bunch of other documentation updates that is on our plate as well and we may pool everything together and update the docs. But, you can leave the ticket open.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/1035809 fixes the accessibility markup. Maybe the changes from that patch also fixes the reference tooltip gadget?

While some fixes have landed related to T53587, we have zhwiki lang conversion disabled in Parsoid (for perf reasons), and since the findVariantLink code calls Parsoid's converter directly, those fixes are skipped for zhwiki. There are planned changes to add a level of indirection where Parsoid asks core for all language conversion which will then call Parsoid's converters if there is a native converter available. That fix will solve this problem. @cc @cscott @Arlolra

For completeness, here are github (non-HTML) uses of:

• mw:referencedBy ( ~540 files)
• mw-reference-text (~512 files)
• mw-linkback-text (~480 files)

I updated the stats in T328695#9125350. Given what I see there, here is an updated proposal:

Anyway, to answer my own question, looks like they may be identical for most wikis, but for some wikis, they may not be (ex: eswiki). I'm going to start doing this copy-paste operation from Common.css to Minerva.css over the next couple weeks. https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Cite_CSS/Change_Log will help me with the wikis that will need this targeting. Meanwhile, I found https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/1035049 will need to also be deployed (either in Cite extension or that rule would be moved to Minerva skin codebase and added there).

In T156351#9643437, @Jdlrobson wrote:

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

I think the description could be edited for clarity -- we can discuss when we chat next. But, your gerrit patches helped clarify your proposal -- and I like it overall. Component boundaries in MW was something that came up in discussions in the code ownership working group and moving in this direction will make it possible to better isolate components for ownership (with all the other attendant benefits in gerrit, phab, wiki, etc. around simplifying descriptions).

In T365309#9810718, @ihurbain wrote:

Patch 6fe99186fb7847dd271503e23fdd03ca32f1af0f is not deployable; on hold for decisions.

I've already separately monitored the known issues wiki page and discussion (and also updated that wiki page) last week. So, consider that part done as well.

Checked Logstash and grafana and nothing notable from the deployment.

In general, for any node with a typeof and an about id, you should walk the DOM forward while the about id matches and all of those dom nodes effectively belong to the structure identified by the typeof & about id. But, typeof and data-mw is only attached to the first element in the list.

That is handled by the about-id assignment ("#mwt18"). Parsoid markups up a DOM forest (made up of a contiguous list of dom nodes) as "template-affected" (typically, just the template output, but sometimes also swallows up content from the top level when the template's output is not well-structured DOM output).

Looks like this CSS rule doesn't apply in Parsoid because of the empty refs lists: .mw-parser-output .ts-Неоднозначность-reflist > [role="heading"]:only-child

Shouldn't be too hard to fix -- we just need to update the post-processing in the Cite extension code to remove empty wrappers.

In T358193#9731418, @Tacsipacsi wrote:

I hope this Phase 5: (Later) doesn’t mean Parsoid read views will be enabled on wikis with language conversion (even in talk namespaces) before this is done.

That said, ParserOutput already has a json object, so maybe I am worried about nothing here.

For now, one solution here is for us to figure out a HTML representation that lets us extract HTML for a specific slot from the combined slot output that is stored in ParserOutput. Alternatively, we would have to store slot output separately in ParserOutput in a json array -- but that leads to encoding bloat and encoding/decoding overheads. But, in either case, once we agree on the representation for this in ParserOutput, when VE asks to edit the page, we can extract the main slot output here. Ideally, VE would also ask for the slot it wants to edit in which case, we wouldn't have to hardcode this either.

This is nasty ... the list handler converts the ":" in "1:00" from a listitem token to a ":" string token. But, the later occurence of ":" doesn't now get reparsed as a "lisitem"!

Just documenting discussion so we don't forget. One option is to run all passes on well-formed fragments (which extension fragments are -- and enforced to be that way -- in Parsoid). This ensures that table fixups run on the extension fragment while we still have DSR offsets rather than try to run them all at once on the top-level page *after* we have cleared DSR offests on some extension fragments (like <poem>).

I'll update here / there once we finalize those details -- feel free to leave your thoughts there as well. But, we expect some gadgets will still need tweaking.

I am going to close this ticket and create a new one for the gadget.

In T303627#9745136, @Nikerabbit wrote:

Is there any appetite for generic wikitext mechanism of having content that is not part of the rendered page, apart from the html-like comments that cannot be nested?

That looks like a Parsoid bug - text nodes (whitespace included) should typically get span-wrapped so they get an about-id. There shouldn't be any discontinuity in about ids.

This is already in production now.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/832495 is riding this train which looks potentially risk and could cause ParserCache errors if the train is rolled back. Not sure if 1.43.1 can correctly process PC entries produced by master (1.43.2). So, I would not roll forward the train till we can establish that. I am signing off for the weekend but wanted to flag this before I disappeared because this came up in a slack conversation with Jon Robson. @cscott FYI.

Those enwiki pages look fixed now.

These work everywhere now, but the reference previews are slightly different from legacy ... the content selection code in the reference preview code probably needs an update for Parsoid's cite output. The difference is especially obvious for named references, unless of course the new output is the preferred version. :)