Another different but related use case is what DiscussionTools does, where it holds itself back from sending certain notifications (or sending them to certain people) if it knows that other notifications about the same edit are already going to be sent. In the new system we'd probably want to achieve this by batching the notifications for the same domain event, and sending them through the middlewares together, so that the middlewares can make these kinds of deduplication decisions.

The .chart page syntax looks good to me. I think a good way to start would be to build that part first, because we know we'll want that regardless of what we do for invocations.

Looks like the first and third paste are identical (except for the comment distinguishing them), so that's great!

[2025-02-12 12:01:17 PST] catrope:~/tmp$ colordiff -u Codex_Design_Tokens_export_before_after_stylelint_3.9.2_→_4.3.3 Codex_Design_Tokens_export_after_stylelint_3.9.2_→_4.3.3_without_.reverse\(\) 
--- "Codex_Design_Tokens_export_before_after_stylelint_3.9.2_\342\206\222_4.3.3"	2025-02-12 12:01:09.938469760 -0800
+++ "Codex_Design_Tokens_export_after_stylelint_3.9.2_\342\206\222_4.3.3_without_.reverse()"	2025-02-12 12:01:17.424764127 -0800
@@ -1,5 +1,5 @@

In theory we shouldn't have code in core that checks if an extension exists. In practice, we do have that in a few places, although those tend to have TODO/FIXME comments lamenting the hackiness of that approach.

Yes, this is done. It's still used in one place but its use is discouraged elsewhere, that's good enough for me.

Whoops sorry, I missed the previous exchange between you and Anne about the demo, ignore me.

The attached patch looks good to me. @bmartinezcalvo could you review the new demo here?

Related: T341351, T312142

Remaining questions/explorations:

• Handle CSS without a FOUC, and render any CSS at all when JS is disabled
• Should we use Vite, or switch to Rollup? Can we support CJS .vue files with either?

In T313945#10511079, @SD0001 wrote:

In T340460, there are three patches awaiting review that make it easier to use Vue in gadgets. Is someone be able to review them?

It's hacky but it looks like it should work for now. I think we should consider making menu headers a real feature in the future so that RCF doesn't have to do these kinds of hacks, but that doesn't have to be a blocker for RCF anymore.

Unfortunately there's no fix or workaround for this yet. There is a new release of stylelint-declaration-strict-value that claims to silence these warnings, but it doesn't work for me locally. The author has repeatedly made clear that they will not migrate away from the deprecated context.fix API until it's removed in a future version of stylelint.

In T374140#10459381, @Jdforrester-WMF wrote:

Unfortunately we can't upgrade test versions of Vue to 3.5.13 when MW is shipping Codex 1.19.1 (as npm ci fatals). I assume this'll get fixed with the next release of Codex next week?

In T383663#10467646, @MusikAnimal wrote:

Vue as I understand will re-draw the whole UI, and external DOM changes will be overridden.

I don't know exactly what will happen, but what I do know is that it'll be nothing good and that the external DOM additions/changes will probably be blown away at some point, but not immediately (which is probably worse from a user perspective). My guess is that they might last for some time, because as long as Vue is only making minor updates to the DOM (say just the text contents of a tag) it probably won't notice the interlopers, but then when an event happens that requires Vue to make a structural change to the DOM in the vicinity of the additions, I think it'll probably wipe them out. I haven't experimented enough to be able to predict the behavior accurately, but I'm pretty confident the answer looks something like "the DOM changes will remain in place briefly but will eventually be destroyed at an arbitrary-seeming, semi-unpredictable time", and nobody wants that.

CheckUser is so tightly coupled with the blocking and recentchanges in functionality in core that it doesn't make much conceptual sense for it to be an extension, IMO. That mini-rant aside, I see two options.

The only browsers we support (looking at Grade C not Grade A, since this is used in CSS-only components) that don't support mask-image are Firefox 49-52. If we bumped the Grade C threshold from Firefox 49 to Firefox 53, we could do this task.

In T361670#10452424, @thiemowmde wrote:

The Codex CSS for icons is surprisingly heavy and e.g. repeats the SVG code for each icon 3 times. I don't know if it's possible to load this part of the CSS dynamically only when an icon is actually needed in a popup?

cc @CDanis very interested to hear if you have any ideas / more context here

Recommend running a batch check on all Data: .chart pages currently on Commons before landing this to fix any with errors.

Yes, I meant to tag this as such but forgot

@Ladsgroup Compare the example under "markup structure" (you have to click "Show code" to see the code) for the old version vs the current version. There are three changes:

• The root element (with the cdx-checkboxclass) is now a <div>, instead of a <span>
• A wrapper div (cdx-checkbox__wrapper) was added
• The label structure is more elaborate: instead of a plain <label> tag with text in it, it's now a <div> containing a <label> containing a <span>

To clarify, it behaved as a soft block for me despite the red banner: after jumping through several hoops I was able to override this block and reenable the extension.

I'm not sure that DOMPurify is the right tool for the job here. DOMPurify takes "dirty" HTML and returns cleaned-up HTML. What we're dealing with here is a JSON blob that will be fed into echarts. There's no security vulnerability in the process of parsing JSON itself (even if that JSON was crafted by an attacker), so it seems to me that what we might be worried about here is:

1. Our client side code trusts the JSON blob too much, and injects data from the JSON blob directly into the HTML without escaping; or
2. There's some sort of bug/vulnerability/poorly designed "feature" in eCharts that injects data directly into the HTML without escaping

Not exactly the same issue but related: I discovered that these data attributes were being URL-encoded instead of using proper HTML escaping. I've submitted an MR for the chart-renderer service to fix this, and a patch in the extension to go with it.