Page MenuHomePhabricator

Responsive Layout for Monobook broken when standard user scripts are used
Open, Needs TriagePublic

Description

The introduction of a responsive layout in Monobook (T195625) breaks the site layout for users, especially sysops and buerocrats, who are using a collection of standard user scripts in their workflow. Some report that they had to switch to Vector to keep the site usable at all.

One less problematic example can be seen here:

Some also reported that they had problems at the large zoom levels they regularly need to use due to bad eyesight. (see T196213)

Since I believe only long-time and experienced users are still on Monobook, many of them because the scripts they need to do their work are only available there, the site working for them should be more important than a responsive layout.

Event Timeline

Cirdan created this task.Jun 2 2018, 7:25 AM
Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptJun 2 2018, 7:25 AM
Legoktm removed Isarra as the assignee of this task.Jun 2 2018, 7:40 AM
Legoktm added subscribers: Isarra, Legoktm.

@Cirdan thanks for reporting. Could you provide links to the specific scripts that are broken?

We're tracking the zoom issue as T196213.

The change has been temporarily reverted for now, as explained at T195625.

Cirdan added a subscriber: Schnark.Jun 2 2018, 7:42 AM

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.

Cirdan updated the task description. (Show Details)Jun 2 2018, 7:43 AM

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.

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.

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.

Cirdan added a comment.EditedJun 4 2018, 7:48 PM

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?

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.

Schnark removed a subscriber: Schnark.Jun 5 2018, 9:21 AM
Isarra added a comment.Jun 5 2018, 9:36 AM

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.

TheDJ added a comment.Jun 5 2018, 10:07 AM

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.

Cirdan added a subscriber: Schnark.Jun 5 2018, 12:36 PM

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.

Cirdan added a comment.EditedJun 5 2018, 12:46 PM

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?

Schnark removed a subscriber: Schnark.Jun 6 2018, 6:56 AM
Vvjjkkii renamed this task from Responsive Layout for Monobook broken when standard user scripts are used to wsbaaaaaaa.Jul 1 2018, 1:06 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot renamed this task from wsbaaaaaaa to Responsive Layout for Monobook broken when standard user scripts are used.Jul 2 2018, 1:18 AM
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.
Evad37 moved this task from Backlog to Responsive MonoBook on the MonoBook board.Aug 21 2018, 7:29 AM