Adaptive Images by Matthew Wilcox: “This is a run-through of a talk I originally gave at Standards Next a few weeks ago. It’s not as smooth as that talk as I’m a few weeks out of practice and pretty tired right now; but hopefully it’s useful to you (it’s also 10min longer than the real talk was, sorry!).”
Step away from the localStorage. Flame-haired FOSS pinup guy, Stuart Langridge, asks “Is being easy to use suddenly a bad thing?”
Stop solving problems you don’t yet have. Rachel Andrew writes, “Make sure every bit of code added to a project is there for a reason, not just because it is part of some boilerplate”
Please add -o- prefixes to your CSS keyframe animations, as we at Opera have released a build containing prefixed support (and also HTML5 Drag and Drop and other goodies) so it’ll be in the wild soon.
Note too that CSS Gradients is soon going to be standardised and so will drop prefixes. This doesn’t mean you should take out your prefixed rules, but rather add non-prefixed rules eg linear-gradient, radial-gradient, repeating-linear-gradient, repeating-radial-gradient.
If you’re the owner of one of those very useful gradient generators that I use all the time, could you please add non-prefixed rules to the output, and retire any creaky old pre-standardised webkit-only output?
There are a couple of key nuggets in there (although the full report is worth a read). First, let’s remind ourselves that the internet contributed £121 billion (not million) to the UK last year, which is more that £2000 per person, making it 8.3% of the economy. Let’s also agree that mobile is an important and rapidly-growing part of that.
A bad experience on a mobile website leaves mobile web users much less likely to return to, or recommend, a particular website. Nearly half of mobile web users are unlikely to return to a website that they had trouble accessing from their phone and 57% are unlikely to recommend the site.
It’s pretty likely that visitors are coming to your website from non-webkit browsers: Opera is huge. It’s becoming more likely as Internet Explorer on Windows Phone 7 hits the market and when Firefox Fennec is released.
If you don’t make sure that your website works in those browsers (this means testing), 50% of those customers won’t come back. And, unless you are selling something completely unique, they’re quite likely to buy from your competitors instead:
Mobile users do not have much patience for retrying a website or application that is not functioning initially — a third will go to a competitor’s site instead.
Another interesting finding is likely to annoy some developers. When asked “What is the most common problem you’ve encountered accessing websites or applications on your mobile phone?”, respondants answered “Slow to load” (38%), “Crashed/froze received an error” (18%), “Formatting made it difficult to read and use” (15%).
This tells us that speed is more important than aesthetics. So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.
Certainly, if you’re using gigantic libraries and frameworks to speed up your development, you might pause to wonder whether trading off faster development for slower loading is a trade-off you want to make, given that most users find speed to be the main problem – and problems drive consumers away and potentially into the arms of competitors.
It seems to me that old-fashioned, oh-so-dull techniques might not be ready for retirement yet. You know: well-crafted HTML, keeping JavaScript for progressive enhancement rather than a pre-requisite for the page even displaying, and testing across browsers.
They might not be cool. But it’s what users want. And if your business doesn’t provide it, your competitors will.
Added 17 April: in a survey conducted in Brazil, 62% agreed that speed was the most important feature for them while browsing the mobile web.
Polyfill for getUserMedia by Addy Osmani, uses Flash as a fallback. Not production ready – more IE testing required, and anyway, the spec is shifting again (events rather than callbacks anyone?)
sendthemyourmoney.com: “The MPAA & RIAA claim that the internet is stealing billions of dollars worth of their property by sharing copies of files. They’re willing to destroy the internet with things like SOPA & PIPA in an attempt to collect that money…Let’s just pay them the money! They’ve made it very clear that they consider digital copies to be just as valuable as the original…Take a picture or scan an image of your money. Send digital copies to the MPAA & RIAA in whatever quantity you feel you can afford.
localstorage
There has been much discussion that localstorage is dead and we should all stop using it because IndexedDB is much better. It’s also 676% harder to learn. I initially wrote “Not sure that localstorage is broken. But “localstorage-for-big-data-eg-images-because-vendors-can’t-agree-on-a-DB-API” is certainly so.”
So localStorage is slower than using an in-memory object. Cars are slower than airplanes. What does that tell us? Not a whole lot. …The reason localStorage is popular is partly due to its simplicity… The proposed alternative, IndexedDB, is perhaps one of the worst API designs I’ve ever seen.
When I was a young man in the late 80s, for reasons to convoluted to go into, I was a regular drinker at a local social club for Polish people who’d come over to the UK in the war. I got to know several colourful characters; one was Jan, an old man with highly idiosyncratic English and smile lines etched deep into his face, who carried in his wallet a photograph of his handsome younger self in Polish millitary uniform and who had stabbed several SS officers to death. Another was an elderly lady whose name was Marta who had her Auschwitz number tattooed on her arm.
Both of them are almost certainly dead now, but I was thinking of them as I’m in Krakow, Poland with a free day before a meet-up tonight, I decided to visit Aushwitz. (I went with Krakow Shuttle, who picked me up and dropped me at my hotel for 120PLN (about £25), including all admission fees, a very knowledgeable English-speaking guide and a simple packed lunch).
As a site, Auschwitz 1 is unremarkable – almost banal. It was built originally by the Poles as a military barracks, and that’s what it looks like: nothing sinister except for the famous Arbeit Macht Frei sign over the entrance, the electrified barbed wire and the gas chamber.
The banality of the exterior makes exhibits in the blocks even more shocking. The mountain of human hair (7000 tonnes were found, apparently) that the SS were selling to industry for 50 pfennigs a kilo for stuffing sofas and making socks made several of our party cry. The mountain of prosthetic limbs, shoes, cooking pots, toothbrushes and childrens’ toys are almost too hard to look at.
Even after that, nothing prepares you for the gas chamber – much larger than I’d expected – and the crematoria. To stand in a place where hundreds of thousands were murdered, to look up at daylight coming through the vents through which the Zyklon B was poured is …. well, I don’t know what it is. Such unimaginable horror took place in that room, and you can feel it.
Auschwitz 2, Birkenau, is a 5 minute drive away. It must be the bleakest place on Earth – flat, featureless, cold, muddy, windswept, just a train track through the middle where the cattle trucks rolled in, surrounded by barracks. We stood where the selections took place, and then walked the same route that countless disabled, elderly, sick people, children and pregnant women walked, directly from selection to destruction.
There’s a bleak monument in between the ruins of the two gas chambers and crematoria (the Germans blew them up to try to hide their crimes as the Red Army advanced). Surrounding the monument are plaques, with a central message translated into multiple languages: “For ever let this place be a cry of despair and warning to humanity, where the nazis murdered about one and a half million men women and children, mainly Jews, from various countries of Europe”.
That’s the terrible thing – “a warning to humanity”. As we drove around Krakow, I saw at least three crossed-out stars of David sprayed on to walls. And, in my lifetime, we’ve seen the killing fields of Cambodia, ethnic cleansing in Bosnia, the genocide in Rwanda and Darfur.
An early 90s live (and unusually mellow) version of a song I wrote about someone who wasn’t called Jacqueline. In fact, while writing the song its working title was “Marigold Says” until I settled on “Jacqueline” because (a) it scans and (b) the only Jacqueline I knew was Jackie Foster at school, and I quite fancied her. (“Caroline” was another possibility, as it also scanned and I fancied Caroline Fowles, but that bastard Lou Reed had already recorded “Caroline Says”.)
Jaqueline wants, so Jacqueline gets.
How long she’ll keep it for is anyone’s guess.
Mary gets drunk, Mary gets to her knees
She never wants the things that you know she needs.
I am sick and tired of you coming round
And falling down and going home.
I’m sick of getting no response.
Won’t you tell me what Jacqueline wants.
Mary should know but it’s been a long time
And you soon forget those once-intimate signs.
Jacqueline wrote, and Jacqueline said
“I drown as the world comes round and fucks up my head”.
She said “You are you and I am me;
what other way could it be?”
I might have thought differently once”
Won’t you tell me what Jacqueline wants.
I recall the boys in the band taking the piss out of me for “going all prog rock” on account of a D diminished chord in the chorus.
Here’s the normal, rawer (and worse recorded) rehearsal version.
What is HTML5 – surprisingly good, 90 second explanatory video for not-so-geeky. Sadly, it loses 98 Brucie points for starting with the word “So”, which is about as sensible as beginning a talk “Notwithstanding” or “Nevertheless”.
Video, multimedia
Encrypted Media proposal in which reps from Google, Netflix and Microsoft propose a form of DRM for HTML5
People have asked me to explain the vendor prefix problem. This is me (Bruce) explaining what I believe to be true (a couple of details are fuzzy to me, so forgive any errors – I’m trying to explain the concept). This is NOT a statement of Opera’s position or intents, so don’t be a dick and blame them for my opinions or mistakes.
Right.
On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit prefixed CSS properties. (Search the minutes for “Vendor Prefixes”. Florian is from Opera, Tantek represents Mozilla, Sylvaing is Microsoft’s glamorous rep, and Tab is from Google. Glazou is Daniel Glazman and Plinss is Peter Linss, the two co-chairs of the Working Group.)
Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings.
Suppose a developer made site a while ago and used the experimental, pre-standardised code -webkit-border-radius and didn’t use the cross-browser future-proof method.
The real CSS property border-radius has been long been standardised and supported without prefixes in all the major browsers. But the -webkit- prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.
The webkit team have said that they won’t remove such legacy properties for compatibility reasons, and I haven’t heard howls of indignation about this. So the recent proposal is that non-webkit browsers will support -webkit-border-radius as if it were border-radius and thus won’t look “broken”.
I imagine that sites that only use -webkit-transition and -webkit-text-size-adjust etc will be similarly supported.
The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set.
Exactly which prefixes would be supported in this way and whether they would be the same in Opera, Microsoft and Firefox, I don’t know.
Personally – PERSONALLY – I’m pretty depressed about all this. I’ve spent 10 years – pretty much since IE6 came out – evangelising cross-browser, accessible, standards-based sites. As a development community we chased the Shiny and we caused IE6 to linger around like a vindaloo fart in a windowless loo. And now we’re doing the same again.
Daniel has put out a call to action for developers to fix their sites and mend their ways: CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*. Chris Heilmann of Mozilla has launched a community action called Pre-fix the web!. Read them. Join in. I truly hope they work (although fear it’s too late).
Comment if you like, but I won’t be able to moderate them for a few days, so better to write your own blog posts!
(added 18:45)
I should add that we will still need responsible developers using vendor prefixes right – this is not the end of vendor prefixes. From those who teach, from those who developers look up to, from those selling frameworksWe still need better, responsible evangelism and demos.
The proposal is to support a subset of -webkit- prefixes, especially the archaic stuff like -webkit-gradient, so that those sites don’t look dreadful in non-webkit browsers. The plan is not to support everything that the webkit devs pull out of their hats, every time they get the urge to extend CSS.
So, we still need to use cross-browser future-proof vendor prefixes if we decide to let experimental, pre-standardised code out on production sites.
Just three links for this reading list, because they show a profound schism in the way people are thinking about building applications that have previously been desktop only and take them to mobile.
The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?
The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.
“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.
It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.
What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.
It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.
We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.
If you read no other high-level articles this month, read that one.
(Article updated to correct some typos noticed by commenters, and clarify some aspects.)
Avid HTML5 watchers will know that the <time> element was dropped from HTML, then re-instated, with more New! Improved! semantics.
As before, you can put anything you like between the opening and closing tags – that’s the human-readable bit. The machine-readable bit is contained within a datetime attribute. Dates are expressed YYYY-MM-DD.
Previously, you could only mark up precise dates. So, 13 November 1905 could be expressed in HTML <time datetime="1905-11-13"> but November 1905 couldn’t be. This is a problem for historians where sometimes the precise date isn’t known.
Now, “fuzzy dates” are possible:
<time datetime="1905"> means the year 1905
<time datetime="1905-11"> means November 1905
<time datetime="11-13"> means 13 November (any year)
<time datetime="1905-W21"> means week 21 of 1905
As before, times are expressed using the 24 hour clock. Now, you can separate the date and time with a space rather than a “T” (but you don’t have to). So both of these are valid:
<time datetime="1905-11-13T09:00">
<time datetime="1905-11-13 09:00">
You can localise times, as before. Appending “Z” to the timezone indicates UTC (a way of saying “GMT” without it being comprehensible to normal people). Otherwise, use an offset:
<time datetime="09:00Z"> is 9am, UTC.
<time datetime="09:00-05:00"> is 9am in the timezone 5 hours behind UTC.
<time datetime="09:00+05:45"> is 9am in Nepal, which is UTC + 5 hours and 45 minutes.
Durations
In New! Improved! HTML5 <time>, you can represent durations, with the prefix “P” for “period”.
The datetime attribute “D” for days, “H” for hours, “M” for minutes and “XQ” for seconds. Just kidding – that’s “S”.
You can separate them with spaces (but you don’t have to). So <time datetime="P4D"> is a duration of 4 days, as is <time datetime="P 4 D">.
Using a “T” after the “P” marker allows you to be more precise: <time datetime="PT23H 9M 2.343S"> is a duration of 23 hours, 9 minutes and 2.345 seconds.
Whichever you choose, it’s represented internally as a number of seconds. Because of this, you can’t specify a duration in terms of months, because a month isn’t a precise number of seconds; a month can last from 28 to 31 days. Similarly, a year isn’t a precise number of seconds; it’s 12 months and February sometimes has an extra day.
You still can’t represent dates before the Christian era, as years can’t be negative. Neither can you indicate date ranges. To mark up From “21/02/2012 to 25/02/2012″, use two separate <time> elements.
pubdate
The pubdate attribute (a boolean that indicates that this particular date is the publication date of the parent <article> (or, if there is none, the whole document) is currently missing from the W3C version of the spec, but is still current in the WHATWG version. Its status is unclear to me (but I’m still using it).
A couple of people have asked me recently if it’s possible to nest ARIA roles. The answer: yes.
Not all of them, of course. Think of HTML elements; you can nest <div>s inside <nav>s and <nav>s within <header>s, but you can’t put an <a> inside an <input> or put an <input> inside another <input> – they just wouldn’t make sense.
In ARIA, it’s perfectly fine to have role=article inside role=main (which is completely analogous to an HTML5 <article> inside a <div id=”main”>.
It’s also fine (as far as I know) to have roles like main inside a <table role=”presentation”>. Although the table is presentational only (it’s an old-fashioned layout table), it doesn’t mean that all the contents are presentational – one cell could contain the entire main content of a site and therefore quite legitimately have a role="main".
The rule of thumb I use is: if your nesting feels right, it probably is right.
Note also that the HTML5 validator also validates ARIA. Even if your content isn’t HTML5, it’s still worth running it through the validator.
Note, I’m not an ARIA expert. Please, if I’ve made a mistake, let me know!