So, who are you and what do you do related with web standards?
I’m Bruce Lawson, I’m a 44-year-old English guy and I got interested in web standards back in 2001 or 2002, when I was working for a publishing company in Birmingham, in the UK, and I led the team that wrote books on Microsoft Visual Studio and .net technologies. I got interested in web stuff, the publisher published some books on web stuff and that’s about my interest. And, of course, it seemed to me that web standards were obviously the correct methodology for developing a robust web. So I started a blog about it, and gave talks in my private time and then some nice guys from Norway suggested that I might like to turn my hobby into my job, so I joined Opera in 2008, about… three years ago today, actually, thereabout.
I’m quite interested in the process of writing a standard. It must be really really hard. Trying to make everybody happy can’t be easy.
I’ve been on the periphery, if you like, of the standards making. It’s a job for people with four times as much brain as I’ve got and 355 times the amount of patience that I have. Something like HTML5, which has been, in one form or another on the boil since 2004… There are many people saying, you know, ‘Oh my god, it’s taking too long’, a lot of people are saying ‘the standard, it’s too fast’, and that’s been happening for 7 years.
If you’re just dreaming up a brand new standard, like XHTML 2 was, for example, it is, I imagine, easier, because you just invent what you want to invent and surround yourself with a group of people who are likeminded, and off you go. But with something like HTML5, and something like CSS, the stuff that we all use and… With the CSS Working Group what they’ve been doing with CSS 2.1 is retrospectively standardizing stuff that actually works. And HTML5 is that, magnified so many times: retrospectively standardizing all the browser behaviours that were there, even if they contradicted a previous standard; retrospectively standardizing all the interoperable behaviours that were never standardized. Things like XMLHttpRequest, as far as we can tell, nobody had ever written down how it works, it was just reverse engineered time and time again.
So this kind of stuff is… I can’t imagine the patience and the brainpower that people behind it need. It’s a dirty, dirty process, I think. It comes from optimism and wanting to make the world a better place, but I imagine most of it is dirty and political, but that’s just my outsider’s perspective, and I don’t represent Opera in any form, I just represent myself and web developers like myself or like I used to be.
And one of the things that comes as a result of that dirty process is that nobody is going to love the standard, even if most of us agree that HTML5 is a big step forward. There’s going to be things like Opera looking at ids and classes that are used on the web and Google doing the same thing and coming up with different results, and that leading to disagreement, for example, over some of the new semantic elements in HTML5, right? (Ed: For the curious, Opera’s analysis is at http://dev.opera.com/articles/view/mama/ and Google’s at https://code.google.com/webstats/.)
The strengths of something like HTML5 are that everybody likes a lot of it, because it already works in browsers. It means, however, that everybody has to compromise. There are certain things in the language which I think are horrible and ugly. To me, things like the way the time element is specified, the way the cite element is specified… Remy Sharp, my co-author in Introducing HTML5, I know that he thinks the way that the drag and drop API is specified is horrendous… But the thing is that you can live with the stuff you don’t like, because we all know that everybody has stuff they don’t like. The potential, if everybody holds their noses and continues walking forward is huge.
So yes, in any massive endeavour, with five browser manufacturers all working together, when historically that’s, shall we say, not necessarily how they’ve always worked, there are going to be weirdnesses, but the weirdnesses are outweighed by the huge advantages.
There is some hype surrounding HTML5, with a lot of people claiming quite outlandish things, like Microsoft using the phrase ‘native HTML5’ to promote Internet Explorer, or quite a few demos out there that works with just one browser, or just one browser engine. I think what we are seeing is, to a much lesser degree, quite a lot of the mistakes that we were making in 2001, and even a few of those that were made around Flash…
Yes, I agree with you. There’s a sense of contradiction. It isn’t a contradiction, but people could see a contradiction in the fact that the browser manufacturers are all working together on this interoperable spec. So, for example, my wife: I think she uses IE6 at work, she uses Safari on her iPhone and she uses Opera on the home computer. It’s ridiculous, in 2011, that a website should work on one or two of those browsers but not on the others. So we’re all working together to make all browsers run all websites. But, of course, to the marketing departments of those organizations it feels like a contradiction, because if everything works everywhere, what is the difference between the browsers? And that’s why, I think, we’re seeing nonsense like perfectly valid HTML demos that sniff for a certain browser user agent string and tell you off if you’re not using it, even when, with a little clever feature detection, you could make it work everywhere.
Contradictions like ‘native HTML5’ being used by marketeers, that’s why we’re seeing them, I think there’s a panic about ‘how do we make a browser appear different’. The obvious answer is, of course, like with any other software, you compete on features. So, if you particularly like the fact that Opera has a really low memory footprint, works on lots of different devices and has lots of stuff built in, you use Opera. If you really really like the fact that you have umpty-squillion extensions, you use Firefox. So, coming back to your question, there are these mistakes, but they are mistakes being made by naïve marketeers, I think. And of course there are people who aren’t naïve but who see a bandwagon, and when they see a bandwagon they see an opportunity to, either make some money with SEO or make some money through link bait articles, and suddenly anything remotely a novelty that you can do with a browser becomes HTML5. I see a lot of people tweeting me or emailing me and saying “please talk about my HTML5 website” and I look and maybe, just maybe, there’s an HTML5 doctype, but often there’s an XHTML 1 doctype, and there might a canvas, but quite often it is just good old-fashioned 1999 DHTML and JavaScript moving divs around, doing some animation… There will always be people who don’t understand the names and technologies and their usage. It is just one of those things and I don’t think we should do anything more severe than nuking those people from orbit.
I believe you have a strong interest in accessibility. To illustrate how much we still have to do on the field, there’s this article I read on how most assistive technologies still don’t know that in HTML5 you can have multiple h1’s at different levels and, thus, are reading all those headers at the same level when they shouldn’t.
Accessibilty is vital, and that’s how I started my web standards career, if you like. The thing with assistive technologies is, most of them, things like screen readers, things like screen magnifiers, if you aren’t blind but need the screen blown up to giant size, most of these things live on top of browsers, they’re like plug-ins to browsers. So the reason that most screen readers don’t know that you can have multiple h1’s and then have a logic hierarchy depending on nesting is because the browsers they sit on don’t know that. So you can’t necessarily blame the assistive technology there. However, it is the case that in 2008, I think, I wrote to the W3C and asked them to invite assistive technology vendors to participate in the HTML working group. The W3C wrote back and said ‘well, you know, anybody can participate’, and I said ‘yeah, I know, but these guys represent a particularly vulnerable community, so let’s write and invite them’, and they did, and… most of the assistive technology vendors declined to participate.
We know there’s a really good assistive technology screen reader, called NDVA, from ndva-project.org that, as far as I cant tell, is literally made by two blind guys in Australia, on donations from big companies, and they do a really good job of understanding some of the latest technologies. And of course RNIB are very active on the HTML5 working group, and of course Apple have the VoiceOver screen reader, which ships with every Mac and iDevice. So it’s not the case that always technology vendors have their head in the sand. And of course, at some point, customers of those technologies are going to be judging the products they use, and when two of them are really well up with the latest technologies and the other ones aren’t, I can only imagine which way the most tech savvy customers will go, where they will put their money. That’s how the market would solve these things, there is no technological solution, I don’t think.
Generally HTML5 is a step up from previous versions with accessibility, because it’s been built with accessibility in mind from the start, the same way it’s been built with security in mind from the start. I always say that, given that most developers, well, many, not most, can’t manage to put an alt text on images, the more complex ways of marking things up don’t get done, and so HTML5 tries to build the means into the language, if you like. And, also, built-in always beats bolt on, because if you rely on somebody to bolt something on, they almost certainly won’t, while if it’s built-in they’ll get comfortable doing it.
And then there’s the fact that AJAX has made the task much harder for the assistive technologies. What’s your stand on WAI-ARIA?
ARIA is deliberately designed to clog the holes in older technologies. So, instead of rewriting your pages in HTML5, really ancient pages, or pages generated by horrible JavaScript… it could very well be easier to add some WAI-ARIA band-aids than completely change your mark-up.
A lot of the things that ARIA is used for go away in HTML5. So, for example, in ARIA you can say role=navigation to say this div, or this lump of content, is a navigation menu. In HTML5, of course, you would just say <nav>, and that carries with it, or will carry with it, when the technologies are actually implemented, an implied ARIA role, so you won’t need to add role=navigation to new content. But if you’re retrofitting old stuff and you’ve got a div, or it might be a table, or a table inside a table, or it might be a table inside an iframe inside a table… rather than to refactor it you might find it easier to just write role=navigation on the existing horror.
So ARIA is really good, the trouble is it’s a complex spec. I’ve read it a couple times and I’ve found it quite difficult to wrap my head around. On the other hand, I’ve found HTML5 incredibly difficult to wrap my head around by reading the specification. It’s one of those things where you have to jump in and do it.
The good thing with ARIA is, actually a lot of it is for dynamic websites, so instead of you adding the mark-up by hand, a lot of the new JavaScript libraries have WAI-ARIA built-in. So, I believe (and I haven’t tested this in the last twelve months) something like Dojo, for example, has very good ARIA support, so if you’re using a Dojo widget you don’t need to worry, because by bringing in the library, you’re bringing ARIA support. And, like I said, built-in always beats bolt-on, and yes, somebody else has done the work so you, as a developer, don’t need to add anything.
With HTML5 —not in every case, but in many cases—, it’s actually built-in to the language. But not all of ARIA goes away, because HTML5 is a general mark-up language, it’s not for every situation, so there will be times when you need to enhance accessibility with a bit of ARIA. The obvious example is when you make use of AJAX to pull in a little bit of content that tells you “you’ve got a new piece of e-mail, do you want to go ahead and read it”. You may or may not be using a div, you may or may not be using an output element, if you’re working with HTML5, but in any case you would just use an ARIA role indicating this is a live region, so screen readers listen for it. It’s easily done and validates in HTML5, as well.
Beyond the Opera Web Standards Curriculum, and taking into account things are changing daily, what are the learning resources you would recommend to our readers if they want to be state of the art?
If they want to be state of the art, be aware of the fact that what is the state of the art today may very well prove to have been a wrong turn in a short time. I remember, for example, following all the image replacement methods there were in 2003 and 2004, and everybody was very excited by the initial image replacement mechanism which did display:none on the content and showed a background image, until somebody pointed out that screen readers, when given display:none in the CSS, don’t announce the content so, therefore, it’s inaccessible. I suppose my message is, if you want to be state of the art, if you want lo live life on the bleeding edge, you have to stay there. Because, otherwise, what you might find as you get off the bleeding edge train is that the technique that you continue to use for the next few years might actually have been proven to be faulty…
There are some very good resources that I recommend. A List Apart is always a great resource. Sometimes the articles are a bit too business or designy for my taste, but tastes vary. You often get good conversations on the Sitepoint blogs. I recommend the Web Standards Group (webstandardsgroup.org), from Australia, a guy called Russ Weakley has a really good once a week e-mail in which he wraps up lots of good news and links. Also, there’s a lady called Laura Carlson, who works at the University of Minnesota Duluth, every week Laura sends out a ‘web developments’ mail, which is just a list of all the exciting conversations and talks (http://www.d.umn.edu/itss/training/online/webdesign/). If you want to stay current with web accessibility, a really good mailing list and a really good blog is WebAIM, which comes out of Utah State University. A really good friend of mine, called Jared Smith, does that.
And I thoroughly advise that your readers stay a good deal away from w3schools (Ed: There’s a good resource about w3schools at http://w3fools.org).
And HTML5Doctor.com?
Well, of course, of course… I’m being British, I’m very hesitant to publicize my own sites, but yes, HTML5 Doctor is a good resource to keep up with, and once in a while we answer questions that are sent to us by email, and we publish the results. Also, from time to time I publish something on my website, called ‘reading list’, which is basically all the links that I tweet (Ed: from @brucel): I realize that a lot of corporate users don’t have access to Twitter, and so never see those links, and so…
And finally, where do you see Opera in the future with all of this? For the last few months you, Patrick Lauke and Chris Mills, at least, have been publishing lots of great stuff, I hope you’ll keep on doing that…
Well, Opera’s been growing, and growing and growing… I think when I joined Opera, which was three years ago, we were coming up to a hundred million users. Last time I looked, which was a while ago, we were at over 170 million, and now, today, with the release of 11.5, I see we’re at two hundred million active users, and that’s not downloads: that’s people who actually use the browser in any given month. So, with the little browser that people unfortunately tend to forget about, we’re the biggest mobile browser and we’re growing phenomenally. I always like to remind I’m committed to interoperability and I’m committed to choice. We know nobody loves everything, we know that this person might not like Opera, this person might love Chome, this person might like Firefox. All we ask that (a) you try it and (b) no matter which browser you use as your primary web browser, as a web developer you’ve got a responsibility to have at least five browser icons in your dock. And if you are not testing in multiple browsers, you are not a web developer, you are a single platform developer.
There are great tools for testing everywhere. I know that IE can be difficult, because you can’t run versions of it side by side. With Opera I know that a lot of people have great difficulty in testing mobile phones, which is an area where we are traditionally very strong, because, of course, you’ve got to get hold of the device, and it might be a private website, or it might be a preproduction website… If you search for the Opera mobile emulator, it’s a misnamed product, really, because it’s not an emulator, it’s exactly the same code as the mobile phone browser, but it’s wrapped up with an installable package on PC, Mac and Linux, and it exactly mimics the code on the phone so you can test out your mobile sites on your desktop machine, which is really really useful, it saves you from having to have a complex setup… And the Selenium project has an Opera driver which allows you to automatically tests websites, which is really important.
And your Developer Tools, which are excellent…
Of course. Opera Dragonfly, which allows you to do remote testing and remote debugging. Yes: try all these things, I would love it if Opera became your main browser of choice, but if doesn’t, you still need to test in Opera, and Chrome, and Safari, and Firefox and Internet Explorer, because the web has to work everywhere.
…or it should, at least. Well, I think we’ve stolen enough of your time. Thank you, it’s been a pleasure and a very interesting interview.
Thank you, it’s been delightful.
Recommended citation: CÓRCOLES, César. Bruce Lawson (English version). Mosaic [online article], July 2011, no. 89. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n89.1138.