I don't quite understand the reasoning behind this. I think the basic question is: what code should be directly writing to the output buffer (and the WebResponse object)? Should skins build strings, and hand them off to core for output? Or should it be the other way around - core (and extensions) build a data structuer, and the skin generates the response?

Change #1060479 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[mediawiki/extensions/WikidataPageBanner@master] Invert font color of banner

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

Change #1059503 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Immediately show middle-clicked notifications as read

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

@ovasileva @Jdlrobson: This has been resolved on the English Wiktionary with the introduction of a new gadget (https://en.wiktionary.org/wiki/MediaWiki:Gadget-PagePreviews.js) capable of previewing a wide range of links. Perhaps the code can be reused on other projects. By the way, your acceptance criteria are not very well thought-out in my opinion.

In T349000#10018867, @Jdlrobson wrote:

Thanks for the URL update! @jhsoby are you still interesting in helping get this fixed?

Change #1059503 had a related patch set uploaded (by Rummskartoffel; author: Rummskartoffel):

[mediawiki/extensions/Echo@master] Immediately show middle-clicked notifications as read

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

Taking a shot at this one.

Given we now have mw.collapsible on Minerva, I think it makes sense to close this task resolved and open a new one for any refinements a designer wants to work on, since that apparently remains a concern.

Not urgent, but would be nice to get this deprecation done. Since it touches OutputPage this should probably be looked at by someone in the platform team. Thanks @daniel for the input so far!

The use of filter appears to establish a stacking context (https://drafts.fxtf.org/filter-effects/#placement)
So even though this only impacts dark mode, this seems like a general bug with the mobile diff page for any element in the footer that might some day use CSS filters. Thanks for flagging @Tufor!

In T369609#10037882, @AAlhazwani-WMF wrote:

In T369609#10035885, @Anujagrawal wrote:

I'm not able to replicate the error and find the same appearance dropdown.

in order to display the appearance button you need to enable the "Accessibility for Reading (Vector 2022)" beta feature in your user preferences

In T369609#10035885, @Anujagrawal wrote:

I'm not able to replicate the error and find the same appearance dropdown.

I've added that suggestion as T371657

Better than having it preserve the skin, which can be set via [[special:preferences]], might be to include a drop-down in [[special:expandtemplates]] that allows the skin to be specified, which then adds &useskin=foo as required?

I'll try fixing those up, thanks

Yeah, you'll definitely have to update that too.

Yep!

@Jdlrobson I just want to confirm with you is this what you are looking for?

That's right, I have been trying to replicate the error(s) locally, but haven't been successful so far. It may/may not be related to the fact that I did not change the makeMessage invocation in /tests/phpunit/structure/ApiStructureTest.php (ref) yet. Definitely would be helpful if you can provide some insight on this.

I'm not able to replicate the error and find the same appearance dropdown. Also i found a scope for improvement.

@Func &diffonly=true has been removed when you click on "next" page". This will be moved to Done. Thanks for all your work!

Thanks for picking up this task @theprotonade. I see you marked you patch as work-in-progress, so I assume you want to investigate the test failures yourself, but let me know if I should have a look at them.