Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm Jen Simmons and this is episode 74. I want to first thank today's sponsors, the Velocity Conference and Media Temple, and then I want to introduce our guest today, Bruce Lawson. Hello, Bruce Lawson.

Bruce

Hello, Jen Simmons. Hello, dear listeners, wherever you are and whoever you are.

Jen

I have to say, it scares me a little to say "Bruce Lawson." [Laughs] Because you're, like, one of these awesome people, way up on a pedestal for me.

Bruce

I think you're thinking of a different Bruce Lawson, Jen.

Jen

Of course, that's what we all say, the obligatory, "No, no, no, no." But it's true. I just got to meet you finally a few weeks ago when I was in London, very briefly. But before that, you're this person who wrote this amazing book called "Introducing HTML5," that you wrote with Remy Sharp. I beat it up. My copy's all torn up because I used it so many times.

Bruce

Well, don't worry, because at some point Remy and I are going to put it all on the web, when we get around to it.

Jen

And you have this amazing website, HTML5 Doctor. Which, basically anytime I'm wondering which HTML element to use for something, I just come to this website and I look.

Bruce

Thank you very much. It's actually a joint effort. It was a conference a few years and I said, "Anybody want to talk about HTML5, meet in the bar." And 4 or 5 other people showed up. And so we agreed to start the site. A few of those guys have moved on but me and the other guys keep plugging away.

Jen

What year was that? What year did you start the site?

Bruce

Oh, crikey. That's got to be 2011 or something like that.

Jen

Yeah. Honestly, because especially at first, but even still, now I... you know, you're like, "Oh, gosh, wait, should I use <figcaption> for this? Uh. Let me go look it up." [Both laugh] And I don't want to search all over the internet. I just want to look it up really quick. And I've found, go to html5doctor.com, scroll like 4 inches down the page, there's a list of all the HTML elements in a nice little box. Click on it. Click on whichever one I'm wondering about, read the thing, move on with my day.

Bruce

Aw, that's nice. We've just spent a bit of time updating it actually, because the trouble is in writing blog posts about moving technology. Obviously technology moves on and if you don't remember to go back and tweak your blog posts. There were a few things in the video element, for example, which I'd forgotten to update. [Laughs] But should be all good now, folks. If it's not, tell me.

Jen

Video is the one thing, of all the shows, 74 episodes in, I'm actually kind of surprised The Web Ahead, which I started in 2011, that it's not more out of date. I think almost every single thing we've ever talked about is still true except for the show on video. Because in there we emphasize how Mozilla how never ever support H264 and then they did. [Both laugh]

Bruce

Yes, yes, unfortunately of course the world moves on regardless of our wish to. I think H264, or the video codec thing is, sadly a battle gone unless VP9 really gets some cool hardware decoding.

Jen

Yeah. I mean, it may not have turned out necessarily the best for openness but it is a good thing that there isn't a battle anymore. I mean, we need to have something, I guess.

Bruce

Yeah...

Jen

But we're not going to talk about video today. We're going to talk about... I guess we're going to talk about HTML.

Bruce

Yes! God bless it. And I'm an atheist.

Jen

It's a theme that's come up a lot in shows recently and if people are kind of tired of it, you should Tweet me and tell me, "Hey, I'm tired of it" and say what else you'd like to hear about. But for some reason it's an issue that I can't quite let go of yet. Because I believe so much that HTML is key to the web and that good HTML is worth, you know, the 3 minutes of effort it takes to stop and think about something and write some good HTML. Anyway, so I think we'd have a conversation today about semantics and about HTML and about, maybe, I'll be more honest about, rather than just be up on a soapbox. Does it really matter whether or not... so we'll start with that question. Does it really matter, Bruce Lawson? [Laughs] Should people take extra minutes to make sure or double check or think about using the quote-unquote proper element for something when they're writing HTML? Or do you feel like, what a lot of developers argue, which is, "Nah, it doesn't matter. I'm just going to use a <div>."

Bruce

