I do not use any of these scripts myself, but one script collection which I know is affected is the very popular fliegelflagel by @Schnark.

For most of these, it's going to just be a problem with the scripts - they make explicit assumptions about the layout that don't hold, and shouldn't necessarily be expected to hold - either because they weren't made with cross-skin compatibility in mind, or were meant to do something specific with this skin in particular.

While ideally these would be fixed script-side for more compatibility across the lot, or, depending, to simply not trigger if they're just not meant for this kind of layout, the presence of an off switch would probably resolve this enough for folks regardless.

That's not to say there may not be actual bugs that should be fixed skin-side - if this change breaks things that are supposed to be cross-skin compatible, that's probably something that needs to be fixed here, or at very least looked into.

In T196215#4253235, @Isarra wrote:

While ideally these would be fixed script-side for more compatibility across the lot, or, depending, to simply not trigger if they're just not meant for this kind of layout, the presence of an off switch would probably resolve this enough for folks regardless.

The question really is why we need responsive Monobook on Wikipedia at all. It is only used by some experienced editors who prefer it over Vector (either because it does not change all the time, or they find it more suitable at high zoom levels) and there are many scripts, quite a few without an active maintainer, which only work with the current, non-responsive Monobook. These very active and experienced editors constitute a valuable part of the Wikipedia communities and I believe the top priority of any update to Monobook has to be to improve the work of these editors, as Monobook within the Wikimedia universe serves no other purpose than being an editing interface for this specific group.

If a third party would like to have a responsive Monobook skin, I see no harm in providing this in the standard distribution, and I'm also not against changes to Vector or whatever skin we have which is used by our readers. But a responsive Monobook seems to me a solution to a non-existant problem, which to the contrary creates many new ones.

In T196215#4253289, @Cirdan wrote:

The question really is why we need responsive Monobook on Wikipedia at all.

Because all skins will need to be made consistent in order to properly fix the backend and move forward with the overall development of the skinning system in mw core.

In T196215#4253325, @Isarra wrote:

In T196215#4253289, @Cirdan wrote:

The question really is why we need responsive Monobook on Wikipedia at all.

Because all skins will need to be made consistent in order to properly fix the backend and move forward with the overall development of the skinning system in mw core.

I'm not very familiar with the way MediaWiki is structured, so I'm curious to learn more. Why does mw core care about the CSS of a skin? Since whatever elements are provided by MediaWiki need to be displayed properly in a desktop layout anyway, there should be no harm in just having this one layout option in a skin?

In T196215#4250328, @Cirdan wrote:

I do not use any of these scripts myself, but one script collection which I know is affected is the very popular fliegelflagel by @Schnark.

That's obviously not true, and unless I get a proper bug report that tells me otherwise, I don't see that this issue has anything to do with me.

In T196215#4255037, @Cirdan wrote:

I'm not very familiar with the way MediaWiki is structured, so I'm curious to learn more. Why does mw core care about the CSS of a skin? Since whatever elements are provided by MediaWiki need to be displayed properly in a desktop layout anyway, there should be no harm in just having this one layout option in a skin?

Because all the skins are currently totally inconsistent and just doing their own things. This makes it so that core/extensions can't make any meaningful assumptions about skins, and yet the only interfaces that currently exist to interact with them do make these kinds of assumptions, and thus just randomly don't work on some. You're right that core should not be caring about this stuff, and just providing data for the skinning interfaces to parse out into whatever, but this just isn't actually how it's implemented currently. And to fix it without breaking everything, we need to get all the different skins more consistent with each other too.

I'm not very familiar with the way MediaWiki is structured, so I'm curious to learn more. Why does mw core care about the CSS of a skin?

The problem is that MediaWiki skins are not just differences in colors etc. They also include their own HTML formatter, so all the html but even the classes and identifiers used for skinning are different.. This is creating lots of problems for all other parts of the software when they want to support multiple skins. This is also partially the reason as to why we are now using more and more OOUI for instance.

Remember, much of this was originally cobbled together over 15 years ago and making changes to that technical design retroactively is VERY hard with everything also being used by one of the biggest websites of the world. Where everyone runs their own JS, with no real way to painlessly transition those people, because if it breaks, even if they haven't touched that tool in 10 years, people will blame everyone but themselves. It's a tough ecosystem.

In T196215#4256378, @Schnark wrote:

In T196215#4250328, @Cirdan wrote:

I do not use any of these scripts myself, but one script collection which I know is affected is the very popular fliegelflagel by @Schnark.

That's obviously not true, and unless I get a proper bug report that tells me otherwise, I don't see that this issue has anything to do with me.

I apologize for not explaining more thoroughly. It's not a bug in your scripts, but a problem that was (presumably) caused by the new responsive Monobook skin which has now been reverted. (See Itti's comment on 09:21, 2. Jun. 2018 (CEST))

I just mentioned you because I know you are active here, your scripts were mentioned on FZW when the bug was discussed, and I thought perhaps you can give an estimate how difficult it would be to adapt scrips to a responsive Monobook.

In T196215#4256512, @TheDJ wrote:

I'm not very familiar with the way MediaWiki is structured, so I'm curious to learn more. Why does mw core care about the CSS of a skin?

The problem is that MediaWiki skins are not just differences in colors etc. They also include their own HTML formatter, so all the html but even the classes and identifiers used for skinning are different.. This is creating lots of problems for all other parts of the software when they want to support multiple skins. This is also partially the reason as to why we are now using more and more OOUI for instance.

Remember, much of this was originally cobbled together over 15 years ago and making changes to that technical design retroactively is VERY hard with everything also being used by one of the biggest websites of the world. Where everyone runs their own JS, with no real way to painlessly transition those people, because if it breaks, even if they haven't touched that tool in 10 years, people will blame everyone but themselves. It's a tough ecosystem.

Thanks for the explanation! However, while I now have a better understanding of what constitutes a "skin" in MediaWiki, I still don't understand why Monobook needs to be responsive. Is it not sufficient to adapt Monobook to whatever changes are made in the core so that it stays somewhat useable?

Monobook is neither pretty nor does it provide a great UX, but many editors prefer it precisely because it never changes. Considering that many scripts heavily alter the UI anyways to the point where it is crammed with links and buttons and wild colors, I guess that many of these editors would prefer a half-broken Monobook over Vector or a responsive Monobook. Which raises the question whether in the long run we should think about having as Monobook replacement an editor-centric skin which can be ugly, but helps to get the work done?