I see no interest so I'll go ahead with my changes in other states.

P.S. If you intend to use my code for uploading files, please send me a quick message on Commons. This will help us coordinate better and speed up our collective efforts for the greater good 😉. Thanks! 😊

Also, is there any documentation (or discussion) onwiki about the specific kinds of syntax errors that are most commonly involved, so that editors could perhaps have tips in mind for what to look for? Or any kind of similar helpful tips.

I already have a bot here: https://github.com/Eccenux/mass-map-USA-county

I no longer think this is a good idea. Patchdemo is probably enough :)

@Aklapper yes, MediaWiki core maintenance script.

Yeah this is probably true for all those county maps of USA. Seems like a one person did an initial version of them. All with similar clip path. So far I've done NY and Alabama. Alaska was a bit more tricky (not really counties, different names)... I guess I might start with the easy ones so that I get more done sooner.

@Skalman Seems like what you need is an ability to pass a matcher function.

var h2 = mw.util.querySection( (s)=>s.level == 2 && s.heading.textContent.startsWith("Svenska") ); // first match wins (as with querySelector)
var h3s = mw.util.querySectionAll( (h)=>s.level == 3 && s.parent.heading == h2 ); // all matches

Result could be an array for easier manipulation with .map() and .filter(). Don't think this API should be using jQuery as a resulting array.

This is the last demo with SVG enabled by default:
https://patchdemo.wmflabs.org/wikis/604876b5e5/wiki/Main_Page

I think the PoC is cleaned up and ready to go.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1043323

There is one weird issue: the SVG disappears when not modified (you edit with VE; modify 1 of 2 SVG; check diff). So I guess some change in the VE configuration or something extra might be needed.
Embedded SVG editing in VisualEditor bug?

Sorry about the noise... 🙈 Finally got this right though. BTW. @SD0001 I think you have a typo in your rendering of attributes ;)

In T366517#9859042, @Tgr wrote:

Gadgets depend on user preferences (even if a module is default, you can still disable it). So either you have a URL which is the same for everyone but the CSS/JS it returns depends on user preferences (meaning it cannot be cached), or you have a URL which changes when the CSS/JS changes, but then that URL has to come from somehwere, so you need to put it in the HTML in form, and then it's the HTML you cannot cache (or need to invalidate all the time). Either of those would be significantly bigger problems than having to be careful when deploying new default gadgets.

In T366517#9858458, @Tgr wrote:

So the issue is that you have newly added the "infobox" gadget (in the sense of making it default) and edited Mobile.css (etc), and changing the list of RL modules to be loaded for a page and changing the contents of an RL module are different actions with different caching behavior (since the module list needs to be included in the page HTML while the contents of a module doesn't)? I doubt much can, or should, be done about that. Invalidating caches is expensive; you can't invalidate every page when you make a CSS/JS change, and you don't want to delay all CSS/JS changes until the cache expires.

Given that duplicate CSS rules are mostly harmless, I think the solution here is just to restore the old CSS rules temporarily.

Thanks Func. Yes, I removed infobox styles both from mobile CSS (Mobile.css) and desktop CSS (Common.css). The problem was last reported 4 days after adding the default gadget when the styles were removed from Mobile.css and Common.css.

for templates used even in 30% of page views, it's better to keep them as template styles instead

Yeah, I already heard in T362747 that it's probably 7 days, but might be up to 14 days (maybe).

@Nux was what deployed ? What gadget? Specifics would be helpful here :-)

Was this deployed? After 4 days of moving desktop and mobile CSS to a default gadget we still get reports that some pages don't get CSS from the new gadget.
https://pl.m.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne?markasread=28372271&markasreadwiki=plwiki

Thanks! And thanks for the warning too :-)

An example article (notice how borders are not collapsing)

User reporting this as a bug:
https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=73830997#Nieprawid%C5%82owe_wy%C5%9Bwietlanie_symboli_IPA_w_pop-upie_nawigacyjnym

I don’t imagine these advanced things being used much. While the third option would be by far the most powerful, I don’t it would be by far the most useful.

Now that 1) ES6 is the Grade A JavaScript requirement for MediaWiki and 2) the validator now supports ES6 (T75714), this means we no longer need the "requiresES6" flag for the gadgets extension, correct?

Confirmed to work on patchdemo :-)
https://patchdemo.wmflabs.org/wikis/745f82bb2b/w/index.php?title=1886_in_Chile&oldid=154&diff=cur

Not ideal but there is a gadget that at least adds whitespace:

// [[MediaWiki:Gadgets-definition]] formatter (links and stuff)
if (mw.config.get("wgCanonicalNamespace") == "MediaWiki"
	&& mw.config.get("wgTitle") === "Gadgets-definition"
	&& document.querySelector(".mw-parser-output")
)
{
	mw.loader.load("https://meta.wikimedia.org/w/index.php?title=User:Nux/gadgets-definition-ux.js&action=raw&ctype=text/javascript");
}

