All the cool kids are doing responsive design, it seems. This means fluid designs, having some hot media query action to reformat your layout depending on screen size, and ensuring your images are flexible so they don’t break out of container, generally by setting them to {max-width:100%;}.
Having images scaling down presents a problem though, if you’re a performance-minded sort of chap(ette). Why send a 300K 400 x 800 image that would look lovely on tablet device attached to wifi, but which takes ages to download on a 3G phone, and which gets resized by the browser to fit a 320px wide screen? Not only are you wasting your user’s bandwidth and time, but not every browser is created equal and not every resize algorithm makes pleasing end results. The CSS 4(!) image-rendering property can help with this but it only hints to the browser.
Sending the right-sized image to devices without wasting bandwidth is one of the knottiest problems in cross-device and responsive design at the moment. In the 24ways advent calendar series of articles, the subject has been discussed twice in eight articles (by Matt Wilcox and Jake Archibald). There are numerous other techniques, as well, such as tinySrc and the Filament Group’s Responsive Images.
All these are very clever, different solutions to solve the same problem, and they all rely on scripts, or cookies, or server-side cleverness or (in the case of Jake’s ideas) dirty hacks and spacer GIFs. I’m reminded of Image Replacement techniques from more than 6 years ago, which were over-engineered solutions to the problem better solved by CSS web fonts.
Let’s recap. We have several images, of different sizes, and want to send only the most appropriately-sized image to the browser. The circumstances differ. The canonical use case is to send smaller, lower-resolution images to smaller screen-sizes on the assumption that connection speed is slow and they have low-resolution displays. This isn’t the case, though. Some people are using retina displays on fast wifi networks. SO, while currently CSS Media Queries allow us to detect screen width and pixel density, we need new media features such as network speed/ bandwidth.
The DAP is working on a Network Information API, there’s a Phonegap version for native apps, and a Modernizr detect, but using script for this seems much harder than being able to access it via Media Queries, and if you just want to rearrange CSS layout, CSS is the place to detect it. (Purists may argue that network connection isn’t a characteristic of device, but in your face, purists!)
Once you have a media query, you can swap images in and out using the CSS content property:
<img id=thingy src=picture.png alt="a mankini">
…
@media all and (max-width:600px) {
#thingy {content: url(medium-res.png);}
}
@media all and (max-width:320px) {
#thingy {content: url(low-res.png);}
}
@media all and (network-speed:3g) {
#thingy {content: attr(alt);}
}
A browser that doesn’t support Media Queries, or doesn’t report “true” for any of the Media Queries shows the picture.png, which is the src of the img. A browser that is less than 600px replaces picture.png with medium-res.png. A 320px or narrower browser replaces picture.png with low-res.png. A browser that is only connected via 3g replaces the image with its alt text.
I first researched this technique in 2008 as a way of doing image replacement without extra markup (ironically enough). The first two media queries only works in Opera and Chrome at the moment, as they’re the only browsers that fully support content without :before or :after. (The network-speed media query works nowhere as I just made it up).
Recently, Nicolas Gallagher experimented with generated content for responsive images, and unfortunately discovered that there are no advantages to the technique because browsers always download picture.png, even if they never show it because they immediately replace it. Perhaps this could be optimised away by browsers, but there would still be the double-download problem with current browsers.
My mind turned to HTML5 video. Here we have an element that has the ability to specify multiple sources (because of different codecs) and can also switch sources according to media characteristics. It borrows syntax from Media Queries but puts them in the HTML:
I firmly believe that if something as new-fangled as video can be responsive in a declarative manner (without needing script, APIs, cookies or server magic) then responsive images should be similarly simple.
Previously, on the mailing list, a new <picture> element was proposed. I mashed up that idea with the already-proven video code above and came up with a strawman:
<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="network-speed:3g">
<source src=lores.png>
<!-- fallback for browsers without support -->
<img src=midres.png alt="angry pirate">
</picture>
This would show a different source image for different situations. Old (=current) browsers get the fallback img element. As I said, this is a strawman; it ain’t pretty. But it would work. (It’s discussed in my recent Smashing Magazine article HTML5 Semantics.)
I prefer the media queries to be in the HTML for two reasons: you don’t need to have ids or complex selectors to target a particular image, and (more importantly) many content authors use a CMS and have no ability to edit the CSS. (Although the nasty <style scoped> could solve this.)
On the other hand, I might be over-engineering the whole problem. I chatted informally with my colleague Anne van Kesteren, glamorous Dutch WHATWG inner circle member. There’s a school of thought that says everything will be 300ppi and networks will be fast enough, so this is really an intermediate problem until everyone starts using highres graphics and all displays go from 150 to 300. Standards are long term, and by the time we have a standardised version, the problem might have gone away.
PrefixFree: Break free from CSS prefix hell – Lea’s script parses CSS on the client and adds only the vendor prefixes that the browser requires. A sort of Modernizr for CSS, but note it adds a dependency on JavaScript.
One of the many joys of going to Fronteers 2011 (even more than seeing Jake Archibald in a mankini) was Seb Lee-DeLisle’s presentation “CreativeJS – beauty in the browser”. Watching sexy particle systems, using mobile phones as pixels and playing NyanCatch was fun and exciting.
I’m a JavaScipt n00b, but an old hand at programming, which I taught myself in the 80s by coding visual games like space invaders and lunar lander. So when I heard that Seb was giving a two-day workshop in Leeds on how to code creative visual effects and games, I decided to go along.
Seb didn’t start at the very beginning; it’s assumed that we have a text editor, a web inspector (I was using Opera Dragonfly, of course) and that we know what variables and loops are. There wasn’t much talk of prototyping and inheritance either – the emphasis was on the making rather than the theory.
We looked at canvas, how to make simple shapes and simple animations. Then we used Seb’s simple library to add drag, velocity, gravity and randomness to particles, all the while building pretty effects that responded to the mouse. We learned canvas rotations and transforms (which I hadn’t really bellyfelt before) by making a generated tree (which I topped off with random cherry blossom).
We learned how to code the game Asteroids, with a reminder of trigonometry that shocked me: who knew I’d ever need SOHCAHTOA or the Pythagorean theorem in real life? This also helped us learn how to make natural-seeming physics.
We all had a brief foray in webGL, albeit abstracting away most of the horrors via Mr Doob’s THREE.js.
It was a great fun course. Seb’s an engaging and effective teacher and I feel much more confident with my JavaScript now (I even suggested an optimisation to Seb’s collision detection code!). Thanks to Seb, Clare who co-organised it, and my fellow attendees.
If you’re looking for an “in” to JavaScript, and you learn by mucking about and seeing what comes out the other end, sign up to Seb’s next course.
Yay! The first, the original, the sexiest, the motherflippin’ brownest book on HTML5, Introducing HTML5 is out in second edition!
What’s new?
It’s bigger, baby – having swollen from 223 pages to a tumescent 295 pages – for less than the cover price of the original. Apart from a photo of the snogtabulous uberhunks™ that are its authors on the front cover, and the inner colour changing from orange to blue, what are the highlights?
Errors are corrected and it’s all re-read and updated
It’s been fully re-edited, re-proofed and re-indexed
Bruce has changed his mind about the <nav> element and now advises you don’t use it bloody everywhere
The multimedia chapter has added information on <track>, getUserMedia, webRTC
Even more detail about how to get more out of geolocation
More storage methods and techniques, including the new IndexedDB storage API
We now have full examples on how to use Server Sent Events
Updated detail on offline applications, gotchas and debugging tips
A full new chapter on polyfills, what they are, how they work and how to use them
Updated launch photos?
You bet!
So buy the book already, or we’re coming round your house dressed like this to ask why you haven’t. And don’t forget to join in the fun by sending a photo of you with a copy of the book, doing your O-face, or wearing in mankini for inclusion in the HTML5 gallery of gorgeous guys and groovy gals.
Thanks to Krijn Hoetmer for the mankini. Next time I’m turning the heating on.
If you’re interested in this stuff at all, you’ll probably know this, but for the sake of completeness, the <time> element has returned to HTML5 after it was removed from the specification.
I reserved cheering until in case it was grudgingly returned to the W3C spec but not the WHATWG spec, as I don’t particularly want to see forked specs.
A few weeks ago, I replaced <time> with <data>. We got feedback from many people saying that there were use cases that <data> didn’t handle, and requesting <time> be left in the spec. It turns out what people were asking for was not quite the old <time> element, it was more like a variant of <data> that was specifically for <time>. (The old <time> was specified as doing locale-specific rendering, had a more or less useless API, and only supported a small set of data and time syntaxes.) Tantek made a proposal for how to handle these use cases, which I intend to add to the spec ("the <time> element is dead, long live the <time> element").
It’s with great sadness that I inform you that the HTML5 <time> element has been dropped, and replaced by a more generic – and thus less useful – <data> element. The pubdate attribute has been dropped completely, so there is now no simple way to indicate the publication date of a work.
A way to mark up the publication date/time for an article (e.g. for
conversion to Atom).
C. A way to mark up machine-readable times and dates for use in Microformats or
microdata.
Use cases A and B do not seem to have much traction.
Use case C applies to more than just dates, and the lack of solution for stuff
outside dates and times is being problematic to many communities.
Proposal: we dump use cases A and B, and pivot <time> on use case C, changing
it to <data> and making it like the <abbr> for machine-readable data, primarily
for use by Microformats and HTML’s microdata feature.
While Hixie says it hasn’t had much traction in microformats. Ben Ward, a platform developer at Twitter and microformats admin, says “We’ve had time documented on the wiki HTML5 page for ages, some parsers had experimental support. But <time> wouldn’t be able to progress into being a requirement or even recommendation for Microformats until HTML5 had that status”.
<time> (or its precursor, <date>) has an obvious semantic (easy to learn, easy to read). Because it’s restricted to dates and times, the datetime attribute has a specific syntax that can be checked by a validator. Conversely, <data value=”"> has no such built-in syntax, as it’s for arbitrary lumps of data, so can’t be machine validated. This will lead to more erroneous dates being published. Therefore, the reliability and thus the utility of the information being communicated in machine-readable format diminishes.
The <data> spec says “A script loaded by the page (and thus privy to the page’s internal convention of marking up dates and times using the data element) could scan through the page and look at all the data elements therein to create an index of dates and times.”
This is a retrograde step from the <time> element that uses a wider standard/ convention for dates, such as ISO8601 because now the script must be “privy to the page’s internal convention”.
<data> as an element is for public consumption, eg for crawlers, search engines, microformats/ microdata parsers. Convesely, data-* attributes are private (only for scripts on a page, not external crawlers: “These attributes are not intended for use by software that is independent of the site that uses the attributes.” ). This is highly confusing.
I’ve added these points to a collaborative notepad set up by Eric Eggert, at his request.
But I have little hope that <time> and pubdate will be restored, even though most comments on the bug in which Hixie changed the spec were negative.
But sing along with me in my Cher costume, and we might just change Hixie’s mind.
Added 20:06 Oct 30: The Mighty Steve Faulkner filed a revert request.
Usual disclaimer: personal opinion, written on Sunday night, not Opera, etc etc.
At an HTML Working Groupp meet last night, it was decided to re-instate <time> and even extend it to encompass things I complained in 2009 were lacking — “fuzzy dates” like “1965″ or “February 2008″ and durations.
However, it remains to be seen whether it’ll be reinstated in both the W3C spec and the WHATWG versions or just the W3C. So I’ll delay celebration until then.
Next week saw me jetting off to Amsterdam for Fronteers 2011. This has, I think, become the best conference in Europe; the level of talks is high (the audience has a disproportionate number of working group members, high-profile developers and all-round smart people, never mind the speakers!) and the fact that Fronteers is not allowed to make a profit means that they can keep it cheap. I confess to being a bit nervous for my talk — the topic they gave me of “HTML5 semantics” doesn’t exactly cause your average web developer to moisten his seat with enthusiasm, but it was a single-track conference so I didn’t find myself alone in a hall while eveyone went to hear Lea Verou on gradient sexiness instead.
As well as looking at some of the new semantics, I wonder whether we need more than the current spec allows, then wonder whether semantics matter anyway (tl,dr: yes, they do) and suggest that, if you’re just squirting obfuscated JavaScript down a line with no real semantics, and targetting one single rendering engine, you’re really just reinventing Flash but with the browser as the plugin. This follows some of my recent posts such as Future friendly, or Forward to Yesterday?, HTML5, hollow demos and forgetting the basics and the toe-tappin’ Web Standards Hoedown.
By clever planning, I flew home from Amsterdam on Saturday in order to fly to Norway on Sunday (via Amsterdam). I was there to MC the Frontend conference where the organisers used large stand-up cartoons of me to entice the Oslo ladies in.
Frontend had one of the weirdest conference parties I’ve been to; we sat in an ex-church, drinking red wine and beer and listened to Oslo’s leading Norwegian-language Calypso band.
From the conference, I went by taxi an Opera event for journalists where I was tasked with stopping the journos becoming mutinous or falling into jetlag slumber during a 20 minute bus ride from their hotel to a restaurant. Rather than sing the Web Standards Hoedown without Ukelele or hippie, I was able to finally realise a long-held ambition of doing a completely fictional bus tour. On our way to downtown Oslo, I was therefore able to point out to my increasingly incredulous fellow-travellers the summer palace of King Gustav The Mad, the high school that was long believed to be the only Norwegian building visible from space and the very tree in which John Lennon wrote Norwegian Wood.
A full three days elapsed before I travelled down to Lahndahn to do a guest Q&A talk at a Kazing HTML5 training course (lots of questions about DART, privacy on the Web and Web vs Native) and then the next day, an overview of HTML5 at HTML5 Live where I pissed on a few bonfires by pointing out
HTML5 is nothing to do with mobiles
a website that is ugly and full of nonsensical jargon remains so even if sprinkled with HTML5 fairydust
a site that fulfills an organisational need rather than user need remains a vanity turd even if sprinkled with HTML5 fairydust
Narrowly avoiding a lynch party, I escaped up the M11 with Jake Archibald where we boarded a RyanAir flight to Krakow in Poland to speak at the inaugural Frontrow conference. Poland is super country, and Krakow seems a delightful city from my brief walks around its pretty centre.
I was also thrilled, on learning that it’s pronounced “Crack Off”, to find this mini-guide to the city in my room:
Full marks to Mariusz, Olga and the rest of the organising committee for a really great line-up mixing Polish and foreign speakers. Congratulations to my old chum Patrick Lauke on his first conference keynote The once and future web. I spoke about HTML5 Multimedia to a small group of people at 9 am on the second day (the day after the conference party, which went on til 6 am!).
After an eventful return flight which arrived 4 hours late (and meant at least that RyanAir couldn’t play their stupid arrival fanfare), I spoke at a conference of 148 venture capitalists and other investors organised by UBS – and I wasn’t even wearing cuff-links!
My heart sinks when I see the latest flurry of tweets about some new “HTML5″ demo. As someone else said, it’s usually a warning that you’re about to visit a browser-freezing lump of JavaScript without a hyperlink in sight.
I feel the same way when I see someone draw an image of the IE logo, a map of Paraguay showing every branch of Greggs, or a gyrating representation of Konnie Huq’s spleen using only CSS, because I know that the HTML will be a series of empty <div>s with no content at all.
“But it’s just a demo!” you will protest. True. And demos exist to kick the tyres of a technology, to see what it can do and what its limits are. But people learn from demos. People pick them apart to see how they work, and hack them about. So using fundamentally the wrong technology to achieve an eye-candy result doesn’t help anyone learn.
The biggest danger is when that demo mentality leaks into production websites.
The Web is about content. Sometimes that content is video, but we can ensure a text-based representation exists for older browsers, lower-specced devices, slower bandwidths and – of course – people who can’t consume video. Content on the web should be available to all using progressive enhancement, polyfilling and the provision of text alternatives.
Because these sites are absolutely reliant on JavaScript, or Flash, or a particular browser … in order to display their content, the sites are failing at their job. They’ve taken us back to the early 90s in terms of the maturity of the web. They show an absolute disregard for the building blocks of the web in favour of ‘the shiny’ — a repugnant phrase which reflects the shallowness at the heart of many web workers’ outlook. They are style over content.
This isn’t true 100% of the time; a tiny fraction of the Web is games. Games don’t degrade terribly well to plain text or map to HTML semantics. But the fact that we can script first person shooters in <canvas> rather than Flash isn’t a signal to abandon responsible practices on non-game sites – practices such as choosing the most appropriate element for the job and ensuring that the content is available to those unfortunate peasants who aren’t running Opera.Next, a WebKit nightly or Firefox Aurora on the latest greatest hardware.
Can I go from here to there with a click? (hyperlinks)
Can I save the content locally? (open accessible formats)
It seems to me that there is nothing inherent HTML5 and associated technologies to diminish the relevance of these rules.
In the first edition of Introducing HTML5, Remy and I closed the book with this advice:
Forget the marketing B.S. of “Web 2.0.” We’re at the beginning of Web Development 2.0: powerful languages like HTML5, SVG, and CSS3 will revolutionise the way we build the Web. Browsers support more and more of these aspects of these languages (and you can be certain that more and more support is being added daily).
Of course, have a play with the new features. Experiment with the new markup structures, manipulate video on the fly, and build fun and attractive games and apps that use <canvas>. By reading this book, you’re demonstrating that you’re an early adopter, ahead-of-the-curve, so please set a good example to your colleagues; respect those visitors to your new creations who have older browsers or assistive technologies.
For the second edition (coming soon!) we were worried enough about The Shiny that we’ve augmented it:
It’s vital that we remember that we are dealing with Web development. The Web is based on URLs, hyperlinks and is a method to deliver content. If your amazing demo is basically content-less <div>s being flown around the screen by JavaScript, or if your content is text-as-pixels scripted with <canvas>, if you require a mouse or a touch-screen, or if you have no links, no content or no URLs for bookmarking or linking to, ask yourself: am I developing for the Web, or am I re-inventing DHTML or Flash intros that just happen to run in the browser instead of a plugin?
On 1st August, Adobe unveiled Edge, a preview of a product that does non-Flash animation. The magazine .net asked for my reaction, and I gave them an edited version of these notes below. You shouldn’t take this as any official Opera position, by the way.
I think it’s a good move from Adobe, and one that’s been widely expected for a couple of years now. I’ve been predicating it since the HTML5 hype really went into over-drive.
Now motion graphics are increasingly rendered via the Open Web Stack (HTML, CSS, JavaScript, SVG, WebGL) rather than a single-vendor plug-in, designers will require authoring tools that can help them turn their creativity into code. Adobe make their cash from selling authoring tools, not distributing the Flash Player – so if people want to author non-Flash motion graphics using a designer-friendly IDE, someone will provide that IDE. Adobe have a great track record on making IDEs that designers find user-friendly. Seems like a no-brainer to me.
I describe Edge’s output as “non-Flash motion graphics”, for two reasons.
Firstly, Edge doesn’t seem to compete with Flash; its visual metaphors aren’t those of the Flash authoring tool, and it makes simple animated thingies (banner ads, amusing pictures) rather than game-like experiences that you can interact with, or movies with sounds (the things I I associate with Flash.)
Secondly, there isn’t any “HTML5″ about Edge at all. Many companies’ marketing people have realised that if I call my dog ‘HTML5’, it’s more likely to win Crufts than if I call it ‘CSS3’ or ‘Open Web Standards’. So everything is ‘HTML5’. It’s a shame, but there we are. Adobe are certanly no more guilty of this than Apple, Google or any number of journalists and analysts.
If you look under the hood of Edge, there isn’t even any use of NEWT – CSS transitions or SVG. In short, what Edge produces is simply old-fashioned DHTML – moving meaningless <div>s around with JavaScript.
This isn’t necessarily catastrophic. A banner ad made in DHTML will render on iOS, whereas a banner ad made with Flash won’t, so there is a win there for site owners – and, let’s face it, some people (the group I call the The iPony Club) see the terms “HTML5″ and “iOS” as interchangeable.
More worryingly, Edge produces non-semantic divs and hides textual content in JavaScript. Morena Fiore’s demo animates the word “Why?”, but that text is not in the source code at all. A user without JavaScript simply would not get the textual content at all.
We started with DIVs because we wanted to get something out there quickly that folks could play with. I say we “started” there because Edge will be evolving rapidly – the product is by no means feature complete.
Hopefully we’ll see regular previews with an increase in semantics and optimisating logic whereby those animations that are best done in cross-browser CSS are done there, whereas those best achieved in SVG or canvas are done there. It’s not impossible, and tools like Dreamweaver show that WYSIWYG tools are not incompatible with semantics and good-quality robust code.
It’s early days yet, and it remains to be seen how cross-browser and lightweight the resulting code will be in the final release, but I tentatively declare it a win for the open web stack and a win for designers (and developers like me) who find scripting animations in a text editor keeps them awake at night in a cold sweat.
I’m quite discouraged because the two articles I’ve read tell me that it’s easy, but I’m still stuck (although they are by noted brain-boxes Oli Studholme and Tab Atkins).
Sometimes, an item gives information about a topic that has a global identifier. For example, books can be identified by their ISBN number.
Vocabularies (as identified by the itemtype attribute) can be designed such that items get associated with their global identifier in an unambiguous way by expressing the global identifiers as URLs given in an itemid attribute.
The exact meaning of the URLs given in itemid attributes depends on the vocabulary used.
What actually does this mean? How do I know if a particular vocabulary supports global identifiers for items?
In the spec, some Microdata vocabularies are listed. vCard is one, and the spec says “This vocabulary supports global identifiers for items.” The URL defining the itemtype for vCard doesn’t seem to tell me, and the examples in the spec make no use of itemid.
And, because I understand real examples rather than the theoretical, what’s the practical benefit of itemid?
[example simplified from an example in the spec which says "The "http://vocab.example.net/book" vocabulary in this example would define that the itemid attribute takes a urn: URL pointing to the ISBN of the book."]
over Schema.org’s Book schema (which doesn’t seem to use itemid – in fact, schema.org seems to make no mention of it):
