52 ms·

The Mobile Web should just work for everyone

124 points by wfjackson 12y ago

deleted 12y ago
[deleted]
higherpurpose 12y ago
And the title will be changed by mods in 3...2..1... even though I think it's the more appropriate/non-misleading one.
- ihuman 12y ago
  The title is almost always changed if the post's title is different from the submission's title. There usually isn't a good reason to editorialize the title when submitting to HN, unless the title is something like a "Show HN." 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"
  - leeoniya 12y ago
    > 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;
    - ihuman 12y ago
      The HN guidelines clearly state to use the original title, though.
      - leeoniya 12y ago
        if the policy is so strict, why not just automate the title extraction? why give users a title choice and then have mods (who essentially hand-review all submissions) just revert it like robots?
    - untog 12y ago
      But it's opinionated. That's the issue - it attempts to colour your opinion on the topic before you've even read the article.
  - deleted 12y ago
    [deleted]
iron_ball 12y ago
"In general, our advice is to develop a responsive site that can adapt to the capabilities of different devices. If you choose to build a mobile-specific experience then we recommend looking for the sub-string "mobile" in the user agent string to determine when to deliver mobile optimised content:" function isMobile() { return navigator.userAgent.toLowerCase().indexOf("mobile")>=0; } This is really the best we can do after twenty years of the WWW?
- recursive 12y ago
  Browser identification is an arms race. It harkens back to the original user agent wars near the turn of the millenium. I think it's unlikely to ever have a solid way to identify browsers. If one is developed, it will be used by (bad?) developers as an exclusion check for their fancy content. That gives other browsers an incentive to lie. I think the whole concept is inherently unstable for this reason.
- misterbwong 12y ago
  No. Feature detection (which is also mentioned in the article) is far superior
- woogley 12y ago
  ug, that's already a bad check, but if they insist, why not just: /mobile/i.test(navigator.userAgent)
  - masklinn 12y ago
    I'd add \b around to avoid matching e.g. `Immobile/1.0`, the slow browser.
  - Cthulhu_ 12y ago
    > Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. 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/Reference/Global_Objects/String/contains https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
nailer 12y ago
Anyone know what the IE11 update User Agent actually is, merely out of curiosity?
- misterbwong 12y ago
  This wasn't immediately clear to me as well. From what I can see, they just mirrored their change in IE11 desktop and added "like Gecko" to the end of it.
  - paulojreis 12y ago
    That was the "before". They've added references to Android, iOS and WebKit.
- TheIronYuppie 12y ago
  Sadly, it's complicated. Read more here: http://blogs.msdn.com/b/ieinternals/archive/2013/09/21/internet-explorer-11-user-agent-string-ua-string-sniffing-compatibility-with-gecko-webkit.aspx 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
- ihuman 12y ago
  All the different IE11 user agents can be found on this msdn page: http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.8... According to the article, they added "like Gecko" onto the ends of them.
- paulojreis 12y ago
  Before the update: 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...
ChrisClark 12y ago
Isn't this basically the state of the User Agent strings across all browsers? The strings are a messy combination of different browsers, versions and rendering engines.
- masklinn 12y ago
  Yes. The more things change, the more they stay the same: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
- atopal 12y ago
  No, not all browsers. Here is the one for the current Firefox release: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0
droopybuns 12y ago
Poor Windows Phone team. 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.
- ulfw 12y ago
  At least they are accepting it and acting accordingly to where they stand in terms of market share. If you have low single digits of share, this is what you need to do to keep up.
- nailer 12y ago
  I'd actually test on Windows Phone if they published images for Mac like they do with Desktop IE (and no, VMs inside VMs don't count). 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-to-run-the-windows-phone-8-simulator-directly-in-os-x/19403057#19403057 http://stackoverflow.com/questions/19402478/is-it-possible-t...
  - chiph 12y ago
    IIRC you can't run a HyperV image inside a Parallels VM because it doesn't have access to the Intel extensions it needs. You could do it via Bootcamp, though.
