On “retina”/high DPI:

• SVG sprites are a beau­ti­ful thing. Make the can­vas size work at a device ratio of 1, and capa­ble user agents (read: mobile Safari) will do the hard work for you. Don’t cre­ate a double-resolution sprite, because you’ll need to man­u­ally re-declare all your siz­ing and posi­tion­ing, which is no fun.
• Opera sup­ports SVG but doesn’t bother to scale it. In most cases, this means a well-quantised PNG is going to be smaller.
• Opera’s device-pixel-ratios are actu­ally expressed as ratios (x/y), as opposed to floats (1.5). I actu­ally think this makes a lot of sense, though I’m pretty sure they’ve already lost this battle.
• Mozilla/Fennec doesn’t do ratios in a stan­dard way, either — their syn­tax is “min – moz-device-pixel-ratio”. They obvi­ously missed the part where browser pre­fixes are sup­posed to be, well, pre­fixed. This was done back in late 2010 and they looked at the –webkit imple­men­ta­tion first, before imple­ment­ing it in a very dif­fer­ent fash­ion with­out much debate. It’s a mind-bogglingly undis­cussed issue on Bugzilla and the wider Internet.
• Android DPI val­ues for DevicesY­ouKnowAbout™ hover around the 1.5 mark. Any­thing lower than this and the device capa­bil­i­ties prob­a­bly don’t make it worth­while, and any­thing higher is prob­a­bly an iPhone. Higher res­o­lu­tion Android devices just don’t seem to exist, or, for the most part, report them­selves as exist­ing (March 2012 — yeah, the Nexus and Galaxy S2 and stuff are big, but don’t seem to be doc­u­mented as report­ing high DPIs).
• Okay, so DPI val­ues aren’t quite that sim­ple. To quote A List Apart, “we don’t know what each device con­sid­ers a pixel and this is a prob­lem.” Read about it, test lots, buy Android devices if you want to be sure.

Mis­cel­la­neous gotchas:

• Cer­tain Android vari­ants — I don’t have enough devices to test con­clu­sively — drop gra­di­ent back­grounds, opac­ity etc. (pre­sum­ably for per­for­mance rea­sons) despite hav­ing “A grade” capa­bil­i­ties in a lot of other senses. Make sure you do sim­ple things like hav­ing back­grounds and bor­ders on ele­ments that would have pre­vi­ously been divided by gra­di­ent con­trast. Your fea­ture­phone vis­i­tors will also thank you. In an ideal world you’d prob­a­bly pro­gres­sively enhance these kind of things, rather than patch­ing it up after­wards, but it’s easy to get caught up in the excite­ment of only need­ing to sup­port “A Grade” browsers (accept­ing that IE is suit­ably ban­ished from Mobile land) and just for­get. Don’t forget.
• Beware HTML5 man­i­fests — they raise stor­age prompts that could scare some users in some browsers (“why is this site stor­ing info about me?). They’re also actu­ally not that effec­tive unless you pin an app to the home screen, so recon­sider your need to use one.
• Fen­nec uses left/right swip­ing for access­ing browser UI. This is a pretty dumb design deci­sion, because it breaks left/right swip­ing ges­tures (think photo gal­leries). Expose an alter­na­tive UI (Next/Prev but­tons per­haps?) for browsers that don’t do touch events in this way.
• Win­dows Phone 7. You’ve heard good things, right? Kinda. It’s def­i­nitely up there, but early ver­sions of this device (2011) had a browser that was more or less equiv­a­lent to IE7 with a few IE8 fea­tures thrown in for good mea­sure. I’m not both­er­ing to sup­port it. How­ever, even the lat­est ver­sions (March 2012) don’t sup­port touch events (!) so expect it to be even worse than Fen­nec for con­ven­tional swipe-driven mobile UI in the browser. It does have Can­vas sup­port, but appar­ently lacks SVG in the browser.
• SVG gra­di­ent sup­port is patchy (prob­a­bly for sim­i­lar rea­sons Android devices choose not to ren­der CSS gradients)

Tips:

• Use text-rendering: opti­mizeLeg­i­bil­ity; on head­ings as it does great things on the iPhone 4. (via Men­ac­ing Cloud)
• Flash ads work. This is stag­ger­ing, but true. Expect that Android devices will suc­cess­fully dis­play Flash ads, and pay atten­tion to dif­fer­ent markup that gets adserved for these devices as it will pos­si­bly impact your CSS.
• Image based ads scale down quite well. It’s tricky get­ting mobile inven­tory smaller than 300px wide, but if you’re expect­ing 240px devices then just use max-width:100% for this. It’s bet­ter than break­ing the lay­out or not serv­ing ads to these screens, not that there are many of them left.

