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”
Being a compendium of links that I’ve read, or tweeted, gathered together for those who don’t hang around on twitter all day. Inclusion here doesn’t imply endorsement, just that I found it useful or interesting.
Standards ‘n’ Stuff
Here’s the <picture> element, all grown up and looking so slinky in a mint-green WHATWG spec and matching tiara
html5-h custom element by Steve Faulkner is a web component to replace <h1>-<h6> and implement the proper HTML5 document outline. Interesting stuff; web components as a way to smooth around broken implementations.
Fuzzy anchoring – another proposal for a method to link to arbitrary places in a document you don’t control. See also Using CSS Selectors as Fragment Identifiers by Simon St Laurent and Eric Meyer (disclosure: I reviewed an early draft of this proposal). I want something like this, but there’s little interest in the standards groups, I think.
Dear Marc Andreessen – “If our industry stops painting anyone who questions our business models as Luddites and finds creative ways to build products and services that sustainably address real needs, maybe we can hold on to the receding myth of triumphal disruption.”
It looks like Manifest for web application is gonna be, like, literally, a thing. It’s already in Firefox OS, Opera likes it, and Alex Russell – sounding like an enthusiastic estate agent with his breathless talk of “window decorating” & “exit extents” – gave it a yay from the Chrome team.
a loose, unofficial, and open collaboration of Web browser manufacturers and interested parties. The group aims to develop specifications based on HTML and related technologies to ease the deployment of interoperable Web Applications
Ten years is a long time, especially so in software, but nevertheless, the achievements of WHATWG have been remarkable. Hixie wrote
The working group intends to ensure that all its specifications address backwards compatibility concerns, clearly provide reasonable transition strategies for authors, and specify error handling behavior to ensure interoperability even in the face of documents that do not comply to the letter of the specifications.
Core aspects of the web platform were never adequately specified. XMLHttpRequest, for example, was shipped in IE5 in March 1999, and reverse-engineered and shipped in Firefox, Opera, Safari and iCab, but never actually documented until Anne van Kesteren co-specified it in WHATWG in a Working Draft of 5 April 2006. Anne’s currently working on the Fetch Standard, which defines something as basic as “requests, responses, and the process that binds them” and the Encoding Standard:
While encodings have been defined to some extent, implementations have not always implemented them in the same way, have not always used the same labels, and often differ in dealing with undefined and former proprietary areas of encodings. This specification attempts to fill those gaps so that new implementations do not have to reverse engineer encoding implementations of the market leaders and existing implementations can converge.
Of course, the poster children of WHATWG are the slew of new APIs that “HTML5″ brings us – Web Workers, Web Sockets, native video and audio etc etc. There have been mistakes along the way (of course there have, in a decade!). Last year, Hixie told me
My biggest mistake…there are so many to choose from! pushState() is my favourite mistake, for the sheer silliness of ending up with an API that has a useless argument and being forced to keep it because the feature was so desired that people used it on major sites before we were ready to call it done, preventing us from changing lest we break it. postMessage()‘s security model is so poorly designed that it’s had academic papers written about how dumb I was, so that’s a pretty big mistake. (It’s possible to use postMessage() safely. It’s just that the easiest thing to do is not the safe way, so people get it wrong all the time.) The appcache API is another big mistake. It’s the best example of not understanding the problem before designing a solution, and I’m still trying to fix that mess.
But to me, the biggest triumph of WHATWG has been error-handling and interoperability (actually, two sides of the same coin). We’ve moved from a vision of the future where everything was supposed to be XML and browsers were to stop parsing if they met malformed markup, to a present where every browser knows how to construct an identical DOM from the most mangled/tangled HTML. We’re moving to a world where interoperability is paramount, and where specifications are made in the open, in constant consultation with developers (for example, Service Workers, Web Components) based on real use-cases.
I think the existence and the work of WHATWG has secured the viability of the web platform. Happy 10th birthday. And thanks.
Update and call for review. HTML manifest spec for offline apps v1 is published. Implementing in Gecko, Blink. “Devs and implementers, please let us know which V2 features should be prioritized.”
Getting to know CSS Blend Modes – “CSS Blend Modes provide a way to specify how one layer will interact or “blend” with the one underneath. Until now, this was the domain of photo editing applications, but now they are available on the web using CSS itself!”
Is Service Worker ready? – no. But Jank Architect has a useful page showing the implementation status of all the pieces needed to get to offline app utopia.