- randomfool 12y ago
  If I remember correctly, Apple had that same exact problem in pre-iPhone and pre-Chrome days. AFAIK this was why they released Safari on Windows- to allow devs to test on Safari without requiring a mac.
- untog 12y ago
  they can't rely on the browser to render content properly. I actually don't think that's entirely fair to the Windows Phone team. Developers are being lazy and only testing on webkit devices.
ntakasaki 12y ago
Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" 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 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.
- afs35mm 12y ago
  I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. Why should we be developing to the lowest common denominator? 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)"...
  - ntakasaki 12y ago
    The problem isn't that developers should be developing for the lowest common denominator. It is that the prefixes are not being dropped by websites even after other browsers start implementing the feature, or it's that they continue to use the webkit prefix for new websites.
  - masklinn 12y ago
    > I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. 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.
    - tomjen3 12y ago
      Why do you blame developers? 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) and for MS for developing a browser at a glacial pace.
aestra 12y ago
So the history of every user agent string ever repeats itself. And they get longer and longer. And we've created a horrible horrible mess. Ever notice everyone identifies as Mozilla first? http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
- Isofarro 12y ago
  Yep, it's a browser vendor's reaction to a developer-tilted monoculture. On repeat. 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."
therogerwilco 12y ago
Hey look at that, Microsoft is doing what it takes to deal with all the crappy mobile developers who don't know how to create web pages.
neeks 12y ago
The sheer irony of it all.
blinkingled 12y ago
> The Mobile Web should just work for everyone 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.
- masklinn 12y ago
  Microsoft invented user agent lying when MSIE 2.0 started advertising itself as Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), so we known exactly where that road goes.
  - blinkingled 12y ago
    Ah, yes - the embrace part ;)
teamonkey 12y ago
For comparison, can someone post the user agent strings from Safari iOS7 & Android Chrome?
- bduerst 12y ago
  Yeah, I really don't understand the Firefox OS comparison. They stress that IE is now compatible with popular websites, but they don't do a comparison with the popular browsers... WP 8.1: http://i.imgur.com/wxXof2J.png http://i.imgur.com/wxXof2J.png FF OS: http://i.imgur.com/o8AZAYf.png http://i.imgur.com/o8AZAYf.png iOS Safari: http://i.imgur.com/uki6KQZ.png http://i.imgur.com/uki6KQZ.png Android Chrome: http://i.imgur.com/AJ6KNRa.png http://i.imgur.com/AJ6KNRa.png
- abhinavk 12y ago
  Chrome on KitKat: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KVT49L) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.99 Mobile Safari/537.36 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