It's a hard question. The death or the obsolescence of HTML is constantly foretold by the same people who tell that that the web will die and apps will take over. I don't believe it, although I think there's a contingent of people who would quite like HTML to go away and just be replaced by <div> tags or just, you know, vomiting loads of markup through script elements. I think it's important to spend the extra minutes on the HTML. I think you're right, it's minutes. It's not rocket science. One of the reasons... there's many reasons the web took off so exponentially in the mid to late 90s. There's view source, of course, which every browser had and not so many do now, which allowed you to see how people were doing stuff. But also, fundamentally, HTML is easy to write. We've seen considerable increase in the number of elements that we have with HTML5. I think it went up from 70 to about 105, 106 elements. But that's a very small vocabulary that you're required to know. I do think for philosophical or pride of work that one should know how to use the essential nuts and bolts of the language. But it's not just about pride, it's about reusability as well. Letting somebody else see what your code does. It's about letting other people view source and seeing how your page looks. And it's about portability of code and repurposing. I'm not sure that repurposing is a knock-dead argument. A lot of people don't want their content to be scanned and re-mashed-up by aggregators because often that can mean people doing site scraping and then putting your content on their ad farm sites, which happens to me, to HTML Doctor a lot. Portability is really important and by that I mean allowing your content to be crawled by web crawlers, not just search bots just primarily search bots. And for non visual media. We've all seen examples of things that look like buttons which actually are 5 or 6 nested <div> elements with a non breaking space in the middle. Then to make that work properly in non visual browsers you have to put a tab index on it to make sure that it can be tabbed into, because only links and form elements by default can be tabbed into, in browsers. Then you have to stick a bit of JavaScript on the top to handle clicks. Then you probably have to use some CSS and on hover or on focus change the cursor pointer to look like a little hand pointing. Then you need an ARIA role to say that this nested <div> pile is actually, fulfills the role of a button. Or you could just use the button element, which is what it's there for, and all this stuff is given to you. It seems to me a no-brainer. I know why we did it a few years ago, when button elements were harder to style. But as the search engine will tell you, if you type in, "Does my website have to look the same in every browser?" You will find a website that will give you the answer. And the answer is, no. Most people do not care if your website looks exactly the same in Opera and IE and Firefox. They may only use one browser, in which case they never know it looks different. But also, if the lion's share of your site looks the same — typography, colors, branding, et cetera — the precise border radius on your buttons won't matter one iota. I will guarantee you. That was a long answer, sorry Jen.

Jen

No, it's fine. It's interesting because I think sometimes, I've met developers who are doing the incredibly complicated thing that you just described in order to use anything but the button element. Then when it's not accessible, whatever it is that they did is not accessible, because they didn't do all of the pieces you just described. They just did some of them. They did enough of them for it to work in their browser of choice on their computer of choice and they haven't really tested it on anything else yet. When you say to them, "Hey, it needs to be accessible. Hey, it needs to work here, here and here." They're like, "[Sigh] That's so much work. It's so hard. We don't have the time for that. We don't have the budget for that." It's like, we would have, if you had just used the button element in the first place. [Laughs] Yeah, there's a certain kind of robustness. Jeremy Keith talks about this a lot. A kind of integrity of, if you code things in a way that's quote-unquote how they're supposed to, then it will work in a lot of ways that maybe you didn't even realize will exist in 2 years.

Bruce

Yeah, yeah, absolutely. It is about robustness. It is the, "Oh, we don't have the budget to make it accessible," is, in my professional opinion, from when I used to be a team leader having to retrofit a disastrously terrible site that was all spacer GIFs and nested tables. Retrofitting accessibility is phenomenally expensive. In the same way that retrofitting to make your site responsive is phenomenally or disproportionately expensive. Building it that way from the ground up is actually pretty trivial, as long as you've taken the time to learn your markup. Like I said, there is a vocabulary of 105 elements. Many of which, the keyboard element and the <var> element and the <samp> element, you probably never really encounter unless you happen to be writing blog posts about computer code or mathematics. The lion's share of the stuff you need is pretty simple and it's pretty simple to learn how to use it well. If it can't be styled to pixel perfect perfection across every browser, it doesn't really much matter. It matters more that it's accessible. It matters more that it's accessible because people who need accessible websites are a significant proportion of the population. There's almost certainly a legal requirement for it in the jurisdiction that you're in. This stuff does matter even if it doesn't matter to you as a developer. I know we've used this argument so many times, but... hopefully it'll win.

Jen

Somebody the other day Tweeted, and there's an article, I'll track it down and put it in the show notes. Of a blog post that someone wrote with some cartoon-y graphs in it of something like IE or maybe it was even particularly the IE 9 browser or IE 7 browser or something, has 4%, 6% user base. While people who use any kind of accessibility equipment or a special whatever, to get around the web, is like 14% in their graph. Their point was, "Why are we freaking out over this 4% and ignoring this 14%?" Kind of makes no sense, you know?

