QuirksBlog - Mobile web dev

Android gradient screenshot madness

Another fine day at the QuirksMode test labs, where we test browsers so you don’t have to. Today’s topic is CSS gradients, and the subtle ways in which the various Android devices fuck them up. Also, the not-so-subtle ways in which Android devices fuck up screenshots of said gradients.

The CSS physical unit problem

Now that we have the iPad Mini, web designers waste no time in wanting to distinguish between it and the iPad 2. Tough luck.

Yesterday Max Firtman explained in detail why that is not possible. Briefly, no JavaScript or CSS property, variable or media query is different on the iPad 2 and the iPad Mini. Both are 1024x768, neither has a retina screen, etc.

Incidentally, it appears that native developers can distinguish between the two, making the playing field for the grand match between native and web unleveled (disleveled?). If you wish you can blame Apple.

That’s not what I want to write about, though. Instead, it’s about web developers’ expectations and physical units in the W3C spec.

Mobile viewport update

In the past week I’ve done the viewport tests on the latest crop of devices, and things are definitely looking better. The visual viewport dimensions are now well-supported, and a consensus on position: fixed is in the making.

JavaScript library poll results

I held a JavaScript library poll in the last three weeks, and it’s time to publish the results. At least 3,350 people responded. With nearly 155,000 responses in total, and nearly 1,700 for the least-answered question, I believe this poll is fairly representative of my readers and the readers of my readers, and therefore gives genuinely useful information about current JavaScript library use.

On average, respondents used 3.5 libraries in the past year, and about 2 in more than 50% of their projects. (Of course the latter figure might mean they use one library in 50% of their projects, and another in the other 50%.)

95% used libraries, which means that 5% didn’t. That’s something, though not much.

59% could have done without a library in his last project. That’s not too bad, but it still means 41% could not.

42% sticks with his current libraries because learning to use a new one takes too much time.

The most-used library is jQuery with 91%. Duh.

Second-most used is Modernizr (58%), and then come underscore.js (33%) and backbone.js (30%).

From 25-40% of the users of a library use it in at least 50% of their projects. For Modernizr, underscore.js, and especially jQuery this percentage is higher. For Zepto, Sencha Touch, and Raphael.js this percentage is considerably lower.

Last call: JavaScript library poll

Two weeks ago I published a poll about the use of JavaScript libraries. So far it had 97,500 responses, but I’d like to make that 100,000 or more. So here’s the poll again, and I request you to answer as many questions as you can stand.

JavaScript library poll

When I spoke at From the Front I was asked what I thought was the worst case of thoughtless copy/pasting I saw going on around the web. My answer: jQuery.

I feel that jQuery, even the mobile version, and in fact all current JavaScript libraries, are too heavy for mobile. I think it’s time for a re-evaluation of the libraries’ good and bad parts. I followed up in this tweet, which caused quite a few reactions.

The browser is always behind

A browser is an infinitely flexible interface, but is it the best interface for everything? Apps allow experiments in new interaction models

The browser is not the most advanced interface there is. It’s too easy to build the wrong features into something as flexible as a browser, and once a badly-designed feature gains traction it’s impossible to get rid of it. (See HTML5 drag and drop.)