[EDIT:] In other words, Wikipedia seems to be the last vestige of the dumb old "separate web for mobile" mindset of ideas like WML. Media queries are just better, and would prevent this inane "that link sucks for half of us; here's one that sucks for the other half" crap.
As someone else said, "responsive" sometimes means loading both versions of a site and being readable for both desktop and mobile. If Wiki Desktop has a lot of features or content that shouldn't get loaded on mobile, it's a bit trickier to do that. Although I agree, at least some kind of media detect/redirect may be in order.
If Wiki Desktop has a lot of features or content that shouldn't get loaded on mobile...
Except it doesn't.
The whole idea behind the iPhone's browser was to avoid the need for crappy "mobile" versions of web sites. It's a crying shame that this vision had to fail because a bunch of underemployed web developers were obsessed with fixing things that were no longer broken.
I don't undertand why the mobile version doesn't have a link to the talk page. For some articles it's a very useful additional reading to the main page.
I'm sorry, what? Last vestige? That's not even close to being correct. Off the top of my head, here are some websites that still have a separate mobile domain: YouTube, Facebook, Reddit, Twitter, and a whole host of smaller websites as well. Granted, many of these do some kind of automatic redirect, so that you're redirected to the appropriate domain for the device you're using regardless of the link you follow. But none of them do the kind of responsive-design-and-media-query approach that you're talking about to differentiate between desktop and mobile.
The reason for a separate mobile site is that we can transfer less data over the wire. mobile sites typically aren't as feature filled as the desktop sites.
Bandwidth isn't the issue as much as latency. Those collapsible sections where the content isn't loaded just mean I have to wait 10 times for 20s while trying to read an article, rather than once for 25s upfront.
wikipedia has a big "never change anything" culture that resists any design changes to the main site, but doesn't seem to care about the mobile site.
more likely we'll see m.wikipedia.org become more desktop-friendly and responsive before we see it happen to "desktop wikipedia". (and really, the m.wikipedia site is quite nice to use on the 11" screen i'm reading on now)
> wikipedia has a big "never change anything" culture that resists any design changes to the main site, but doesn't seem to care about the mobile site.
Except for the deletionists. They like to change things!
I think that's basically the same crowd. And from one perspective, those articles never existed to start with so deleting them is just reverting a change.
Unless they get rid of the vast amounts of position: absolute; in the Vector skin it is unlikely. Which will most likely require switching out entirely to a new skin. Unfortunately many extensions that are not parser extensions rely on the Vector skin to function.
Flaw in media query. They work on resolution and on pixel density as reported by the device but you have no way to know if it's a small size high density screen or a large screen with average density.
There are 13" laptops with a resolution which overlaps with the higher end mobile phones and that is where mq falls apart because you can't tell where you are. The real issue is with all browser reporting the same fixed dpi, for reason which make sense in context but don't allow to discern all cases.
We work with a mix of media query + user agent sniffing to enable mobile queries only on mobile stuff.
It was all fine and dandy as long as pc had >1280 pixels, tablets where between 768 and 1024 and phones below that range. Now that everything overlaps with everything, not so much, and because all browser reports metric around the 96dpi magic number, there's no solution. At least making a media query in em instead of pixel saves you from the trouble with people zooming on pages.
And if your website is responsive and allows iframing, it's even worse.
> The real issue is with all browser reporting the same fixed dpi, for reason which make sense in context but don't allow to discern all cases.
I'm certainly unaware of browsers doing this, except for a few old ones on desktop and Windows Phone 8's IE, and I can't find anything claiming other browsers do this. Certainly it's never been an issue I've hit.
all browser have fixed dpi, at 96dpi precisely. it's part of the css3 standard and it's tied to the physical unit - so if you get 1cm as css width, it's the same amount of 'logical' or 'css' pixels irregardless of actual device density. (and of course if you ask 1inch to css you get 96px https://www.w3.org/TR/css3-values/#absolute-lengths )
you can use device-pixel-ratio and the likes to have an hint on the pixel density, which doesn't protect you from the extremes (small, very high density devices and large low density screens)
like the galaxy tab 7.7" has a 1280 width, which would trigger desktop line of queries if you break at 1024 like many do.
It's actually in 2.1 as well, the fact that 96 CSS pixels equal 1 CSS inch. But that's not what's relevant here, as we're talking about media queries where we have resolution units, and resolution units give the device pixels per some CSS unit.
> you can use device-pixel-ratio and the likes to have an hint on the pixel density, which doesn't protect you from the extremes (small, very high density devices and large low density screens)
> like the galaxy tab 7.7" has a 1280 width, which would trigger desktop line of queries if you break at 1024 like many do.
Oh, right, so the issue here is the fact we have relatively high density screen (197 PPI) but where 1 CSS pixel still equals 1 device pixel? That seems pretty bad generally, given I presume the same is true for the rest of the OS (AFAIK in general Android browsers just follow the OS here)? It seems like to fix this we'd need to add resolution units giving number of CSS pixels per physical length unit, right?
exactly, instead they went on the road of giving physical pixel per css pixel, which means we need to create all combination of kinda valid queries to support future devices (problem isn't THAT bad now, but it's getting worse)
> exactly, instead they went on the road of giving physical pixel per css pixel, which means we need to create all combination of kinda valid queries to support future devices (problem isn't THAT bad now, but it's getting worse)
Do you have examples of other device and browser combinations of this being a problem? Let's make this situation better!
(FWIW, these browsers are likely not conforming CSS implementations, because you either must have 1 CSS inch equal 1 physical inch (and 1 CSS pixel is still 1/96 of a CSS inch, with whatever ratio to device pixel that ends up being), or by relating the CSS pixel to "the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length", but hey, they exist so we may as well add media queries to deal with the resultant fallout.)
[Edit: In the Galaxy Tab 7.7 case, the reference pixel, assuming 15.75" viewing distance (which is totally non-scientifically the viewing distance my partner uses her tablet at) works out to be 1/170th of an inch: almost exactly a device pixel. I guess a lot of the problem with tablets is the viewing distance varies so much...]
Responsive design is the design ideal of not having two separate sites -- one for mobile and the other for desktop -- but rather just being able to visit one site and have its CSS dynamically adjust so that it looks good in all screen sizes.
If you can do it without adding a bloated JavaScript framework and adding tons of requests to a page load, sure. If you can't do that I'd prefer auto detection by the load balancer and redirects to the mobile site
Jesus, you don't need frameworks or sniffing, it's an almost all-text site with very minimal styling. It's almost more difficult to make it non-responsive. There isn't anything really on the desktop version that isn't on the mobile, so I'm not sure where those extra requests would be coming from.
Sorry for the the tetchy reply, I just find it nuts that, to get around writing maybe a page of CSS, people build and maintain an entirely separate site that has to be in lockstep to the the first, along with ever-reliable sniffing, and then say that is the simpler way to do it. There are several scenarios where it turns.out to be useful; this isn't one of them
You can do a fair amount these days with CSS thanks to flex-box, it handles the row based layout transition to column based quite well.
A benefit of using CSS is that it handles browser zoom and high dpi screens much better as you can use units other than pixels (eg: em/rem, vh/vw, %).
From a architecture point of view, you want to keep layout logic out of the JavaScript anyways as JS should be for interactions and other 'nice to have' behaviors.
The responsive bit doesn't really work though. The mobile version does, but there doesn't seem to be any good reason for that being extra functionality, rather than it just being how the site should reflow at smaller sizes
Haha that's an ironic URL. Clearly I was wrong about Wikipedia's use of media queries, but that makes the persistence of the ".m." subdomain even stranger. It's time to start 301'ing this.
[EDIT:] In other words, Wikipedia seems to be the last vestige of the dumb old "separate web for mobile" mindset of ideas like WML. Media queries are just better, and would prevent this inane "that link sucks for half of us; here's one that sucks for the other half" crap.