Bruce

Well, there's many reasons for that. I think people are fundamentally, or most people fundamentally are uncomfortable thinking about any kind of disability. Is my take-me-hate-me psychology take on that. That people just don't like to think about themselves when they can't necessarily hit tiny hit areas with a mouse or read tiny type in a grey on a white background. It makes people feel uncomfortable. That is human nature. But we're professionals, the people who are listening to this show are, by definition, the kind of people who really care about their craft. Otherwise they wouldn't be listening to this show. I'm kind of preaching to the converted. But it is a mark of professionalism, I think. It's like a carpenter who makes sure that the underneath of the table is well-finished even though few people will look at it. It's just professional.

Jen

You just can't help yourself. You want it to look beautiful underneath.

Bruce

Yeah.

Jen

At least I do. [Laughs] I mean, you were a big part of the web all along, the web standards project, back when there were not as many HTML elements and then all this stuff happened, WHATWG, blah blah blah. And then HTML5 came along and there's all of these new elements. Those were created for a reason. They were created because people through we needed them because they would be good and helpful and part of good craftsmanship. How do you think that's gone? Now that we're 3 or 5 years in? Do you think that that was successful? Adding more elements to HTML5?

Bruce

Well, the genesis of them is interesting. It appears, and I didn't know this when I wrote my book with Remy, it appears that they were kind of just dreamed up without any supporting data. There's a guy called Luke Stevens, I believe, who wrote a book on HTML5. It might be called, "The Truth About HTML5" or something. I can send you the link and you can add it to the show notes. He's done some archeology on the mailing lists and I think spoke to Ian Hickson, who was the, is the editor of HTML, the living standard, through HTML5. Hicks, he just rather dreamed them up on the grounds that it was easier for developers to type in <article>, <header>, <footer>, rather than <div id="header"> or something like that. Then subsequently, Hicks, he did some data mining on Google's index, because Hicks, he works for Google so he has access to that. And he had a look at the most common class names and ID names that are used in webpages. They kind of mapped pretty well to his proposed new HTML elements. <div class="menu">, <div class="nav">, navigation, sidebar, which kind of became an after the event rationale for the <nav> element. So those things I think work well. <header>, <footer>, <nav>, and I recently wrote a blog post, because a friend of mine, Matt Wilcox, who you all should follow, asked on Twitter, should he use <header> and <footer>? So I did a bit of thinking and wrote a blog post about a month back. And yeah, <header> and <footer> and <nav> and also the <main> element, which is a relatively recent addition to the canon, they have genuine utility. You don't see it, more of which later, but those things have built into them, the default information that gets passed to assistive technologies. Not all assistive technologies, like browsers, not all browsers support the same stuff. Not all assistive technology support the same stuff. For example, if you use <header>, that carries with it, what they call a default ARIA role that's implicit. You don't need to add an ARIA role in your markup. When the browser sees the <header> element, it will pass to assistive technologies the fact that this has an ARIA role of banner. Not all of them but in certain cases. And then in supporting assistive technologies, people with disabilities can then jump directly to the banner or the header using a combination of keystrokes. Likewise with <nav>, likewise with <footer>, and likewise with <main>. <main> is just something you would use... you know when you have <div id="content"> or <div class="mainstuff">, the bit that you use to surround all the main content after the nav and the header and the footer. If you use the <main> element there, people with supporting assistive technologies can just zoom straight into that with a single keystroke. Which is of enormous benefit to those people. That's called landmark roles. And WebAIM do a screenreader survey every year, this is the 5th year, and a decent proportion of screenreader users do navigate pages by these landmark roles. You don't have to do anything as an author except use <header>, <footer>, <nav> and <main> in your markup. And then you get in this accessibility for free. Of course, you can also hang CSS off these new elements just the same as any other elements. You can't in IE 6 through 8 unless you prod it to with JavaScript. But, you know, IE 6 through 8 are pretty geriatric now. And you can force those guys to apply CSS styles to HTML5 elements with a bit of JavaScript. The experience won't be great for users without JavaScript but my take is, if you're surfing the web all day with IE 6 with JavaScript turned off, your experience of the web is generally pretty shitty anyway and your website isn't going to make it any worse for people who are already having a bad web experience. But if you do use these HTML5 elements, then you are giving a much better experience to the X% of people who surf the web using assistive technologies. I don't know how many that X% is. Estimates vary wildly but I'm sure that wherever the listeners live, they can find out on their government websites, the number of people who are registered with disabilities in their country.

