@Aklapper: You are the one who started a meta-discussion here; please refrain from getting this ticket further off-track than you already did.
For the last time, thank you for focusing on constructive ways you can contribute to our projects

@Aklapper: This ticket is not a platform to argue for whatever conception of priorities you have. If you want this ITS to define Priority in a specific way, please argue for that in a specific ticket, ideally upstream.
That being said, I would expect someone who thinks that priority does not matter to prioritize other things than playing with priorities and their definition.
Thank you

In T6547#10984538, @Aklapper wrote:

Of course it does.

@Chealer: "... priority fields summarise and reflect reality and do not cause it".

Greetings Daniel,

The problematic code has moved to includes/Html/Html.php. The function code still looks incorrect, but I must say I am not sure this still affects MediaWiki 1.39.13, given that:

1. mine seems to work fine even now that I disabled my workaround
2. there is a lot less activity in this report than it used to.

Thank you for reporting

In T899#10984481, @Aklapper wrote:

Sure. As the maintainer of Wikimedia Phabricator, I do not plan to address this issue.

@Aklapper: This is not a feature, but―like the vast majority of tickets―an issue report, with an implicit (sometimes explicit) request to solve that issue. The corrected title does not imply this issue is a bug any more than "Andre does not do my dishes" is a bug. It merely describes the current situation.
We try to keep reports functional and focused on problems. An even better title would be "ITS (Phabricator) allows creation of too many duplicate tickets". Analyzing which solutions are best is a second step.
Thanks for your understanding

In T899#10981188, @Aklapper wrote:

@Chealer: What did you reopen?

In T6547#10977498, @Aklapper wrote:

I strongly disagree with reducing this ticket’s priority to "Low".

@Chealer: It does not matter. Priority reflects reality. It does not influence planning.

Thank you very much @Pppery.🙏 The little public information about @MZMcBride’s ban is available on that MediaWiki discussion page.😓 @Aklapper: Are you saying that "inactive accounts" (as you call them)🙄 cannot even get notified of activity, and hopefully reply through other channels?

@Aklapper: Nobody asked about "your"(?) plans. What are you declining?

In T899#824497, @Qgil wrote:

Checking https://phabricator.wikimedia.org/token/given/ we can still see that tokens are being used on a daily basis by a variety of users, and in most cases the meaning is easy to interpret. I think we can resolve this task and decline the request to disable tokens.

In T899#792191, @Qgil wrote:

[…]

So yes, Tokens is an application and it can be technically disabled. However, I don't see a reason to remove it. Tokens are not doing any harm, and they seem to be doing some good.

Then one day code review will arrive here, and chances are that people involved will use them as equivalents of +1, 0, -1, this time as part of a process.

Thank you for reporting @Amire80
It has been a long time since I used VisualEditor and I was not aware of the 2017 wikitext editor, so I am poorly qualified to contribute to this ticket, but I nevertheless tried to clarify it. I removed the VisualEditor tag, since although there is a relationship, applying that tag probably just adds confusion.
I encourage you to review the changes I did to the description. In particular, the name of the main button is "Publish changes…" following T189803. Prior to that, it was (just) "Publish changes". I changed your description assuming that this changed from "Save" to "Publish changes" quickly after you reported.

The "new wikitext editor" which T104479 tracks is now available as an opt-in alternative. It is indeed very similar with the VisualEditor in that regard, however that creates its own issues (discussed in T153306 ).
@Nemo_bis: There are obviously switching costs to using different interfaces, but I am a little surprised by this issue. Placing buttons such as Save/Cancel at the bottom is very common in HTML forms. Was the problem worse for the editor who started with VisualEditor? Can you provide an estimate of how much time was lost finding the button?

Some of the comments relevant to this issue are actually found in the related T6547, which is very long. They were posted in 2010 and Q1 2011.

This was done, but reverted in September 2011: https://static-codereview.wikimedia.org/MediaWiki/95396.html

@MZMcBride: Could you clarify what you mean by "global modules"?

I strongly disagree with reducing this ticket’s priority to "Low". I consider this a very high importance issue, and the cost seems reasonable considering that the MediaWiki change which was meant to solve the performance problem was formerly merged.

Thank you for this report. This is blocking T6547, which has at least medium priority, so I am increasing this ticket’s priority accordingly.

Tpt: I do not know what this report is about, but MediaWiki has allowed it for decades. This is not a duplicate of T6547.

In T8575#112057, @bzimport wrote:

aculver wrote:

!== Non-TOC Section ==

Then you could do things like:
<includeonly>!</includeonly>== Section to not apprear in TOC of including pages ==
<noinclude>!<noinclude>== Sections to only appear in TOC of including pages ==
in your templates

@GOIII : I renamed this report back to something closer to its initial title. The initial title was not great, but issue report titles should avoid suggesting specific solutions and stick to describing the problem in functional terms. This makes it easier to find tickets.
Moreover, I am not even sure of the sense of "Conditional use of plain heading element tags use".

I do not know about color spaces so am not able to comment on what librsvg does or should do. But my Windows 11 color picker is showing different values for the PNG and the SVG, so something has to be wrong. Unless Firefox is misdisplaying the SVG, the PNG is inexact.

@Glrx: If you're questioning the first number in the 2 cases provided, I certainly did not analyze the PNG file's contents. I must have used a color picker. This still reproduces at least with #1, using Firefox 137's color picker. Both now and back in October, I was testing with Firefox on Windows 11.

Many/most use cases of pre-formatted text at the time can now be achieved with the HTML code element. MediaWiki can generate the HTML pre element in a list when writing the tags, as explained in T3581.

Thank you very much for this report @Purodha. Other tickets tracking the lack of list expressivity are T3115 (formerly ticket 1115 on Bugzilla) and T3584.

