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.

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.

I should have written a better description -- I'll update it later. But, the summary is that we won't remove section tags from Parsoid's canonical HTML that is stored in the Parser Cache and which will be available via APIs. But, HTML served for read views might have some post-processing to reduce HTML size. See https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Performance and T272331: Evaluate and recommend strategies for ensuring Parsoid HTML payload doesn't degrade performance in low-resource contexts..

For now, we can continue to rely on the legacy parser for handling wikitext in banners. No need to block read views on this task.

This implements a SpecialPage and as such we can continue to let it be parsed by the legacy parser. No need to block on it for read views.

@cscott is currently working on a fix. It'll take a bit to get it right, get it reviewed and merged. See T332243#8716049 above.

The only utf-8 ones left now have always been for "Main Page" of ukwiki, ruwiki, bewiki. That indicates someone is POSTing some wikitext to the API which makes it harder to debug without having access to the wikitext in question. We have been ignoring this in the Parsoid logstash for a while now as possibly user error. But, maybe we should dump the wikitext being POSTed and see if we can figure out if it is an issue in Parsoid. But, need to figure out what the best way to do this is since the POSTed wikitext could be large blobs.

Looking at the Score extension code, it looks like the only markup that is impacted is image linking. But, @Arlolra has been working to have legacy parser generate Parsoid-style output for images. So, we may be have to get away without needing to write a Parsoid-native handler and simply continuing to proxy calls to the legacy parser.

Looking at the CharInsert code, I think we can safely proxy this to the legacy parser for now without any impact. So, removing this as a blocker.
But, for anyone looking at this, it should be simple to create Parsoid-native handlers.

I added back the parent task -- that epic isn't about read views necessarily - but about ensuring these extensions have native Parsoid handlers.

I added back the parent task -- that epic isn't about read views necessarily - but about ensuring these extensions have native Parsoid handlers.

Ooops. I am going to add back all those subtasks (except 3D which isn't a tag extension or uses parser hooks afaict). This epic isn't about read views necessarily - but about ensuring these extensions have native Parsoid handlers.

Looking at the CategoryTree code, I think we can safely proxy this to the legacy parser for now without any impact. So, removing this as a blocker.

Looks likes this builds up a bunch of wikitext and then parses it to HTML. This is only enabled on wikivoyages except (en, de, it). This looks like a fairly straightforward (if a bit cumbersome) port to Parsoid.

This extension constructs wikitext for a list with links to subpages and parses it to render the subpage listing. So, we can continue to render this with the legacy parser for now - there is no great loss in not having Parsoid-style HTML for the subpage links, especially given its sparse usage ( only enabled on cswiktionary and wikiversity besides labs and test wiki ).

This is not a tag extension - nothing to do here for read views.

Since Parsoid can continue to call the legacy parser for expanding wikitext it doesn't natively support (ex: extension tags like these), Parsoid can continue to proxy expansion of such extensions to the legacy parser. The only constraint is on extensions that accept wikitext constructs and process them.

In T328034#8717081, @daniel wrote:

.We can't really avoid the complexity of ensuring the right options are set, because we need to options to be set in order to determine which ParserCache instance to use. Otherwise, we'd have to loop this information through separately, which would require us to change method signatures on all the relevant code paths.

If the different PC instances in code map to the same backing store (mysql for now), presumably, the cache name would be used for the physical "split" of the shared backing store, but that would presumably still be simpler than trying to mess with options? It is possible I am missing something in this discussion.

But, I am asking about actually instantiating a new instance (vs "splitting" a cache). My understanding of splitting is that the same cache instance is used but the cache key ensures that different entries are used within that instance. There seems to be a some complexity in ensuring that the right set of options are set on save and fetch of the right cached entry. It seems like a different instance would avoid that.

I am going ask a possibly stupid question. It seems like the best strategy overall would be to use a different cache instance (instead of a trying to vary by options) for 'useParsoid'. I know we talked about that in the past and I thought that was the solution that you all had landed on as well. Trying to use the same cache instance but use varying options seems unnecessarily complicated to me. Given the different output that Parsoid and legacy parser generate, different PC instances seems like the best approach to me.

Core and Ext are the only two namespaces that should be used outside parsoid, and everything in them is @stable unless otherwise marked; everything outside those two namespaces is @internal (and shouldn't be marked otherwise)."

https://en.wikipedia.org/api/rest_v1/page/html/User:SSastry_(WMF)%2FSandbox/1144869788 looks right now.

Never mind. I found T190083: Make MediaWiki:Mobile.css render-blocking and friends.

It is not possible to move these into template styles or core since these are for references and wikis have traditionally been able to customize their rendering on-wiki. Trying to customize citations server-size in Parsoid doesn't work for VE editing (desktop or mobile) which is why CSS based customization was originally proposed in the first place back in 2013/2014 and nothing fundamental has changed there.

Yes, this will require us to copy over wiki-specific CSS changes added to Commons.css to Mobile.css. T156351: Add wiki-specific CSS styles for Parsoid Cite output so that it renders exactly like core Cite output is the task where that happened.

Officewiki does not use RESTBase.

This is probably an edge-case bug in the TableFixups code in Parsoid.

Scott: I wouldn't be so sure that Parsoid didn't do this ;-) There are edge case in the newline separator insertion code -- and that whole code needs an overhaul some day based on all the accumulated knowledge of the last decade and test cases. But, yes, it could be a result of the HTML we got from DT. Anyway, all I am saying is "Needs investigation".

Looks like this will get resolved once Parsoid is integrated into the rendering pipeline and ResourceLoader will add all the relevant modules, in this case, the ext.cite.a11y.js and ext.cite.highlighting.js.

In T289191#8530858, @vadim-kovalenko wrote:

In https://pt.wikipedia.org/api/rest_v1/page/html/Sebastian_Vettel topics Vitórias por equipe and Referências belong to the same section with data-mw-section-id=13 (see the shot)

Okay, moving this to Tracking on the Parsoid board.

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.

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.

It might be worth checking if Parsoid will not dirty if you run selser with VE's HTML as your new.html but where you update the mw:WikiLink back to mw:MediaLink. If that doesn't get dirtied, it would indicate that a fix in VE would fix the problem. If not, we probably have things to find in both Parsoid and VE.

Filed T330772: Mobile-html switchover to REST API (from RESTBase) should account for http 400 response for non-wikitext content models.