Jen

I just dropped the WebAIM screenreader survey into the show notes. The show notes, by the way, if people don't know where they are, they're at 5by5.tv/webahead/74. This is kind of fascinating. I think part of the reason that people, once people want to do right by accessibility and make their websites, for examples, accessible to a screenreader, I think part of what can be tricky about that is not having a screenreader in front of them or not being sure where to get one or not having seen one being used before. Maybe they saw it once or twice in a demo or watched a YouTube video, but they haven't... there's not... we work so hard to have all these other devices on our desk lots of times, not having access to a Windows machine makes it really hard to test for IE. Not having access to a screenreader makes it harder.

Bruce

Maybe other accessibility types will disagree because it's a truism that when you have 3 accessibility people in a room they will have 5 different opinions, but I would argue that if you are not a screenreader user, there is no, or very little, benefit to trying to test with a screenreader. Because you don't know how to use it. You don't know the keystrokes that people will use. Just listening to a screenreader talking while you're looking at your site on the screen, is not meaningful testing. I mean, if you have budget, you can pay somebody to test, I don't know about in the US, in the UK for example there are organizations like the Shaw Trust that give people with disabilities employment to test out websites and applications with assistive technologies. But generally if you mark up your stuff the right way, the stuff will be accessible. And I mean using the right elements. Taking care with something like WAI ARIA, where there are not elements in HTML, because HTML's a simple language. It needs to be simple. Which is why we don't have billions of elements for every use case. Why sometimes you do have to wonder what element is best for this bit of content, because we have a limited vocabulary and sometimes we don't have any vocabulary at all for some things. Which is why you need to use WAI ARIA. But being professionally minded and choosing the right elements and keeping abreast of latest developments, following things like WebAIM, following people like Steve Faulkner or the Paciello Group and Patrick Lauke, also at the Paciello Group, looking at the stuff they blog will help you make your stuff accessible. And it's also worth bearing in mind that there will be people who come to sites with archaic screenreaders that do not have capabilities to give them the best experience but that is their problem, not yours. if your site is correctly marked up and somebody comes to it with the screenreader equivalent of Netscape 4, that is their problem, in my opinion.

Bruce

Hooray! I have a sponsor message actually. My bit of the show is sponsored by Earl Grey Tea. And Opera, who are my employers, and they like me to say that.

Jen

Nice. What do you do for Opera these days?

Bruce

I'm a juggler.

Jen

Juggler? You run around and juggle and keep people smiling?

Bruce

Quite. [Jen laughs] Quite. I also work on the developer relations team to help people who might have a question about Opera's different browsers, et cetera, and I am one of the people who work on the product management squad of our desktop product.

Jen

Nice. Yeah, I think people don't necessarily know as much about the Opera browser as they should. And people should go check it out. Especially, you know, I think I worked for years without really realizing. You think, "Oh, Opera's got a tiny, tiny, tiny, tiny, tiny fraction of users. But then you... Opera Mini. Opera Mini does not have a tiny fraction of users. [Laughs] Opera Mini is one of the most popular browsers in the world.

Bruce

Yeah.

Jen

And you, developer, designer, QA person, business person, could go right now and download Opera Mini for your phone, for your very expensive smartphone, you can find an Opera Mini browser and then test your website in Opera Mini. I feel like that's a great test. It's a great test of making sure that your markup is right. Like, if your website gets completely scrambled, then you have been doing something very strange and Opera Mini does not like it. But if you're doing things pretty good, Opera Mini, it's going to come out pretty great.

Bruce

Yeah, it's worth testing. When I started with Opera we had 15 million users. Now I think we have 350 million users. So that's more than a third of a billion people. The good thing about it is that, literally, genuinely, for tens of millions of people across the world, it's the only way they can get to the web. And that's a really important thing. And the same technology's also a really great way to save money if you're data roaming overseas or you're in a congested place like New York City. But enough of my employers, because you haven't got me on to do an infomercial. [Jen laughs] Did I just say infomercial?

Jen

