The Web Manifest specification – HTML5 Doctor article by me and Mozilla’s Magical Mr Marcos. It’s an important spec, and a brilliantly witty article full of poetry and erudition.
Let’s Talk About RTL – a useful guide to making sites with Arabic, Persian and Hebrew text by Ahmad Alfy
W3C Web Payments – an overview Manu’s actually responding to the Bad Voltage podcast discussion, but even outside that context, this is an excellent overview of the initiative. Scroll down for more comments from Stuart Langridge and yours truly, too.
filing bugs – Steve “Bogan” Faulkner’s shit is solid in this article about how to file browser bugs
Now, obviously I can’t speak for Microsoft or the IE team (Bill Gates despises me since I beat him in a nude limbo competition at Patrick Lauke’s birthday disco a few years back) but this brings a wry smile to my little face. It fell to me to write the blog post announcing that Opera was going to support some -webkit- prefixed CSS and be hated by the Internet for the 2.6 seconds it takes before someone more evil pops up.
tantek [Firefox]: At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla … Currently we have zero. Zero is no longer an option for us.
Florian [Opera], Sylvain [Microsoft]: Zero is not an option for us anymore either.
The reason that IE are doing it now, and we did it then, is simple. WebKit browsers, like other browsers, shipped experimental CSS with a prefix. When the CSS property was considered stable, all browsers apart from WebKit removed support for the prefixed version. WebKit browsers, however, did not remove the prefixed version, supporting it in parallel with the unprefixed syntax so that sites that had been made before the “standardising” of the property would not break.
Moreover, lazy developers only tested on WebKit browsers, so didn’t even add the -ms- prefix for Microsoft, -moz- prefix for Firefox or -o- prefix for Opera, so those browsers got a markedly worse experience.
At Opera, we did what we could with a relatively small team to contact site owners and developers and ask them to change it, but there were simply too many to deal with. It was much more effective simply to “support” those -webkit- prefixes that were the analogue of things we already supported; for example, we simply aliased -webkit-border-radius to border-radius.
Magically, lots of iPhone-only sites looked a lot better in Opera. As you can see from the screenshot comparisons in the IE blogpost, the same happens for them. It’s difficult to argue for ideological purity when a simple aliasing makes the user experience so demonstrably better – and one thing I’ve learned at Opera is most users don’t care two hoots for ideology if their favourite site works better in another browser.
It’s tempting to blame the mess on lazy developers, and they are without doubt at fault for enjoying the advantages of the Web without respecting its core principle of cross-browser compatibility. But some of the blame lies with WebKit developers, and (to a lesser extent) with the CSS Working Group for blessing vendor prefixes (though of course, browser makers just did this sort of crap anyway: scrollbar-face-color lurked around for years in IE without a prefix).
But, as managers around the world like to say when laying staff off because of bad management decisions, “we are where we are”. Legacy -webkit- prefixes hide in the dim recesses of sites used every day, and users deserve good experiences.
W3C Web Payments Activity Update – “we believe that we have now the critical mass… We will now start the formal W3C process”. If I were worked for a bank, I’d be watching this; better to be disrupted by the web and be a big, incumbent player with a hand in guiding it all.
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).
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.
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!”
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
Full video game engine with 3D rendering and real-world physics in a browser? Yes. Ability to style <select> dropdowns in a browser? No.
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?
Grid Style Sheets – “GSS reimagines CSS layout & replaces the browser’s layout engine with one that harnesses the Cassowary Constraint Solver — the same algorithm Apple uses to compute native layout”. Imagine if this were not a polyfill, but baked into the browser, with normal CSS as a fallback.
Native Versus Web: A Moment In Time – “the web represents independence from platform owners. It offers incredible freedom to build what you to want build, and to ship when you are ready to ship, without any gatekeepers.”
Pinboard Turns Five – “I enjoy the looking-glass aspect of our industry, where running a mildly profitable small business makes me a crazy maverick not afraid to break all the rules.”
Bad Voltage podcast – “an amusing take on technology, Open Source, politics, music, and anything else we think is interesting”
(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.
I/O Thoughts – write-up of Google I/O conference from an iOS developer.
Beautifully illustrated children’s books which break social norms – a kickstarter to raise £6000 by author and computer book publisher Amie Lockwood. “when was the last time you read a children’s story where the mother ran her own business; the father was the primary caregiver; there were children in wheelchairs; there were multi-racial households; there were same-sex parents or single parents”