In T200632#10226047, @FeRDNYC wrote:

Though it's admittedly a question of semantics, I'd argue that it's the shorthand properties that are dangerous, more than the CSS variables.

In T200632#4623300, @Anomie wrote:

CSS does provide a way around this in the CSS Custom Properties for Cascading Variables Module Level 1 (which is currently supported by about 87% of browsers)

<style>
div.box {
    border: 1px solid var(--color, green);
}
</style>
<div class="box">Green box</div>
<div class="box" style="--color:red">Red box</div>
<div class="box" style="--color:blue">Blue box</div>
<div style="--color:orange">
 <div class="box">Orange box</div>
 <div class="box">Also an orange box</div>
</div>

The trick would be to make sure that someone can't write something like this

<style>
div.box {
    border: 1px solid var(--color, green);
    background: var(--bg, white);
}
</style>
<div class="box">Green box</div>
<div class="box" style="--color:red">Red box</div>
<div class="box" style="--color:blue; --bg:purple">Blue box with a purple background</div>

because

<div class="box" style="--bg:url('http://evil.example/tracker.png')">Uh oh, privacy violation</div>

also works with that example. That particular example wouldn't work in MediaWiki because MW forbids "url(" in inline style attributes, but css-sanitizer and TemplateStyles shouldn't rely on that.

In T334940#9645371, @ChaseKiwi wrote:

this editor is of the view that a low overhead and secure graph option that allows an ordinary editor to update changing data by text entry is core functionality moving on that the Wikimedia Foundation could usefully prioritise.

Note that, despite the task description, the existing set of reports isn't quite so perfectly balanced. There isn't actually an "Unused pages" report. (What would that even mean?) Instead, there are several reports that cover different types of low-use conditions for pages, like Orphaned pages, Dead-end pages, Dormant pages. and Pages not connected to items*.

After I updated the instructions in that FAQ entry to include a version of the code above, including the check to preserve web-updater write access, I realized: The instructions tell the user to run the web updater in their new installation directory, before making it live. Which AFAICT isn't actually possible.

@aaron : Actually, testing locally I'm getting an error in the PHP logs, with is_defined():

Brilliant, thanks! Is there any issue with splitting it up into two lines (actually, two statements on three lines) like this, for readability?

Apologies for dredging this up, I just wanted to ask one point of clarification on the code @aaron
provided above:

In T213778#8033682, @alexhollender_WMF wrote:

It would be great for us to have some kind of response/plan regarding updating infobox background colors (maybe also needed for tables as well).

In T306568#7885858, @Anomie wrote:

I paraphrase that as you believing that assertNotTrue and assertNotFalse should not be used, and you want the sniff to push people in that direction rather than have the sniff produce a more accurate replacement that would be less likely to need manual attention.

In T246901#5969679, @Pigsonthewing wrote:

In T246901#5964613, @Jdforrester-WMF wrote:

For WP:BEANS reasons I won't go into depth about the potential abuse vectors, but certainly things we touched on were around problematic imagery or content, especially forms that are stenographically "hidden" or textures painted onto the inside of a surface so they're invisible on casual inspection.

While this may be so, how is it an different to stenographically hidden material in 2D-images or video files?