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.
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:
Part of me thinks “yay, cool!”. The other part of me thinks that it’s a shame that some designers still haven’t yet come to terms with the idea that the Web’s not print, and still hanker after pixel-perfect layouts that mimic highly-designed magazines rather than design for a new medium.
CSS Regions are doubtless coming for iPads and other such devices where glossy magazine publishers feel safely DRM’d away from the nasty open Web, so we might as well get used to them.
At the moment, the regions have to be manually expressed as a series of points, but it’s easy to imagine some sort of CMS that allows the page author to upload a page’s background image which is then overlaid with a canvas/ SVG-based app that allows the user to trace arbitrary paths on the image (like Photoshop’s lasso tools) or choose primitive shapes such as circles, rectangles etc, and then the paths can be exported as CSS declarations.
Another useful feature that people have suggested would be the ability to tell the browser via CSS to wrap text using the alpha channel of an image so you wouldn’t need manually to define paths.
I’m looking forward to debugging pages laid out in a combination of floats, absolute positioning, grid layout, template layout, flex-box, CSS tables, multicolumns, regions and exclusions. And I bet you are too.
This will be a really fast-moving talk with tips and code snippets you can use right away. We’ll cover
mobile web philosophy: what is “mobile web”?
The three methodologies for mobile web development
Tips and tricks (code) to make your site faster on mobile
Apps vs Web and how the boundary is blurring
What’s coming soon, with hopefully a preview of what’s cooking in Opera Labs
I doubt many people will be there—it’s pretty late in the day, but do come along if you can. Otherwise, please come and say hi at the Opera booth in the trade show; there will be a giant red O suspended from the ceiling, so you can’t miss us.
with the empty <div>s being used to hold the top half of an image of some rounded corners. The page’s document landmarks needed rounded corners, and my friend was using images rather than CSS3 border-radius so it would work in IE<9.
Her problem was lining up the top half of the background effect with the bottom half, as they’re behind two separate elements and browsers have inconsistent browser stylesheets. So to get it to line up she was going to reset loads of elements and potentially resort to CSS hacks.
The trouble with this is that you’re then building hacks on top of hacks. Using completely empty <div>s for presentational purposes is already hacky, and it means that Opera, Firefox, Safari, Chrome and IE9 get markup and images they don’t need, as they could just use border-radius.
It might seem obvious, and the “build for good browsers, then hack for bad browsers” methodology has been around for a while, but let me gently remind you: don’t penalise the good guys. In Web design, unlike the real world, the polluter pays.
So, my friend should have designed her site with no extra unsemantic thingummies, and used border-radius to achieve her design effect. (If she were using more experimental CSS3 properties, she’d neeed a cross-browser future-proof vendor-prefix stack.)
Once this is tested and lovely in Opera, Firefox, Safari, Chrome and IE9, she can add one line into her CSS, courtesy of CSS3Pie, and her CSS rounded corners will work everywhere, but only the naughty browsers download the extra stuff.
This works nicely for CSS. For HTML5 APIs, there are all the HTML5 Polyfills. Sure, there are edge-cases and undetectables, but as a general methodology, the polluter-pays approach will speed up your development and leave you with clearner, less-hacky and therefore more maintainable code.
It’s usually nice to receive feedback. But not always. Before Twitter became so popular an outlet for one’s ephemeral thoughts, I would occasionally receive emails berating me for having the temerity to publish personal blog posts and urging me to return to posting techy stuff. I would always answer these
Dear kindly correspondent, as you may have noticed, my site is not called freewebtips.co.uk, but brucelawson.co.uk – the unique portion of which is my name. This is not a co-incidence; it is because this is a personal site which I pay to register and I pay to host and therefore consider it my personal space upon which I can write personal posts if I so choose. Please do not read them if they offend you.
That seemed to work: I never heard from those people again, anyway.
This morning, someone had taken the trouble to write:
Im just getting into coding as i am myself a Graphic Designer. And i keep seeing your book advertised in most the places im learning from. I was suprised to see (with no offence meant) that your site is not the best looking around. Sorry i know thats probably not your general worry here, but personally i think for someone who seems quite well known you should have a much more attractive site!
When I launched this site in 2003, I was aware that I am graphic-design challenged. Being an old punk rocker, and admiring Jamie Reid‘s punk do-it-yourself aesthetic, I spent as long as two to three hours sticking bits of newspaper to paper and scanning it. In the intervening seven years, I’ve even added the Holy Grail of design, border-radius, and spent days and days reading the HTML5 spec to craft the best markup I could.
Should I now add all the other things that current web design mandates by law: hundreds of empty nested divs upon which to hang transitions, gradients, reflections and transforms that distract from the words, double the rendering time and drain mobile batteries?
Or point out that markup and semantics != visual design?
Trying out my new Ranting Hat, a present from Japan from Nedjma. Please note that rants are just that, and not necessarily eloquent or factual. (And I know that Eric Meyer and Jeffrey Zeldman are not the only two social liberals in the USA; I’ve actually met the other three.)
Oh, and do I have to say that this is a joke, is personal and nothing to do with my lovely employers at Opera? Unfortunately, I probably do.
As someone who is timezone-maths challenged and forever dialling into international conference calls an hour early or an hour late, I greatly appreciated the intuitiveness of the everytimezone iPad app by Amy Hoy (idea & design) and Thomas Fuchs (development).
Additionally, the main CSS was only using -webkit-border-radius and -moz-border-radius, while Opera and IE9 use the naked property name border-radius. (See my Writing cross-browser, future-proof CSS 3 for more on this.)
Adding this to our proof of concept made the application work in Opera. There are differences; Opera doesn’t support CSS Gradients so those don’t show (although an SVG gradient as a CSS background-image would work perfectly well) and a bug means it doesn’t pick up the Futura font. But visual differences are to be expected on the Web; it’s the content that’s king (or, in the case of an application, the functionality).
We sent this to Thomas, and very sportingly he made the code live, so now everytimezone.com works in Opera too. The moral is that it’s pretty easy to make your sites work across all modern browsers and, while you might expect the user to be coming from one specific device, if your app is on the Web (rather than a W3C Widget or some proprietary format like Apple app store) you can expect visitors using other devices, browsers and operating systems.
Of course, it won’t work in IE9, even though it was announced yesterday that IE9 will support canvas, as the browser-sniffing locks out all versions of IE, past and future. That’s the downside to browser-sniffing: it’s completely non-futureproof. If you make a deliberate policy to block a browser, and a future version of that browser is capable of supporting your code, you have to go back and amend your blocking code. If you have hundreds of sites in your portfolio, that’s a massive commitment.
So congratulations s to Thomas and Amy for a lovely little app; I can now dial into conference calls with confidence and punctuality!
Here’s a quick tutorial (actually, rant) that came out of an aside I mentioned when doing my talk for Future of Web Design two weeks ago.
It came about when I was using the IE9 preview to test some sites. I noticed that a site that boasts rounded corners didn’t appear to have them in IE9, even though IE9 allegedly has border-radius support.
“Silly IE9″, I thought.
Wrong. Silly developer.
The difference between a pro developer and a wannabe is that the pro developer makes sites that are cross-browser and, as far as possible, future-proof. By contrast, the wannabe assumes that everyone is the same as him and therefore if the site works on the browsers he uses, that’s enough.
By using only vendor prefixes, the wannabe developer ensures that this nice part of the design will only work on those browsers.
A pro, however, cares about his client so doesn’t leave them with a site that will need changing later. A pro cares enough about his site’s users to give the design to their browser and let it do with it as it will.
Simply by adding the non-prefixed cross-browser version of the property, he can add border-radius support for IE9 now, Opera now and any new browser that comes along in the future:
In the above example, border-radius is pretty mature, so IE and Opera jumped straight to using the standard prefix-less property, but other fancy CSS 3 properties are implemented only with vendor prefixes at the moment. Note I said “at the moment”; in two years’ time, a new browser may consider that feature stable enough to implement without a vendor prefix and, because you’re a pro rather than a wannabe, you want to ensure your code works in 2 years time as well as today.
For maximum compatibility, I advise adding all vendor prefixes (I do it in alphabetical order to help me remember) plus the non-prefixed version.
So here’s a version that future-proofs and cross-browserifies™ CSS3 transforms:
If, for example, IE adds support for the prefixless version, or uses the -webkit- version, you have one line—27 bytes—of redundancy. So what? And now your code works everywhere that has support, today and tomorrow.
And that’s how it should be.