FWIW, display: block is used in several places of the CSS inheritance tree in this case, even in the inline style. The other places are mostly originating from MinervaNeue.

Now it's up to services to fix service-runner. I'm think other service-runner based projects will run into this as well if not fixed soon.

@JoeWalsh Another easy way to get the language variants in this MW API request. It also shows the fallbacks, which should be followed IMO.

Should crashes on appservice.wmflabs.org even be reported in Logstash?

I think it would help if there was at least some Varnish caching for a certain amount of time but I guess that editing might have more issues with that than PCS.

No objection, as long as we can have the same port in all environments (local dev, beta, production, ...) if there is such a thing as an exposed port in Kubernetes.
(I think it adds more burden if the ports of the same service are different per environment. Example: In MCS we use 6927 for local development, but 8888 on the production machines.)

Thank you @NHarateh_WMF. That sounds useful enough to expose it. The issue is that we already have a callback for the setup functionality. I guess I'll make a parameter object which can hold multiple callback functions.

In CollapseTable.setupEventHandling() is the footerDivClickCallback used by iOS or Android? Just wondering if that should be exposed.

@phuedx Yes, that is correct.

Keeping mobile-sections with the rest of PCS makes sense to me. Thank you for preserving the git history. The rest is nice to have and not necessarily blocking.

The lexeme work sounds promising. (That would be a big enough change to warrant at least a major version bump if not a new endpoint.)

Even if we removed the functionality in the app we would have to keep the endpoint running for a bit for older versions of the Android app.
This task might also be a reminder to look into definition alternatives, i.e. if the Android OS provides one.

Moving out the feed stuff sounds like a reasonable approach to me. I'm just not sure if we really should be starting with a brand new repo. Have you considered using a clone so we can keep the Git history?
Some of the libraries are shared between mobile-sections and the PCS endpoints. We may consider creating an npm library for sharing those if it make sense to do so.
Before we move code to other repos I think it might be beneficial to make sure the OpenAPI spec is merged and some other code cleanup is done. That could be updating of dependencies, esp. eslint configs, a convention for unit test file names.
We could start out with moving easily identifiable files and subfolders into different buckets, at least for the lib and test. Probably the routes could be done as well.

Reproduced with https://en.wikipedia.org/api/rest_v1/page/mobile-html/Windows_10_version_history on desktop browser and running pagelib.ThemeTransform.setTheme(document, pagelib.ThemeTransform.THEME.BLACK) in the console.

I see now. I forgot to close the table earlier.

@MSantos Thank you. Good catch!

Maybe I will create a PR on wikimedia-page-library of making a new method of getting references collection.

Should we getting the id from id="cite_ref-RuddAvengers4_11-0" or href="#cite_note-RuddAvengers4-11"?

The page library code has not been updated to work with the references output. It still assumes MW API content structure, whereas the PCS references output is based on Parsoid.

Example URI: https://en.wikipedia.org/api/rest_v1/page/metadata/Dog
More info: https://www.mediawiki.org/wiki/Page_Content_Service#/page/metadata

Purged https://meta.wikimedia.org/api/rest_v1/data/css/mobile/pagelib and verified with https://en.wikipedia.org/api/rest_v1/page/mobile-html/Dog in incognito mode to avoid browser cache.
+ ran pagelib.ThemeTransform.setTheme(document, pagelib.ThemeTransform.THEME.DARK)

Keeping the old page loading code around for a while is another valid option. It does come with the burden of keeping a lot of old code around and added complexity. On second thought, that might be still needed for the MW API fallback until Parsoid and RESTBase handle language variants correctly. Maybe keep track of how many pages are stored in the old saved pages format and report that via event logging?

I think it's probably easiest to just redownload the saved pages.

@JoeWalsh Thanks for the videos. They clearly show the flash of un-styled content.
Would it be sufficient if we just added the callback as an optional parameter to pagelib.ThemeTransform.setTheme and pagelib.DimImagesTransform.dim?
What kind of abstraction did you have in mind? Would that live inside the page lib or outside?

+1 to "DOM subtree editing" from me as well.

Fixed by https://github.com/wikimedia/wikimedia-page-library/pull/184

@NHarateh_WMF Are you testing this in the lite app? I don't recall a task that fixed the flash.

The margins and padding of the body can be adjusted by clients with the following calls on any mobile-html page now. Examples:

Tagged this by mistake. This is not merged yet.

@NHarateh_WMF or @JoeWalsh are the callbacks really needed there? We already have most of this implemented in the page library. If they are needed then I'd probably just add an optional callback parameter to these two functions. BTW, I've added a bit of documentation about this here: https://www.mediawiki.org/wiki/Page_Content_Service#/data/javascript/mobile/pagelib

Released in page library 6.4.0. Still needs to be picked up by a new MCS deploy.

Ok, that should be quite easy then. I like the simplicity.

@Mhurd Uploaded https://github.com/wikimedia/wikimedia-page-library/pull/182. I think we could get rid of the added rules for T214728, now that the base CSS endpoint is more stable and doesn't include most of the extraneous CSS rules from Minerva (see T220045).

@Jdlrobson The border doesn't cover the whole circumference of the image. In a comment for PS2 of the patch you mentioned that a MobileFrontend dependency was missing. Which was it? I suspect we might need to add this to our base CSS output.

If this takes longer I suggest just updating its dependencies.

It took a few tries but it's finally deployed now. See P8371 for the deployment issues yesterday.

It took a few tries but it's finally deployed now. See P8371 for the deployment issues yesterday.