The Mobile Web should just work for everyone
blogs.msdn.com
blogs.msdn.com
The simple fact is that it works better for Windows Phone users. If developers hadn't been using webkit-prefixed CSS everywhere it wouldn't be an issue, but it is.
That said, I wish Windows Phone IE had better developer tools. Both Android and iOS let you plug your phone in via USB and access the web console. It's great.
Mozilla/1.22 (compatible; MSIE 2.0; Windows 3.1)
On the mac, they are support VMWare, VirtualBox and Parallells.
I'd like to join you on this mobile rant for a bit. Mobile browsing completely sucks right now. Whether it's websites that don't know how (or don't bother) to design with mobile in mind, or websites that do try to design with mobile in mind, and go completely over the top to the point that it ruins UX (Why do we still see websites where you can swipe left/right to switch articles. Does anyone every actually need to swipe through blog posts that rapidly?) It feels like there are very few websites that don't outright ruin mobile browsing.
And even when you find one of the nice ones, your browser mucks it all up by thinking it is smarter than the web designers. "Font Boosting" makes Reddit and several forums I frequent completely unreadable for me. Even on the mobile versions of the sites! It seems to get worse as you go down the page, and after 30-40 comments, the font sizes might as well have been chosen completely at random.
The other day, my phone warned me of low internal storage, and I saw the Chrome app was taking up 225mb of space on my android, and this is not including the additional 100mb+ from cache and data. That's 10% of my internal storage! Could you imagine if Chrome for desktop took up 100GB? /endrant
Basically I think that if a site is made for mobile, pinching should change the text size.
At least this is the case on Android. Perhaps iOS is different.
(My personal pet peeve is onswipe, the most horrible mobile experience ever imagined, always worse than the desktop site on the same device, and yet ubiquitous.)
Looks like the webkit prefix tags are creating the new IE6. As usual, it's the web developers fault for not updating their CSS prefixes.
http://css.dzone.com/articles/why-webkit-new-ie6-trap-vendor
Mozilla, Opera and Microsoft have been complaining about this and Opera had already implemented support for the webkit prefixes(before switching to webkit/Blink entirely) and Firefox-OS will probably follow.
On the one side I want to make a ramble about why it takes so long for those standards to finish and unprefixed CSS3 and beyond is possible, but on the other hand - without actual real-life use, how can you find all the edge-cases and practical application to create a complete standard?
Many of them are _still_ prefixed because WebKit has a policy of never removing prefixed features, even if they implement the unprefixed one. So people feel no compunction about using the prefixed stuff in production, and since they only test in WebKit they don't notice when they're using the -webkit-prefixed version even though every single browser (or every browser except WebKit, in some cases) supports the unprefixed standard version.
It's ridiculously easy to make sure you include all appropriate browser-specific and generic prefixes for almost all experimental CSS features. If you use something like Compass, it's even done for you, totally transparently.
Lazy developers ruin it for everybody, again. What a surprise.
I think we should also watch out for link-bait SEO headlines such as "Why Webkit is the New IE6 (The Trap of Vendor Prefixes)"...
No. It tried to solve two different needs: proprietary stable APIs and unstable/in-flux specs. And the abuse of the latter forced browsers to drop the use-case entirely and hide features behind flags because developers could not be trusted to act responsibly, so it definitely didn't solve that problem.
> Why should we be developing to the lowest common denominator?
That's not developing to the LCD, that developers deploying half-specified and unstable APIs in production.
Because the fault lies with them and no one else, no matter how in denial you are.
> The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature)
That doesn't even make sense, standards work is not "you shipped some random unspecified and mostly broken pile of shit and some other bloke was convinced to half-implement something which kinda looks similar if you squint so let's just call it standandard :shipit:"
Co-Chairmain of the web standards group:
http://www.glazman.org/weblog/dotclear/index.php?post/2012/0...
Mozilla on the issue. http://alistapart.com/article/the-vendor-prefix-predicament-...
True, browsers need to support some pre-standardization variants for now, but this will fade. It doesn't seem like a huge burden for browsers to support older websites for a while, and it doesn't affect new websites.
These are features which changed semantics and syntax multiple times over the course of their standardisation, it's not like standards guys were slow because they found it fun
> If the tags had been standalized then we would be using them.
Webkit browsers have all supported unprefixed box-sizing since the release of Safari Mobile 5.1 in March 2012. 2 years later… https://github.com/search?l=CSS&o=desc&q=-webkit-box-sizing&...
That query means developers by and large don't care and just cargo-cult through.
> The prefixed one is there for backwards compatibility.
Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version.
Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on.
Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"
And while IE and Firefox have supported unprefixed CSS transforms for a while now, Chrome and Safari only support the -webkit-prefixed version of CSS transforms so far. So if you want to do transforms, you have to use -webkit prefixes...
Oh for fuck's sake, the query is specifically looking for -webkit-box-sizing, not for webkit-prefixed properties in general.
This bothers me. Webkit isn't some ancient browser that is has remained stagnant for years until google/apple decided to do something about it. Nobody spends hours debugging their perfect layouts in webkit. Webkit isn't holding the entire web back. It's just a poor comparison.
I browse mobile web in mostly firefox mobile, and I don't think I've ever seen a mobile site broken on FF but working on Chrome.
In fact at least Google has taken some steps to recitfy it, and they've stated they're putting experimental CSS properties behind developer flags. If we're talking about the fact that old people don't update old browsers then Microsoft is one to talk with IE7, IE8, IE9, and IE10.
That last part underscores that we're fortunate browser makers are issuing regular updates (a big difference from IE). On the other hand, with some of those updates come new bugs and (particularly on Android) fragmentation. Consider that by 2006 there were enough people/resources documenting IE6's quirks that it was pretty rare to run across a bug that someone didn't have a good idea of how to fix/workaround. In 2014 when you run across a mobile bug (particularly one from a recent release, of which there are many), it may well be that nobody knows how to solve your problem, and in some cases nobody seems to even know how to tell you to duplicate it across devices/emulators (http://stackoverflow.com/questions/23142762/how-to-identify-... ).
And of course, like IE, many developers code webkit-only, even iOS only (and I know why: at the level of ambition people often have for mobile websites and with the difficulty involved in testing more than a few devices, it can sometimes seem like the only way to get things out the door).
IE6 was no picnic, but there are times I think to myself I'd rather be working on the 2006 desktop web than the 2014 mobile web....
Nowadays at least I code responsive layouts to target screen resolution, and its gotten leagues better. Sure there's a few quirks in separate browsers and things aren't necessarily ideal, but it sure beats the days of "I wish I could use xxxx CSS property but I can't because only 2% of my users would be able to render it".
For a long time, IE6 ruled the roost, so developers used IE6 as their development target. Browsers that moved beyond it, or implemented things differently (often correctly) were ignored.
On mobile, webkit rules the roost. Developers use it as their development target. Browsers that move beyond it or implement things differently (by using non-webkit prefixed CSS) are ignored.
That's why I don't really see the comparison. When I think of IE6 I think of the hours I wasted trying to make it work right. I'm not currently coding IE mobile websites, then checking it on a webkit browser, having everything be broken and then spending hours trying to fix it.
What happens is that designers (and product managers) stress over minute details instead of seeing the bigger picture. So developers spend an obscene amount of time fixing iOS and Galaxy specific bugs that don't degrade the overall experience but instead aren't pixel-perfect.
And as a result most other devices simply aren't tested. And instead of allowing those devices to see the site (warts and all) they resort to a whitelist of devices that can see the (QA verified) mobile site while everyone else gets either a basic mobile html site or the desktop.
Ever notice everyone identifies as Mozilla first?
On the plus side, User agent strings are moving closer to being useless as conditional branches for features. Hopefully, vendor-prefixes won't be far behind.
I guess developers just don't grok abstractions when it comes to the Web. They know their preferred browser, but somehow fall short of abstracting their development to "work on the Web" rather than "Works best in Chrome on an iPhone 5S."
If I knew that the user's browser was 3 inches wide I could choose a point-based font size that's appropriate. It would also be trivially easy to scale font and image sizes up or down based on that knowledge. Especially if I'm using SVG.
72pt is precisely 1 inch tall (width is variable). However, if I set a font to 72pt we'll see that almost all browsers get it wrong. They are hard-coded to assume that the user's display is 96dpi or even worse (in the case of Apple devices) it simply pretends that the device is some fixed pixel width when it isn't (i.e. retina displays).
Did you know that the CSS spec has 'in' and 'mm' as size options? Yet when you set the font-size to '1in' you will almost never get a font that is one inch tall because the browser is hard-coded to assume that the user's display is 96dpi. It drives me crazy and it will only get worse over time as we get a larger variety of devices.
We need to stop the madness (that was introduced by Apple with the pretend-the-screen-has-this-many-pixels nonsense) and switch to accurate screen size/dpi reporting. Anything else is doomed to crap like what's mentioned in this article.
That's completely useless, 1cm on a mobile device and 1cm on a desktop are not the same for a user, to say nothing of 1cm on a TV screen, an Oculus Rift (where would you even measure size there?) or a projector (which would require a rangefinder for precise estimation and will probably vary slightly over the whole surface, won't that be fun?)
> Not pixels. Pixels lie and so do browsers, actually.
And you'd expect them to lie less for "physical dimensions"… why?
> Did you know that the CSS spec has 'in' and 'mm' as size options? Yet when you set the font-size to '1in' you will almost never get a font that is one inch tall because the browser is hard-coded to assume that the user's display is 96dpi. It drives me crazy and it will only get worse over time as we get a larger variety of devices.
Before suggested that others read the CSS spec, you may want to do so yourself:
http://www.w3.org/TR/css3-values/#absolute-lengths
> For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
> The reference pixel is 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. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
> We need to stop the madness (that was introduced by Apple with the pretend-the-screen-has-this-many-pixels nonsense)
That's not going to happen. Every time some schmuck advocates "practicality > purity" somebody down the road will have to support their "practical choice" and you end up with virtual pixels because all content is completely broken if you use actual physical pixels.
> switch to accurate screen size/dpi reporting.
http://www.quirksmode.org/blog/archives/2012/06/devicepixelr...
http://www.quirksmode.org/blog/archives/2012/07/more_about_d...
You lost me. How is 1cm on a mobile device not the same as 1 cm on a desktop. Yes, they have different pixels resolutions within that centimeter, but the length of a centimeter doesn't change.
Well, unless the engineers are fudging the standard so marketing isn't seen to be lying.
That's because you stopped there and didn't read the rest of the phrase.
> Yes, they have different pixels resolutions within that centimeter
That's not relevant in any way, shape or form, the issue would exist even if all devices had the exact same pixel density.
> the length of a centimeter doesn't change.
The length of a cm doesn't change, but what you can do with it changes a lot due to different viewing distances: a cm at 20cm, a cm at 80cm and a cm at 3m are very different visual beasts, and so are a cm manipulated using fat fingers, a mouse, a stylus or some sort of laser/ir pointer.
The really user-relevant size is subtended angle, not linear size, which is why the "px" unit in CSS was defined the way it was.
For instance, because it's used with fat and impressive fingers a smartphone held close to your face (and thus with a high angular size for its physical size) needs to provide much bigger controls (in both angular and absolute terms) than a desktop computer manipulated through a mouse.
And of course this isn't linear as manipulating e.g. a Wii through its remote is also very impressive.
What does the browser in an Oculus Rift report? What about the projector on my wall?
Perhaps we're more interested in angular sizes, and then possibly pixel densities (again in terms of angular size) in case we need to worry about font legibility etc.
Which is how the reference pixel is defined:
> The reference pixel is 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. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
You would also need distance from the user's eyeballs. This is especially important for screens that can be significantly closer or farther from the user depending on the use case. See Google Cardboard. See also larger monitors that could be used as lean-back television displays in dorm rooms.
I'm blown away people see this and react with "if we had more of a singular monoculture, this wouldn't be an issue", when the exact opposite is true. Making it difficult/near impossible for newcomers/outliers to operate in the browser space is very unlikely to improve things in the long run.
I'm sure Opera had many reason to cave in and throw away their rendering engine in favor of a webkit fork, but I suspect having to continuously swim upstream against the ever growing proprietary extensions and broken browser detection logics out there might have played a role.
-webkit prefixes are supposed to stash away experimental features until they get standardized, but with the webkit monoculture, they become de facto standard as their implementation trickle through the webkit forks and releases. That's harmful.
Perhaps having faster standard tracks where prefixed features don't have time to become second nature for webdevs, and fostering a culture of "proprietary prefixes don't belong in production code" could help here.
This is a symptom of the ecosystem's indifference to the windows phone platform.
Browser vendors implementing hacks to trick web apps into presenting the right content because web developers have learned that they can't rely on the browser to render content properly.
I think there's a lesson in here about treating your ecosystem right.
It's actually possible to run WP8 under Fusion on a Mac, but MS need to add mouse cursor support: http://stackoverflow.com/questions/19402478/is-it-possible-t...
I actually don't think that's entirely fair to the Windows Phone team. Developers are being lazy and only testing on webkit devices.
IMO, it's the IE team who sewed this mess.
I wonder if Microsoft had said something remotely similar if WP had Windows like market share and sites were coded to IE!
At least WebKit/Blink are OpenSource and Microsoft can dream of being compatible easily.
https://bugzilla.mozilla.org/show_bug.cgi?id=921014
Even though sites should be using the standards version the Apple one is still very popular. If you decide not to support it, users just think your OS / Browser looks like crap. It's a tough spot to be, especially considering that its financially in Apple's best interest to break the web.
EDIT: Linked to wrong bug
function isMobile() {
return navigator.userAgent.toLowerCase().indexOf("mobile")>=0;
}
In JVM land I've had pretty good success with UADetector [1] for delivering device specific content to mobile phones and desktop/laptop/tablets.
/mobile/i.test(navigator.userAgent)Just because the API call and syntax is a bit iffy doesn't mean it's a bad pattern. ES6 will finally have a string .contains method btw (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
Ah, irony.
There's some features that simply cannot be tested with feature detection (the HTML5 Appcache and the tel:// URI scheme to name two of them but I'm sure there's more) and tweaking the user-agent might also break some web pages.
I run a website in production where I test for the Chrome & Firefox user-agent to enable the appcache. I'm not saying that IE does not have any support on it (it's actually supported), it's just that I don't have the time to test fully the IE implementation to make sure that the user will have a web page that will be updated properly. So IE will still work but without any appcache (which is not a real issue). If they change their user-agent and their implementation of the feature is not 100% perfect, the website might not work properly.
Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0
Safari on iOS 7: Mozilla/5.0 (iPad; CPU OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53
WP 8.1: http://i.imgur.com/wxXof2J.png
FF OS: http://i.imgur.com/o8AZAYf.png
iOS Safari: http://i.imgur.com/uki6KQZ.png
Android Chrome: http://i.imgur.com/AJ6KNRa.png
Also, see this article:
http://www.smashingmagazine.com/2014/07/22/responsive-web-de...
They are indeed! ;-)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0
Firefox has had its problems too recently, but at least it's open source and they're trying. Microsoft has literally nothing going for them on this front.
The world doesn't need Trident. The case for IE being mandatory in the OS died years ago, and the new direction Microsoft talks about taking embraces open source.
A Microsoft backed browser that ran WebKit (or even Gecko) would give their team a much stronger platform to stand on when discussing standards. It would also close the door on one of Microsoft's biggest black eyes; the stagnation of the web in the early 2000's because of IE.
http://blog.chromium.org/2013/04/blink-rendering-engine-for-...
Mozila/5.0 (Windows Phone 8.1; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 625) like Gecko
After the update:
Mozila/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 625) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537
---
Sounds pretty desperate. But this is Microsoft with Windows Phone, so, no surprises here...
Read more here: http://blogs.msdn.com/b/ieinternals/archive/2013/09/21/inter...
But the default is:
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
According to the article, they added "like Gecko" onto the ends of them.
even though I think it's the more appropriate/non-misleading one.
For anyone seeing this comment after the title has been changed, OP's title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly"
editorializing or not, i prefer the less vague title. serves as a great tldr;
why give users a title choice and then have mods (who essentially hand-review all submissions) just revert it like robots?
I wonder if we can just block IE11 on mobile. Not that many people use it anyway.