You can add this in:
https://meta.wikimedia.org/wiki/Special:MyPage/global.js
and it will fix scrolling on:
https://commons.wikimedia.org/wiki/MediaWiki:Gadgets-definition

I'm with Izno on that (especially with point 1). That particular template feels like even/odd modules in npm [:

I should mention that what I would actually love to have is <section> or any kind of parent/wrapper of the elements in the section. That would make many such things as nominations easier (del requests, good article, dyk article etc).

Hi. I specifically moved buttons away from section headers recently and into a template we can control locally (on wiki). This has drawbacks -- I needed to add section names to the template... but also again something we can control locally, not something that might change with a skin or MW update.

In T334940#9617644, @NorthernMoonlight wrote:

it has become clear that there isn’t a safe shortcut here and that the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on.

Am I reading this right? A year after a major feature was broken they haven’t even started working on it?

In T357197#9582720, @SD0001 wrote:

In T357197#9531264, @Krinkle wrote:

It's not that simple I'm afraid. To diverge browser support in Gadgets from the rest of MediaWiki in this way you'd need customisation for mw.loader, for startup.js,

No customisation is required when gadgets are in a separate group. If any of them contain an ES8 feature which is not supported in the browser, the bundle doesn't work – which at the maximum can only cause other gadgets to not load, which seems like a reasonable tradeoff considering that no one so far has brought up a single example of a Grade A browser that doesn't support ES8. Even if one exists, gadgets are optional enhancements without which the site still works. Quoting from the frontend best practises: "Embrace that every page starts with basic HTML and CSS, and that JavaScript adds optional layers that may or may not arrive. Its eventual arrival depends on numerous factors, and may vary over time even for the same person"

Fixed by moving style out of text element, so there seem to be some problem with the render possibly related to style cascade.

As someone who spent years maintaining user scripts and gadget on en.wp and providing support for users on WP:VP/T..... There is some truth to that, but I'd argue that a significant amount of the userscripts and gadgets are continuously broken. They cause issues for people where their javascript sometimes doesn't load. They cause errors to show up in the WMF logging.

[…] I've tested building my DYK tool with Babel. The build is significantly slower. […]

This is an excellent argument against such build step! We generally don't use one for MediaWiki. Do you still need it? For many devs, they mainly did this in ~2013 as a way to get "Package files" and ES6 syntax. These are supported natively now. Build tools now mostly a left-over trend from the 2010s era of frontend development, involving needless complexity for largely unproven and misunderstood benefits.

I just want to add a few things to those already quoted by @SD0001 (thanks).

@Nux Standardisation is not in question. Unlike new Web APIs (such as fetch), which can be polyfilled, or used via a conditional "if" statement, new syntax, if allowed even once, immediately breaks all code in many browsers that we still support. You can complain to upstream TC39 for having introducing features in ES2017 in a way that is backwards-incompatible. When MediaWiki raises its minimum requirement to ES8/ES2017, we will on the same day, raise the ESLint and site script validator to also allow this syntax.

In T350181#9527187, @Izno wrote:

Diff colors: see T90948: Identify the best diff style (mobile or desktop) and use it on both mobile and desktop, which has related links and rationale for why blue and yellow exist. The short answer is red-green color blindness, especially in the context of inline diffs. That task has already been linked here and is the correct place to discuss further if at all.

Hi. I was forwarded here from another task :). I did a colour change for myself as I had problems remembering on mobile which colour is which. Changing to red-green helped with that.

Sorry, I forgot I have a much smaller request. Could you flip the legend in HTML? I think "removed" belongs on the left side, and this is where inline diff puts "removed".

I was hoping I wasn't too late to make all of them red-green (so changing mobile/wikitext, not VE)... I think I agree with Sam here:

There are no plans currently to raise browser requirements to ES8/ES2017 or ES2020 etc. Not likely until browser engines, browser vendors/apps, audience usage thereof catch up.

In T334940#9510646, @Lockal wrote:

@Nux, just to say, there is ongoing work in T222807.

Somehow they managed to implement the sandbox even without a separate domain. Although, if I understand correctly, this allows to make /api.php calls (non-authenticated, ofc).
...

Just BTW, but it is weird that visual is red-green and wikitext (inline) diff is yellow-blue. Shouldn't they both be red-green?

In T334940#9480339, @TheDJ wrote:
Separate domain to serve iframes from, so that we can have interactive and cacheable content (pretty complex)

In T178356#9458411, @SD0001 wrote:

In T178356#9458355, @Nux wrote:

(ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

For the record: This is incorrect. Both async and await comes with ES2017/ES8. See e.g.: https://flaviocopes.com/es2017/#async-functions and also https://262.ecma-international.org/8.0/

It's not incorrect. for await is for asynchronous iteration which appeared only in ES2018. https://caniuse.com/?search=for%20await

(ES2018) for await - Firefox 58+, Safari 11.1+, Chrome 63+, Opera 50+, Edge 18+

Note that async allows you to do much, much more readable code. E.g. by using await in HTML dialogs:
https://github.com/Eccenux/wiki-DYKCzyWiesz/blob/59d3b9ed4d93b6c42a59a9e7ce85b327d4bd9d64/src/DoneHandling.js#L80

I did not mean to argue that using requiresES6 for ES8+ should be supported, only that if that parameter is dropped or people are directed to remove it, Tech News should make it clear that that isn't a no-op change. I don't think it's that unlikely that someone did use for ES8+ code, either because they did not realize the code is ES8+, or because they didn't know requiresES6 means "ES6 and ES7 but not ES8". If a gadget breaking is the gadget developer's fault, it is still helpful to point them to the cause of the breakage.

You need to change comments moving them out of list items. https://ar.wikipedia.org/w/index.php?title=%D9%85%D9%8A%D8%AF%D9%8A%D8%A7%D9%88%D9%8A%D9%83%D9%8A:Gadgets-definition&action=edit

Oh, so all of that leads to an article. I assumed it was for a script :)... So that is not blocking removal of the Gadget namespace from enwiki too.

So if I understand it correctly, when sandbox'ing is applied, it always gets a transient origin, which means that upon each request the origin effectively changes and thus there is no caching right ? And the only way around it is using a separate domain without sandboxing ?

I think the message should be modified. This is not a very friendly message. Especially with that "localhost" which might freak out a dev 😉 (my initial thought: why is Wikipedia trying to connect to my localhost). Jokes aside, the message does suggest there is problem on my side but – as I understand – this is mostly a backend problem. So maybe log some details to JS console or a tooltip or something...

I also found this in whatwg spec:

<iframe sandbox src="https://usercontent.example.net/getusercontent.cgi?id=12193"></iframe>
[Warning!] It is important to use a separate domain so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page.

Use a separate but unsandboxed domain (en.wikipedia.wikimedia-usercontent.org or something like that) that internally resolves to the same wiki (with similar effects to the "sandbox mode" mentioned above, except it wouldn't do sandboxing, just relying on the origin / registrable domain being different). This would of course vastly increase the effort required (buying the domain, setting up DNS rules, certificates, a bunch of changes to site configuration...).

Clam and others supported by 95.8% of browsers globally:

The quick fix for this particular case is to update the URL in Toolhub to the un-encoded value of https://commons.wikimedia.org/wiki/File:Logo_Dzień_Nowego_Artykułu_Orem_version.svg. I have done this at https://toolhub.wikimedia.org/tools/dna/history/revision/46196/diff/48064 and the desired icon is now rendering.

Thanks for the fix. That seems like a less invasive way then I wanted to do it.

Ci/cd configuration can be separated. For example I have a Jenkins installation of which configuration is not accessible to anyone. Jenkins pools GitHub and runs Wikiploy. That Wikiploy script can be in a separate repo if I need to. There is no problem in that.

So I kind of actually implemented this myself 🙂

Does that mean you cannot reach non-mobile https://pl.wikipedia.org/wiki/Specjalna:Różnica_mobilna/71469982 anymore? Because I can.

I assume modules and templates using the classes are also affected, right?
https://pl.wikipedia.org/w/index.php?search=insource%3A%2Fmw-ui%2F&title=Specjalna:Szukaj&profile=advanced&fulltext=1&ns8=1&ns10=1&ns828=1

Petscan also depends on this. Or to be more exact it assumes calback parameter is available to avoid CORS issues.

Hi. @Aklapper this shows that Wikipedia:Portal wikipedystów also triggers the switch of skin from monobook (prefered by Cuku New) to default (V'22).

If supporting negation perhaps it should be thought about more broadly and apply to all options (see also T342532)

Hm... I guess the parser part can be more universal. But I think having gadgets not in main namespace would help with budgets etc more. I assume most people, most of the time, probably visit only the main namespace.

For the performance sake could you support namespace!=0 syntax?

@Jdlrobson done. Didn't help, but I guess maybe cache? (purge didn't help though)

For Polish Wikipedia all disambiguation pages have {{Ujednoznacznienie}} on top and the page preview fails for them.

Seems like tags with explicit display:none are removed. So the problem was not the span with class (like I assumed). I've modified our template and it should work now.

I think .noexcerpt should be added explicitly to templates (rather then implicit, default class for Phonos).