tomjen3 12y ago
Great that is going to bring all sorts of weird bugs (because IE doesn't implement these standards exactly like the other browsers). I wonder if we can just block IE11 on mobile. Not that many people use it anyway.
sanxiyn 12y ago
"We are collaborating with Mozilla to record broken sites." Ah, irony.
symlinkk 12y ago
How exactly is the mobile web biased towards iOS? I've rarely (if ever) had to use a vendor prefix when developing for mobile. I am using Bootstrap, so maybe they're doing those for me.
- hadri 12y ago
  https://github.com/twbs/bootstrap/blob/master/less/mixins/vendor-prefixes.less https://github.com/twbs/bootstrap/blob/master/less/mixins/ve... They are indeed! ;-)
- cwyers 12y ago
  Because some websites use user agents to determine whether or not to serve a website optimized towards modern mobile devices, and some of those user agent sniffers are only looking for Mobile Safari. If you aren't Mobile Safari or claiming to be, you either get the desktop site or the ancient mobile site designed for feature phones.
Touche 12y ago
This is a product of over-design. Stay with me. 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.
rayiner 12y ago
The mobile web is just a disaster all around. I remember when I got my iPhone in '08, the browsing experience was amazing. Most sites were still relatively simple, and whatever highly non-standard tricks Safari played to do things like text reflow worked great on that small 3.5" screen. Half a decade later, I'm profusely disappointed with Chrome's browsing experience on my Nexus 5's massive 5" screen. Even on HN, I can't read the titles on the main page without scrolling sideways at any zoom factor where I can still make out the text. Reddit is better than most, but it still renders the "233 Comments" link text in miniscule text that's impossible to hit without zooming in. Advanced web technologies and CSS layout has turned the mobile web into a sea of too-small text, too-wide columns, pop-overs that are too easy to fat-finger, etc. /rant
- elinchrome 12y ago
  For reddit you should use the .compact url. E.g. reddit.com/.compact.
  - mbrameld 12y ago
    You can also use i.reddit.com to get the same effect.
- squeaky-clean 12y ago
  I'd recommend ihackernews.com for browsing HN on mobile (not my website). I use it daily, and it's much better than the completely non-responsive HN site. 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
Kiro 12y ago
Why do you need to detect if mobile? Why aren't media queries enough?
- e15ctr0n 12y ago
  Some websites have tailored a completely optimized experience for mobile. For example, if homedepot.com detects your device as "mobile", it will redirect to http://m.homedepot.com/ http://m.homedepot.com/ otherwise it will show content from http://www.homedepot.com/ http://www.homedepot.com/. Try it on your mobile device versus desktop and see what happens. Also, see this article: http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/ http://www.smashingmagazine.com/2014/07/22/responsive-web-de...
- cenhyperion 12y ago
  Because a ton of people ~5 years ago decided to do entirely separate mobile sites instead of responsive designs and we have now ended up with the mess everyone said we'd end up with.
edpichler 12y ago
I really didn't like this part: "...even where this meant we would be adding non-standard web platform features."
e15ctr0n 12y ago
Firefox OS has a Web Compatibility program [0] where they work with the webmasters of the Alexa Top 1000 Sites to achieve 90% compatibility for the mobile content sent to Firefox for Android and Firefox OS. They use the website http://arewecompatibleyet.com/ http://arewecompatibleyet.com/ to check how far they've come along. The Firefox OS user agent is very simple: Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0 [0] https://wiki.mozilla.org/Compatibility/Mobile https://wiki.mozilla.org/Compatibility/Mobile
untog 12y ago
I think the Windows Phone team deserve some credit for doing this, knowing that the developer reaction to it will be deeply negative (read: most comments in this thread). 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.
- fidotron 12y ago
  This is also symptomatic of the way Windows clients have fallen out of favour with many devs generally. Android people have enough trouble persuading them (and designers) that the world isn't just Apple, but having a toolchain that requires Windows desktop? Instant not-going-to-happen.
  - untog 12y ago
    Yes. It feels philosophically unfair to complain about, but I want a Windows Phone emulator for OS X. Of course, Windows users don't get an emulator for iOS either, but Apple has popularity on their side.
    - tiernano 12y ago
      Couldn't you technically run Windows 7/8 under VMWare and then run the Windows Phone tools under that? VMWare has nested virtualisation (at least on Workstation 10 on Windows, think its there on Fusion or the Paralles options). And given MS give free VMs for testing IE on Macs too, your a step closer...
      - untog 12y ago
        Last time I tried, no. This is going from memory so I may be incorrect, but the WP emulator required some level of hardware virtualisation that VirtualBox (at least) could not offer in that nested way.
      - 12y ago
fred_durst 12y ago
Firefox OS is dealing with similar compromises with homescreen site icons and the apple touch icons. https://bugzilla.mozilla.org/show_bug.cgi?id=921014 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
- elmerland 12y ago
  And that is exactly why web-standards are so important. It's always in a broswer's best interest to break the web.
gprasanth 12y ago
Does this mean they will open source their rendering engine?
riskable 12y ago
This is just another reason why all browsers (not just mobile) should be reporting their screen size. As in, the actual height/width. Not pixels. Pixels lie and so do browsers, actually. 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.
- repsilat 12y ago
  > As in, the actual height/width. Not pixels. 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.
  - masklinn 12y ago
    > Perhaps we're more interested in angular sizes 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).
- humanrebar 12y ago
  > As in, the actual height/width. 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.
ChikkaChiChi 12y ago
Why doesn't Microsoft just adopt or fork WebKit? 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.
- untog 12y ago
  The world might not need Trident, but it does need multiple browser engines.
  - ChikkaChiChi 12y ago
    Sure. Maybe Gecko and WebKit are enough. At least then the foundations are all open and freely accessible to the world.
- fred_durst 12y ago
  Because forks anyway. http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html http://blog.chromium.org/2013/04/blink-rendering-engine-for-...
  - ChikkaChiChi 12y ago
    Hence why I said fork. Google still contributes heavily back to Chromium.
rbanffy 12y ago
Interesting. They don't show Android screenshots for comparison. Not the built-in browser, not Chrome.
realusername 12y ago
Although I agree for the -webkit prefix implementation (this can cause no harm to the render of the web page), I disagree strongly with tweaking the user-agent. 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.
neil_s 12y ago
On a tangent: are they ad-blocking, on the NY Times screenshot?
drivingmenuts 12y ago
Funny they should say that now, seeing as how they used to think the web should work for everyone, as long they were using IE.
usingpond 12y ago
It's silly that all the anti-IE comments are being downvoted. IE8, 9, 10 and 11 are still complete shit and the debug tools are even worse. Microsoft talks a good game about implementing all these standards but I experience bugs regularly in Trident, even when I was developing something specifically for it a few months back. It's a completely primitive and glitchy browser that doesn't need to exist. 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.
markb139 12y ago
I thought en.m.wikipedia.org/wiki/UAProf Was designed for this exact thing
itsnotlupus 12y ago
Good. UserAgent-based feature detection needs to be broken every few years as it is a gross abuse (Aggravation; like Rant) 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.

124 points by wfjackson 12y ago

deleted 12y ago

[deleted]

higherpurpose 12y ago

And the title will be changed by mods in 3...2..1... even though I think it's the more appropriate/non-misleading one.

ihuman 12y ago
The title is almost always changed if the post's title is different from the submission's title. There usually isn't a good reason to editorialize the title when submitting to HN, unless the title is something like a "Show HN." 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"
- leeoniya 12y ago
  > 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;
  - ihuman 12y ago
    The HN guidelines clearly state to use the original title, though.
    - leeoniya 12y ago
      if the policy is so strict, why not just automate the title extraction? why give users a title choice and then have mods (who essentially hand-review all submissions) just revert it like robots?
  - untog 12y ago
    But it's opinionated. That's the issue - it attempts to colour your opinion on the topic before you've even read the article.
- deleted 12y ago
  [deleted]

iron_ball 12y ago

"In general, our advice is to develop a responsive site that can adapt to the capabilities of different devices. If you choose to build a mobile-specific experience then we recommend looking for the sub-string "mobile" in the user agent string to determine when to deliver mobile optimised content:" function isMobile() { return navigator.userAgent.toLowerCase().indexOf("mobile")>=0; } This is really the best we can do after twenty years of the WWW?

recursive 12y ago
Browser identification is an arms race. It harkens back to the original user agent wars near the turn of the millenium. I think it's unlikely to ever have a solid way to identify browsers. If one is developed, it will be used by (bad?) developers as an exclusion check for their fancy content. That gives other browsers an incentive to lie. I think the whole concept is inherently unstable for this reason.
misterbwong 12y ago
No. Feature detection (which is also mentioned in the article) is far superior
woogley 12y ago
ug, that's already a bad check, but if they insist, why not just: /mobile/i.test(navigator.userAgent)
- masklinn 12y ago
  I'd add \b around to avoid matching e.g. `Immobile/1.0`, the slow browser.
- Cthulhu_ 12y ago
  > Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. 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/Reference/Global_Objects/String/contains https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)

