Reading List

Review: JavaScript & JQuery by Jon Duckett

Disclosure stuff: I was sent a free copy of this by the publishers. From 2000-2002 I worked with its author. I currently work with Mathias Bynens, the book’s technical reviewer (but didn’t know this until after reading it).

Don’t tell anyone, but I’m not very confident with my JavaScript – I learned to program in COBOL, FORTRAN, BASIC, 6502, Z80 and DCL which are all procedural, so I was looking forwards to a book that starts at the very beginning and treats me kindly, before clubbing me over the head because I polluted the global namespace and laughing at me for extending my prototypical object literal constructors into my callbacks.

The book’s blurb says “We’ll not only show you how to read and write JavaScript, but we’ll also teach you the basics of computer programming in a simple, visual way” and is the follow-up to Duckett’s hugely successful HTML and CSS Book which sold over 150,000 copies. (In tech book terms, that’s practically Harry Potter; in this industry, 5,000 is a successful book.)

The book looks beautiful. High quality paper, colour images, with real care and attention lavished on the layout and the words. I’m no quivering aethete designer, but I found it pleasurable to read even though it’s a weighty 600 page tome. Each page (or spread) is its own discrete infolump so it’s easy to out down and come back to.

It starts light – defining events, objects, methods and properties, showing the relationship between HTML, CSS and JS, and with a section on Progressive Enhancement (hoorah). However, I was slightly peturbed that the first worked example uses document.write. I can see why you’d do this – it allows you to show something, but without having to muck about appending to the DOM or using getElementById and innerHTML but it didn’t feel particularly good practice (especially as getElementById and innerHTML are introduced soon after, anyway.) In the author’s defence, he does note that this is Considered Naughty.

Elsewhere, we see lots of workarounds and IE-specific aspects of the DOM. I’m comfortable with these being there; we have to live in the real world, and I think that a book that ignores this does a disservice to its readers – it’s right to equip someone to make pages work on IE.wtf or understand what’s happening in older/ inherited scripts.

The book moves briskly after the traditional introduction to loops, variables and other syntax. By page 270 we’re looking at event listeners, including IE5-8, event delegation, mutation events (with a note that mutation observers are coming, but no more than that.)

Chapter 7 begins with jQuery. Again, there are times when jQuery is entirely appropriate. What’s good is that this book teaches JS concepts first, and always keeps the two separate. (I get tired of “JS” tutorials that are actually about jQuery.)

The rest of the book romps through “HTML5″ APIs, JSON, common UI widgets and – usefully – debugging. Attention is paid to pointing out what’s standard and what isn’t, what’s vanilla JS and what isn’t. Progressive enhancement, accessibility and separation of concerns is are kept in mind throughout. This is good. You can see the table of contents.

When I’m reading, I often don’t care if I’m reading a paper book or a Kindle. But in this case, I was glad I was reading the full-colour, attractive book. I’ve railed about the shoddy quality and general unattractiveness of most computer books before. When so much information is available on the web, publishers must provide some sort of extra value. This book has it – the information is thought-through, beautifully presented and clearly explained. While I guess that the majority of my regular readers won’t need an explanation of what a loop or variable is, I believe this would be an excellent book for someone wanting to start with JavaScript, and learn it well. It doesn’t cover Promises, Mutation Observers, but I don’t really think they’re right for a beginners’ book, anyway.

Oh – and it made me realise that I’m not nearly as crap at JavaScript as I thought I was. Which is nice.

On the complexity of the picture element

On dev.Opera, the man we call “Bovo the bachata boss” just published Responsive Images: Use Cases and Documented Code Snippets to Get You Started. It’s excellent; go and read it. (It isn’t a primer to the whole concept; we have one of those in the works.)

We umm-ed and ah-ed about what order to present the examples – “most likely use-case first” or “simplest to gnarliest syntax” order? We eventually decided the second, because the full syntax can be a bit scary.

But don’t that put you off. Responsive images addresses 4 different use-cases. There are also new constructs like sizes and srcset to wrap your bonce around. So the syntax for addressing all four at once is, at first sight, pretty complex.

But, like the most complex of the 24 English tenses, the Future Passive Perfect Continuous tense*, you’ll probably rarely need it.

And if my dull brain can understand it, yours can.

*I used it once, when complaining about how long a repair shop was taking with my guitar. “By our next gig, it will have been being mended for three weeks!”

On violence

I want to get the men who shot down MH17, and the leaders of Hamas and Israel, and repeatedly punch them in their faces until their noses are smashed. I would enjoy it.

The horrible, bitter irony of this is not lost on me.

Reading list

Bonus video content!

“My job is to make sure that the web wins” – The Awwwards people interviewed me and my extra chins in Paris in February.

Review: Two Gentlemen of Verona, RSC

It’s easy to seriously muck up a production of one of Shakespeare’s great plays, but exceptionally hard to pull off a good production of a relatively weak play like Two Gentlemen of Verona. I enjoy seeing one of the lesser plays produced, as it’s fascinating to see what a really good director and cast can do with unpromising source material.

