HTML5, hollow demos and forgetting the basics
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.
I agree with the anonymous author of the provocatively-titled Reckless web development practices are encouraging idiots:
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.
My colleague Karl Dubost wrote 3 rules of thumb for Web development:
- Can I bookmark this information? (stable URIs)
- 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?
We mustn’t forget the basics.
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
37 Responses to “ HTML5, hollow demos and forgetting the basics ”
Here here *raises pint*
Couldn’t agee more.
When is the second edition likely to arrive?
I think it largely depends on the reasoning behind doing The Shiny. I do a lot of work with WebGL which typically has no “reasonable” fallback in any sense, it’s just a means of rendering to the screen and something you’ve mentioned it in passing. In my case I’m attempting to understand the limitations of these newer technologies, and very often JavaScript itself, which occasionally does result in empty divs or a heap of unwieldy JavaScript. Or it may require a newer browser. For that I don’t make any apologies because it’s in doing so I can find out where certain boundaries are. Pushing a browser to its limits is not hollow, it’s just not what you necessarily want people to do. We have speed limits for public roads, but we also have Formula 1 and Demolition Derbys.
With that said, I totally agree that outside of that “lab” setting we need to move beyond flinging a load of divs into a page and having a DHTML redux. We have expressive, semantic markup and a responsibility to ensure that content is delivered in the best way possible.
What we have is a slow? change from the web as interlinked text-based documents to interlinked scripted applications. I rarely see anything like Twitter as far as “it does stuff” but does it right. Anytime any of us mentions how it’s broken here and there and other there too, the developers just roll their eyes and say something about “I supposed you want video to work for stupid Lynx users as well”.
This is a lost cause. Those of us who want information and applications on the web and social connections and e-commerce to be available to as many people as possible, following the hippy Tim Berners-Lee idealism of a free web where hardware and software do not lock people out, are called Nazis and Luddites and are “against the times” and “it’s users’ fault they don’t use the right (browser, plugin, OS… bandwidth mobile plan)”…
I had a second interview at a company recently and when they said “no, sorry”, the reason was that I might consider content, functionality and accessibility more important than someone’s pixel-perfect design, even though I usually feel pretty confident that good developers and good designers can, if they actually feel like it and actually bother themselves, build nice-looking and nice-acting stuff that still works for everyone else. That just never seems to be important to anyone but us web weenies though.
That and I guess looking around at HTML5 stuff lately I’m getting a bit too tired of getting signs telling me I suck hairy balls for not running some webkit nightly as my regular surfing browser.
The future is awesome, for those who can afford it and who accept that they cannot choose their hardware or software. For the rest of us, I dunno. We’ll see.
BTW I wasn’t saying Twitter does stuff right, but that it’s a popular web application that, when it does work for people, those people are quite happy to have it.
<html class=”nojs”> (and in the same vein <noscript>) do little to encourage web sites that work sans-JavaScript.
Glad to see it’s not only me then.
The funny thing is that most of these “tech” demos are pretty cool considering the limitations of the web, but suck balls compared to regular standards. Anyone remember the Spider-Man animation … what crap that was. Even Flash animation looked better, and that’s a pretty low standard right there.
I agree with the sentiment of Bruce’s article, but have to convey the reality that many web developers are pushed to deliver inaccessible features on the websites they build.
The people (clients) doing the pushing have usually seen one of these ‘demos’ or an adaptation thereof while they’ve been browsing the web and want it on their website – NOW.
Despite best attempts to convey the importance of accessibility, or question the business goal or value to users of such a feature, developers often get told to just do it.
And we do, because the people requesting a snazzy new widget be added to their site are paying the bills.
The big gotcha right now is that everything is supposed to be “moving to JavaScript”, and consequently, the push is to have content loaded dynamically through jQuery utilities. This, by its very nature, precludes browsers that don’t support JavaScript, and there is no way to fix that. The only option is an “Oh, you’re one of those users…” page. The alternative, going back to flat pages, makes smartphones and tablets second-class citizens instead of the outdated technologies we support being second-class.
I’m increasingly considering the philosophy that content is provided in modern standards, with a link to flat text. It gets rid of the mudball of backwards code, and discourages people from keeping IE6 for an eleventh year (2.4% of my hits) or NN3 for a sixteenth (3 per month of my hits). The entire reason companies and individuals keep these machines and bad browsers for so long is that we bend over backwards to support them for so long (“it still works”). When IE6 consistently gets nothing better than reading in Notepad, attitudes might change, and if not, then nobody cared enough to put forth the effort to “degrade well” in the first place.
The Web is about content
hmmm….
I had a second interview at a company recently and when they said “no, sorry”, the reason was that I might consider content, functionality and accessibility more important than someone’s pixel-perfect design
Just supposing someone thought of a super cool application for CSS animations and they wrote a web site that required (shock horror) empty divs to achieve it – how would you feel about that ? Sure they maybe should have used canvas, but if they give their div a class of “football” then surely according to the logic that says any markup language where you cannot create your own tags can be “semantic” they haven’t done anything wrong ?
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] up documents and applications, boosting the total number of elements available to us to over 100. Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
This website by adobe must just make you cry: beta.theexpressiveweb.com
I’ve never seen so many hollow divs!
I really agree and got very good experience of HTML5. HTML5, SVG, and CSS3 are really powerful languages for supporting browsers and easy for Web Designer/developers also to make website Search engine and User friendly as well.
What kind of content, that is relative and good information for an audience, would have to use the Canvas element anyway? Wouldn’t using a graphic whether jpeg or gif be more appropriate and certainly bullet-proof as to OS/Browser?
I’m just asking. Seems there is so much ‘digital-loyalty’ (my term) to whatever ones given practices/learned experiences and such are that the confusion as to what tool should be used for what purpose is totally lost before even considered anymore.
[…] Sexy yet hollow demos aside, even the most JavaScript-astic Web 2.0-alicious application will likely have textual content that needs to be marked up sensibly, so let’s look at some of the new elements to make sure that your next project is as semantic as it is interactive. […]
Absolutely right; I saw a ‘should you work for free’ flowchart done along these lines earlier this week, and the markup was a hulk of and elements; there was no meaning of the information retained without the style. Surely, as a web designer/developer, that’s the first priority?