edit: formatting
edit: formatting
You may find humour in the comically small "desktop" link at the very end of the page, next to the privacy policy.
// ==UserScript==
// @name Redirect from mobile wiki to desktop
// @namespace http://tampermonkey.net/
// @version 0.1
// @description try to take over the world!
// @author You
// @match https://*.m.wikipedia.org/*
// @grant none
// @run-at document-start
// ==/UserScript==
window.location.hostname=window.location.hostname.split(".")[0]+".wikipedia.org";A tablet could be easily confused, or a phone in landscape mode, too, but for a phone in portrait mode this seems a bit hard to imagine, because DPI is taken into account when converting the display width into CSS pixels, so even a phone cramming 1080 or 1440 or whatever amount of physical screen pixels into its display width should still come in at something like 300 to 400ish CSS pixels. Or am I misunderstanding something?
Also, many times mobile breakpoints don't look at the device orientation and pick numbers like 800px, to capture landscape orientation on medium sized phones or something (I'm not sure where this number comes from to be honest). This obviously breaks the two windows side by side case on laptops but is a top result for me if you google the arcane syntax for how to target mobile browsers with a media query.
I am not 100% sure what all the pitfalls are with the current interface, but they exist often enough for me to run into them semi-frequently on smaller laptops.
The worst part of this is that simple mostly text sites without a fixed-with layout would look perfectly on mobile if this tag was the default but somehow mobile browser vendors thought it was better to hack around sites with table layouts by giving them a larger viewport (but still inconsitently scale the font sizes so you have to zoom in and out to read different parts).
Once you start with the hack of giving non-mobile-compatible pages a larger viewport in order to not break layouts that react allergic when being squeezed into 300-something pixels, what else do you want to do?
Not scaling font sizes at all just gives you either tiny text (if you zoom out to fit the large viewport onto the small mobile screen) or loads of scrolling around if you display the page at 100 % zoom level instead.
And scaling up all text means you end up approximatively just where you started before you started resizing the viewport. It might not be absolutely exactly the same layout breakage as when squeezing an old page directly into the 300 or so pixels available on a mobile phone in portrait mode, but it will be pretty similar.
So that only leaves trying to scale up only the main body of text (which normally isn't that sensitive with regards to scaling up the font size and therefore increasing its size requirements) and leaving alone smaller bits of text like menus, the page navigation etc., which are more likely to be size-constrained and start causing layout breakage if increased by an extraordinary amount.
The bigger problem is people hiding functionality if you're in the mobile breakpoint. That's an issue: all functionality should be enabled, at least in some way IMO. Mobile should never be a second class citizen :)
@media (hover: none) and (pointer: coarse) {
That allows the dev to select for devices that do not have a mouse and such rely on touch targets, to increase the sizing. I've been implementing this myself recently in our web application, while still allowing us to change the layout to fit the narrow width!I'm sure there are some devices it doesn't fit perfectly for though. This stuff is capital-H hard.
You mean quote-unquote Hard?
The implementations for these have some... complications, the device sets we now deal with are huge, and making sure there are no idiosyncratic bugs that creep up when using them is legitimately a fair bit of work.
It's not, is the thing.
I have a 23 inch screen for my 1080p screen. My phone has a 6ish inch diagonal.
When I make a window 960 x 1080, that's still something like 10 inches across and 11 inches tall. It's sheet-of-paper sized. I'm perfectly comfortable reading that as it was designed for a desktop layout.
Do you sit as close to your monitor as you hold your phone?
Phones are far taller than half of a 1080p screen.
Half a monitor is: 960 x 1080, or 1:1.125 A iPhone is: 828 x 1792, or 1:2.164
So websites tend to shove a candybar shape into a nearly square sheet of paper and waste a lot of usable proportions for things like controls or hamburger menus.
But, at least as far as I approach media queries, if you've triggered the mobile breakpoint (well, default CSS as mobile-first is the way we approach it), its because the desktop design we've used literally will break on a browser window that narrow.
I really, REALLY prefer desktop mode for almost everything, relying on pinch to zoom.
It shouldn't, because with proper reactive design therre are no "mobile" and "desktop" versions but only one version that adapts to the viewport size. If you want a larger viewport that should be solved at the browser level by providing the website with a larger viewport. Seems firefox behaves this way while chrome does something weird that increases the viewport a bit but then still "intelligently" scales some text.
I agree that you should prefer flow and size-to-fit but that does not mean that break points are never the right tool.
I agree, although in the case of Wikipedia the "mobile" design is actually the one that is responsive. I want the "mobile" design on all browsers including my desktop. I believe you can actually set your default theme if you're logged into Wikipedia, but I don't know if their cookies eventually expire or what, but I often end up clicking on Wikipedia links and getting the awful "desktop" design.
All of this is just to say that, yes, they shouldn't use separate "m." URLs, but it's just as wrong to get upset at mobile users sharing "m." URLs as it is to get upset at desktop users sharing URLs without the "m." Arguably if you expect all users to always share the most versatile URL, you should expect them to always share the "m." URL since it has a responsive design.
Also the mobile site might be more responsive in the sense that it better scales down to narrower viewports but it does not scale up to make use of larger viewports by e.g. bringing back the sidebar and other links that are hidden behind dropdowns. That's a problem with many mobile-first designs - in reallity they are mobile-only designs.
I’m career military and the fact that Wikipedia (and Facebook) have low bandwidth m.* redirects made life immensely easier on the limited internet in far off places. We really appreciated it being available.
https://en.wikipedia.org/wiki/Yugoslav_gunboat_Beli_Orao - 913.39 KB / 298.41 KB transferred
https://en.m.wikipedia.org/wiki/Yugoslav_gunboat_Beli_Orao - 919.43 KB / 270.18 KB transferred
Not much of a difference. Would be better to spend time optimizing the desktop site for everyone.
On a phone, the mobile Wikipedia is perfect tho.
However, that link is totally in the wrong place, no wonder I could not find it. I just assumed there was no such link/button and always angrily removed the 'm.' from each URL.
https://addons.mozilla.org/en-US/firefox/addon/skip-mobile-w...
They used to just put "?s=19" through "?s=22" or so, which enumerated clients (desktop, mobile, Android, etc), which was better than the junk most other services stuff in (like utm_source and friends...)