Episode 143 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Bruce Lawson who is a member of the Web Standards Project’s Accessibility Task Force, works at the Opera team and contributes to HTML5 Doctor.
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
SitePoint Podcast #143: Happy HTML5 Holidays with Bruce Lawson(MP3, 37:44, 36.2MB)
Episode Summary
Louis sits down with Bruce Lawson to talk about HTML5 semantics, usage, developed, packs, workarounds, polyfills and everything in between.
Browse the full list of links referenced in the show at http://delicious.com/sitepointpodcast/143.
Interview Transcript
Louis: Hello and welcome to another episode of the SitePoint podcast. As it happens it’s the last episode of the SitePoint podcast for 2011, and with me on the show today I’ve got a suitably fantastic guest, Bruce Lawson. Bruce is a member of the Web Standards Project’s Accessibility Task Force, he works on the developer relations team at Opera, he’s a legend really in the fields of accessibility and web standards, an expert on HTML5 and a contributor to HTML5doctor.com. Have I forgotten anything? And hi and welcome to the show, Bruce, while I’m at it.
Bruce: Hi Louis, hi everybody, no, you haven’t forgotten anything that summarizes me, although possibly the Wasp Accessibility Task Force, I’m kind of a emeritus member of that, I haven’t done a great deal with that for a while.
Louis: Right. So, yeah, I wanted to have you on the show for a number of reasons, there’s all sorts of stuff going on, obviously HTML5 has been a major topic in the web design and web development world for a little while now, and you’ve certainly got a lot to say on that. In fact, the second edition of your book on HTML5 has just been released if I’m not mistaken.
Bruce: That’s right, yeah, I think it came out, I don’t know if it hit Australasia yet, it came out in the UK about a month ago I think, it’s quite exciting for Remy and me, so lots of typos and bits of utterly oblique language corrected and opened up and a whole new chapter on how you can actually use this stuff now because that’s why everybody came up; at conferences and things people will sidle up and up and say, “Oh, sounds great, but how can we use it now?” And it occurred to us that we’d very cleverly omitted to mention anything useful like that in the first edition, so it’s in there now.
Louis: Yeah, there was certainly a lot of trepidation, I want to come back to this and sort of ask about the new edition because it is, if I’m not mistaken, the first second edition of an HTML5 book, so that’s got to be some kind of landmark for the maturity of the specification of the language.
Bruce: It may not be because my chum, Peter Lubbers, and some colleagues of his from Kaazing wrote Pro HTML5 Programming, which may have come into second edition before ours, it’s certainly out as a second edition, I don’t know who was first but we’re not competing.
Louis: What I was saying is we’ve reached that point where there are now second edition books about the topic, so that does say something about HTML5 and maybe its staying power and that it hasn’t petered away.
Bruce: Well, it may not be indicative of the maturity, it may be indicative of just how much the whole thing is shifting sands and things are being changed from under our noses so we have to go and rewrite stuff, I wouldn’t necessarily say that it’s indicative of maturity, put it that way.
Louis: Hmm. So, talking about the second edition of the book, you said one of the things you focused on was a chapter on putting the stuff into practice, and I know I worked on the HTML5 and CSS3 book for SitePoint, and that was something we had in our minds when we started working on it because your book and Jeremy Keith’s book were already really strong on sort of that, you know, explaining the specs and the process by which they came about and what they really mean, and we wanted to try and maybe just do something a bit different and focus more on the practical aspects. But are there any other things that you’ve had to change, for example, things that have just flipped around on you and you’ve had to actually go in and change?
Bruce: A fair few. I changed my mind on the semantics of using the nav element. Originally I was marking up everything that looked like a link to somewhere else in the website as nav, and I was actually doing a workshop at the BBC and talking to some of their web developers, and they convinced me, or I convinced myself, I don’t recall how it went, but we kind of convinced each other that I was being a bit overzealous and had suffered nav-itis for a year, and so I changed my mind about that. The time element disappeared and then came back (laughs) or it will be in a modified format so it won’t be, as we say, in the book, but it will be in the spec. A lot of new stuff with multimedia, so in the first edition I put together a dirty, dirty hack to do our timed transcripts, timed captions to video, and by the time the second edition was out the spec was pretty much sorted on a new format called Web VTT which is Video Timed Text which will be probably the easiest way for web authors to add subtitles and captions to audio and video, so it was really great from my accessibility background to be able to say goodbye dirty hack is the official way, and point to some pretty damned great polyfills that you can just grab off the shelf and employ now. So if that’s your thing you want to look up Playr, p-l-a-y-r, which is kind of a nice quick and dirty way to do rapid prototyping but it doesn’t work in IE10 yet. There’s also a really great polyfill called mediaelement.js, and this is totally fab, at the moment it relies upon jQuery but I think that dependency will go soon. But what mediaelement.js does is it adds subtitle support, etcetera, as a polyfill, but what it really cleverly does is it fakes all the JavaScript HTML5 API’s for audio video and implements them in Flash, so if you’re using IE6, IE7, IE8, you get a Flash movie instead of native movie but you can still interact with it using all the JavaScript API’s because it fakes it. And because our community is so brilliant and generous all these things are open source and you can just grab ‘em and use ‘em and that’s deeply marvelous.
Louis: Yeah, that’s fantastic, I was unaware of that sort of wrapping of the Flash movie with the API, I can exactly see how that would come in handy, you write your JavaScript once and it just interacts with the movie the same way whether it’s a Flash movie loaded in or not.
Bruce: Exactly.
Louis: You were talking about the new subtitle specification and sort of presenting some polyfills for it; is there any actual browser support on the ground for that yet?
Bruce: I think there’s a Labs release of IE10 supporting it, they said they’re going to support Web VTT, which I said was the easiest mechanism for web developers to subtitle stuff, but it’s not the only mechanism, there’s an existing standard called TTML which is a far more sophisticated XML based subtitling method which a lot of the big, big houses like from the top of my head Netflix and the BBC have already been using, and Microsoft is going to support TTML, but because it’s XML based it’s harder for Mr. or Ms Joe web developer to bung on their sites. Chrome have said they will support Web VTT, and I work for Opera so I can tell you that we are in the process of implementing it, but I don’t have a release date for that yet, whether Safari and Firefox are I couldn’t say, but I would imagine they are.
Louis: Yeah. But, again, if there are good polyfills out there that at least tides us over and we can start using the stuff —
Bruce: Precisely.
Louis: — and wait and see what happens with the browser support. Just talking about the browser landscape, I was looking through your recent tweets in the lead-up to the interview, and I saw you made an announcement about the recent release of Opera 11.6, which I’d missed, did you want to talk a little bit about what’s new in there.
Bruce: There’s a lot of really cool things. The coolest thing, which for a web developer of a certain vintage is insanely cool, and to everybody else it’s entirely yawn-arama, but it’s the HTML5 parser, and I show this to people and deliberately build it up as the coolest demo of HTML5 you’ll ever see, and then I show some markup which is b i, close b, close i, with the mis-nested text, and HTML4 as a spec told browsers what to do with good markup, but it had nothing to say about what to do with markup that wasn’t good, and we did some research in 2008 when we looked at three million randomly generated URL’s for a projected called MAMA, Opera MAMA, and we discovered that 96% of the Web surprisingly was not a valid markup. So the trouble is, is that the browsers didn’t know what to do with invalid markup, but all browsers are very forgiving beasts and don’t want to show you a blank screen so they do their best to render stuff. So what they’ll do with that mis-nested b and i is different things; IE and Safari behave one way, and Firefox and Chrome and Opera behave another way, and nobody’s right and nobody’s wrong because it was undefined. And if you’ve ever written JavaScripts that have to go around a DOM that you can’t predict and do stuff in a web app or a web based word processor, or whatever, you’ll know there’s a world of pain associated with the fact that you don’t know what an individual browser’s going to do with the same markup because of this problem. So HTML5 defines unambiguously and completely what to do with any variation of markup no matter how broken and twisted it is, every browser that implements the HTML5 parsing algorithm will produce the same DOM, and this might not seem glamorous to a newbie web developer, but to those of us who’ve been in it for ages the idea that you’ll get the same DOM across all browsers is a wonderful thing, and this isn’t just a theoretical benefit either, it’s great for consumers because nobody uses just one web browser anymore. My poor Mrs. who has to use IE6 at work will use Safari on her iPhone and then Opera on the home computer, so the idea that one website will work on one or two of those browsers but not the third, it’s mad, you know, and it’s utterly stupid of any business to have a website that won’t work on all browsers across devices, and the HTML5 parser is a step forward in interoperability between the browsers which is a massive win to the consumer who’s never even heard of HTML.
Louis: Yeah, absolutely, I can see the impact of it. Is Opera the first browser to sort of fully implement the parser as its specified?
Bruce: No. I believe it was in Firefox first, although it was an option, then it was in Chrome, so I think Opera is the fourth and then IE10 will have it I believe, although you can’t speak for unreleased versions yet. And, of course, once IE10’s got it this is a giant win for the interoperable web there, and we’re still of course going to have to take care of old browsers because not everybody has the luxury of being able to upgrade, that’s another thing that I feel very strongly about; it’s all very well telling people you appear to be using a crap old browser, please go away and upgrade.
Louis: Yeah, there was sort of a bit of a kerfuffle on Twitter about this a few weeks ago, I don’t know if you caught wind of a brief pitched argument with John Allsopp and few other people about this, the idea of supporting all browsers and older browsers inclusively, and John wrote a really excellent blog post about it.
Bruce: And I’m with John, you know; if you are a web developer it’s easy to forget that there is a world out there using old web browsers with no real end in sight to that. I believe the net apps stats show that 49% of the world is on Windows XP, and for whatever reasons they have Microsoft has decided that you won’t be able to use IE9 on Windows XP, and you certainly won’t be able to use IE10 on XP, so, 49% of the world will stay on XP and we know that most people don’t upgrade or install a different browser, so there’s gonna be if we’re not careful a web of haves and a web of have-nots, and that’s in my personal opinion entirely antithetical to the idea of a worldwide web.
Louis: But of course the people who have made that argument a lot of times this stuff gets inflamed over Twitter, and this is something that constantly comes up, because I like to bring up these sort of arguments and debates between the various factions in the world of web development in my interviews, and what always comes up is that people will say things on Twitter and provoke a debate because they had to compress their point of view into such a small amount of space that they made it much more absolute than it sounded. I did an interview with Jeremy Keith which entirely came about as a result of we had a discussion on a show about something that he had said in a blog post that we, you know, that seemed very absolute because he’d written it in that kind of manner, in a kind of provocative manner, and obviously people do that deliberately, but I don’t think anyone has been disrespectful in any of these debates, and that’s one of the things I really like about this community, and I think we can all agree on that is that people are very respectful even when they disagree.
Now, going on, let’s see, while we’re on the topic of controversial, I got a couple of recent articles that you sort of responded to on your blog, one in more length and one in lesser, so you’re very much a semantics guy and you’re really excited about the idea of semantics and that comes through a lot in your book and in your writing, and you’ve talked a lot about the issues with the time element when it was first dropped, and so there’s a recent article that I read and I thought was very interesting that Divya Manian wrote at Smashing Magazine which was sort of a deconstruction of the idea that — or maybe pointing out that a lot of web designers and developers spend a lot of time paying attention to semantics and maybe that’s not necessarily a good use of our time. And I thought it was really interesting because I saw a lot of different reactions to it, but personally I kind of felt, yeah, I get that, you know, I get that there’s been a lot of fuss about HTML5 in the sense of, oh, should we be using a section or an article or an aside, you know, and in your work and your writing at HTML Doctor you’ve encountered a lot of this when you’ve had to sort of rewrite articles when sort of the opinions about things have changed, and you even mentioned with regards to your book sort of changing your mind about nav.
Bruce: Yep.
Louis: And I thought this was interesting because a lot of people sort of came out and said oh, no, semantics that’s the most important thing or you can’t just do away with it, but I did think that maybe some kind of moderate consideration might be worth pursuing. So I wanted to know what your thoughts were on that because you did sort of respond to it in another article that you wrote for Smashing Magazine, even though it wasn’t a direct response you did sort of present a defense of semantics.
Bruce: Yeah, I mean I didn’t write that article as a response. Vitaly from Smashing Mag had asked me to summarize my Frontiers talk, but that happened to be a defense of semantics. I mean Divya’s right, if you spend an idea, you know, I have endless talks with Dan Cedarholm because he put a cite inside the anchor and I was putting the anchor inside the cite, and who was right and who was wrong, and actually of course if doesn’t much matter, what’s important is it’s consistency, in the same way with the nav element, I’ve always said think about who’s using it at the end; if every link inside the site is nav then the people who actually need the nav element, people with assistive technologies, everything’s a nav and so nothing’s useful to them. So it’s a matter of moderation and balance, and I’m certain that’s what Divya was writing, and I’d agree.
Louis: Yeah, I think some of it might come from, you know, we’ve had the same set of semantic elements which have had very limited semantic value for a very long time just using pretty much divs and spans everywhere with a few little highlights of semantic value here and there, and suddenly we’ve got this smorgasbord of elements with HTML5.
Bruce: Sure.
Louis: And like you said with nav, I think a lot of people might just get a little bit high on the fumes of semantic value and start throwing this stuff all over the place without really stepping back and thinking oh, well, I can use this the same way I’ve always used these little semantic touches like cite and like block quote.
Bruce: So, yeah, we’ve got this smorgasbord of new semantic elements, but we only have I think it’s 105 or thereabouts; if you think how many words we use in English to express ourselves it’s tens of thousands, so a hundred elements in our vocabulary means that there is nowhere near enough to express every nuance of your content because it’s about marking up your meaning and your meaning is the words and the intention, so inevitably there’s grey areas where no particular element seems to fit or two elements seem to be equally applicable, and the answer is, no, don’t sweat it, choose one and use that consistently throughout this site, and if you realize you might not have been perfect don’t sweat it, just do it better next time, it’s not worth getting a semantic knickers in a twist about. If somebody said to me what’s more important, correctly deciding between article and section or making sure that this works on IE6, I would say make sure it works on IE6, you know. Semantics are vital but they’re not the only game in town, and I know that Divya and I totally agree on that.
Louis: Yeah. This kind of leads in nicely, you were talking about the sort of limited vocabulary that we have in HTML, and that sort of leads into I wanted to get your view on what happened with the time element because we’ve sort of talked about it on the show before, but I think you might have a pretty interesting perspective, you wrote about it both when it was initially removed and when it was re-added. So my understanding was the initial idea was Ian Hickson removed the time element because he said, one, it wasn’t being used or it hadn’t gotten a lot of traction and, two, something similar could be accomplished with a more generic data element, sort of thinking, look, time is just one type of machine readable data so why give it a special place over all the other types of machine readable data you could have in your pages.
Bruce: So the history of time’s interesting. It was dreamed up because the micro format’s people were abusing the abbreviation element to markup dates and times, and this wasn’t a semantics knickers in a twist, this was a problem because certain screen readers with verbocity settings readout the totals of abbreviation element, and that in the micro formats world was being turned into an incomprehensible string of numbers and letters that people would hear instead of a human understandable date. So what was happening is that people with assistive technologies were actually not being able to comprehend the content given to them because there we no adequate way to markup dates or times in HTML. So, HTML5 gave the micro formats people this time element, but they crippled it by not allowing you to have a fuzzy date, by which I mean you could markup the 19th of February 1867, but you can’t say February 1867, and you can’t say 1867. And this is a problem for historians or people who run museum websites, and I know this for a fact because some of my friends do this, because of course you don’t necessarily have the absolute date, and also you couldn’t markup dates before the Christian era, so anything — even though you know that Julius Cesar was murdered on the 15th of March 54 BC you couldn’t write that because it’s before the Christian era. And so the micro formats community didn’t use the time element because it was crippled like this right from the inception, and then Hickson saw that nobody was using it and so removed it. And, yes, time is just one form of machine readable data, but it’s a special form of machine readable data, I mean my bugbear, or the bee in my bonnet, is the fact that most things on the Web are related to who, what, when and where, you know, who’s doing something, when are they doing something, where are they doing it. So we have a time element because the when is obviously important, we don’t have a location element, yet, although we might do, and that would have latitude and longitude as mandatory attributes and potentially an altitude attribute.
Louis: But, again, even if you’re — sorry, coming back to that now, just want to get your opinion on this, when you say latitude and longitude as mandatory attributes that, again, sort of precludes you from using a more fuzzy term like, say, Melbourne or Australia when you’re describing a place and you want to be able to mark that up semantically as referring to a place, right?
Bruce: Yes, I’m not saying that it needs — I’m not implying any kind of degree of precision here.
Louis: Right.
Bruce: I mean there’s no reason why you shouldn’t be able to say approximately 54 north or something, I don’t know, but it seems to me that there are certain types of machine readable data which are more prevalent and more common and it’s easier to see use cases or being able to access them through an element. So the trouble is with marking up a date or a time with the data element is that the attribute there’s no way for a machine to know that this attribute is a date or a time because it’s just some random data.
Louis: Right, and then to react to that and enhance it in some way by providing you with a richer set of metadata or interactions, yeah.
Bruce: Precisely. In the same way that why invent a header or a footer, why not just stick with div. Well, these are more specific, more obvious use cases, I’m not suggesting that we have a length of nose tag (laughter) and a circumference of eyes tag, and a distance from forefinger to elbow tag, because there are some use cases that are more important than others, and that’s why we only have 105 words in inverted commas in our vocabulary; HTML has to be a general markup language which means that you can’t cover every use case with it, but it means that it has to be easy to learn, and I’m a great believer in the Web remaining a place where it’s relatively easy to write and publish content, and I often used to worry that XHTML was heading to a place where you needed some kind of special, specialist training if you just wanted to write a blog post. I think we’re getting back to the degree of simplicity now, which is useful, although I acknowledge that most people don’t hand code HTML anymore, they use some kind of CMS.
Louis: Yeah, absolutely. But I mean I do agree with you that the idea of making it simple enough that anyone can write it, and even I would have a much easier time hand coding an HTML5 page than I would’ve had four or five years ago coding an XHTML page where I would’ve had to look up both the doctype and the various meta tags. Now I’m fairly confident that I could do the thing from scratch were I stranded on a desert island with nothing but a stick I could write my SOS in HTML, in valid HTML.
Bruce: Well, you’d need to; if you wrote your SOS in some kind of proprietary format then loads of IOS might not be able to display it, who knows about its SEO, you know, HTML is the lingua franca.
Louis: Absolutely.
Bruce: But I’m a great believe in the fact that the Web is the most democratic medium that we’ve ever had as people. I’m getting all poncy on your now, but I think it has to be easy to consume so you don’t have to have the latest three thousand dollar Macbook Pro just in order to be able to read a website, you don’t have to have a super, super-duper Wi-Fi connection, and neither should you need to have a computer science background to author the Web. There’s billions of people on the planet with stories to tell and pictures of kittens to show, and I want to make sure they can continue to show those things and everybody else can continue to access those things even if they don’t have the latest, greatest Smartphone over an industrialized nation’s Wi-Fi infrastructure.
Louis: (Laughs) and even then not all industrialized nations.
Bruce: I’ve been to Australia.
Louis: (Laughs) ah, yeah, still bitter about that one two years in. So those are great words and fantastic and inspiring stuff.
Bruce: Maybe you could dub in some angels like humming Silent Night behind this (laughs), but yeah, it is a nice outake.
Louis: I did want to briefly touch on the — because you released for the release of Opera 11.6, you posted a YouTube video of yourself playing a guitar and singing a Christmas carol about the new features in Opera 11.6, and I just wanted to specifically give you props for your rhyming of Gabriel with radial (laughter), as in the angel Gabriel with radial gradients, I thought that was fantastic, I listen to a lot of hip hop and that’s still one of the best rhymes I’ve heard all year.
Bruce: Thank you, sir.
Louis: So huge props for that. On to some more serious things, so you briefly mentioned in there that the democratic nature of the Web has a lot to do with the availability of bandwidth. And what I want to get to here is that obviously the big topic in web design over the past year, I think if anyone had to say what the topic in the web design sphere for 2011 was, we’d all agree that responsive web design was the clear winner. But people seem to have come up against one particular thorny issue in attempting to do responsive web design, and I noticed this because, first of all, because 24Ways — if anyone listening is not familiar with 24Ways you still have time, go to 24ways.org, it’s a sort of an advent calendar of great web design articles that comes out each December, it’s been going since 2005, fantastic stuff, and this year I’ve noticed that there have so far, even though we’re not even halfway through the month, there are so far already been two articles about responsive images. And I also noticed that you’ve recently written a short blog post sort of suggesting an alternative way of handling responsive images, and that kind of touched on this idea of bandwidth, right, because you’re doing a responsive design, great, it can fit all content, but if all you’re doing is adapting this one giant image to a number of different screen sizes that’s a huge bandwidth hit for most of your users, and a lot of those might not be seeing that giant image.
Bruce: Yeah.
Louis: So there have been a bunch of different alternatives suggested, and you’ve sort of proposed an interesting, maybe a more fundamental change that could take some cues from the video element.
Bruce: It just seemed to me that HTML5 gives us a video element which because of the debacle with no single codec working everywhere has the ability to pull in different source files using the source child element, and it struck me that if we had some kind of new version of image, and I call it picture but it could be called anything you like, then you could have source elements below it and a media query on those source elements, not in the CSS because it isn’t about layout, it’s about pulling and actually different sources, and then it could be handled declaratively. Because it seemed to me that if you can get something as cool as video and pull in different videos for different media queries, which works now in Opera and IOS, it seemed odd that for something as simple as an image we should have to resort to really clever and brilliant hacks with noscript and spacer gifs or mucking about with HTaccess and PHP and generating things on the fly. And I don’t want people to misunderstand me, I think the brilliant workarounds that people are coming up with are a testament to the excellent lateral thinking of my friends and my peers, but fundamentally we shouldn’t have to be doing those, it should be easy, and as you know I’m not a designer so I can’t do CSS, and I’m no longer a programmer so I’m too thick for JavaScript, so I’m very fond of simple declarative ways of doing obvious and basic web pages. And bringing in an image and making sure that you don’t nuke your mates bandwidth seems to be a basic use case, it should be basic HTML and shouldn’t need limbo-ing under HTaccess’ and shimmying weird deferred scripts, and maybe I’m wrong. And I have a great deal of sympathy with the idea that this should be negotiated between the client and server, so in other words, you say I want this image here and the browser should say to the server, well I’ve got low bandwidth at the moment, and of course that could change in a session, but at the moment I’ve got low bandwidth so send me the smallest in file size version of this image you have and then the server goes and looks to find out which one is its smallest version and sends that. And maybe actually this shouldn’t be something that web developers have to worry about, maybe this is something that machines should do, and this is an idea called content negotiation; my colleague and friend from Montreal, Karl Dubost, is a great believer in this. I think Carl is right, I think it should be done auto-magically, but we know that designers would prefer that fine-grained control rather than trusting auto-magic discussion between the silicon in your phone and the silicon on the server. So, I think we have to give a way for designers to do this, but again, I’ve got every sympathy with people who say okay well make up a new HTML6 picture element, but it’s still ten lines of code to put a responsive image on a page, isn’t that too much, and I think, well, if you think it’s too much let content negotiation deal with it and we’ll have to deal with a mechanism for that, but if you want the finer-grained control then you can do that in a simple declarative way. But, you know, yes! bandwidth matters, and at Opera we know this because we have all kinds of mechanisms for squeezing compression in pages to make things appear faster, but actually most people in territories or nations where bandwidth is either very slow or very expensive, because they’re paying by the megabyte, they’ll just turn images off anyway; every browser has a setting ‘don’t show images’, so you can bust a gut getting responsive images, but a lot of people just turn your images off anyway, and then of course that is back to basic good practice of making sure your web pages are accessible so that if people turn off the images they see the alternate text that tells the user what the image means.
Louis: Yeah.
Bruce: And if the image doesn’t mean anything then it shouldn’t be an image it should be a background image in your CSS. So, you know, it’s the thorny issue de jour, but ultimately it just comes back to basic good practice of semantic HTML with alternate text for images that are part of content or putting the prettiness and all the eye candy in the CSS because ultimately your users want the content, and we see this all the time and I know that loads of designers are now marching upon Birmingham UK to kick my head in (laughter) when I say that CSS is just prettiness, but, you know, in the vast majority of websites it is.
Louis: Yeah.
Bruce: Sorry designers.
Louis: (Laughs) I was just interested to talk about this because looking at your, it’s not really a proposal, but your just sort of quick sketch of how this might look, I thought, oh, that looks pretty good, makes sense, I would use that. And I had already looked at these two articles on 24Ways, and in both cases been kind of like uh-huh, not so much; definitely in the case of the sort of server side handling because I work on large enough websites that having a PHP process run for every request for an image is just not an option for performance reasons. And then the other one, the sort of the mix of comments and no-scripts and hacky JavaScript, I thought yeah, you know, that works, that’s very clever, I could consider using that and some kind of script based image loading. But, yeah, I was impressed by your idea and I hope to see something like that coming in, as you said, perhaps HTML6. But, yeah, as you said, the key, and we see it all the time, a well designed mobile site that when you pull it up on your phone it loads really, really snappily, even on Australian 3G, is a joy, and it’s something that a lot of people do, it just needs a little bit of care and stripping out the excess.
Bruce: Absolutely. And with the putative picture element, whatever it’ll be called, I know that this stuff is starting to be discussed, and when I published that blog post some biggish names in the ‘Responsive Design’ community got in touch with me, and bizarrely I duplicated a proposal they’ve been working on privately between themselves, even calling it the picture element.
Louis: Right.
Bruce: And so I know that they’re going to be putting a proposal to their working group pretty soon, so hopefully it’ll be discussed and acted upon. Again, nobody’s saying it needs to be called a picture element, nobody’s saying it needs to be exactly like I suggested, that was a straw man to say let’s have a simple way of doing this where you don’t have to know JavaScript and PHP and some really quite nasty hacks, because it always seems to me when you’ve got nasty hacks like that there’s something fundamentally lacking in the language.
Louis: Hmm-mm.
Bruce: That degree of complexity says to me that we need another wave of linguistic development to get back to the simplicity again.
Louis: It’s fantastic t to have reached an era when we can look at a hack like that and say what you just said which is, oh, if we need this kind of hack we’re probably doing something wrong, when we were doing this for rounded corners for seven or eight years and nobody said a word. Yeah, yeah, this is fine.
Bruce: Ah, but we weren’t’ doing anything wrong. What it was is that we didn’t have the necessary tools for the job. Jake Archibald’s 24Ways thing with no script and spacer gifs is not doing it wrong, he’s got a brilliant workaround for the fact that we don’t have the necessary tools; I really want to get away from the idea of hacks being something wrong or hacks are —
Louis: Absolutely.
Bruce: — brilliant creative workarounds where there’s an obstacle.
Louis: Yeah. I guess all I was trying to say was that it’s interesting that we now think about it somewhat differently than we used to, we used to see a hack and think, oh, that’s great, that’s all we need, end of story; now we see a hack and say, oh, that’s great, clearly we need to do something with the underlying specifications to make this possible without a hack.
Bruce: I think it’s because we’re seeing movement on the spec again, and we’re actually seeing the fact that — one of the things that HTML5 gave us was the fact that the spec was being written based upon what people actually want to do, and we know they want to do it because they’re doing it, you know, we know that people were using div id = footer, div id = header, so let’s put it in the language, that’s the great thing; the spec was based upon real world needs and problems, and it seems to me that still continues to be the case. But I just wanted to make sure that nobody thought I was dissing Jake because he’s a lot bigger than me and he’s from the Northeast of England and therefore he’s really nasty when he’s had a pint or two.
Louis: (Laughs) Alright, let it be, let the record show that no disrespect was intended. Alright, well I know you’ve got a meeting in just a few minutes, so I’m gonna let you go, but I wanted to obviously thank you very much for taking the time to come on the show and talk about this stuff.
Bruce: Thank you for inviting me.
Louis: It’s been a lot of fun, and it’s a fitting end to my year of interviews; all this stuff is so much fun and I’ve had a great time talking to all these people about the stuff that’s going on, because it’s interesting to be in an industry where nothing was going on for a long time and now lots of stuff is going on.
Bruce: Absolutely (laughs).
Louis: So I think everyone seems to be energized and it’s been great seeing everyone across the industry, regardless of what their opinions are, everyone’s energized and everyone’s excited about this stuff, and I hope our listeners are as well.
Bruce: I hope so too.
Louis: So, thanks again, and have yourself a great break if you’ve got a bit of time off coming up for the holidays.
Bruce: Thanks, Louis, and you too, and to all the listeners have a great 2012.
Louis: Awesome. Thanks very much, Bruce.
Bruce: Take it easy.
Louis: Take care.
Bruce: Bye, mate.
Louis: And thanks for listening to this week’s episode of the SitePoint Podcast. I’d love to hear what you thought about today’s show, so if you have any thoughts or suggestions just go to Sitepoint.com/podcast and you can leave a comment on today’s episode, you can also get any of our previous episodes to download or subscribe to get the show automatically. You can follow SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m, and you can follow me on Twitter @rssaddict. The show this week was produced by Karn Broad and I’m Louis Simoneau, thanks for listening and bye for now.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Louis SimoneauLouis joined SitePoint in 2009 as a technical editor, and has since moved over into a web developer role at Flippa. He enjoys hip-hop, spicy food, and all things geeky.
