I have no issue whitelisting the rest: <mark>, <progress>, and <time>. (Of these, <mark> seems the most obviously useful.)

What about <meter>, <details> and <summary>?

In T25932#4801842, @Nirmos wrote:

you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is

If I'm reading https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view correctly, then IE8 is at 0.5%. If we assume that 1% of those have disabled JavaScript, that makes it 0.005% of all users, or five in ten thousand. Is that good enough to start whitelisting a few HTML5 elements in wikitext?

I don't think there's anything the parser (or any other part of MediaWiki) can do to change this behavior. It's completely up to the browser as far as I know. Would love to be corrected if I'm wrong.

The diff in https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-4o7rea2lrkhv4y4/ is illegible. All I did was adding <details> and <summary>.

you'll probably want to re-evaluate UA stats after Nov 17 to see what the true final fallout is

If I'm reading https://analytics.wikimedia.org/dashboards/browsers/#all-sites-by-browser/browser-family-and-major-tabular-view correctly, then IE8 is at 0.5%. If we assume that 1% of those have disabled JavaScript, that makes it 0.005% of all users, or five in ten thousand. Is that good enough to start whitelisting a few HTML5 elements in wikitext?

nor is the TOC headline in blue

I am struggling to understand what you mean by this, but it sounds like a regression, and an unintended one at that. You should probably file a new task about this, and tag it with "Regression".

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

In T210822#4788433, @Nirmos wrote:

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

As JJMC89 has already noted, this is because '' in wikitext opens an <i> tag. This <i> tag is then closed before the closing </code> so that the tags do not overlap incorrectly, causing the ; to be italicized. The following wikitext gives the intended result:

<code><nowiki>output='';</nowiki></code>

Can confirm. I recreated the minimal test case live in case that helps anyone:
https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Nirmos/T208901
https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Nirmos/Comment
https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Nirmos/Comment/styles.css

In T208140#4700118, @Krenair wrote:

In T208140#4700104, @Nirmos wrote:

loading an external script

CSP is on its way: T28508, T135963, T207900

CSP is good but it probably won't catch people e.g. loading JS from another, lower privileged, user?

loading an external script

CSP is on its way: T28508, T135963, T207900

Has the Parsoid patch that removes the p tags around style tags been deployed, and if so, when was it deployed? I'm asking because I'm still seeing style tags wrapped by p tags on for example https://sv.wikipedia.org/api/rest_v1/page/html/Anv%C3%A4ndare%3ANirmos%2FAnders_Bj%C3%B6rck

So, this was a combination of 3 things:

1. While the massmessage-optout-category category certainly is recognized by MediaWiki, it of course isn't added by MediaWiki. It is added manually by the users. This was a brainfart on my end.
2. On Swedish Wikipedia where I investigated this, old pages had the category "Pages with obsolete Vega 1.0 graphs". It had since been localized to "Sidor med föråldrade Vega 1.0 grafer", but the pages were still in the old category. This is a MediaWiki bug in itself. I have now resaved the pages so that they are in the new category and moved the category to the name that MediaWiki uses.
3. MediaWiki no longer adds any "Pages containing blacklisted links" category. It used to do this (the category key was spam-blacklisted-category). It was disabled for performance reasons in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/SpamBlacklist/+/122285/ Unfortunately, English Wikipedia manually adds this category using a template (Blacklisted link inline) which fooled me. This category really should be deleted on projects where it is empty, and hopefully the admins on enwiki can rename their category, although I doubt they would agree to that.

@Bawolff I'd like to get svwiki in report-only mode. Should I start a discussion with the community about this now, or is it way too early?

Filters can add tags. Doesn't this create the same chicken-and-egg problem that has already been described in T53421? Or am I completely misunderstanding what this task is about?

In T206411#4650108, @Framawiki wrote:

It is also possible that this bug is wanted, to avoid empty dict key in json files.

Now there is no line break between "(View source | Export)" and "Uses:"

If I'm reading https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b correctly, then the b tag only accepts phrasing content as content, and according to https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Phrasing_content neither ol nor li belongs to that category, so as I understand it, the input is invalid.

