Josh (the blog)

I’ve delivered simple, clear and easy-to-use services for 20 years, for startups, scaleups and government. I write about the nerdy bits here.


@joahua

IE7 expected a string, identifier or number

JSON is nice to read. It’s also nice when parsers are forgiving, but here we are.

I just spent ages chasing [what I thought was] a bug using $.getJSON in IE7 that turned out to be an issue with something else entirely.

If you’re using $(el).css or .animate with JSON, make sure you’ve terminated all items correctly and don’t have any hanging commas left over:

Hanging comma at end of JSON params

This case sent me particularly crazy as I was also dealing with an actual JSON request in the same general vicinity that I’d validated a bunch of times and seemed perfect.

Note to self: Before you go down the whitespace and text encoding rabbithole next time, make sure you’re actually checking the right JSON!

Some tips for mobile CSS

On “retina”/high DPI:

  • SVG sprites are a beautiful thing. Make the canvas size work at a device ratio of 1, and capable user agents (read: mobile Safari) will do the hard work for you. Don’t create a double-resolution sprite, because you’ll need to manually re-declare all your sizing and positioning, which is no fun.
  • Opera supports 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 actually expressed as ratios (x/y), as opposed to floats (1.5). I actually 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 standard way, either – their syntax is “min–moz-device-pixel-ratio”. They obviously missed the part where browser prefixes are supposed to be, well, prefixed. This was done back in late 2010 and they looked at the -webkit implementation first, before implementing it in a very different fashion without much debate. It’s a mind-bogglingly undiscussed issue on Bugzilla and the wider Internet.
  • Android DPI values for DevicesYouKnowAbout(tm) hover around the 1.5 mark. Anything lower than this and the device capabilities probably don’t make it worthwhile, and anything higher is probably an iPhone. Higher resolution Android devices just don’t seem to exist, or, for the most part, report themselves as existing (March 2012 – yeah, the Nexus and Galaxy S2 and stuff are big, but don’t seem to be documented as reporting high DPIs).
  • Okay, so DPI values aren’t quite that simple. To quote A List Apart, “we don’t know what each device considers a pixel and this is a problem.” Read about it, test lots, buy Android devices if you want to be sure.

Miscellaneous gotchas:

  • Certain Android variants – I don’t have enough devices to test conclusively – drop gradient backgrounds, opacity etc. (presumably for performance reasons) despite having “A grade” capabilities in a lot of other senses. Make sure you do simple things like having backgrounds and borders on elements that would have previously been divided by gradient contrast. Your featurephone visitors will also thank you. In an ideal world you’d probably progressively enhance these kind of things, rather than patching it up afterwards, but it’s easy to get caught up in the excitement of only needing to support “A Grade” browsers (accepting that IE is suitably banished from Mobile land) and just forget. Don’t forget.
  • Beware HTML5 manifests – they raise storage prompts that could scare some users in some browsers (“why is this site storing info about me?). They’re also actually not that effective unless you pin an app to the home screen, so reconsider your need to use one.
  • Fennec uses left/right swiping for accessing browser UI. This is a pretty dumb design decision, because it breaks left/right swiping gestures (think photo galleries). Expose an alternative UI (Next/Prev buttons perhaps?) for browsers that don’t do touch events in this way.
  • Windows Phone 7. You’ve heard good things, right? Kinda. It’s definitely up there, but early versions of this device (2011) had a browser that was more or less equivalent to IE7 with a few IE8 features thrown in for good measure. I’m not bothering to support it. However, even the latest versions (March 2012) don’t support touch events (!) so expect it to be even worse than Fennec for conventional swipe-driven mobile UI in the browser. It does have Canvas support, but apparently lacks SVG in the browser.
  • SVG gradient support is patchy (probably for similar reasons Android devices choose not to render CSS gradients)

Tips:

  • Use text-rendering: optimizeLegibility; on headings as it does great things on the iPhone 4. (via Menacing Cloud)
  • Flash ads work. This is staggering, but true. Expect that Android devices will successfully display Flash ads, and pay attention to different markup that gets adserved for these devices as it will possibly impact your CSS.
  • Image based ads scale down quite well. It’s tricky getting mobile inventory smaller than 300px wide, but if you’re expecting 240px devices then just use max-width:100% for this. It’s better than breaking the layout or not serving ads to these screens, not that there are many of them left.

