Good point. I may have to revise "it will not take twenty minutes" to "it will not take a couple of days".

Events have overtaken me!

A colleague of mine says:

in ve-core we load in codex-design-tokens/theme-wikimedia-ui.less and use the variables from there, which in MediaWiki should use the correct CSS variable
You'll need to check which variables are actually available in that less file as I think it was snapshotted a while ago

Thank you for letting us know about this!

Oh, and I forgot to do this earlier… screenshot!

This was doable with TextMatchEditCheck. The words list is by no means great (it didn't have color/colour on it when I got it...), but it works!

Turns out this is (almost) pure TextMatchEditCheck and I've been overthinking. See parent.

Related: we can decide whether to run a check based on categories: T347775: Implement edit check configuration setting to specify categories it'll apply within

See parent ticket for other requirements for a larger ticket.

This is in progress, although currently still in markdown format in a local editor. I'm waiting for some feedback, and I'm hoping to start getting this on the wiki this week.

We could cue with wikitext, also subtly hinting to users that they can choose these levels by typing the appropriate number of = characters:

See also: https://phabricator.wikimedia.org/T72004

Fixed.

We attempted to reproduce this in bare VE using a comment node, but the behaviour did not recur.

We were able to reproduce this bug in raw VE using a comment node.

It's doing a little jump before the animation starts, I'll investigate. It's occurring with or without parsoid.

I just realised the keyboard is another angle. I installed GBoard.

I've attempted to reproduce with no luck. @Esanders could you confirm I'm taking the right steps here?

Could you provide a minimal example of a page that breaks? I've been having trouble reproducing this.

Good point!

Signing off for the day, here's where I got:

i fixed up my caches so that partial caches from failed runs don't mess up the subsequent run. I tried lxml, which allegedly is better for avoiding OOMs while parsing XML, but it's still OOMing so possibly it wasn't there.

Logging some useful commands. On toolforge having done become zoe-oneoff-scripts:

I've modified my script which downloads thread info to accept an endpoint and an output file, and summarised the sizes of these wikis in terms of LQT threads:

I've tried using focusin and focusout events, but this doesn't seem to fix the issue. I think there's something funky going on with focus as clicking around inside of a RadioSelect causes the events to fire where I wouldn't expect them to (both for the focus/blur family and focusin/focusout).

Ah, good catch. Well, I'll be treading delicately...

Quick survey of what's got Flow and what has LQT:

I'll probably have to work my way through this sporadically, so I apologise in advance for things coming in comment by comment.

@Pppery I've written a community notice, we're reviewing it internally and are hoping to have it translated and up on ptwikibooks next week. I'm currently proposing that we give a weeks' notice and then execute everything in one go, unless the community wants us to make changes to that schedule.

Good news: looks like DiscussionTools exists by default and I don't need to enable it manually

There's complexity because this involves an interaction between two specific checks and we may have to discuss further how to approach this

Phew! I think I may have broken this down into too many tickets.