Produced HTML:

<p>
	<b>
	</b>
</p>
<b></b>
<ol>
	<b>
		<li>a b c</li>
		<li>d e f</li>
	</b>
	<li>
		<b>g </b>
		h
		<b> i</b>
	</li>
	<b>
		<li>j k l</li>
		<li>m n o</li>
	</b>
</ol>
<b></b>
<p>
	<b></b>
</p>

You have misspelled "minerva" as "minera" in https://zh.wikipedia.beta.wmflabs.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5/styles.css

Shouldn't the comment in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/454285/2/tests/phpunit/AbuseFilterTest.php be updated too?

The description mentions some onerror attribute that I've never heard of:

CSP disables all the inline ways of executing javascript (e.g. <img onerror="alert(1)"> )

Will this also affect onclick attributes?

As far as I can see, https://stream.wikimedia.org/v2/stream/recentchange works perfectly for glwiki. I'm testing this personally on https://sv.wikipedia.org/wiki/Wikipedia:Senaste_%C3%A4ndringar/EventStreams with the gadget that I have made: https://sv.wikipedia.org/wiki/MediaWiki:Gadget-EventStreams.js

It has nothing to do with lang=ru. It's the same problem on svwiki.

While starting to clean Commons.css, one of the administrators wondered if TemplateStyles might extend the loading time (parsing, possible duplication, ...). Do we know if this has a negative impact on performance?

See T185853. Even in the worst case scenario (i.e. in the migration period when styles in the MediaWiki namespace and styles from TemplateStyles are loaded at the same time) there was no measurable change in performance. In theory, TemplateStyles would be good for sparsely used templates, and bad for ubiquitous templates, but since we did not observe any such thing, my guess is that the amount of CSS that is local to a wiki is so small in proportion to the total amount of CSS. Unfortunately, I don't have any numbers to support that – it's just a gut feeling.

There is also svwiki-mw-tour, set to expire 1969-12-31T23:59:59.000Z (and yes, I actually can see this under Network → Cookies → Request Cookies in Chrome, not just under Application → Cookies).

In T12331#4419260, @IKhitron wrote:

Good idea, but could you, please, add filtering by namespace? Thank you.

If this is the case, then there wouldn't be interface editors at some wikis.

The idea of an interface editor or engineer group that is meant to be more accessible than sysop is indeed backwards with regard to security.

How are you viewing this data exactly?

I used the Storage tab in Firefox. If I instead use the Network tab, cpPosIndex, UseCDNCache and UseDC are not present.

cpPosIndex, UseCDNCache and UseDC definitely do not go away with two minutes of browsing. Also, I started my computer this evening (the 25th) and as you can see these cookies have an "Expires" date for the 24th, i.e. a date that has already occured.

Here are the cookies I have, if that helps:

centralauth_Session
centralauth_Token
centralauth_User
cpPosIndex
forceHTTPS
GeoIP
loginnotify_prevlogins
svwikircfilters-toplinks-collapsed-state
svwikiSession
svwikiUserID
svwikiUserName
UseCDNCache
UseDC
VEE
wikiEditor-0-booklet-characters-page
wikiEditor-0-booklet-help-page
WMF-Last-Access-Global
WMF-Last-Access

The relevant messages here are scribunto-limitreport-memusage-value-html and size-megabytes.

I made an edit request at https://meta.wikimedia.org/wiki/Talk:Www.wikivoyage.org_template#Pashto

there’s no reason a wiki cannot locally decide to add their sysops to the new group too

The problem here is that there are many wikis that do not have any bureaucrats. These projects would effectively lose the ability to edit their own site-wide CSS and JS.

Just noting here that there are two modules mentioned in ecc812f0 that are not present in PerfektesChaos's comment. These are:
mediawiki.api.login
mediawiki.api.rollback

(Most tasks regarding ApiSandbox seem to be tagged as MediaWiki-API, not MediaWiki-Special-pages, hence the retag)