So what should we talk about next? I feel like there's two... there are two different pieces I think about semantics and HTML. One is to talk about ARIA. There have been several shows where we've talked about accessibility recently, and if people haven't heard those, then you should go back. And if they have, then, you know, you already know what we said. And then the other thing that we've skated around at times on the show but haven't really gone deep in, is this microformats, microdata, micro... and it feels like both of them are similar, in that they both are efforts to add more complexity to the semantics of HTML without actually changing HTML itself. Because on the one hand, it's really good for HTML to be very, very simple. It's true that that is part of why it became so successful. And on the other hand, there's good reasons to make HTML more complicated. And there was an effort with XHTML 2 to do that. To replace HTML with a more complicated and more strict, robust-data-representing version of HTML. Then that failed. But then we get things like RDFa, which seems to now have a... now it's failing? And microformats, which never really took off.

Bruce

Yeah. I would quibble with... no, I wouldn't quibble.

Jen

No, please do.

Bruce

I raise a British eyebrow when you say that ARIA is trying to extend HTML. That's almost the opposite of what it's for. It's there to bridge gaps in any markup language. So you can use ARIA perfectly with SVG, for example. It's there because with HTML4 for example, there are things that we did with HTML. You know, I'm thinking about web apps with little quote-y marks in the air with my fingers, because nobody can adequately describe what a web app is. But say you've got a site that does stuff rather than a site that lets you read stuff. Like, you know, a web mail client or something like that. When you're AJAXing in information, left right and center rather than always refreshing the screen, that was never envisaged when HTML4 was signed and sealed in the year 2000. So that HTML4 doesn't have the concept of stuff that's going to change on the page afterwards. So ARIA's there to bridge that gap. To let you add stuff to your existing markup which you can't change because it's generated by some great big enterprise level CMS or something. To say, "This is a live region that will update," and that tells a screenreader to listen out for that bit being updated and alert the user with a sound, because otherwise they wouldn't see that something had changed. And things like navigating around from header to footer, et cetera. HTML4 has no concept of header and footer so in HTML4 where you have <div class="header"> you would say, aria-role=banner and that doesn't validate in HTML4. Because, of course, HTML4 was concluded long before that. But that bit of invalidity doesn't matter because it doesn't hurt anything and it brings a benefit to the users who need it. Quibbling but it's not really extending HTML so much as bridging the gaps that the language doesn't have, in order to make it communicate better with assistive technologies. That's the purpose. To communicate it. That's why in HTML5, <header>, for example, you don't need to put an ARIA role in it. Because it's built in. Because HTML5 came later and we all know, every time you've ever looked at an image that has useful information in it but no alternate text, if people have to bolt something on, lots of people don't. But if it's built in, then it's there, whether or not you care or like it. It's there anyway. Built in always trumps bolt on, I think. With microformats, et cetera, well... is it a problem worth solving? With microdata-stroke-microformats-stroke-RDFa? I'm not so sure. People will tell you that umpty squillion sites use microformats but, yeah, yeah, umpty million pages use microformats because they were all generated by the same CMS. But did anything really consume microformats? I don't know. Microdata may be more interesting because schema.org, which is the consortium of big search engines, will use your microdata or your RDFa to enhance the way they show search results. They very carefully say it will enhance the way your search results look. Rather than enhance your ranking in the search results.

Jen

What problem do you think that microdata, microformats, RDFa, was trying to solve? How would you define that?

Bruce

It seems to me that it was trying to add extra semantics without actually adding stuff to the language. Instead of having an ISBN tag around which you'd note a book, for example, you would have a <span> and then you'd give it some kind of attribute, which told a consuming client that this stuff was an ISBN. Because adding stuff to the language is hard. It complicates it for people trying to learn the language and it absolutely complicates browser development and testing of browsers because you have more permutations of stuff that you then have to test every time you make a change to your code. The thing is, I don't know how many people actually do consume this stuff. I know there's universities, et cetera, that emit stuff with Dublin Core information. But I don't see a great deal of this extra stuff, this microdata — with a small "m" because I'm including RDFa in there — I don't see that many sites using them. I hear, anecdotally from people, that using microdata-stroke-RDFa, using the schema.org schemas, has a useful effect on their search results. Under the hand, of course, it's very hard to do a controlled, A/B testing there. My advice is if it floats your boat, use it. And I use it as well, on my site, primarily because my personal site is the one place where I can experiment at will. If it floats your boat, use it, but I wouldn't spend lots of money trying to retrofit all of my CMS and my pages to use this stuff. And the jury's not out between microdata and RDFa Lite, in my opinion. RDFa was pretty complex, I thought. When I'm reading about triples and CURIEs and stuff, my brain starts to spin. And I learnt XHTML rather than HTML5. But they've simplified it a lot now. It's easy to grok. But what benefit it brings, I don't know. It certainly doesn't bring about the tangible benefits that using some of those HTML5 elements like <header>, <footer>, <nav>, <main> bring for example.

