At Google I/O last week, I was hoping to hear Google’s thoughts on responsive images. Every developer I speak to wonders how to send the right image size to browsers, Google is obsessed with performance, Peter Beverloo and Paul Kinlan were explicit in their talk Mobile HTML: The Future of Your Sites that web sites should request the correctly-sized images. But how?
The <picture> element seems to be at an impasse; no-one from Google showed any enthusiasm (nor does any other browser vendor, seemingly). That’s OK; when I dreamed it up 18 months ago it was a strawman to get the conversation going in standards groups (I’d previously been told that there was no need for any standard, as everyone would have huge devices on reliable, fast wifi in the future).
We have the srcset attribute, with its wildly unintutive syntax, “ready for first implementation”, so supported nowhere yet. It also doesn’t satisfy the art direction use case.
Google has proposed a Client Hints header with device resolution, viewport size, touch-enabled flag etc. The idea is that the server generates lots of different sizes of foo.png, and when a request comes for foo.png, the server looks at the Client Hints and sends the most appropriate size. Opera (and soon, Chrome) announces that it accepts webP images, so the server could intercept requests for foo.png and send foo.webp in its place for conforming browsers, thereby reducing bandwidth.
This server-side negotiation will be great for legacy pages as it means source code doesn’t need to be touched. I’ve heard it also touted as being much simpler to author, but I wonder about that; HTML isn’t hard to write, while implementing server-side image resizing and transcoding, intercepting headers, doing the negotiation and setting cache control is much harder for an HTML wrangler than writing HTML is. It also assumes everyone has full access to the server. Don’t forget that some uses of HTML (for example, ebooks) have no server.
But those are all for the future. What can you do now?
Clever, but ultimately unsatisfying workarounds.
Firstly, have <img> with a dummy source, then replace the src with JavaScript once you know the dimensions and resolution of your device. This makes images dependent on JavaScript.
Alternatively, make your images into single-frame <video>s, and take advantage of media queries on the child <source> element to send differently sized images. Ian Devlin dreamed this up, and it’s evil genius – except that file sizes increase and <video> doesn’t have an alt attribute, so the “images” are therefore inaccessible.
A similarly inaccessible technique for webkit browsers is simply to use a <div> element instead of <img> and set an image-set background-image in CSS. Don’t do this; it’s inaccessible, and is single-engine.
The current best way is brilliant albeit somewhat hacky: Estelle Weyl‘s clown car technique. This uses a data-encoded SVG file, embedded using an <object> element. Unfortunately, there’s nowhere to hang alt text, and right-clicking to “save as” doesn’t behave as expected.
So that’s the interim report. Inaccessible and/ or single-engine, or JavaScript-dependant, or relying on server-side shenanigans. Images are central to the web; we need a declarative HTML method to achieve them in our multi-device world.
I’ve done my part in suggesting a strawman, and although cleverer minds than mine tell me it’s a bad solution, in a year and a half no-one has told me what a good one looks like.
Here’s your reading list for the next 2 weeks – I’m off to Google i/o where I’ll be speaking at the “Web Platform Fireside Chat” 3pm (to 3.40pm) on the Friday, Room 5. Come and say hi if you’re going to San Francisco (be sure to wear some flowers in your hair).
Some very meaty stuff this week, so it’ll last you 2 weeks (next week I’m in Las Vegas for Future Insights Live conference – use the discount code “Bruce” to get 10% off the ticket price).
Web Standards
HTML5 VIDEO bytes on iOS Mobile devices by Steve Souders: “Mobile devices ignore all values of PRELOAD in order to avoid high data plan costs, and instead only download the video when the user initiates playback … However, my testing shows that iOS downloads up to 298K of video data, resulting in unexpected costs to users.”
blink-dev: Intent to implement lazy-block layout – “Developers can page in new content while the user is scrolling without fear of making the app slow as well … Our demo has a 4 second layout that’s reduced to 32ms with lazy-block.”
ptb/flexgrid: a flexbox-based CSS grid in 3.6k – “The flexbox layout is supported on Chrome, all versions of iOS, Safari 3+, IE 10+, Opera 12.10+, and Firefox 22+. Other browsers get the fluid Bootstrap 3 layout, except Internet Explorer 6 and 7 which use a fixed layout.”
Testing WebP compression for app icons – “Looking at the ratio of WebP file sizes to PNG file sizes ratio, we can see WebP constantly provides better results”
Stop standardizing HTML says Simon St. Laurent. It’s XML again, but without draconian parsing or schemas. Essentially, every web page has its own private vocabulary.
It’s about time: RuneScape dumps Java for HTML5 – “With more than 200 million RuneScape accounts and thousands online at the same time, RuneScape is a big reason for a lot of people not to uninstall Java”
jQuery 2.0 Released – “leaves behind the older Internet Explorer 6, 7, and 8 browsers”. I wonder if this, and Windows XP in its last year of Microsoft support, will give devs/ biz “permission” to stop supporting older browsers?
I Stand With Trolls – “I’m calling out our culture of blaming the employer for the mouthiness of their employees in a personal capacity … We’ll end up with a Twitter full of teen-agers talking about their bowel movements and a million carefully curated corporate accounts.
The <hgroup> elements is removed from HTML 5.1. It was defined as “typically used to group a set of one or more h1-h6 elements — to group, for example, a section title and an accompanying subtitle.”
I shan’t be sad to see it go; in November 2010, I argued that it was too hard to grasp; if you want to indicate that something is a subtitle or tagline, you want to indicate that on the tagline itself, rather than on an element that groups a tagline and non-taglines.
More recently, Alex Russell and I had a conversation in which he argued that elements without a UI are likely to fail (more of that from him, later). I think he’s right in this case; <hgroup> is used solely to preserve the outlining algorithm which itself is esoteric.
So how do you now mark up taglines and subheaders? Simply: as you always have. The spec now discusses this in the Common idioms without dedicated elements section.
Three methods are suggested. The simplest is simply with punctuation:
<h1>The Lord of the Rings: The Two Towers</h1>
The second is by using a <span> inside a heading element that allows you to style the secondary part, for example with h1 span {display:block; font-style:italic;}:
<h1>The Mothers
<span>Fillmore East - June 1971</span>
</h1>
The third (and the one I use, because a tagline doesn’t feel like a heading to me, but does belong with one in the <header>):
<header>
<h1>The Mothers</h1>
<p>Fillmore East - June 1971</p>
</header>
Expect HTML5 Editor Steve Faulkner to blog about this for HTML5 Doctor when the jet-setting roister-doister returns back to Blighty next week.
Element Queries – “like a Media Query (specifically, the min-width/etc queries), but for a parent or ancestor element, rather than the viewport” by Tab Atkins
HTML5 vs. Native vs. Hybrid. Global developer survey 2013 interesting stats, however, note comment: “surveyed individuals were (mostly? I am one of them) Telerik customers including Kendo UI customers might have leaned the results towards Windows and HTML 5?”
The web platform has advanced out of all recognition, and continues to evolve at a frankly bewildering pace (I’m paid to keep track of all this stuff, and if I take a fortnight’s holiday I scramble to get back on top of it).
Four years ago, if you wanted to access your device’s GPS information, you pretty much had to use a native app; now, the W3C Geolocation API is available in all browsers, on most classes of devices.
The advancement of what marketing and the press like to call “HTML5″ (but mostly isn’t just HTML5) is closing the gap between the capabilities of native and web. But it isn’t there yet.
In 2011, Joe Hewitt (original Firebug developer and Facebook person) wrote a great blog post called Web Technologies Need an Owner, which I quote here but is worth reading in its entirety:
The arrogance of Web evangelists is staggering. They take for granted that the Web will always be popular regardless of whether it is technologically competitive with other platforms. They place ideology above relevance. Haven’t they noticed that the world of software is ablaze with new ideas and a growing number of those ideas are flat out impossible to build on the Web? I can easily see a world in which Web usage falls to insignificant levels compared to Android, iOS, and Windows, and becomes a footnote in history. That thing we used to use in the early days of the Internet.
My prediction is that, unless the leadership vacuum is filled, the Web is going to retreat back to its origins as a network of hyperlinked documents. The Web will be just another app that you use when you want to find some information, like Wikipedia, but it will no longer be your primary window. The Web will no longer be the place for social networks, games, forums, photo sharing, music players, video players, word processors, calendaring, or anything interactive. Newspapers and blogs will be replaced by Facebook and Twitter and you will access them only through native apps. HTTP will live on as the data backbone used by native applications, but it will no longer serve those applications through HTML. Freedom of information may be restricted to whatever our information overlords see fit to feature on their App Market Stores.
I disagree with Hewitt’s suggested remedy – that there should be one rendering engine with “competent, sympathetic, benevolent leaders” and therefore no standardisation forum – but I share his worry. I want web to win.
I’ve been musing on what’s still missing from the web platform to make it more attractive to developers, and asked for people’s reasons why they chose native app development which I recorded in a gist.
Hardware access is being looked at by the W3C sysapps group, which is working on things like Bluetooth API, Calendar API, Device Capabilities API, Network Interface API, System Settings API.
Camera access (and microphone) is handled by WebRTC, implemented in Chrome and Firefox. Presto-based Opera allows access to the camera with the getUserMedia API (a subset of WebRTC).
A Notifications API exists, but it’s not implemented anywhere as it’s incomplete I’m a liar; Web Notifications is supported by Chrome. (Correction courtesy of @simevidas) However, the spec only allows native-style notifications to show while the user has the relevant page open.
Offline working is very important – we see that in developing countries, web sites offering Java apps are very popular because of games that can be played offline. Although the current Application Cache is good enough for simple offlinerification, it isn’t powerful enough for industrial use. Jonas Sicking of Mozilla has a proposal to improve appcache.
One spec that also needs a mention here is the badly-named Indie UI spec. I assumed it was about User Interface and was therefore bound to fail (who would take seriously an attempt to standardise UI?) but it’s actually about User Interface Independence, abstracting away the “how” a user attempts to scroll (scrollwheel? swipe? pen? joystick? keyboard down-arrow?) from their intention. It’s like W3C Pointer Events taken further:
Independent User Interface (IndieUI) is a way for user actions to be communicated to web applications… IndieUI will allow web application developers to get these events from different devices without having to recognize how the user performed the action. With IndieUI, AT will have a simple set of events to control web applications, and web application developers will have a uniform way to design applications that work for multiple devices and contexts.
The adequacy of the Web platform depends on what kind of apps you’re making. The UK Government Digital Service recently cheered my cold, cynical heart by saying
Our position is that native apps are rarely justified … Stand-alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office … For government services, we believe the benefits of developing and maintaining apps will very rarely justify their costs.
When it comes to mobile, we’re backing open web standards (HTML5). We’re confident that for government services, the mobile web is a winner, both from a user and a cost perspective.
Apps may be transforming gaming and social media, but for utility public services, the ‘making your website adapt really effectively to a range of devices’ approach is currently the better strategy. It allows you to iterate your services much more quickly, minimises any market impact and is far cheaper to support.
This is about informational or transactional apps, rather than super high-performance games or heavily media-centric apps. But the latter aren’t the majority, even if they are higher-profile – according to yesterday’s HTML5 vs. Native vs. Hybrid. Global developer survey 2013. (Beware reading too much into this survey, as it’s commissioned by a Microsoft-centric company, so the respondants may have different perspectives than other app developers.)
Games developers benefit from the huge performance increases in JIT JavaScript engines, WebGL and Mozilla’s asm.js project looks very interesting. Whether this is enough, I don’t know; I neither write games or even play them. (Disclosure: Opera has a game engine product called Sphinx that I’ll talk about soon.)
Monetisation feels like a big deal to me. The Mozilla guys have an API called navigator.mozPay() but as far as I can tell this is only for Firefox OS and not the open web, so not relevant to this discussion at the moment. Hopefully, it will feed into the W3C Headlights project, which has identified Web Payments, HTML5 Performance and “Closing the Gap with Native” as areas for urgent study.
It seems to me that if reach is your goal, the Web Platform is your better choice – it works in lots of places. If getting paid for your app is your goal then currently native or hybrid development is your better strategy. We need to stop looking queasy when people want to get paid, too; free stuff isn’t an inalienable human right.
What can you do if you want the web to win? Use it, and nurture it. If you’re prepared to spend hours debatingwhetherrebase or squash is considered harmful (and you should, because using tools well is the mark of a professional), then be prepared to spend 41 minutes considering whether your markup makes sense – the code that the browser runs is your product. As Confucius would undoubtedly have said, “Don’t just be on the web, be of the web”.
Hassle me, and other representatives of browser companies to get new standards agreed, and implemented. Vendor co-operation, clueful devs, Device APIs, open Operating Systems that don’t lock users into one browser, and (crucially) auto-updating browsers are the cornerstones of an open web.
(Added Friday 12 April: .net magazine interviewed me after reading this, where I reiterate and elaborate some of my points.)
Inspired by the excellent Thatcher for One Direction fans, here’s my guide to Open Web Standards for fans of the finest band since .. like, ever!
Interoperability
Imagine that you and your bezzies save up and buy a brand new guitar for Niall. You write to the fan club, and they send you VIP tix for a gig and ask you to present it to Niall on stage for him to play it at the encore! Swoonsville.
You give it to him, on stage in front of thousands of jealous fans; he hugs each of you to say thanks (and his lips brush your cheek when he whispers his gratitude!) and then – OMG! disaster!! – the standard jack plug that every other guitar uses won’t fit in the one you’ve bought him. He shrugs, puts your guitar down, picks up his old one and all the audience laugh at you in a totally bitchy way!
Horrible, I know. Why didn’t the standard lead fit into your guitar – rubbish! Web standards are standard ways for different parts of the web to fit together, so web sites from Microsoft and Google play just as well in browsers from Opera and Firefox as they do in browsers from Microsoft and Google, YGM?
HTML5 vs XHTML2
So, imagine that Simon Cowell wants to get a new member of the band in. Impossible to improve on total perfection, I know, but this is, like, imagination, yeah?
So what would he do? He can’t sack one of the boys … so he gets a 6th member in! And it’s George from Union J! Perfectomundo! And that’s like HTML5: it just improves on what went before, without losing anything!
Now, imagine that instead of getting George in as well, Simon sacks Louis and Zayn and gets in Nathan and Jay from The Wanted instead. The magic’s gone. That’s what XHTML2 tried to do – it wanted to improve the web, yet breaking what we love while it did it. That’s why Tim Berners-Lee (he’s like Simon Cowell, for the web) called XHTML2 “a total barfmare” and told all those guys to get real!
So we love HTML5: the initials even stand for “Harry, Three Men, Liam” – and there are five of them! HTML5 FTW, LOL!
No plugins
Imagine Harry sends you an advance CD of the next album (to make up for the guitar disappointment). But when you listen to it, there’s no singing – just the music! There’s some loose electronic stuff in the envelope and a note (written by Haz himself, sigh!) saying “to hear the vocals, just install these chips into your CD player”. But you can’t – there’s nowhere to add them, and they might break your CD player when they’re added, anyway.
That’s what plugins are like – extra stuff to add to your web browser. Open web standards want the browser to be able to deal with all the content without having to muck about with extra stuff, so you can listen to the dreamy sounds of the boys’ new songs anywhere you can surf the web!
Open web standards: that’s what makes them beautiful!
Open collaboration
OK, we all know that “Live While We’re Young” is the finest song ever written – except for all the other ones the boys recorded, natch! But if every song sounded the same as that it would quickly get boring, right? So what Simon and the boys do is get new writers in, to bounce ideas around, mix it all up, and make sure that there are constant new ideas so the boys stay the best band in the universe.
And that’s open collaboration does for the Web – keeps it fresh, shakes it up, and ensures there’s something for everyone. That’s why we say to open web standards: it’s Gotta Be You, One Way Or Another!
DRM
DRM stands for Digital Rights Management. Imagine that you find a DVD on eBay of the best performances on the American leg of the Take Me Home Tour. None of your m8s even knew that this DVD existed (some fans they are!) You wait for ages for it to be shipped from the states, and all gather round your DVD player at home, to find … the DVD flashes the message “wrong region” and won’t play at all!
Just imagine if DVDs were artificially locked to certain regions … oh.
I gratefully acknowledge the help of my 14 year old daughter for her insights into the world of One Direction. Even though she like totally hates them.
As you probably know, Google announced Blink, the new rendering engine that will power Opera and Chrome, forked from WebKit (which itself was forked from KHTML).
Thoughts on Blink – “WebKit wasn’t a love fest of like-minded engineers but 2 lions circling each other, always prepared for the battle” by Krzysztof Kowalczyk, an early contributor to WebKit
asm.js is a cool initiative from Mozilla. It’s a subset of JavaScript that will behave identically whether it is run in an existing JavaScript engine or an ahead-of-time (AOT) compiling engine
Nintendo Web Framework “is a development environment based on WebKit technologies, supporting application development on the Wii U system using HTML5, JavaScript, and CSS.”
Responsive Retrofitting – “finding a way to use responsive techniques on legacy sites to create a better experience for more users”
Industry
Introducing Tabula – “Upload a PDF, get back tabular CSV data.” Another cool Mozilla initiative.
Forty mobile phone facts – “every fifth person you meet has two phones and is probably a crystal meth dealer/having an affair.” Or is a developer.
It’s great to be able to talk publicly about Blink, the new engine that will power Opera’s browsers (disclosure: my employer, but this is a personal post) and Chrome henceforth. I know a lot of people worried that there would be less diversity on the Web once Opera Presto was retired, and the forking of WebKit into Blink restores that balance. Opera will be contributing to Blink in future.
[added 22:46 UK time] My boss, Lars Erik Bolstad, said on Opera’s behalf: “Our ambition is to contribute Opera’s browser engine expertise to Blink, ranging from the implementation of new web standards to improvements in existing code.”
My personal feeling (not representing my employer, wife, children or hamster) is that Blink has a lot of promise for the Web. Its architecture allows for greater speed – something that Opera and Google have long focused on. When browsers are fast and interoperable, using the web as a platform becomes more competitive against native app development. I also hope that it’s easier for smaller players and even individuals to contribute to the new rendering engine, with a more transparent gatekeeping process: “Our goal is for anyone to be able to participate, regardless of organizational affiliation.”
It’s also great that there will be no more vendor prefixes in Blink (only legacy ones inherited from WebKit that will be removed or dropped where possible). Vendor prefixes were like Morrissey’s solo career: on paper, a good idea – but in reality, a horrible mess.
So, hello Blink. With Presto remaining in the wild until 2020, and Firefox’s co-incidental announcement today that it’s collaborating with Samsung on two early stage projects to build a new rendering engine called Servo, diversity on the Web has never looked healthier, and interoperability never (er) interoperabler.
