Explore Wikipedia's New Look(wikimediafoundation.org) |
Explore Wikipedia's New Look(wikimediafoundation.org) |
It's a really nice improvement from the previous design.
No, the only thing I actually hate is that the main page has plenty of space on the side to show the sidebar, yet I still have to click it in order to get it to open up and see "Current Events".
I don't dislike it because it's different, I dislike it because it is measurably slower to do something I used to do in one click. THERE IS NOTHING THERE WHEN THE SIDEBAR IS COLLAPSED.
Dictionary app still seems to be working fine, though.
my guess here would be that they probably don't access the HTML at all, but instead go through MediaWiki's API.
How do people write things like this with a straight face
The new look seems to mess up some inline images.
In the following links, the histogram chart under section Historic Population has an unnecessary horizontal scrollbar for the chart image.
https://en.wikipedia.org/wiki/Bern (New vector-2022 look)
https://en.wikipedia.org/wiki/Bern?useskin=vector (Previous vector look)
Note: I am viewing this on my surface tablet in landscape mode.
I'll still need to keep the generic one around that I use on demand to fix other unreadable pages though.
(1) https://addons.mozilla.org/en-US/firefox/addon/mobile-wikipe...
Combined with tools like ChatGPT (or improved variants) for high quality translation of any article in any language, or combining submissions in several languages, or to get summaries or interactive explanations on some subject, this will become the most powerful tool of knowledge in history.
A lot of the time they're just making the citation up. Wikipedia's page on French toast says this:
> The earliest known reference to French toast is in the Apicius, a collection of Latin recipes dating to the 1st century CE, where it is described as simply aliter dulcia 'another sweet dish.'[8] The recipe says to "Break [slice] fine white bread, crust removed, into rather large pieces which soak in milk [and beaten eggs] fry in oil, cover with honey and serve".[9]
The problem is that the reference to eggs doesn't exist in the Apicius. It comes from an "augmented translation" that was written in 1936; the eggs are original content from that "translation". The sidebar's claim that French toast originates in the Roman empire is a lie, and so is the claim that French toast appears in the Apicius.
This has been noted on the associated talk page forever, but (apparently) so what?
More on the obscure end of things, I'm also annoyed by the page on Chen Shimei ( https://en.wikipedia.org/wiki/Chen_Shimei_and_Qin_Xianglian ). It claims that Chen Shimei, a stock dramatic character which the page itself dates to 1594, is represents an attempt at character assassination against an official of the Qing dynasty, which began in the mid-17th century.
The claim (that the fictional character is based on a historical person) used to be cited to a newspaper article which did not itself cite anything. That citation has since been removed, but the claim lives on in the page without even a fig leaf citation.
https://gist.github.com/kool-user/457cbf0100e075cc83977c1fe8...
That was my primary concern. Last thing I need is to have a JS-only Wikipedia added to the seemingly ever-groing list of websites that try to squeeze as much data from their visitors as possible and using "functionality and features" as an excuse.
2) Are they ingesting and modifying raw WP pages, and haven't updated for the new design? I ask because on desktop Safari there are tons of major layout errors (search field completely overlaps left menu; top logo image missing; page stretches one full, empty screenfull past the end of the footer; some text sits on top of section dividers rather than within the boundaries of a section) and wonder whether that's normal or just a temporary issue.
As of right now (UTC 4:50 am):
- Hanlon's Razor (new design) https://en.wikipedia.org/wiki/Hanlon%27s_razor
- Dunning-Kruger effect (old design) https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
(sorry)
Is there a way to change it back?
I'm not sure what value the collapsible table of contents is. Maybe it's useful on mobile, to help save screen space, but on desktop it would just be extra work for me to collapse the sections (which appear to be expanded by default). I have not found the length of the table of contents to be a problem, and I see the value of this structure as being that it allows me to see everything at once.
I get why having a maximum line length is good for readability. My reaction to this feature is negative, but I wonder if it's because I've gotten good at sizing Wikipedia articles the way I like them to be, by upping the font size and shrinking my browser window. Maybe I will come around on it, but my initial reaction was that I don't trust them to make the right decision for me, so I'd rather they just kept it flexible.
2003: Ouch. Yeah, that's bad.
2005: Great.
2011: Not worse. Maybe a little better. I have a vague recollection that some things that aren't well-showcased by a still got better with this one, but the still is at least not-offputting compared with '05.
2022: LOL are you serious? You cannot be serious. Please tell me this is unfinished.
All that padding. WTF. Someone accidentally hit "0" too many times in their CSS editor.
[EDIT] I mean I guess you need enormous swathes of empty space when you remove all other indicators of section division, but... like... just don't do that, then?
[EDIT 2] OK, I was like, "whatever, it sucks, but I'll get over it" until I read this: "When you are logged in to Wikipedia, the updated header will move with you as you scroll." Thank god when I try it on the site this doesn't actually work, since that'd force me to have custom CSS for Wikipedia. {ah, I see now it's because I'm not logged in. Great, easy to avoid then, no problem} Also: I'd love a before-after on page weight. Everyone always seems to add like a full MB of junk to the damn page when they add smart search like that, for some reason, even though it shouldn't require anywhere near that much (see: Github, whose pages bloated a ton when they made their search field "smarter"). One of the nicest things about WP is that it's semi-usable on a potato connection and I wouldn't want to see them sacrifice that in the name of almost any other improvement.
[EDIT 3] Being the change I want to see in the world: I checked with caches disabled and it looks like transfer and weight are damn near identical compared with the "wikiless" site that someone else linked, for the same article. Very nice, happy to see that. However, it appears to use double the memory of the Wikiless version (which I suppose represents something closer to the old design?) which seems pretty bad to me.
I also don't need a header following me, but that's not really what they're talking about. They've moved the "section header/outline"-table-of-contents-links from the top of the document (where they would scroll off the screen) over to the left side, so what follows you is not the old set of headers to other parts of wikipedia that you never clicked, but rather the in-document, titled, relative links up and down the current page.
it's actually pretty useful. (which does not mean I'm embracing what the designers have done; given the general track record of designers and all the spurious white space here, I must assume that this useful bit was only accidentally left in :)
javascript:(function()%7Bdocument.querySelectorAll(%22body%20*%22).forEach(function(node)%7Bif(%5B%22fixed%22%2C%22sticky%22%5D.includes(getComputedStyle(node).position))%7Bnode.parentNode.removeChild(node)%7D%7D)%3Bdocument.querySelectorAll(%22html%20*%22).forEach(function(node)%7Bvar%20s%3DgetComputedStyle(node)%3Bif(%22hidden%22%3D%3D%3Ds%5B%22overflow%22%5D)%7Bnode.style%5B%22overflow%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-x%22%5D)%7Bnode.style%5B%22overflow-x%22%5D%3D%22visible%22%7Dif(%22hidden%22%3D%3D%3Ds%5B%22overflow-y%22%5D)%7Bnode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D%7D)%3Bvar%20htmlNode%3Ddocument.querySelector(%22html%22)%3BhtmlNode.style%5B%22overflow%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-x%22%5D%3D%22visible%22%3BhtmlNode.style%5B%22overflow-y%22%5D%3D%22visible%22%7D)()%3B%0A
> I don't need a header to follow me down the page, in fact I'd prefer it not to.
Edit: I wasn't logged in before, and thus wasn't shown the header you are talking about. Now that I see it, I'm with you and don't like it. Everything there could have gone in the sidebar above the ToC instead of wasting vertical space. I also dislike the extra non-persistant sidebar box shown when logged in that pushes the ToC down off the screen. That should be one side or the other, not in place of the ToC.
I find the persistent ToC to be very helpful, and the space is uses would have gone to waste anyway in full-screen mode, so it doesn't cause any harm. I don't love the menu button in half-screen (and presumably mobile) mode. I feel like they would have been better off with a full-width bar at that point since it blocks reading those top few lines anyway.
> I'm not sure what value the collapsible table of contents is.
For some articles the full multi-level ToC is longer than will fit on a single page, so you either need to allow collapsing, or scrolling of the side bar which never works well.
> I get why having a maximum line length is good for readability. My reaction to this feature is negative ...
I was nervous when I read this as well, but I like the results. They didn't over do it like so many websites to today with tiny newspaper-like columns, and will be more readable for the majority of people who never resize the browser. For me, I keep all my browser windows half-screen anyway and the redesign has smaller gutters than before, which is a win.
>> I don't need a header to follow me down the page, in fact I'd prefer it not to.
> I find the persistent ToC to be very helpful
I don't know that I prefer it, but I also don't think I hate it. I feel indifferent.
I definitely love how they put the ToC off to the left. It's a great use of all the horizontal space on our 16:9 screens, and will make zipping around to different parts of a large article a lot easier. I'm willing to put up with the small banner in exchange for this.
To what extent Wikipedia's UI/UX assessment team are aware of this and can note a strong defection from any new features even where that defection represents only a small fraction of visitors I don't know.
Worse: sufficiently annoying / offputting features can simply lead to defection from a site entirely. A major problem with A/B testing is that if the cumulative effect of features has been to drive away those preferring the path not taken, then all your A/B tests are doing is validating survivorship bias.
(I'd give my experience with Reddit over the years, which has lead me to all but entirely avoid the site, or more recently a rather drastic turn in Twitter's dynamics affecting many long-term participants, as cases in point.)
Of the specific changes Wikipedia are putting into place, the maximum line length is a style change I've applied myself for about a decade now using various CSS browser extensions. I'm not much a fan of pinned headers, though that would be less an issue on desktop than my e-ink tablet. For that, I prefer the Desktop layout generally, but zoom the screen to cut off the left-hand sidebar entirely, which works fairly well until such time as I want to view an image fully zoomed.
I do find the sidebar useful on desktop. The present Mobile layout is annoying in multiple regards though it might be useful on a smaller device (I'm using a 13" e-ink tablet, which is generally not constrained for space.)
I feel like some of these changes are meant to make better use of the landscape aspect ratios typical in laptop and desktop setups (i.e. moving the ToC to the left)
Several other changes ... seem fairly agnostic.
guess what else will be persistent when donation drive banner gets turned on
We need to stage some kind of intervention with web designers. There can't be a single person on the planet who actually likes this anti-feature. Why on Earth do they keep doing it?
From the discussion on sticky header [0],
> Our preliminary results show that an overwhelming majority of test participants reported positive experience with a sticky header. Participants mentioned they enjoyed the ability to access important functionality from any part of the page.
> Overall, there was an average 15% decrease in scrolls per session by logged-in users on the 15 pilot wikis in the treatment group (with the new sticky header), compared to the control group (without the sticky header). This indicates that our hypothesis was correct - adding the sticky header to the page reduced the need to scroll to the top of the page significantly.
> there was a 2.8% and a 6.8% increase in the percent of people who were able to successfully complete at least one edit using the edit button within the sticky header,
[0] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
I guess I dislike it on mobile when it takes up too much space.
Mostly this. I visit a website to view its content, not its header. I don't need to waste 10% of the screen on something I will almost never use. On Desktop, I can press "Home" to get to the header in the rare instances I want to. On Mobile, screen space is even more valuable, so it's even more annoying to have to waste screen space on the stupid header (and no, web designers, the style that pops up and covers up the content you are trying to read when you scroll up one pixel is not a solution).
I'm here to read. Stop interfering with that.
Of course the big ones are simply obnoxious wastes of space, and any that have a drop shadow on the content bother me for what seem like obvious reasons, but even the small ones bug me and I think that might be why.
[EDIT] That's just for the static ones—the ones that pop in and out based on scroll behavior are one of the worst design trends in the entire history of the Web, which is saying something, and are in an angry-making category all their own.
-
On Wikipedia, and any MediaWiki installation, you can add the useskin query parameter to the URL to change skins on a page, even when not logged in.
Current (vector-2022): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
Previous (vector): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ve...
Older (monobook): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
Older alternative (modern): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mo...
Older alternative (cologneblue): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=co...
Mobile (minerva): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=mi...
Responsive alternative (timeless): https://en.wikipedia.org/wiki/59th_Academy_Awards?useskin=ti...
Installed skin list: https://en.wikipedia.org/wiki/Special:Version
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).
So yeah I'd say [1] is strictly better for readability than [2].
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.
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...
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/*?*
[0] https://addons.mozilla.org/en-US/firefox/addon/redirector/
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/(.*)\? main#content {
max-width: 40em;
}
I really hope any website could be as flexible as Wikipedia to allow users to write their own CSS.
The page gets much less padded when you reduce the size of the window, because the padding isn't there to make blank space, it's there to enforce a maximum line width.
This seems like an excuse to force JS to enable ads & what should be the default that is toggled with the fullscreen button in the bottom right. It does not justify wasted width as the user can more easily set the text to the appropriate zoom than applying some custom CSS:
.mw-page-container {
max-width: none !important;
}
.mw-content-container {
max-width: none !important;
}
And not everyone wants all content crammed into a little area.
All in all, it should be up to the user decide how much content density they want on websites.
Mostly the repurposing of the left side for the table of contents, but also the width reduction. I only use half of my screen for my browser already, and on many pages, lines are just insanely long.
Personally, I nevery really minded having open space on websites. I never felt it made reading worse. Contrary, pages with little whitespace felt cramped and I lost my position now and then. But I understand that other people will feel differently about that.
I'd stil like the language selector below the table of contents in the sidebar.
> I'd stil like the language selector below the table of contents in the sidebar.
would also cover most of the reason I wish they'd do that.
[EDIT] Incidentally, what ever happened to 3-column layouts? They could keep the site menu on the left and stick the TOC on the right (keeping it visible all the time is definitely an improvement, and the thing I like most about this redesign). We used those layouts a ton when 800x600 4:3 was still a common monitor resolution & ratio, so surely it'd be fine on 16:9 and 16:10 monitors with 3x or more the pixels.
Interestingly, the work toward implementing this new version of Vector allows any skin to decouple the TOC from the page content in MW 1.38+. It wasn't possible to move the page-generated ToC out of the content body before without resorting to JS/CSS hacks or implementing a parallel ToC generator in the skin or as an extension.
https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWik...
- Sidebar for navigation
Bad:
- Wasted screen space
- Other languages are not available as a simple anchor tag anymore. They are hidden behind <button> elements. It's annoying for readers who consult their own language and en.wikipedia.org in the same session. It breaks my bookmarklet to change languages, which depended on something like `document.querySelectorAll('a')`
Don't fall for that mental trap. White space is not wasted space.
Even in the new design they're still a bit larger than what I'd like.
Don't worry, it will soon be filled with solicitations for donations.
Edit: You can also have it take up the entire width by hitting the button in the bottom right. Doesn't seem to remember the change for me though so hopefully they add that in soon.
Kudos to WM for keeping the option for that theme in MediaWiki. Now I have a reason to browse logged in all the time.
Ooh good spot. That fixes my one issue, the bizarrely narrow column width.
I don't mind the current UI change, but I wish significant changes would come with a toggle button to let me look at the old and new renderings. I don't think it's possible to mentally "place" the improvements without side-by-side comparisons and affordances for finding edge cases where the new UI may be lacking.
Why are so many people against white space when it hasn't been overdone? Obviously "overdone" means different things to different people but in this case the information that matters is still pretty dense.
> These improvements will make Wikipedia more welcoming and easier to use.
Above quote from the notification, which, again, has no visual borders. Just an insanely contrast-less sky blue on a white background.
Whoever has thought of this being a good idea should just go and resign in shame. Not every questionable design "trend" has to be followed.
[1] https://twitter.com/tuomassalo/status/978717292023500805
Screenshot: https://cloudflare-ipfs.com/ipfs/QmaovnEHiCo6knhTPpp4XJyr5x9...
This actually increased the line length.
One thing I noticed with Wikipedia with JS /enabled/, all the sub-categories of a topic are by default, closed.
But when I browse with JS disabled, all the sub-categories are /opened/ and I have the full article.
Since most people browse with JS enabled, this means they have to make additional clicks just to read the sub-categories.
Which leads me to question: which version is better? The JS where you have to make additional clicks, or the no-js version where you get the full article?
So Much White Space
Its also off-center which
is annoying on an 15"laptopEverything decays, especially software.
Is this actually true? I'm curious if anybody has sources for this and if it's a common UX practice. I tend to use wider windows than traditional 8:9 half-screens and this max-width practice drives me nuts.
Surprised they did not include a citation for this research...
Computer text line lengths affect reading and learning
Peter Orton
https://cdn.tc-library.org/Edlab/eye-tracking%20article.pdf
[1] https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improveme...
[2] https://www.scienceopen.com/document_file/671b2d53-73ce-4a91...
[3] https://sci-hub.se/https://link.springer.com/chapter/10.1007...
Since it is on some language version for some time I already did. But it took some time.
I hate that sides want to control how "wide", I mean narrow the text can be. Sorry, I prefer longer lines and not a bunch of empty space on the sides.
old.wikipedia.org when?
Judging by the rave reviews this gets though, it seems that people who use the site as opposed to just wanting pretty design are in the minority. If most users don't even switch languages or such, I wonder how many readers check the citations and discussions before blindly believing what random anonymous authors tell them.
https://en.wikipedia.org/wiki/Does_not_compute https://en.wikipedia.org/wiki/Combinatorics https://en.wikipedia.org/wiki/Stable_Diffusion
And I guess my one complaint is, it now takes 2 clicks to iterate through random articles.
Second take: oh wait, the menu in the left was completely useless and they replaced it with the table of contents for that particular entry. That’s actually a welcome change. I’ll get used to “different so it sucks” soon enough anyway, that’s my fault not theirs.
It’s kind of fascinating when you catch yourself having knee-jerk reactions and “watch” your brain correct them.
I guess I'll be modifying it to plaster ?useskin=vector at the end of every link as well...
https://en.wikipedia.org/wiki/GeForce_30_series?useskin=vect...
You could arrange the different wiki sections to be side by side.. in a dynamic responsive way depending on device/screen size
And with an arbitrary article length, multicol would require pagination, right?
Also, zooming and changing browser window size is, while only a keystroke away, isn’t something I want to do just to make a site that should be optimized for reading text more legible. It should just default to that way.
In short, I’m sorry this doesn’t fit your flow. That’s frustrating. But I think this is a better design. Matthew Butterick’s Practical Typography seems to support this view. [1] (MB is a lawyer, typographer, and Racket programmer for those not familiar with his work.)
[1]: https://practicaltypography.com/page-margins.html#on-the-web
Even on desktops where it's reasonably easy, it's pretty annoying to have to resize the window when you go to different sites to get them to format properly.
The only issue is, you need to log in to do this. I don't want to have to log in to a website that I read, and never edit, to get rid of the giant distracting table of contents.
https://greasyfork.org/en/scripts/458494-old-wikipedia-layou...
Basic customizations should never be blocked behind an accountgate.
1: https://en.wikipedia.org/wiki/Wikipedia:IP_edits_are_not_ano...
2: https://en.wikipedia.org/wiki/Help:I_have_been_blocked
3: https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption
Once upon a time, there was an initiative for websites to add a unique CSS ID to the <body> tag so users could customize them with user stylesheets.
For example: <body id="news-ycombinator-com"> for this website, and then users can apply CSS rules as they see fit via the user stylesheet.
Sadly, the initiative never took off and most browsers nowadays don't even know what a user stylesheet is.
I can't be the only one who feels this way. I have yet to buy a book where 90% of each page is blank and there's just a tiny column of words down the middle of the page.
I mean seriously, a 27" diagonal monitor is 24"x17". Do you routinely read on 12"x17" paper with near zero margin?
At the very least, I feel like responsive options to toggle some of the various max-width CSS settings as an opt-in feature is worthwhile at least for reading-heavy sites like getpocket.com and news websites. I end up toggling these in Firefox / Chrome debugger and wish I could install extensions to apply custom code automatically but my employer does not allow this.
Long lines of text force you to move your eyes and/or head side to side every time you go from one line to the next.
As far as I can tell, the people who say this are citing each other. And can't wait to reply when you say you find it unpleasant that it's actually scientifically ideal.
I don't.
We live in an age where attention is a valuable currency and most people would likely leave your site if they can't quickly find the thing they're looking for. The fewer things you have on your screen at a time, the easier it is for them to find what they're looking for. It doesn't apply everywhere but I think it applies to a good amount of cases which is why lots of white space has become the norm.
There's a reason we have a character limit per line when writing code - it's much easier to read and understand short chunks of vertical text. Personally, I find it far more comfortable reading text which doesn't go above 600-900px in width and this has been a well known UX/UI guideline for the last 10 years. Having your eyes go from the far left to the far right of your screen is also very straining on any >21" screen.
But the real question is, why is it good to strain the eyes darting them across distances that large. What is gained by filling in the white space just to fill it?
I see some examples on MDN:
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
I imagine there are a few ways to do it. I'd just have columns break at section headers. It'd also jive well with the wiki pic/quick-info right hand sidebar that's common
I think the 80 characters-per-line for code was a holdover from when IBM punch cards had 80 CPL, but I could be wrong there. I know American typewriters had about 80 CPL, so from a typography perspective maybe that's why 80 is the accessibility sweet-spot? If it's the ballpark equivalent to what we'd see on an 8.5x11 sheet of paper?
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.
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) ?
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.
How so? You just scroll horizontally rather than vertically. Even actual scrolls come in both vertical and horizontal (column-based) formats.
No, it's an accurate description of most users' reading preferences, myself included.
Do you realize the level of entitlement and absurdity here?
.mw-page-container,.mw-content-container{max-width:none!important;}https://cloudflare-ipfs.com/ipfs/QmVMS6LFUEqJJdnXDVuVZWRDSHT...
The biggest challenge has been keeping it legible while dense. Ultimately I’d like to give it aesthetics similar to a roman serif, but for now still experimenting with the basic construction.
That hasn't been my experience at all, in fact for me macOS works better when windows are mostly sized to fit their content. Windows and Windows-like Linux DEs is where I feel pressure to maximize everything.
I'm curious if you're seeing this on desktops? My sample of mac users is very heavily biased towards laptops (and I've only used macos on a laptop) - but I've seen the exact opposite.
How? Seriously, if you have a way to do this that works for pages in general I'll be extremely grateful. I tried using a user stylesheet that said * { max-width: 100% !important } for a while, but that breaks too many non-root elements on all sorts of sites.
Whereas making the page narrow when it doesn't set a max-width seems very easy to do with a custom stylesheet.
You can have one style apply to multiple domains, I have a simple one for making text black and setting the font size and line spacing which works on a dozen sites or so. You can even use SCSS or Stylus instead of plain CSS if you want.
https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
Yes, I'm talking about that kind of thing. It's trivial for people who want narrow sites to put a max-width on the root element that way. As someone who wants wide sites, how do I do undo all these designers' narrow widths without having to figure out manually what each individual site has done?
My point: if you care that deeply about how Wikipedia in particular is laid out, you likely have the tools to force it to work that way. Meanwhile, the rest of us plebs get a better (from a typographical standpoint, not necessarily a case-by-case basis) default.
The issue isn't with width but a lack of user preferences, logged in and not. You don't need user accounts, cookies, persistence, or frankly even Javascript to change the content width on an article. The skin designer can set the best practice for a contrived ideal use case as the default, and still let anyone with other use cases expand the content's max-width to fill more space.
EDIT: Looks like they added one — there's now a "Toggle limited content width" button now appearing for me in the bottom-right corner of the wider desktop views.
(And I'll note that in my own usage, when I'm on my 11" Macbook Air I full screen most apps. But that's a weird edge case due to the screen size.)
div.article-text {
max-width: unset !important;
width: 100% !important;
}