https://test.wikipedia.org/

Will this task (and/or the parent task T161671) allow us to do cross-searches between page and user? For example: "Give me the edits on Wikipedia:Village_pump_(technical) by Nirmos".

This task seems like a special case of the more generic T63007. I think it would be better to solve that task instead. If that task is solved, you have solved it for any page, not just the main page, and not just for CSS, but JavaScript too.

Does this task have anything to do with the fact that

== Innehåll ==

is changed to

==Innehåll==

in https://sv.wikipedia.org/w/index.php?diff=42944724?

Wouldn't it be easier to create a template with the content

<code>{{#tag:nowiki|{{{1}}}}}</code>

?

And, for completeness

{
	const regex = /EmbedPLayer\./i;
	Object.keys( mw.config.get() ).filter( v => regex.test( v ) ).length;
}

gives 46, which means EmbedPLayer.IFramePlayer.DomainWhiteList is the only key with any capitalization error in that part of the name (that is, before the first dot).

Wooooaaahhh. I wrote

Object.keys( mw.config.get() ).filter( v => v.startsWith( 'EmbedPLayer.' ) );

in the console to see how many keys there are, and was surprised when I only got one value in the array. Turns out that one of the keys is misspelled. See the capital L in PLayer?

Will I as a gadget author have access to the violation reports for svwiki?

I would also like to challenge

In T190015#4171403, @Bawolff wrote:

You can't mass vandalize wikipedia using CSS.

I could live with "tech(nical)? (admin|sysop)" or "technician".

What's wrong with just "developer"? Is it because Wikimedia folk usually say "the developers" when they mean WMF staff, and you want to avoid confusion?

I'm pretty sure the BadMethodCallException is PHP, not JavaScript. The code below that is JavaScript, though.

Is this because of https://gerrit.wikimedia.org/r/419520 for T167246?

Now that this has happened, I suppose what needs to be determined is: Was this a one-time hickup, or will the same thing happen next week? If the former, there's not much use beating a dead horse, and this task can probably be closed. If the latter, I'd like to see some effort from the WMF going in to investigating this.

T193091 was filed about this.

Could someone remind me, is hewiki one of the two Wikipedias that get new software updates one day early? Is it hewiki and cawiki?

I'm a little bit confused here. This bug is about quoted URLs, and that's also what the commit message in https://gerrit.wikimedia.org/r/428371 says. However, RELEASE-NOTES-1.31 says unquoted URLs. Have you actually fixed two different issues here, or is the wording in the release notes a mistake?

If I understand your problem correctly, then resolving this task will not solve your problem because:

1. As far as I know, there is not (yet) any infrastructure for filtering out edits with a certain tag. The inverse (only showing edits with a certain tag) does exist, but that's not what we want to do here.
2. As far as I know, tags aren't applied retroactively.

In lieu of support from MediaWiki to do this, we can use JavaScript and CSS. You can add

$( function() {
	'use strict';
	if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Listfiles' ) {
		$( '#mw-content-text' ).prepend( '<button type="button" id="gadget-toggleflickr2commons" title="Toggle visibility of images uploaded using Flickr2Commons.">Toggle Flickr2Commons</button>' );
		$( '#gadget-toggleflickr2commons' ).click( function() {
			$( '.TablePager_col_img_description' ).each( function( i, e ) {
				if ( $( e ).text() === 'Transferred from Flickr via Flickr2Commons' ) {
					$( e ).closest( 'tr' ).toggleClass( 'gadget-toggleflickr2commons' );
				}
			} );
		} );
	}
} );

to Special:MyPage/common.js. This adds a button at the top of Special:ListFiles. When you click it, it will add the HTML class "gadget-toggleflickr2commons" to all rows where the description is "Transferred from Flickr via Flickr2Commons".

Ah, I see! So I have to change my code to

mw.hook( 'wikipage.content' ).add( function( elements ) {
	'use strict';
	if ( elements.hasClass( 'mw-changeslist' ) ) {
		console.log( 'wikipage.content fired' );
	}
} );

Thank you!