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.
Navigation Transitions Specification – apply a stylesheet to a page when leaving it for another page. Initially I thought this rather gimmicky, but it’s useful in making web UX closer to “native”
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).
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.
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 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.
GOV.UK design patterns – “A wiki for people working on GOV.UK services to discuss GOV.UK design patterns and share ideas and experiences. Contributions from other designers welcome.”
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.
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.
Resource Hints – draft spec defines preconnect, preload, prefetch, and prerender hints that the developer, or the server generating or delivering the resources, can use
to optimise performance
Unfashionably profitable – Rachel “Grandma” Andrew explains why her successful business relies on PHP rather than something cool.
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.