You[r inner copywriter[/editor]] will love this.

[Visit] Telescopic Text.

Click [[any of] the [first [three]]] words.

(My formatting will make sense when you start using it)

A solution to Auspost’s unhelpful suburb/postcode license

Australia Post provide a nice convenient CSV of all of their postcode data, and then proceed to make the license quite prohibitive.

Commercial use? No. Open source modification? No. Redistribution? Nope.

This is really annoying, but thankfully there’s another option. For your bookmarking pleasure, enter https://github.com/joahua/AusPostcode. It’s a CC-BY licensed version of suburb/postcode data in both CSV and JSON formats (feel free to fork and submit a pull request if you’ve got others) based on Australian census data that’s much more permissively licensed.

Happy free/open-source postcoding!

WebGL ready for primetime

A particularly timely email went around the office this morning about WebGL and 3D animation.

All in all, it’s pretty depressing for us – but we’re on 2.5-3 year old hardware in some cases so the next generation won’t have the same issues. In fact, today’s mobile devices would probably demolish the desktops of yesteryear.

From: Sam
Sent: Thursday, 10 November 2011 9:02 AM
To: Web Developers Frontend-DL
Subject: Three.js – 3D Animation in jQuery

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

This one is particularly cool
http://alteredqualia.com/three/examples/webgl_terrain_dynamic.html

Sam

From: Fiona
Sent: Thursday, 10 November 2011 9:09 AM
To: Sam; Web Developers Frontend-DL
Subject: RE: Three.js – 3D Animation in jQuery

:(

Browser support - your graphics card doesn't work

From: Josh Street
Sent: Thursday, 10 November 2011 9:14 AM
To: Fiona; Sam; Web Developers Frontend-DL
Subject: RE: Three.js – 3D Animation in jQuery

Doh.

VPU recover prompt

From: Sam
Sent: Thursday, 10 November 2011 9:18 AM
To: Web Developers Frontend-DL; Anton; Darian
Subject: Three.js – 3D Animation in jQuery

Safe to assume it’s not ready to go mainstream just yet.

Imagine IE6 trying to deal with it…

IE6 is probably not relevant anymore, but the real issue is IE7-9. On the basis of something that’s mostly software related – whether at a level of browser support for different graphics cards, or a user’s access to a particular browser at all – we’re inhibited from deploying particularly cool/useful technologies.

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

The difference here is that, post Windows XP, upgrades aren’t being held back by hardware or platform anymore. Performance has plateaued across desktops as integrated graphics are “good enough” for many applications (see system-on-a-chip mobile solutions where CPU and GPU are tightly – and beneficially- integrated) and discrete graphics are blazingly quick.

I was surprised to discover that the much-hyped Skyrim would purportedly run at high detail on my 18-24ish month old desktop. Caveat – I’m a bit of a hardware geek and probably over-specced (in terms of gaming) when it was built, but it cost under $1000 once you exclude all the hard drives (video editing box… before I switched to OS X). It’s still (apparently) getting incredible performance by today’s standards. This doesn’t speak to a lack of innovation – though it probably says something about the self-cannibalising properties of that industry.

“Oops, my PC is too fast” probably remains an uncommon complaint. Still, I’d contend that for many users, perceived speed will become less of an issue over the next upgrade cycle. Form factor (Macbook Air), low latency (SSDs) and portability (tablets) are the key competitive fronts today and will continue to be. For web technology, this means that we can innovate with confidence where performance is concerned.

The blocker is software.

For now, the trend appears to be targetting applications at particular select user agents to the exclusion of others. WebGL is a great example of this insofar as it doesn’t have a neat fallback option as tools like Raphaël do with VML. Fundamentally, this may be no different to nested video embedding that differs on the basis of browser capabilities. In practice, few will seek to implement equivalent functionality or design 2D experiences to match rich WebGL ones – it’s just too complex.

The real winner in all this is mobile, which has a reasonably broad support for hardware accelerated web experiences.