This has only ever applied in CodeEditor before (therefore only non-wikitext formats), but now that I think of it this would be good to have in wikitext too, i.e. with {{templates}}, (anything in parentheses), and [[links]]. Unless anyone objects.

Here is an exhaustive list of vulnerable attributes, taken from https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/url_function:

Also, double-clicking at the start or end of a bracket pair (...), [...], or {...} should highlight all the text between the brackets, like it does with CodeEditor.

Thanks for the history! It was sort of a rhetorical question, but still neat stuff to hear about. 😄

In my opinion, the best thing would be to get rid of custom signatures entirely, but I acknowledge that this may be difficult since they are well-liked and heavily used. More of a "why were they introduced in the first place?" kind of thing than "we should actually remove them."

The checkbox "do automatically prettyprint the code when editing and remove such temporary formatting when saving the code" is checked off on the list in the task description. It was checked off by @Bhsd in January 2024 at T166098#9469820. Unless I'm misunderstanding what this point is talking about, it has not been done. There's no additional context available since it doesn't link to a subtask like the others do. Was this a mistake? If not, can someone clarify the text or add a link to a relevant Phabricator task? Thanks.

Instead of displaying just one of the two logs when viewing page-nonspecific log lists, it would make more sense to simply have history merges generate a single log entry that is associated with multiple pages simultaneously. No idea how challenging that would be technically, but it seems the better solution in theory, right?

Agree that this should be bundled, but wait till v6 is out of beta.

At the vary least, I'd suggest we wait till DPL4 has a stable release, since that's supposed to come with significant performance improvements.

Defining custom CSS variables has been error-free for some time now (since at least MW 1.43, although I'm not sure exactly when the change occurred). However, warnings are still generated in most cases when using variables. One notable exception is the background property, which doesn't produce a warning, even though background-color does. It seems that background undergoes no validation whatsoever, because even totally bogus values like background: blah blah blah are warning-free. Go figure.

IMO, the parser should give the same output regardless of user preference, so if we keep this preference, it should be done via CSS. As Ladsgroup mentioned, this would result in users who set their preference above 250px getting blurry images. I can think of two possible solutions:

Yes, I believe so, since the contents of <title> should match the title shown on the page (minus any HTML tags, of course).

Also, the header should probably use take the header markup from MediaWiki:Newsectionheaderdefaultlevel instead of hard-coding it.