I do know how costly a solution would be, but given how high the importance is, the priority is surely at least medium. The only reason reason given (in 2019) for not setting it high was to reflect "actual priority for developers", which didn't seem high since this had stayed outstanding for so many years🙄

In T40010#10259652, @RazrFalcon wrote:

but resvg's loss of Yevhenii Reizner, who had been doing about 9/10 of the work from the beginning, is a serious threat to its future

Funnily enough, when I've started working on resvg around 2017, librsvg was dead/abandoned for more than a decade, which was one of the reasons behind resvg creation.
And like a year later, 2018ish, librsvg authors started a rewrite to Rust, which revitalized the library.

I went ahead and proceeded to reframe this as a more specific request. I must clarify this does not mean I oppose marking this as a declined request. Or even as a processed request, since if this is an RFC as the title claims, this has already managed to gather its fair share of comments.

In T40010#425867, @Aklapper wrote:

What are the exact criteria to evaluate against, in order to get this ticket fixed? Currently this sounds unfixable due to vagueness.

In T40010#10252579, @AntiCompositeNumber wrote:

The qps codfw k8s and qps eqiad k8s graphs contain queries per second data for the current primary and secondary datacenter, respectively. Thumbor doesn't unconditionally echo requests from the primary to the secondary datacenter anymore, so the primary datacenter has a higher load. The CPU time for >75% of requests is recorded in the Processing CPU time graphs.
The numbers have all gone slightly up since 2020.

In T40010#6635039, @AntiCompositeNumber wrote:

According to Grafana, eqiad and codfw each get an average of 0.8 queries for new SVGs per second, with spikes up to 4 qps. More than 75% of those requests are handled using 575ms of CPU time on average. For context, there are 8.4 requests per second to eqiad and codfw for filetypes handled by imagemagick, including SVGs, which use 2-4s of CPU time.

In T40010#10251993, @Bawolff wrote:

If you are effectively saying that an SVG rasterizer yields better results on files which contain JavaScript than client-side rendering of the same file via <img>, please highlight that significant concern in T5593.

No, it would be mostly the same. Javascript is disabled in both contexts.

In T40010#10251565, @Bawolff wrote:

there was no robust and up-to-date FLOSS SVG sanitiser that could ensure that the SVGs were safe to display directly in the browser.

DOMPurify exists now and meets that criteria imho. However that is actually besides the point since svg in <img> tags do not execute javascript or external resources so is safe (embedding in an iframe/object is more risky, but probably not any more than the status quo and i dont think that is wanted anyways. The only really risky thing here would be to directly embed the svg tags in the html page, which i dont think anyone is suggesting). […]

In T40010#6639738, @Gilles wrote:

My recollection of why we don't serve user-submitted SVGs directly as thumbnails is that the last time this was looked at there was no robust and up-to-date FLOSS SVG sanitiser that could ensure that the SVGs were safe to display directly in the browser.

XML is notoriously hard to sanitise and there are new tricks invented regularly to bypass sanitisation. Essentially, we don't want to deal with the possibility of a badly intentioned actor being able to inject a tracking URL inside an SVG that would let them collect IP addresses of anyone viewing that image in an article, run some arbitrary javascript, or worse, being able to leverage a browser security flaw in SVG parsing.

Furthermore, we would still need to have fallbacks for browsers that either don't render SVG natively or do a terrible job at it.

Side note about color accuracy

I noticed while sorting all our check mark variants that the color of some PNG conversions are slightly incorrect. The body of the check mark in the SVG has a color different from the body in the PNG, although the difference is hard to notice from naked eye. Cases I noticed:

I absolutely agree with @JoKalliauer that lowering priority to Lowest was wrong in 2015.

Wikimedia now uses a recent enough librsvg, but as @JoKalliauer wrote, this does not solve the problem, it only facilitates one avenue; I rectified the description accordingly.

In T106240#4181577, @Nikerabbit wrote:

some recommendations to do user testing with TemplateStyles and CSS filters before investing further (brion, 21:48:11)

The issue with CSS filters is that it is damn hard to add a (specific) color to black icons.

Yes, you are right @Pppery, I also have that permission. As you say, the interface was just more counterintuitive than I could imagine.
Thank you for the change, for the explanation and for the extra advice

Thanks @Reedy, but the appropriate type adds a visible red label to the report itself and in listings, and allows to find it using advanced search.

@Aklapper: this is in fact a bug report, not a task. Although this comes from a rasterization bug and would naturally be fixed by getting a correct rasterizer, it was most appropriate for @Arthurfragoso and @doctaxon to mention alternative solution a decade after this was reported. Moreover, MediaWiki 1.43 will drop support for Internet Explorer 11 and Wikimedia sites already dropped even basic (grade C) support a few months ago. In any case, srcset allows avoiding rasterization for the vast majority of users.

Completion was announced in Tech News: 2024-24.
Thank you very much for processing

For clarification, multilingual SVG files are discussed in https://gitlab.gnome.org/GNOME/librsvg/-/issues/735

@Nemo_bis: This does not duplicate T3115. T3115 is requesting a wikisyntax semantic change.

In T181987#3808826, @Reedy wrote:

	static function srcSet( array $urls ) {
		$candidates = [];
		foreach ( $urls as $density => $url ) {
			// Cast density to float to strip 'x', then back to string to serve
			// as array index.
			$density = (string)(float)$density;
			$candidates[$density] = $url;
		}

		// Remove duplicates that are the same as a smaller value
		ksort( $candidates, SORT_NUMERIC );
		$candidates = array_unique( $candidates );

		// Append density info to the url
		foreach ( $candidates as $density => $url ) {
			$candidates[$density] = $url . ' ' . $density . 'x';
		}

		return implode( ", ", $candidates );
	}

Does casting to a float if local is de cause this problem?