nailer 12y ago

Anyone know what the IE11 update User Agent actually is, merely out of curiosity?

misterbwong 12y ago
This wasn't immediately clear to me as well. From what I can see, they just mirrored their change in IE11 desktop and added "like Gecko" to the end of it.
- paulojreis 12y ago
  That was the "before". They've added references to Android, iOS and WebKit.
TheIronYuppie 12y ago
Sadly, it's complicated. Read more here: http://blogs.msdn.com/b/ieinternals/archive/2013/09/21/internet-explorer-11-user-agent-string-ua-string-sniffing-compatibility-with-gecko-webkit.aspx 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
ihuman 12y ago
All the different IE11 user agents can be found on this msdn page: http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/ie/hh869301%28v=vs.8... According to the article, they added "like Gecko" onto the ends of them.
paulojreis 12y ago
Before the update: 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...

ChrisClark 12y ago

Isn't this basically the state of the User Agent strings across all browsers? The strings are a messy combination of different browsers, versions and rendering engines.

masklinn 12y ago
Yes. The more things change, the more they stay the same: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
atopal 12y ago
No, not all browsers. Here is the one for the current Firefox release: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0

droopybuns 12y ago

Poor Windows Phone team. 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.

ulfw 12y ago
At least they are accepting it and acting accordingly to where they stand in terms of market share. If you have low single digits of share, this is what you need to do to keep up.
nailer 12y ago
I'd actually test on Windows Phone if they published images for Mac like they do with Desktop IE (and no, VMs inside VMs don't count). 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-to-run-the-windows-phone-8-simulator-directly-in-os-x/19403057#19403057 http://stackoverflow.com/questions/19402478/is-it-possible-t...
- chiph 12y ago
  IIRC you can't run a HyperV image inside a Parallels VM because it doesn't have access to the Intel extensions it needs. You could do it via Bootcamp, though.