Jen

Yeah, I mean, I think, it's interesting, your example of the ISBN number. It seems like there's so many... just Googling around right now, search around all these words that we're saying, I'm seeing recipes. Like, oh, so you could mark up a recipe so that you know... so that the robots, basically it's telling the robots, "Hey, this is not just content. This is a recipe. Look, here are the ingredients. Here's the this and that." Or movies, that's the director of the movie, that's the title of the movie, so the robots would know. And you're right, yeah, that's where I've seen some people advocating for using, especially microdata most recently and schema.org stuff. Google's been pushing this because that way, someone searches for a movie, then all the search results in the display of the Google search results will be... you'll get one of those nice little... Amazon uses this, I think. Where you get nice little... there's the cover of the movie and there's the title and it's formatted in a certain kind of way. That Google puts formatting in. And they're advocating, "Hey, use this for SEO because instead of just getting a plain search result, you'll get this fancy search result." And there are people who care deeply about SEO and marketing.

Bruce

But it's important to say that, last time I looked, the schema.org people do not say, "Use this stuff and you will appear on the first page of..."

Jen

Right.

Bruce

It just says, it may make your search results display nicer. But it may not. I mean, I'm sure there are upteen other factors in. Who knows how the search engines work. This stuff is the residual, the residue of the Semantic Web dream, I think. "Semantic Web" with the big "S" and the big "W". When the machines actually know what content means. So that it will know if you type in "cook" whether you mean a Mr Cook that you've met or somebody who can prepare food. I'm unconvinced by the Semantic Web for lots of reasons. Conspiracy theorists will have good reasons why it will never work and will be killed by the search engines. I just don't believe that that level of... the level of metadata production won't be enough to sustain it. Given that most people won't write alternate text, I don't believe that people will actually spend the time and the effort to make sure the metadata that isn't displayed anywhere is kept up to date. Or is actually accurate. The temptation to spam it, to get extra SEO, extra semantic web juice, would just be too great.

Jen

It's funny that there's somehow... people who are big fans of artificial intelligence and maybe loving things like the Google self-driving car, kind of intersect with the marketing, SEO, brand-loving kind of advertising world. You take those two things and crash them together and you get microdata and schema.org. It's funny that those two worlds...

Bruce

Yeah, yeah, I mean, I'm probably going to get beaten up now by SEO merchants and sem-web people. It's important that I say that this is Bruce you're talking to and it's outside office hours and this isn't my employer's perspective. I just personally don't see there being a critical mass enough of this information for it really to allow Skynet to become sentient, which is the dream, if you like. On the other hand, if it makes your search engine search results look prettier and attract more people to click on them, by all means, do them. Schema.org, it's not hard to implement, if you have a CMS or some kind of templating facility where people can type it in.

Jen

In my head, I'm sticking it into a bucket of like, this is a really great tool, especially if you have a project or a client or you're working for a company or your own company's a company that this is an important priority for you. But it's not necessarily in the other bucket, the other bucket being, for me, the nature of the web itself. And when I wake up in the morning and make websites, the care and the craftsmanship and the quality in which I want to do my work, sort of always includes a certain small, hopefully not too big, set of things that in that set of things includes taking 3 minutes to find the correct element for the thing I'm writing today. Making sure it's accessible. Like, that's not an option. That's just every project.

Bruce

