Change #1041202 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/MinervaNeue@master] Statically define max width breakpoints without calc

https://gerrit.wikimedia.org/r/1041202

Change #1041228 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.less: Fix calculation for Less

https://gerrit.wikimedia.org/r/1041228

Change #1041202 abandoned by Jdlrobson:

[mediawiki/skins/MinervaNeue@master] Statically define max width breakpoints without calc

Reason:

After further investigation, we realized this is only applying to skins which do not use Codex design tokens and this should not be needed.

https://gerrit.wikimedia.org/r/1041202

Change #1041228 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.less: Fix calculation for Less in skin.defaults.less

https://gerrit.wikimedia.org/r/1041228

After investigating this some more, it transpired the issue was a longstanding issue that was only causing an issue in Monobook. We have fixed the issue by making sure these are wrapped in brackets to force LESS to calculate it correctly.

@Jdrewniak created the following minimal test case:

@a: 666px;
@b: @a - 1px; // treated as string @a - 1px.

@media (max-width: @b ) {
	.foo {
		color: blue;
	}
}

According to @Catrope the problem here is "MW is stuck on a PHP port of an older version unfortunately".

@Catrope what are next steps on this ticket?

Note that calc() works in media queries, although it is not valid according to the formal definition. See this thread on Stack Overflow (for instance this answer, which points to the specs and to the browser compatibility table).

As it seems to be not (yet) officially supported, I can't recommend to use it, for the time being. Maybe the media query specs would need to be updated, to unambiguously allow using this feature.

That being said, we should avoid such dynamic client-side calc() here, as beforehand server-side, we are able to determinate the plain value.

Thanks @Od1n for the further information. Reason for calc() in original Codex definition was, that we aimed to provide possible Codex theme authors with the possibility to use not only pixel values, but also em values for breakpoints, as those have been stated as best practices in CSS for responsive design from some authors in the past. And then we'd end up mixing (giving fictitious numbers here): calc( 30em - 1px ).

You made the confusion that I was fearing: in the current asset provided to clients, there is no calc(), only a bare addition (resulting from some Less transclusion), which is invalid CSS.

edit: I doubt you made such confusion… On my side, I don't recall what is that original Codex definition. Whatever, the bug has been found and fixed. Everything is fine.

In T367103#9877618, @Jdlrobson wrote:

According to @Catrope the problem here is "MW is stuck on a PHP port of an older version unfortunately".

Indeed, development of leafo/lessphp seems to be almost stale for 10 years…

• edit: We are using a fork, see Volker_E's message below, which points to this repository (GitHub mirror). Though, this fork seems to also lack the desired features, see T288498 for details.
• edit 2: What we are using is not a fork of leafo/lessphp, but a continuation of oyejorge/less.php. See Krinkle's message which brought the explanation.

Issues with calc() have been fixed (for a long time) in the canonical JavaScript version, see for instance this issue and this question on Stack Overflow.

But it's still occurring in the PHP port, see for instance this issue, which points to this workaround (same workaround as above).

In T367103#9877618, @Jdlrobson wrote:

After investigating this some more, it transpired the issue was a longstanding issue that was only causing an issue in Monobook. We have fixed the issue by making sure these are wrapped in brackets to force LESS to calculate it correctly.

According to @Catrope the problem here is "MW is stuck on a PHP port of an older version unfortunately".

• Less.js PHP port

Which also added to another confusion here for the next comment by you @Od1n. We're using a [[ fork of the library at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/libs/less.php | mediawiki/libs/less.php ]].
See also T288498: Update less.php port to support Less.js 3.13 behaviours

@Catrope what are next steps on this ticket?

From my point of view this should be 1) resolved and 2) another task started to replace the calc() based breakpoint tokens with absolute values as long as calc() in media queries isn't supported in our Less.js PHP library and maybe 3) add another task to re-instate this with dependency to the Less.js one.

In T367103#9878184, @Od1n wrote:

development of https://github.com/leafo/lessphp seems to be almost stale for 10 years…

In T367103#9878381, @Volker_E wrote:

We're using a fork of the library at mediawiki/libs/less.php.

FYI: wikimedia/less.php is not a fork of leafo/lessphp.

Before 2015, MediaWiki used leafo/lessphp and we also contribed upstream. In 2015, MediaWiki switched to oyejorge/less.php (T112035). This is an independent implementation. Not a fork.

Then, in 2019, Wikimedia coordinated to transfer and take over maintenance of this library. The history of the less.php library is documented in our repo's README.

Jdlrobson removed a project: MediaWiki-Platform-Team.

I assume this means this is no longer seen as a bug/regression in Less.php, but a bug against Minerva/Codex where it was found that something starting to make use of an unsupported Less feature? It's not obvious to me what changed, but let me know if you do think it's a Less.php regression.

Here's the bug in Less.php: T367603

Sadly, these changes broke displaying of the search input in the Pale Moon browser, on screen widths below 1120px. See this forum thread.

It is because this browser doesn't support calc() in media queries. Sadly again, the main developer stated that implementing this feature would be quite difficult.