randomfool 12y ago
If I remember correctly, Apple had that same exact problem in pre-iPhone and pre-Chrome days. AFAIK this was why they released Safari on Windows- to allow devs to test on Safari without requiring a mac.
untog 12y ago
they can't rely on the browser to render content properly. I actually don't think that's entirely fair to the Windows Phone team. Developers are being lazy and only testing on webkit devices.

ntakasaki 12y ago

Edit: The previous title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly" 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 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.

afs35mm 12y ago
I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. Why should we be developing to the lowest common denominator? 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)"...
- ntakasaki 12y ago
  The problem isn't that developers should be developing for the lowest common denominator. It is that the prefixes are not being dropped by websites even after other browsers start implementing the feature, or it's that they continue to use the webkit prefix for new websites.
- masklinn 12y ago
  > I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need. 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.
  - tomjen3 12y ago
    Why do you blame developers? 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) and for MS for developing a browser at a glacial pace.

aestra 12y ago

So the history of every user agent string ever repeats itself. And they get longer and longer. And we've created a horrible horrible mess. Ever notice everyone identifies as Mozilla first? http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/

Isofarro 12y ago
Yep, it's a browser vendor's reaction to a developer-tilted monoculture. On repeat. 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."

therogerwilco 12y ago

Hey look at that, Microsoft is doing what it takes to deal with all the crappy mobile developers who don't know how to create web pages.

neeks 12y ago

The sheer irony of it all.

blinkingled 12y ago

> The Mobile Web should just work for everyone 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.

masklinn 12y ago
Microsoft invented user agent lying when MSIE 2.0 started advertising itself as Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), so we known exactly where that road goes.
- blinkingled 12y ago
  Ah, yes - the embrace part ;)

teamonkey 12y ago

For comparison, can someone post the user agent strings from Safari iOS7 & Android Chrome?