It's an interesting thing though, because I've mentioned it twice now, and I shall skillfully segue way into something I found interesting. Is that what you, as a developer, can see on the screen matters and most developers, I think, are sighted. Which is one of the reasons why we don't have enough websites that are accessible. The trouble is with a lot of this metadata stuff, is that it's stuff that we can't see. So if it's wrong, or if it's rotten like your update, you're copying and pasting some content, you will automatically update the stuff that appears on the page that you can read, but you might forget to update the metadata. It's one the reasons why HTML5 wrote microdata rather than accept RDFa, because what they wanted was that everything that you needed from microdata was around the elements that it affected. So that if somebody were to copy and paste it, they would copy and paste all of the relevant metadata rather than stuff that's in the header. I think with Dublin Core and some RDF stuff, it required you to have stuff in the header, which you couldn't rely upon a harassed developer copying at the same point that he or she copied the markup, and thus you get metadata rot. But I was reading recently a 10 year old post on WHATWG, I'll send you the link later, Jen. I'm going to read out a bit of it now if I can find it. It's from a guy called Matthew Thomas and this was sent in 10th of November, 2004 and he's saying that he doesn't believe the new HTML elements that Hicks was proposing would be used. One of the things he says is that unless they have some kind of default visual presentation or behavior, they won't be understood. And I am kind of coming around to this perspective. He says, "One way to reduce the situation will be to recommend distinct default presentation for each of the elements." For example, default article, and that he means in the browser CSS, could have a drop cap. Default sidebar could always float right. Default header, footer and navigation could have a darker background than the parent element. And default header li and default footer li could default to inline lists, horizontal lists. Not because that default will be good, but because people when copying and pasting be forced either to override it with CSS or more likely to question whether that was actually the element they wanted at all. The thing is, with a lot of these HTML elements is that, for better or for worse, the default presentation or behavior manifests itself only with assistive technologies, which we know that a lot of developers don't use. I think that email was very present actually, and that's a decade ago. That's the problem. It's about, you have to think about the tools that you're employing in your website development. But, you know, that's kind of what we're paid to do.

Jen

Yeah, and we do think about a lot of other things. I mean, lots of times I see developers advocating very strongly for things like using spaces instead of tabs in their code. [Laughs] Or using comments and documenting their code as they write it. There's lots of other ways in which, kind of behind the scenes, best practices are evangelized and taught and handed down from generation to generation and codified in in-house coding standards that are sort of enforced with tests. Your code gets rejected if it's got tabs in it or something.

Bruce

Sure, sure.

Jen

Some of this stuff could definitely be culturally held up as well, as important. And is, in many places. Just not as universally as I might hope.

Bruce

Yeah, I do wish that 10% of the energy and emotion that was expended in the recent SASS versus LESS riots that rocked London [Jen laughs] would be spent on establishing a canon of best practice with the new HTML elements. And it's worth remembering as well, that me and you and other geriatrics listening, we were still arguing about the right way to mark up menus and navigation and decided it was probably an unordered list in some kind of container element. A <div> and now it would be a <nav>. But we were arguing or discussing this stuff 5, 6, 7 years ago. Long after HTML4 had been signed, sealed and delivered and put to bed as a spec. Now, we didn't just suddenly, magically all know this canon and best practice. We developed it through talking and podcasts and blogs and conferences and books, et cetera. And that's what we're doing now. The fact that everybody doesn't understand when to use <section> or <article> isn't necessarily a failure of a specification or a failure of those elements. It takes time for people to become accustomed to new tools in the trade. And to discuss how those are used. It's a social contract. if we all agree to use these things in such a way, then they all become more useful. If we just have the Tower of Babel, that those who would advocate just, you know, vomiting out loads of <div>s from JavaScript and hanging CSS on it, then of course we will never develop a best practice because there is no conversation or best practice possible there. And, you know, we might see, hopefully we're going to see, a similar conversation about web components, which of course are the next big thing in semantics. That we're already seeing that when people discuss, "Should we have a caption element?" Or, "Should we have a..." What was it I saw? A geo element, to hang geolocation information from. That's now hand waved away by, that's what web components are for. And initially when I heard about web components from Alex Russell of Google, sinister mastermind and all around clever guy and nice guy, I was really concerned there would be a Tower of Babel. If everybody's making up their own elements, how can any of them be beneficial? So I've been talking lately, like at an accessibility conference in Stockholm and will be talking in other places, about the need for us as a community to establish a canon of best practice now. Let's make sure that our web components are built to be accessible with ARIA stuff. Web components are interesting because we went from bolt on, adding ARIA stuff to HTML4, to built in, with default ARIA roles in HTML5 elements. Because we're now making up or extending existing HTML elements or just making up our own ones, we have to bolt this stuff on, and we have to build it with internationalization and security and reusability and accessibility and comprehensibility in mind. We as a community can do this if we choose and the time to choose to do it is now before this stuff hits mainstream. Otherwise, we'll be left with billions of low quality web components much like jQuery UI plugins or something. Some of which of good, some of which are bad, all of which claim to be the best at identical use cases. Hopefully something like webcomponents.org will act as a repository or best practice place to download good web components. Only time will tell.

Jen

So, I know you need to go soon, Bruce Lawson.

Bruce

