

The Mobile Web should just work for everyone - wfjackson
http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx?

======
untog
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.

~~~
alyx
You can do it on your desktop,

[http://oi58.tinypic.com/2rrnyxc.jpg](http://oi58.tinypic.com/2rrnyxc.jpg)

~~~
untog
Which is certainly better than nothing, but not much fun when it comes to
debugging touch gestures and the like.

------
rayiner
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

~~~
squeaky-clean
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

~~~
jhallenworld
Mobile websites like ihackernews annoy me in a different way: there is no way
to zoom without going into settings.

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.

------
ntakasaki
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.

~~~
mikelat
> Looks like the webkit prefix tags are creating the new IE6.

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.

~~~
wwweston
Most of my professional time these days is spent on mobile/tablet websites for
a major automobile manufacturer. And there are days when we absolutely do
obsess over layout and other issues introduced by mobile safari itself. On the
release of iOS 7, we actually probably burned a month working with a bug that
we never found a solution to (which, fortunately, was fixed with iOS 7.1).

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-...](http://stackoverflow.com/questions/23142762/how-to-identify-
factors-that-will-help-reproduce-web-rendering-bugs-for-android) ).

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....

~~~
mikelat
I think you forget how bad it was with 2006 desktop. So many CSS hacks. We
take our div layouts for granted but if you dared venture away from the
standard table layouts of the early 2000s you were in for a lot of debugging
for browser quirks.

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".

------
Touche
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.

------
aestra
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
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."

------
riskable
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.

~~~
masklinn
> This is just another reason why all browsers (not just mobile) should be
> reporting their screen size. As in, the actual height/width.

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](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/06/devicepixelrati.html)

[http://www.quirksmode.org/blog/archives/2012/07/more_about_d...](http://www.quirksmode.org/blog/archives/2012/07/more_about_devi.html)

~~~
drivingmenuts
> 1cm on a mobile device and 1cm on a desktop

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.

~~~
bzbarsky
The difference is that they look like different sizes to the user because of
the different viewing distance.

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.

~~~
masklinn
It's worse than that, there's the visual effect from angular size and the
"manipulative" effect from interaction device.

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.

------
itsnotlupus
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.

------
droopybuns
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.

~~~
nailer
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-t...](http://stackoverflow.com/questions/19402478/is-it-possible-to-
run-the-windows-phone-8-simulator-directly-in-os-x/19403057#19403057)

~~~
chiph
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.

------
blinkingled
> 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
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
Ah, yes - the embrace part ;)

------
fred_durst
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
And that is exactly why web-standards are so important. It's always in a
broswer's best interest to break the web.

------
iron_ball
"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?

~~~
woogley
ug, that's already a bad check, but if they insist, why not just:

    
    
        /mobile/i.test(navigator.userAgent)

~~~
Cthulhu_
> 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/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/String/contains))

------
sanxiyn
"We are collaborating with Mozilla to record broken sites."

Ah, irony.

------
realusername
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.

------
e15ctr0n
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)

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

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

~~~
abhinavk
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

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

~~~
cenhyperion
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.

------
symlinkk
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.

~~~
cwyers
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.

------
ChrisClark
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
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/)

------
gprasanth
Does this mean they will open source their rendering engine?

------
usingpond
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.

------
ChikkaChiChi
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
The world might not need Trident, but it does need multiple browser engines.

~~~
ChikkaChiChi
Sure. Maybe Gecko and WebKit are enough. At least then the foundations are all
open and freely accessible to the world.

------
drivingmenuts
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.

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

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

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

~~~
misterbwong
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
That was the "before". They've added references to Android, iOS and WebKit.

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

------
neeks
The sheer irony of it all.

------
higherpurpose
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
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
> 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
The HN guidelines clearly state to use the original title, though.

~~~
leeoniya
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?

------
tomjen3
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.