A par­tic­u­larly timely email went around the office this morn­ing about WebGL and 3D animation.

All in all, it’s pretty depress­ing for us — but we’re on 2.5 – 3 year old hard­ware in some cases so the next gen­er­a­tion won’t have the same issues. In fact, today’s mobile devices would prob­a­bly demol­ish the desk­tops of yesteryear.

From: Sam
Sent: Thurs­day, 10 Novem­ber 2011 9:02 AM
To: Web Devel­op­ers Frontend-DL
Sub­ject: Three.js — 3D Ani­ma­tion in jQuery

The Web GL exam­ples may not work if you have an older com­puter. I tried them at home – pretty cool.
http://mrdoob.github.com/three.js/

This one is par­tic­u­larly cool
http://alteredqualia.com/three/examples/webgl_terrain_dynamic.html

Sam

From: Fiona
Sent: Thurs­day, 10 Novem­ber 2011 9:09 AM
To: Sam; Web Devel­op­ers Frontend-DL
Sub­ject: RE: Three.js — 3D Ani­ma­tion in jQuery

:(

From: Josh Street
Sent: Thurs­day, 10 Novem­ber 2011 9:14 AM
To: Fiona; Sam; Web Devel­op­ers Frontend-DL
Sub­ject: RE: Three.js — 3D Ani­ma­tion in jQuery

Doh.

From: Sam
Sent: Thurs­day, 10 Novem­ber 2011 9:18 AM
To: Web Devel­op­ers Frontend-DL; Anton; Dar­ian
Sub­ject: Three.js — 3D Ani­ma­tion in jQuery

Safe to assume it’s not ready to go main­stream just yet.

Imag­ine IE6 try­ing to deal with it…

IE6 is prob­a­bly not rel­e­vant any­more, but the real issue is IE7-9. On the basis of some­thing that’s mostly soft­ware related — whether at a level of browser sup­port for dif­fer­ent graph­ics cards, or a user’s access to a par­tic­u­lar browser at all — we’re inhib­ited from deploy­ing par­tic­u­larly cool/useful technologies.

This is an old story. Users take too long to upgrade.

The dif­fer­ence here is that, post Win­dows XP, upgrades aren’t being held back by hard­ware or plat­form any­more. Per­for­mance has plateaued across desk­tops as inte­grated graph­ics are “good enough” for many appli­ca­tions (see system-on-a-chip mobile solu­tions where CPU and GPU are tightly — and ben­e­fi­cially– inte­grated) and dis­crete graph­ics are blaz­ingly quick.

I was sur­prised to dis­cover that the much-hyped Skyrim would pur­port­edly run at high detail on my 18-24ish month old desk­top. Caveat — I’m a bit of a hard­ware geek and prob­a­bly over-specced (in terms of gam­ing) when it was built, but it cost under $1000 once you exclude all the hard dri­ves (video edit­ing box… before I switched to OS X). It’s still (appar­ently) get­ting incred­i­ble per­for­mance by today’s stan­dards. This doesn’t speak to a lack of inno­va­tion — though it prob­a­bly says some­thing about the self-cannibalising prop­er­ties of that industry.

“Oops, my PC is too fast” prob­a­bly remains an uncom­mon com­plaint. Still, I’d con­tend that for many users, per­ceived speed will become less of an issue over the next upgrade cycle. Form fac­tor (Mac­book Air), low latency (SSDs) and porta­bil­ity (tablets) are the key com­pet­i­tive fronts today and will con­tinue to be. For web tech­nol­ogy, this means that we can inno­vate with con­fi­dence where per­for­mance is concerned.

The blocker is software.

For now, the trend appears to be tar­get­ting appli­ca­tions at par­tic­u­lar select user agents to the exclu­sion of oth­ers. WebGL is a great exam­ple of this inso­far as it doesn’t have a neat fall­back option as tools like Raphaël do with VML. Fun­da­men­tally, this may be no dif­fer­ent to nested video embed­ding that dif­fers on the basis of browser capa­bil­i­ties. In prac­tice, few will seek to imple­ment equiv­a­lent func­tion­al­ity or design 2D expe­ri­ences to match rich WebGL ones — it’s just too complex.

The real win­ner in all this is mobile, which has a rea­son­ably broad sup­port for hard­ware accel­er­ated web experiences.