bduerst 12y ago
Yeah, I really don't understand the Firefox OS comparison. They stress that IE is now compatible with popular websites, but they don't do a comparison with the popular browsers... WP 8.1: http://i.imgur.com/wxXof2J.png http://i.imgur.com/wxXof2J.png FF OS: http://i.imgur.com/o8AZAYf.png http://i.imgur.com/o8AZAYf.png iOS Safari: http://i.imgur.com/uki6KQZ.png http://i.imgur.com/uki6KQZ.png Android Chrome: http://i.imgur.com/AJ6KNRa.png http://i.imgur.com/AJ6KNRa.png
abhinavk 12y ago
Chrome on KitKat: Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KVT49L) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.99 Mobile Safari/537.36 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

tomjen3 12y ago

Great that is going to bring all sorts of weird bugs (because IE doesn't implement these standards exactly like the other browsers). I wonder if we can just block IE11 on mobile. Not that many people use it anyway.

sanxiyn 12y ago

"We are collaborating with Mozilla to record broken sites." Ah, irony.

symlinkk 12y ago

How exactly is the mobile web biased towards iOS? I've rarely (if ever) had to use a vendor prefix when developing for mobile. I am using Bootstrap, so maybe they're doing those for me.

hadri 12y ago
https://github.com/twbs/bootstrap/blob/master/less/mixins/vendor-prefixes.less https://github.com/twbs/bootstrap/blob/master/less/mixins/ve... They are indeed! ;-)
cwyers 12y ago
Because some websites use user agents to determine whether or not to serve a website optimized towards modern mobile devices, and some of those user agent sniffers are only looking for Mobile Safari. If you aren't Mobile Safari or claiming to be, you either get the desktop site or the ancient mobile site designed for feature phones.

Touche 12y ago

This is a product of over-design. Stay with me. 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.

rayiner 12y ago

The mobile web is just a disaster all around. I remember when I got my iPhone in '08, the browsing experience was amazing. Most sites were still relatively simple, and whatever highly non-standard tricks Safari played to do things like text reflow worked great on that small 3.5" screen. Half a decade later, I'm profusely disappointed with Chrome's browsing experience on my Nexus 5's massive 5" screen. Even on HN, I can't read the titles on the main page without scrolling sideways at any zoom factor where I can still make out the text. Reddit is better than most, but it still renders the "233 Comments" link text in miniscule text that's impossible to hit without zooming in. Advanced web technologies and CSS layout has turned the mobile web into a sea of too-small text, too-wide columns, pop-overs that are too easy to fat-finger, etc. /rant

elinchrome 12y ago
For reddit you should use the .compact url. E.g. reddit.com/.compact.
- mbrameld 12y ago
  You can also use i.reddit.com to get the same effect.
squeaky-clean 12y ago
I'd recommend ihackernews.com for browsing HN on mobile (not my website). I use it daily, and it's much better than the completely non-responsive HN site. 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

Kiro 12y ago

Why do you need to detect if mobile? Why aren't media queries enough?

e15ctr0n 12y ago
Some websites have tailored a completely optimized experience for mobile. For example, if homedepot.com detects your device as "mobile", it will redirect to http://m.homedepot.com/ http://m.homedepot.com/ otherwise it will show content from http://www.homedepot.com/ http://www.homedepot.com/. Try it on your mobile device versus desktop and see what happens. Also, see this article: http://www.smashingmagazine.com/2014/07/22/responsive-web-design-should-not-be-your-only-mobile-strategy/ http://www.smashingmagazine.com/2014/07/22/responsive-web-de...
cenhyperion 12y ago
Because a ton of people ~5 years ago decided to do entirely separate mobile sites instead of responsive designs and we have now ended up with the mess everyone said we'd end up with.

edpichler 12y ago

I really didn't like this part: "...even where this meant we would be adding non-standard web platform features."

e15ctr0n 12y ago

Firefox OS has a Web Compatibility program [0] where they work with the webmasters of the Alexa Top 1000 Sites to achieve 90% compatibility for the mobile content sent to Firefox for Android and Firefox OS. They use the website http://arewecompatibleyet.com/ http://arewecompatibleyet.com/ to check how far they've come along. The Firefox OS user agent is very simple: Mozilla/5.0 (Mobile; rv:31.0) Gecko/31.0 Firefox/31.0 [0] https://wiki.mozilla.org/Compatibility/Mobile https://wiki.mozilla.org/Compatibility/Mobile

untog 12y ago

I think the Windows Phone team deserve some credit for doing this, knowing that the developer reaction to it will be deeply negative (read: most comments in this thread). 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.

fidotron 12y ago
This is also symptomatic of the way Windows clients have fallen out of favour with many devs generally. Android people have enough trouble persuading them (and designers) that the world isn't just Apple, but having a toolchain that requires Windows desktop? Instant not-going-to-happen.
- untog 12y ago
  Yes. It feels philosophically unfair to complain about, but I want a Windows Phone emulator for OS X. Of course, Windows users don't get an emulator for iOS either, but Apple has popularity on their side.
  - tiernano 12y ago
    Couldn't you technically run Windows 7/8 under VMWare and then run the Windows Phone tools under that? VMWare has nested virtualisation (at least on Workstation 10 on Windows, think its there on Fusion or the Paralles options). And given MS give free VMs for testing IE on Macs too, your a step closer...
    - untog 12y ago
      Last time I tried, no. This is going from memory so I may be incorrect, but the WP emulator required some level of hardware virtualisation that VirtualBox (at least) could not offer in that nested way.
    - 12y ago

fred_durst 12y ago

Firefox OS is dealing with similar compromises with homescreen site icons and the apple touch icons. https://bugzilla.mozilla.org/show_bug.cgi?id=921014 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

elmerland 12y ago
And that is exactly why web-standards are so important. It's always in a broswer's best interest to break the web.

gprasanth 12y ago

Does this mean they will open source their rendering engine?

riskable 12y ago

This is just another reason why all browsers (not just mobile) should be reporting their screen size. As in, the actual height/width. Not pixels. Pixels lie and so do browsers, actually. 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.

repsilat 12y ago
> As in, the actual height/width. Not pixels. 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.
- masklinn 12y ago
  > Perhaps we're more interested in angular sizes 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).
humanrebar 12y ago
> As in, the actual height/width. 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.

ChikkaChiChi 12y ago

Why doesn't Microsoft just adopt or fork WebKit? 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.

untog 12y ago
The world might not need Trident, but it does need multiple browser engines.
- ChikkaChiChi 12y ago
  Sure. Maybe Gecko and WebKit are enough. At least then the foundations are all open and freely accessible to the world.
fred_durst 12y ago
Because forks anyway. http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html http://blog.chromium.org/2013/04/blink-rendering-engine-for-...
- ChikkaChiChi 12y ago
  Hence why I said fork. Google still contributes heavily back to Chromium.

rbanffy 12y ago

Interesting. They don't show Android screenshots for comparison. Not the built-in browser, not Chrome.

realusername 12y ago

Although I agree for the -webkit prefix implementation (this can cause no harm to the render of the web page), I disagree strongly with tweaking the user-agent. 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.

neil_s 12y ago

On a tangent: are they ad-blocking, on the NY Times screenshot?

drivingmenuts 12y ago

Funny they should say that now, seeing as how they used to think the web should work for everyone, as long they were using IE.

usingpond 12y ago

It's silly that all the anti-IE comments are being downvoted. IE8, 9, 10 and 11 are still complete shit and the debug tools are even worse. Microsoft talks a good game about implementing all these standards but I experience bugs regularly in Trident, even when I was developing something specifically for it a few months back. It's a completely primitive and glitchy browser that doesn't need to exist. 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.

markb139 12y ago

I thought en.m.wikipedia.org/wiki/UAProf Was designed for this exact thing

itsnotlupus 12y ago

Good. UserAgent-based feature detection needs to be broken every few years as it is a gross abuse (Aggravation; like Rant) 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.