Interesting. They don't show Android screenshots for comparison. Not the built-in browser, not Chrome.
The Mobile Web should just work for everyone
91–100 of 127 posts
Re: The Mobile Web should just work for everyone
#92Why 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 blac…
The world might not need Trident, but it does need multiple browser engines.
Re: The Mobile Web should just work for everyone
#93I 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…
You can do it on your desktop,
Re: The Mobile Web should just work for everyone
#94Earlier quoted context omitted.
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.
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.
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...
Re: The Mobile Web should just work for everyone
#95Although 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.
Re: The Mobile Web should just work for everyone
#96Earlier quoted context omitted.
That query means nothing. Most of those results include the non-prefixed version as well. The prefixed one is there for backwards compatibility.
> That query means nothing. 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".
Preprocessors often have prefix support baked in. It's not about explicitly testing your site for backwards compatibility. It's about casting that net as far as possible with minimal effort.
Re: The Mobile Web should just work for everyone
#97The 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 c…
When I first experienced browsing with mobile devices the stand out feature was zoom. Double-tap on a column of text and it would zoom to fill the width of the screen. This (and similar navigation features such as swipe to scroll) made mobile browsing preferable to desktop browsing for me, despite the smaller screen. Fast forward a few years. Almost every website has a mobile version. Three quarters of these mobile s…
That's why I use Dolphin and spoof my user agent string (often). I usually want the full site. Your mobile site sucks.
Re: The Mobile Web should just work for everyone
#98Earlier quoted context omitted.
> That query means nothing. 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".
No reason to remove them when they are there.
Erm… the query is sorted by most recently indexed, this is code which was just changed, the top hit at this moment is https://github.com/mdilaver/mdilaverins/commits/421298cf9bf1... which is 5 days old.
Re: The Mobile Web should just work for everyone
#99This 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…
> 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.
Re: The Mobile Web should just work for everyone
#100This 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…
> 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
> 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...