Looks like my analysis on the other post using Wikiless for comparison is wrong: the new theme does transfer about 50% more data and has double the uncompressed "weight" that the previous one did, for this article. Memory use similar, bouncing between about 215 and 230MB.

This really should be the top comment on this post. Incredibly useful, and the last link shows that most of these skins are being actively maintained.

All of those skins are open source and their repos are browsable on Wikimedia's Gerrit. Here's good old MonoBook: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/ski...

For most old Wikimedia-maintained skins, the maintenance commits are largely automated build and translation changes, though they do still keep them kind of viable for modern features like notifications, or major architectural changes.

For example, MediaWiki 1.35 added Mustache templating: https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWik...

So here's the commit to MonoBook converting it to use Mustache: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/ski...

Hey there, developer here and I can confirm that we are still actively maintaining those skins and preserving them. We have around 101 skins that work with MediaWiki and 7 skins deployed in production.

You might be interested in the sections "WE MADE IMPROVEMENTS TO BACKWARD COMPATIBILITY" and "WE IMPROVED THIRD-PARTY SUPPORT" on https://jdlrobson.com/posts/2023-01-17_the-new-wikipedia-app... which have a few more links that might be of interest.

Hey! What happened with the AFBTL a11y feedback on focus-order issues, like closing or hiding the language menu throwing focus back to the top of the page, or the ToC menu problems? Those seemed like a11y dealbreakers, but they made it through to GA.

Hey there. As I mention in my blog post, there are still remaining issues that we are aware of and will fix. We got some consultancy on the remaining accessibility issues, and they were graded with priorities. We took care of all the ones that were flagged as blockers, and are working through the rest of the list over the next three months. You can track progress if you are interested in https://phabricator.wikimedia.org/T318373.

Some of these are made a little more complicated as they involve different teams - for example the language button is owned by a team who works on a Asia/Europe timezone (compared to our US/Europe timezone).

I think you are specifically referring to https://phabricator.wikimedia.org/T325009 (still awaiting discussion) and https://phabricator.wikimedia.org/T318013 (resolved next week) ?

It seems like Monobook is the only skin whose styling matches all the boxes and tables used in articles. (Minerva makes a valiant attempt to restyle infoboxes but doesn't touch other elements like https://en.wikipedia.org/wiki/2020_Masters_(snooker)#Main_dr... .) It's forward-thinking, placing the search box in the sidebar where it doesn't take up valuable vertical real estate on widescreen displays. It doesn't try to shove controls in between the title of the article and the content of the article. It's even got a responsive layout for mobile devices!

I say they should have bumped up the font size a notch, added a max width option, and saved themselves thirteen years of redesign work. Web design truly did hit its peak in the early 2000s.

Yeah, I hate it, it introduced lots of white space (I'd say about 20-25% of the screen) on the right-hand side. I don't see how this new version [1] is better than this old version [2]

[1] https://imgur.com/a/IZHxqOy

[2] https://imgur.com/a/q1PD3WY

The reason for this is readability. Long lines of text are empirically bad for readability, making it hard for readers to find the correct next line.

However, the line length Wikipedia picked seems to be a bad compromise. At around 120 characters per line it‘s double the recommend line length (60 characters).

If you look at newspapers, magazines and books you will see the 60 character rule of thumb adhered to pretty exactly and thoroughly. It‘s just a typographical best practice.

On the web and on wider maximized screens the issue is always the white space. Newspapers solve this issue with columns. However, that‘s not a realistic solution on the web (not so much for technical reasons, mostly because scrolling is fundamentally incompatible with columns).

> mostly because scrolling is fundamentally incompatible with columns

How so? You just scroll horizontally rather than vertically. Even actual scrolls come in both vertical and horizontal (column-based) formats.

That is actually a nice idea (and I’ve seen designers’ personal pages that do do that), but would probably look too artsy on today’s web. Gestures on mobile are also quite married to the vertical direction, so unless you’re willing to switch directions depending on screen size (way too jarring) that’s going to be somewhat broken as well.

Mouse wheels. That‘s the issue. They mostly scroll only vertically. Horizontal scrolling frequently is a massive pain for everyone involved.

> However, the line length Wikipedia picked seems to be a bad compromise. At around 120 characters per line it‘s double the recommend line length (60 characters).

Unfortunately, Wikipedia uses a lot of right-side floats, some of which are quite wide. They are also frequently referred as “on the right” in the main text, which can be quite jarring on mobile/minerva where they might be above or below.

I could imagine a breakpoint where those floats would turn into margin notes, but that sounds extraordinarily fiddly.

60 characters is way too short for comfort. Too much vertical movement makes it hard to keep track of the line I'm on. 120 is better but still too short in my opinion if the page is wide enough for longer lines.

To read one full line on [2] moving my eyes is not enough, I have to move my head. It's tiring, and when you're at the end of a line it makes it harder to come back to the beginning of the next line. Just reading a few lines on your screenshot, I ended up reading the 3rd line 2 times because my eyes went back to the wrong line, and because the lines are long I forgot the beginning of the line I just read.

So yeah I'd say [1] is strictly better for readability than [2].

> , I have to move my head.

I don't.

I find timeless most visually pleasing - it does bring some professional look to Wikipedia. And it also provides direct access to pages in other languages without additional clicks, which is important for me because it's the feature I'm using all the time.

I think "timeless" is ugly, unprofessional and not very usable. i'm happy about vector 2022, i think they did a really good job. but, of course, de gustibus non est disputandum.

Thanks, used this in conjunction with a url editing add-on [0]

    Description: Wikipedia Vector Skin
    Example URL: https://en.wikipedia.org/wiki/Joseph_campbell
    Include pattern: https://en.wikipedia.org/wiki/*
    Redirect to: https://en.wikipedia.org/wiki/$1?useskin=vector
    Pattern Description: Auto Redirects to vector skin version
    Advanced Options: 
        Exclude pattern: https://en.wikipedia.org/wiki/*?*

Feel free to toss a better way or an improvement for this if you end up doing the same. I'm sure the include and exclude patterns can be tuned, the add-on supports regex, otherwise you'll want a second rule for searches and such, but this should get a person started.

[0] https://addons.mozilla.org/en-US/firefox/addon/redirector/

I've made a Regex Version, which should support international wikipedia articles once the new skin arrives for them too.

   Description: Wikipedia Vector Skin
   Example URL: https://en.wikipedia.org/wiki/Joseph_campbell
   Include pattern: ^(https?://)([a-z0-9-]*\.)wikipedia.org\/wiki/(.*)
   Redirect to: $1$2wikipedia.org/wiki/$3?useskin=vector
   Pattern type: Regular Expression
   Pattern Description: Auto Redirects to vector skin version
   Advanced Options:
       Exclude pattern: ^(https?://)([a-z0-9-]*\.)wikipedia.org\/wiki/(.*)\?