No problem. It's interesting you mentioned Velocity, which, by the way, dear readers, I can recommend. And they're not paying me anything. They give Jen a mink coat every time she mentions them.

Jen

[Laughs] Right!

Bruce

There's a useful performance gain with using markup. And I'm not talking about semantic markup per say, I'm talking about using traditional HTML, rather than an empty body tag and then just scripting loads of HTML. AirBnB published a blog post a little while ago in which they were very excited and they said, quote, "I'm proud to announce that we have launched our first holy grail app into production." It looks exactly the same as the app it replaced. However, initial page load feels drastically quicker because we serve up real HTML instead of waiting for the client to download JavaScript before rendering. Plus, it's fully script crawlable by search engines." And they reckon it renders 5 times faster. Simply because they're using HTML rather than sticking all that stuff into scripts and then injecting that later. So if nothing else, that is a really good reason for keeping the separation of concerns, HTML for your content, CSS for presentation, and then the JavaScript for behavior, and don't mix those guys.

Jen

Yeah. Yeah. That really feels like the canon, right there. And I think part of why I do get so on a high horse about this is, I started doing website stuff in '96 and built, you know, using tables for layout and...

Bruce

[Gasps]

Jen

... using Dreamweaver to write, as a WYSIWYG...

Bruce

Dead to me. You're dead to me.

Jen

[Laughs] Well, you know, '98, it was more ok.

Bruce

Yeah.

Jen

It's like building amazing Flash websites in 2000. Like, ok, in 2000 or 2002, amazing Flash websites were... but that's what I was doing. And I was, you know, as Netscape... god, I think it was Netscape 3 and Internet Explorer 3 or 2 or 4 or... it's all fuzzy. But in there. And I remember trying to make things in circles because I wanted to lay some stuff out in circles and so everything was an image slice and I wanted, like, when you rolled over, for this thing to change, and so that required JavaScript and I was letting Dreamweaver write the JavaScript. And the code was a mess and everything was just such a mess, and it didn't work. And this was back in the days when people would build 2 websites, one for Internet Explorer and one for Netscape, because we were trying to do these fancy things, and they totally didn't work and the hacks you used for one browser didn't work in the other browser. I mean, people complain about IE 6 now, but either they weren't there or they just have blocked it out. [Laughs] Like, we don't want to remember what it was like when it was IE 3. Then web standards. Then I read Jeffrey Zeldman's book. Then I was like, I'm never doing that again. I am going to do this other thing where you hand write the code and it's really beautiful and it's very simple and then I layer on top of that, CSS. And then I'm done. And it's not so hard, it's not so complicated, it doesn't break constantly. I don't have to worry when a new browser comes out that my website is going to break and I have to go redo my website for the new browser, which is what things were like. Yeah. So I feel like those lessons, there are lots of new people, every day, building websites and they may not remember those terrible, painful days and all of the lessons that were learned around progressive enhancement and building things exactly like you described. Like, just get some really great HTML out of your system. Whatever it is. Whether you're using Jekyll or you're hand writing things or you're using a big CMS like Drupal or you're using WordPress or you wrote your own CMS or... like, just get really great HTML of it, feel really good about that. Make sure the source order makes sense. Make sure it's accessible. Make sure it's going to look cool in whatever, Readability or Read It Later or Instapaper. And then layer on your CSS. And then layer on your JavaScript. And then make it spin on the end of a finger like a 3 dimensional basketball or something.

Bruce

Yeah, yeah. Is this what we fought the web standards war for? It's the first thing we did in the web standards project, or they did before I joined, was to try and educate developers. Then they tried to harass the browser vendors. And now it's educate the web developers because it's another generation and that's kind of great. It means that geriatrics like me and thee, sorry Jen.

Jen

[Laughs] It's ok.

Bruce

... Can bring out all those tried and tested arguments again and hopefully win.

Jen

Yeah, the old is new again. The good old and the bad old.

Bruce

[Laughs] Yeah, it's great, isn't it?

Jen

Well, thank you so much for being on the show.

Bruce

A delight. Thank you.

Jen

People can find you at brucelawson.co.uk and read your blog.

Bruce

Or @brucel on Twitter.

Jen

@brucel on Twitter. People can follow me, @jensimmons, on Twitter or the show itself at @thewebahead on Twitter. And that's it. Until next week, thanks for listening.

Bruce

Thank you very much. I'd just like to say to each listener, each one of you looks absolutely lovely today. Keep it up.