One thing you can do is have lots of music and spectacle and there are a few musical interludes in this new production. The extended opening is a joy; the ensemble cast re-creates a busy restaurant in Verona, with live music and without dialogue but with lots of audience interaction. It’s great fun. It’s contrasted with the sophistication of the Milanese court later, in a fabulous interlude involving a cabaret singer/ exotic dancer and bizarre Tudorbethan disco dancing.

The production doesn’t try to overwhelm with spectacle, however. In fact, occasionally it lacks pace. This may because I watched it on the third night of its run, so the actors need to get into their stride. But it may be the quality of the text. One of the reasons that the play is weak is that Shakespeare was still learning his craft (many scholars believe this to be his first play) so there are long speeches that are undramatic wordplay. Perhaps they were funny in the sixteenth century but they aren’t now, so I found myself thinking that if I’d directed the play, I’d have been ruthless with my red pencil and removed some of those speeches. (It’s an advantage of one of the minor plays that you can excise stuff without offending too many purists.)

Something else that doesn’t work so well these days are the plays dodgy sex and racial politics. When Proteus falls in love with Sylvia and out of love with Julia he says “And Silvia — witness Heaven, that made her fair!— / Shows Julia but a swarthy Ethiope. / I will forget that Julia is alive”. However, it’s foolish to expect a sixteenth century play to conform to modern standards.

I thoroughly enjoyed the production, especially the performances by Pearl Chanda (Julia), Nicholas Gerard-Martin (Thurio), whose serenade scene was very funny, and Michael Marcus (Valentine). Honourable mentions, too, for Sarah MacRae (Silvia) and Martin Bassindale (Speed). The outlaws were also amusing. It’s also beautifully staged, with enough physicality and dark moments to carry the preposterousness of the plot – no twins or shipwrecks, but we do get a woman dressed as a man and instantaneous reversals of character.

An excellent RSC directorial debut from Simon Godwin. One small niggle: the first half was very long – almost two hours by my watch.

“Native experience” vs styling select boxes

I mused about this on stage at Fronteers 2013, and was reminded of it when reading Stephanie Reiger’s excellent slidedeck The future of media queries?, specifically slide 42 which I reproduce with Stephanie’s permission.

Stephanie suggests a mechanism of telling a user agent to render a navigation list as a native component, so it looks native across a range of devices, because it is native. (We could bikeshed about the markup and whether it should be in the CSS, but that doesn’t matter.)

I get that developers want their sites to appear native on the host device. Presumably users like native feel, too; there’s a reason why users show a huge preference for native apps over web apps, and one of those reasons is that native apps

allow the user to use device-specific hand gestures. Android and iOS are gradually developing different conventions for interaction, and a native app responds the way its user expects. User Experience Stack Exchange

So Stephanie’s idea makes perfect sense to me.

But what puzzles me is the fact that for ages designers and developers have also desperately tried to style away native controls. For example, recently Nicholas Zakas said

and was retweeted hundreds of times. Nicholas isn’t wrong to want this, and this wish isn’t new; when Safari first came out, designers were close to burning their moleskines because they couldn’t make buttons in corporate orange and heliotrope. When I first started showing HTML5 form controls at conferences, without fail I’d be asked how they can be styled. There are endless articles and scripts that painstakingly take real selects, hide them more or less accessibly, then recreate them so they don’t look native on any device.

But why this urge to re-style page elements that end-users are familiar with? You’ll be shocked to learn that I’m not actually trained as a designer – so what am I failing to understand? Or is it that we love native look and feel, except when we don’t?

UPDATE 21 July 2014: Aaron Gustafson wrote an interesting response to my post: The “Native” vs. “Stylable” Tug of War.

Reading List

Apps For All: Coding Accessible Web Applications – book review

(I was sent a free ebook of this title. That hasn’t influenced my review. This ebook is published by Smashing Magazine and costs €10.95. There’s a sample chapter available. I have no financial connection with the publisher or author.)

When I read about this book I was excited to read it. I don’t need Yet Another Accessibility Book (I co-wrote one a long time ago) but wanted something that delves deeply into WAI-ARIA and how it interacts with HTML5 and assistive technologies. As this book’s blurb says “the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users”, it seemed like the book for me. It’s also tech-reviewed by Steve Faulkner who’s my go-to Bogan for practical accessibility information, so I was pretty sure I could trust it.

WAI-ARIA is one of the vital specifications for making the web accessible. There are three problems with using it, though: firstly, the spec is hard to read and understand, even in the context of specs’ inherent indigestibility; secondly, it’s hard to understand how its concepts intertwine with other specs like HTML and, thirdly, most developers don’t use assistive technologies so are unable to understand or test the output of their ARIA pages.

Therefore, I greatly appreciated that author Heydon Pickering is a developer, so keeps the book practical. ARIA is used, in conjunction with markup and script in situations that you’d really encounter. The problem to be solved is elucidated, and the output is clearly explained. It goes deep, too; I learned a great deal and plan to re-read it soon.

It’s a short book (but quite dense) and Heydon’s prose style is clear and occasionally humorous. But don’t let that fool you; this is an important book because it’s the only one that thoroughly explains the technical merits and use of ARIA (and doesn’t browbeat the reader about accessibility).

Without hyperbole: every developer should read this book, and put its techniques into practice. Now.

Reading List