The Changelog: Software Development, Open Source - HTML5 Boilerplate and JavaScript (Interview)

Episode Date: August 19, 2011

Adam and Wynn caught up with Paul Irish of Google’s Chrome developer relations team to talk about HTML5, JavaScript, CSS3, polyfills, and more.

This week's show is brought to you by Paste Interactive. Paste Interactive makes apps that help people perfect their lives. They create a jump chart for wiring content into websites, Staction for staying on task together, and Paprika for tracking your text and to-dos. Check out Paste at PasteInteractive.com. And by Gobble. Gobble has a job opening I want to let you know about.

At Gobble, you can write code that feeds people, learn a lot, and deploy every day. Gobble.com connects people with neighborhood chefs, and the engineering team at Gobble is looking to hire programmers that are dedicated to good code, learning, and skill sharing with each other. They achieve continual learning through weekly retrospectives, code review, and the occasional pairing session. If Rails, RSpec, Haml, Sass, and jQuery strike your fancy, apply today. Gobble is located in Palo Alto, California,

and they're open to relocating people from around the country. Welcome to the ChangeLog episode 0.6.7. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. And if you head to github.com slash explore, you'll find some trending repos, some feature repos from our blog, as well as our audio podcast. And if you're on Twitter, follow Changelog Show and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N. For an episode this week, talk to Paul Irish over at Google

about HTML5 and other stuff. Other stuff for sure. We're a couple of fanboys since we, I guess, talk about this stuff all the time. You perked up a bit on this episode. It's actually, you know, a lot of the shows, I mean, RVM, I get that, right? But you go to BDSM and I'm lost.

And thank God for Steve to come on that show because that wouldn't have been my place. But shows like this I can have fun with. For sure. I had a week off. We took a week down at Lone Star Ruby Cuff down in Austin. Got to meet our buddy Steve Klabnick face-to-face. He brought the house down

with his talk on shoes and how we need to support those that give to open source, like Wayne and some others that we've had on the show recently that have just poured out their blood, sweat, and tears into apps that we use every day and just give props to folks that make our lives easier. And I think that's what we're trying to do here on The Change Log is just shine a light on folks that are giving away software. That's right.

Shine the spotlight on the people that are moving and shaking this world. Absolutely. Back to the web this week with Paul, but if you've got other ideas for who we should have on the show, let us know. Hope to get some no sequel in the show soon. And I'm trying to track down the folks behind Tmux and some of the other command line goodies that you and I have gotten into lately.

So hopefully we'll switch gears a bit. That little session we had today in the terminal was pretty fun. So that'd be a fun conversation. I wowed you with the Tmux, didn't I? You did. Fun episode this week. Should we get to it? Let's do it. Chatting today with Paul Irish from Google. So Paul, for those that don't know you, why don't you introduce yourself a little bit about your role over there. Sure. So I'm on the Google Chrome developer relations team. And essentially what I do on my team is I engage with the wider web developer community

and make sure that everyone knows kind of what's capable, what are the capabilities of browsers, Like what are the features inside there, what you can get away with and basically like what, what can we do to make really like engaging, compelling experiences. And then, uh, I also publish a lot of tutorials, guides, screencasts, uh, and, and, and software to help people do that kind of stuff and do it well. So that's kind of pretty much what I do. I got a glimpse of that at Southwest. I guess you had the Google event down there where you were doing some demos up on stage.

Yeah, totally. Yeah, I got to talk about, give a brief overview of the HTML5 Umbrellas feature set and then also talked a little bit about some of the newer features in the Chrome developer tools. Yeah. You might be the best person to define this. Now we'll stop hogging the mic in a second. Adam asked a question, but HTML5, what's it mean to you?

Ah. Uh. Uh. Uh. Uh. Alex. Uh, uh, uh, uh. Alex, so I think, I think like Dion Almeyer said that it was, uh, HTML5 is everything after HTML4, um, which is nice. I, in general, like the, I'm not too pedantic when it comes to the definition of HTML5. I certainly don't think that it's what's in the spec.

Um, I'm fine with clarifying that CSS3 is not HTML5, but certainly don't think that it's what's in the spec. I'm fine with clarifying that CSS3 is not HTML5, but it's really hard to make a HTML5 demo without using CSS3 because you want it to look good. Like you're not going to release something with web sockets and local storage and not make it look good. So anyways, they all kind of get mixed up and I think that's okay. HTML5 is the term that kind of like carries the flag and has the logo and like, and that's what all the excitement is about. And sure, it's a little bit messy, but I don't think it's like, it's very harmful that we use the term HTML5 to mean things that are not technically HTML5. So I'm pretty fine with an ambiguous definition there. I'm curious how HTML5 has that military stripe logo. The CSS3 is like Air Force. Yeah. The Army and the Air Force. What's

that about? I don't know. I actually saw, where was it? I saw someone made a new CSS3 logo and they took the typography of the five and then made a three out of it and put it on like a blue badge instead of an orange badge. And it actually looked really, really good. Um, I don't know what the iconography is about. Uh, I don't, I, I, I like the HTML five logo, the other, those other smaller icons. I don't really have much of a use for myself. Um, so whatever. When you're quoting Dion, I thought you were going with the quote that he said, HTML5 is a jewel that we need to cut into a weapon.

Oh, yeah, yeah. Yeah, it's Yehuda Katz's Twitter bio. Right. HTML5 is the gem that we need to cut in. Yeah, yeah, yeah. Yeah, it is the gem that we need to cut in. Yeah, yeah, yeah, yeah, it is. Um, the gem that we need to cut into a weapon. Um, but I agree, like, uh, I think a lot of us, uh, a lot of developers are, are really engaged, uh, and really excited about the web platform. And I think, um, I think it's important that we make the web platform be, platform be competitive with what people are doing on

native mobile platforms. And, you know, I hate it when people think that native apps look and feel better than what we can do with web apps. I think that's like, that sucks. And I think that, you know, web apps, certainly, a lot of people are completely delighted by web apps. It's terrible when you hear things like that because in general I think that not only have people experienced web apps that have changed their view of what you can do in a browser, but the capabilities that someone might not even know are there. Like I was talking to one of my old friends and she was like,

yeah, I'm thinking of making an app, an iPhone app. And I was like, why? And she's like, well, it's going to be like a to-do list, something, something. But I want it to work when I'm not connected. And I was like, well, it turns out you can make a web app that works when you're not connected. And she's like, really? I was like, yeah. It might seem weird that you would open up Mobile Safari on your iPhone to access a web app even though you're not connected.

I can understand the cognitive disconnect there, but there's certainly capability that we're not exploring as developers right now. Well, the browser certainly expanded to do far more than i think the very first iteration of it was intended to do so it just makes sense that as the web progresses and as technology progresses and as the back end meets the front end and all these things start to collide as we go into this newer space of the web and how it's morphing from app to web app to you name it, that the browsers catch up and allow for a more native experience.

Yeah. Yeah. And I think it's actually interesting. GitHub is a really actually interesting example because there's conversations around websites versus web apps. And GitHub is like half and half. They were the first to really make use of HTML5 history and push state to, to do the cool URL rewriting with a state change in the transition

looks really good, works extremely well, um, falls back. It's like the most progressively enhancement-y friendly thing ever. Um, and it works, but like, I don't want to call GitHub an app because it's not just a single-page app. There are certainly pages. But it's not just a straight-up site. It's almost like a hybrid, but I don't want to call it a hybrid. It just delivers a good user experience. And that's what they're focused on.

So making a good user experience is more important to them than qualifying their product as an app, which I think is rad. Yeah, not to go too deep on GitHub and glorifying those guys because they are awesome. We do know that. But I about did two backflips yesterday when I realized I could push. What's the key win? E, to go into the editor. Right.

I was like, wow, that is just insanely sexy. And there's many times I want to just edit a readme or just do one simple commit to help somebody out. And you either don't do it because you don't want to just edit a readme and or just do a one simple commit to help somebody out and you either don't do it because you don't want to pull the repo down and do the change and push it back up and do the whole you know terminal slash push scenario then you got to just in the web browser just sexy it's just awesome but um Paul I think you're probably most known for or at least that's what I knew you for at first was, uh, HTML5 boilerplate.

What's the story behind that and how did it come about? Sure. Uh, well, so before I was here at Google, I, uh, worked at a interactive agency, um, in Boston, it's called Isobar. And, uh, it is, we, we made web, web apps and websites for everyone, everyone, for Nike and Nikon and Reebok and things like that. And I, you know, over the course of making a number of different web projects, I realized that I was always taking clever snippets files of HTML and CSS and JavaScript that made a lot of sense to just like use as a default. Kept on growing that and we kind of made it the default way that we built sites inside the agency. And then I was like, I decided that we should probably, you know, share that externally. For a while it was called front end, no, pro front end template, I think. Which is very accurate, but I didn't feel it had a really good name.

And so I was trying to find a new name. HTML5 boilerplate, because it was somewhat HM5-y, though it's mostly a front-end developer's thing. It's not specific to HM5. And it's certainly not boilerplate as far as the definition of boilerplate code goes. It's not the minimal amount that you need, but it works. It's a reference library, more or less, right?

I mean, well, so I'm fine. I think it works. Um, it's a reference library more or less, right? I mean, I, well, so I'm fine. Like, I think it works really well. And, and the idea is that it's not too codependent on, on each other and you're completely free to like pull things out of it. Um, it's documented well enough so that you can feel comfortable, um, pulling parts, but, um, but I think it works really well just like as grabbing the whole boilerplate and deleting a few things that you might not be too keen on and just using it from the start. You know, I think the important thing is to understand what you're pulling and what you're leaving. As developers, I think we are more prone than any other profession to cargo cult. Yeah, totally. Like, yeah, there's plenty of things that have just like been kind of good practice or the thing you do, uh, or the thing you don't do. And, and a lot of times we don't really understand why. Um, so yeah, it's interesting

because HMF boilerplate, you know, I, I created it and I released it as a way to save people time when starting a new project. And, um, and what it ended up, uh, also having an effect on is, is more of like an educational thing. There's a lot of techniques in there that, um, uh, a lot of people have worked on refined and, uh, and, and are smart. And we, we made sure to keep things documented well enough so that you understand it. You can go and find the links about it, read more, and figure out, like, understand the justification why you would want to do something like this. So HTML5 bullet plate, you know, it's this thing you can kind of pull things from. But at the same time, you've got some other kind of cool little niceties that fall in there as well. You're using Respond.js in there.

And something I thought was kind of cool, too, because I've been using a reset for a number of years now, but Wynn and I kind of bashed brains the other day and we're like, why do we keep resetting our CSS to this complete reset, but then we have to go back in and add bold for certain things. So you also brought in normalized CSS for that

as well. How long has normalized been in the HTML5 boilerplate? It's only been shipping uh with uh boilerplate for the last i don't know was it three weeks i think three weeks ago is when we when we shipped 2.0 boilerplate um but it was in github for the last uh four or five months how did you find out about it well uh so the the long story about it was that, you know, people have been doing resets for a long time. And the first time I started using resets, I was really keen on it. And the number of edge case bugs that popped up in only one browser, that dropped to zero so quick when i started using resets and i just like

i really knew that this was a lot better than um than not resetting at all um but as time went on then you realize you know it is kind of annoying that we have to uh put font weight uh bold on our b's and our strongs all over again and our headlines and And it's like, this is kind of silly that we're like bulldozing everything, building it all back up. And so of course the better approach and what's at the foundation of normalize is only change the things that are different and make sure that they're the same.

But what that means is that you need to take inventory of the default way that every browser styles their elements by default and then change them accordingly. And so that requires quite a bit of research. WebKit and Gecko, since they're open source, you can just go and find their default user agent style sheet. But for IE, it takes a little bit more work and same with Opera. So Jonathan Neal, who actually does the music for the Yequery podcast, but he's also a really talented front-end developer. He started digging into this. He did a lot of the research. If you go to iecss.com, you can see the default style sheets of the IE browsers and also the other browsers as well. And then Nicholas Gallagher, who's a London-based developer, started digging into this as well. So it was a

collaboration between the two of them at start. And then Nicholas took it on, uh, as his own project later on. Um, and so it's basically, yeah, it's, it's finding out the differences between the user agent style sheets only changing what you need to, uh, at the end of the day, you get a, uh, uh, style styling file that is smaller than a reset. Um, plus, uh, because you don't have to uh you know build all that styles back up and uh and it also feels a lot nicer um i think i think people are we're kind of getting tired of of feeling so redundant in uh the reset approach of styling well i i'm sad because i was just so close to being almost as famous as you because i was just about the release on reset oh yeah yeah that's a joke to like you know reset it and then there's a separate project to unreset it i was because

that's what i did every time i was going crazy every time i would reset this our styles for a new project i'd be like right i'm putting bolds and all these other things that you really do want. But, you know, I was so close. It's like Yahoo had a reset and they had a base.css, which was basically an unreset. And it's funny because it duplicates all the effort that the user agent style sheet already does.

The thing that I actually like most about the project is that now when you're looking inside Chrome DevTools or Firebug and you select an H1 or whatever or a P tag, there's not this enormous list of cascading rules that all got overridden and things like that. It just goes back. There's maybe two styles that are inherited that you see on the right-hand pane,

and that's it, which makes for a much more cleaner developer experience. I like that. And I guess probably the next thing that comes along with HTML5 Bulletplate is Modernizer, and that is such a cool project that I don't think I fully understand

and or tap into. I'm not really sure why, but I think Adobe has done something pretty cool with it recently. But how did Modernizer come about? It's funny, Modernizer. So I work on it with Farouk Atesh and Alex Sexton and Farouk launched it maybe two years ago or three years ago. I'm not sure. And I remember when it came out and I was like, I don't know.

It just has a pink website and it says it modernizes. I was like, all right, sounds cool. Whatever. And then like two months later, I was doing some work with some CSS3. And I was probably like doing something with a box shadow, and I put a box shadow on, and then I was, like, thinking about what happens when I'm in a browser that doesn't have native box shadow support. I probably actually want to do something a little bit differently. And I was like, hmm, how to do this? I wonder if, like, I could use JavaScript to, like,

figure that out. And then I, like, went back and I looked at the modernizer site. I was like, oh, it does exactly that. And I was like, cool. And then, and then I, I looked at the JavaScript behind it and I was like, oh, this is terrible. This is no. And then, so me and my friend Ben Allman, we rewrote the entire thing, um, and told Farouk and he's like, oh, cool. Okay. And then, so then I joined the project,

uh, after telling him that his code was terrible. Um, but now, yeah, it's really good. So modernizer basically detects all these sorts of CSS three things and lets you kind of style the page differently if you're, if it's not there. And it also does a really robust detection of all sorts of HTML five and other features that you want to know that are there. And it gets tricky. Like, user agent sniffing gets a really bad rap, and much of that is deserved. But one of the trickiest parts, I mean, one of the worst parts about user agent sniffing is because everyone does it their own way. And a lot of times when

you do things your own way, you do it wrong the first time and the second time. And, uh, with feature detection, it's, it's, it can also be quite similar. Um, a lot of times writing your own feature to text, you're going to do it the wrong way. Um, like detecting for HTML5 forms, um, a lot of the published techniques for that are flawed at this point. And so Modernizr is kind of the clearinghouse for feature detects. And we make sure that our detects work across everywhere that we can and tackle all sorts of edge case bugs that pop up in like, there's a really nasty one in IE8 that runs on Windows Server 2000 without the entertainment media service pack installed. You'll get an exception if you look for an audio elements can play type function.

It'll just blow up in your face. We've been using Modernizr in the changelog for a while. When we first put it on there, we were getting a lot of complaints about it trying to test for local storage. Ah, yeah, yeah. Because it tweaked that. Yeah, we changed that. There was a Safari setting that, well, there's two ones.

There's one, a Firefox problem Firefox problem. If you have your security settings really high, um, and we nerfed that. And then there was also a Safari preference where if you change your preferences, then it always asks you if, if you, uh, if this thing can use your local storage and you have to say yes. And that's equivalent to like, okay. And every single cookie that gets placed on your browser. So I don't know. But the cool thing now with Modernizr is that there is no default production ready version. It's like, you know, jQuery has the new minified version. You grab that, you're good. There's nothing like that for Modernizr. So with Modernizr 2, which we put out a few months ago, your build will be custom.

You select only the features that you want to detect. We make the file as small as it can be. And so it goes as fast as it can, and the file is really tiny. So I really like that method of distribution for now. Just curious if you've seen Rack Modernizizer from Marshall Yount, friend of the show? Yeah, yeah. There's actually, I think there's three total projects that take Modernizer and kind of enable

that visibility on the server side. And I think that's a really cool approach. It's like the old browse caps, except not doing user agent sniffing and feature detection. Yeah, yeah. I really like that. I think that's really a wise way. You have a lot

more control so you don't have to rely on JavaScript to manage everything for you. That's really cool. I think the first time that I came across your name in a memorable way, I'm sure paths crossed before that was, did you coin the term Fout or did you? Yeah, I did.

Flash of unstyled text yeah totally um that i got i got really into web fonts a few years ago and um and at the time the the behavior for web fonts in firefox was uh to um that you would get a default you would get a default, you would get a like Arial or Times New Roman or something font. And then the web font would download and then you would get the new upgraded font. And there was that little flash of going from the regular boring font to the new font. And a lot of people hated that. And a lot of people actually prefer that because the WebKit behavior is that it's all invisible and then you get the new one what's really cool is that there so there's a lot of conversations around this because people felt strongly in different ways and so

now moving forward there's a new kind of hybrid approach so what was adopted in Firefox this ships in Firefox 4 and will actually be landing as a modification to the behavior in WebKit soon, is the text is invisible for three seconds. And after three seconds, if that web font has still not downloaded, then it goes back and it goes to the fallback font and then eventually to the web font whenever that's ready. But so it's like invisible up to a certain threshold. And then you're like, okay, I actually

want to read the text on this website. It finally gives it to you. Um, and so you're, you're pretty much covered. Uh, so that's kind of where things are going. I'm convinced that the, uh, the CSS three spec is kept, uh, JavaScript developers employed more than anybody else. You know, we have the Google font loader, umader that can load fonts both from Google Font Directory or your own or Typekit.

Yeah, right. Does some of that as well if you need a polyfill for your other browsers. So speaking of polyfills, is the universe growing or shrinking? Are we needing these less or are we finding more ways

that we need these things? More, probably more. like I just saw yesterday. Uh, what is that? It's IE web GL.com. It's a plugin that, uh, enables the use of web GL content in IE, uh, which is pretty cool. And apparently their performance is really great. Um, although thinking about it, like if you're going to have your user, your IE user install a plugin to view your WebGL content, you might as well make that plugin Chrome frame so that it's so that they get all the other benefits beyond just WebGL. But I think, you know, to be honest, so I maintain this list of polyfills on the Modernizer wiki. And a lot of stuff comes in there that give you functionality of HTML5 stuff and CSS3 stuff. A lot of it's really cool.

Like I like using input type equals range polyfills so that I get a slider in Firefox instead of a not a slider. But the polyfills that I use the most are actually, uh, ECMAScript polyfills. So I really like, uh, function prototype bind and I like, um, my array extras and I like object dot keys, um, and things like that. I end up using those, uh, polyfills quite a bit, uh, more, probably a considerable amount more than the, than the more robust HTML5 and CSS3 ones. You mentioned the input type range. I've found lately I've had to adjust CSS selectors when doing forms and things.

Used to, you could just get by with the input type text and a text area. Now, it seems like you need to select anything that has a type and then opt out of input type button or submit or reset. There's just a growing number of those now. Yeah. Yeah. Styling form controls is really tough. And I mean, that's styling form controls is the reason that, uh, because it is so tough. That's the reason that, that Mozilla has not yet, um, implemented some of the new form types is because they want to make sure that you have the ability to make those look like you want. And so once they figure that out,

then we'll be seeing a few more of those coming into Firefox. So prior to moving to Google, were you a WebKit guy or a Firefox firebug guy? I both. What's the biggest jump moving? I'm assuming at some point you were a firebug. Like most of us started out moving from Firebug as your everyday development tool to WebKit. I'm assuming you're camped out in Chrome for the most part now.

Yeah, yeah. I was an enormous Firebug advocate. I gave presentations on how to use Firebug more effectively, and I collected every single tutorial that was ever posted on Firebug online. I was all about it. Because to be honest, there was a lot of features that people didn't know about in Firebug, and it was incredibly powerful, even three years ago when I was all into it. But I think the way that it's happened for a lot of web developers is they end up switching over to Chrome because, uh, they'd really liked the browsing experience.

And, uh, and then what, since they're already in it, then they open up the dev tools and then they figure out if, if they can make that work. And for a while I came for the JavaScript console, just, I found it the autocomplete a lot better than firebug. I hated the CSS inspection and things that's got a lot better lately yeah uh the one thing that still bugs me and i don't know if it if it's just me is user error what it takes me about 10 clicks to actually select element style we were supposed to click in there to put styling on a particular element over in the inspector. Yeah, it takes a good amount. So yeah, there's a few things that we're thinking about.

One of the things that we're thinking about is, so it certainly has gotten a lot better. Like a year and a half ago, if you said that you hated manipulating styles, I would totally agree with you. But now we have autocomplete on everything and tabbing between property and value is a piece of cake. And a lot of that has gotten quite a bit better from a usability standpoint. One of the things that we're thinking about doing, a small little difference in behavior between what people have seen in Firebug and what we have is that when you're clicking to

either with elements, you're manipulating attribute names and values, or in the styles, you're playing with styles. In Firebug, it's only a single click, and then you're in edit mode. And always in the WebKit Inspector, it's always been double click to enter into edit mode. And I wonder if single click is better um and so we're we're

thinking about kind of experimenting with that and seeing if that makes for a more usable product that's funny you say that because it's it's something that i kind of battle recently i like win said i pretty much camp out in either firefox and or chrome Chrome or Safari and pretty much in a WebKit or a Gecko browser more or less. And I'm using either Firebug or the DevTools in Chrome. And I find that now that you just say that, now I realize why I think Chrome is a little unusual for me is because that one small thing, it's not a huge thing, but I think sometimes I have an element selected, like I have it highlighted in blue, and then I want to jump into an attribute and like a single click should work then.

But this isn't a stage for me to give you feedback on that particular feature, but I do see that disconnect. How much of that is Chrome's influence? How much of it do you share with WebKit and Safari and every other WebKit browser? So the large majority of the commits that are going into the WebKit inspector are coming from the Chrome team right now. But pretty much 95% of their work, the work that that team is doing, is going into the WebKit level. There are a number of features that are specific to Chrome, like our heap snapshots for memory leak detection or the ability to live edit JavaScript is unique to how we have V8 working.

But most, pretty much everything else is happening at the WebKit level, which means that Safari gets that and all the mobile WebKit ports as well. So one of the features that we announced at Google I.O. was remote debugging. So you have the ability to basically your host browser or your client browser can run a little web server, which hosts the dev tools,

and you can open up the um, the dev tools in your desktop machines browser and, and then look at like the network info or like do full script debugging, um, that's happening on your, on your, either your phone or your tablet. So the, yeah, the BlackBerry playbook is already shipping with that. Currently, no other devices are. But if you're on a BlackBerry Playbook, you can totally just use your machine and debug the JavaScript on that tablet, which is really rad. And we're expecting, you know, since it's at the WebKit level, every manufacturer that ships that can have that functionality. So the next year or so, we're going to see a lot more devices with that. Switching gears a little bit to use Wynn's phrase so eloquently.

A little inside joke there. I can tell that you're a little bit into CSS3, at least from what I can tell just from your social profile. Sure. And you've created a few pretty neat tools one css3 please and the other one mother effing text shadow that's a pretty cool little website there and you kind of dive into these fun little ways to uniquely show off some very skilled design talents from what i can see too but these make micro apps look huge yeah i mean this um i like i like this for one of the styles i'm

going to compliment you there but what i want to come into is the state of css3 um and just kind of what is really fun after the people are really just using well what what is over defining in css3 and what is what is to come from css3 uh i think you know so i think you forgot mother effing HSL Which is also pretty rad I really like HSL as a way to pick colors Way better than RGB So check that out if you want Our favorite actually is HSL Picker

I don't know if you've seen that one Whatever That name sucks, man Need some work But anyways Some of the most exciting things are happening That name sucks, man. I need some work. But anyways, some of the most exciting things are happening. Yeah. Because you said that you can't even use HTML5 bullet plate and or do an HTML5 demo without including CSS3.

So there's got to be some fun things that are just being bolted on to the design experience we now have and now are capable of with this brand new tool that's being far more supported than in the past. It was just difficult to even get the most oddities of bugs fixed in your obscure browsers. But it's a whole different world there now. Yeah, totally. And we're finding a lot more bugs, I think. Because the styling possibilities are getting so crazy, you know, like I actually have a fixed landed today and web kit that I've been watching for a while, which was if you put a 2d transform, a scale on an iframe, there's some really weird clipping behavior. Oh yeah. Well, what I had is like, I do all my

slides, my presentations, my slide decks are in HMO five and on each slide, sometimes I would like just iframe in a website and it'd be like talking about, you know, modernizer for instance. So I would have the iframe, but I would want to shrink it down so that it fits inside the slide. So I do a scale like 0.7 or something. And so it looks perfect inside the slide, but there was this weird behavior. Um, so like there are edge case, uh, situations where things don't work the way that you'd expect and those get fixed, but there was this weird behavior. So there are edge case situations where things don't work the way that you'd expect, and those get fixed. But there's a lot of exciting places. One of the things that comes to mind

is Lea Beru's CSS Gradients Gallery, which showcases a lot of gradients that she's made and other CSS experts have been making. In gradients, there's just linear gradients and radial gradients, and yet they're able to make these incredible like plaid patterns and patterns that come from pottery and really impressive stuff and so I really like the people who who decide that they're just going

to take you know a small feature whether it's like box shadows or gradients and like really explore the boundaries of it yeah i was doing that i'm writing a chapter for the the sass book on uh drop shadows and so i was trying to see what shapes i could make so even from one circle i was able to create like the old simon says game via just different color drop shadows yeah i was curious on uh mother effing tech shadow here how come i can only go in one uh one axis what you can go in four axes. Yeah, one at a time. Oh, hit the WTF checkbox. Ah, okay. Well, then, yeah.

Okay, there you go. Okay, nice. Clearly, yeah. Yeah, did you make sure to hit the all the way button? Oh, the rainbows? Yeah. That was nice. And you're also welcome. We have content editable on that text, so you can just click into the text and change it to changelog.

Yeah. That looks pretty good. That's definitely going in the show notes. Oh, yeah. One of the things that I'm really, really excited about in CSS3, or CSS4, actually, is what it's going to be, is filters. Filters are coming in kind of from the SVG side of things, but it's going to be is filters um filters are coming in kind of from the svg side of things but it's going to be really pretty trivial in css so we'll be able to like in regular styles we'll be

able to say like blur uh 20 pixels and we'll get a 20 pixel radius blur on that content which is like blur is something that we wanted in css for a while or like, we'll be able to like desaturate the colors of whatever HTML content that is. Or like, do all sorts of like, the filters that you know from Photoshop, we were able to do in like just a line of CSS. I'm really excited about that stuff. Somewhere the IE team though is laughing at us.

Oh yeah, and their filters? I mean, they were right up. I mean, that API was absolutely horrible, was laughing at us oh yeah and their filters i mean they were they were right i mean that that api was absolutely horrible but true that feature set was super cool there's got to be some you know newbie developer that's getting into this and they're seeing some sort of uh you know polyfill for doing some of those things in older browsers older versions of i and just think to themselves what is direct x yeah there's there's a lot of legacy that's a bad word so on the notion of css3 i think this is kind of cool that you have mother effing tech shadow and you've got css3 please but the first thing that comes to mind

since win just mentioned his sass book he's writing is the fact that we're both just SaaS lovers in general. And these tools are always useful to us, but they don't give us SaaS mix-ins to this stuff. That's what kind of drives me crazy, that all this stuff just spits out as CSS, and it's almost as if the CSS3 world just doesn't appreciate, doesn't look at, doesn't care for what SaaS is doing for CSS3?

Yeah, you know, so I do. Okay. I really like the authoring experience that SAS gives. I love the feature set that Compass provides. I really like authoring in that SAS gives. I love the feature set that compass provides. Um, I really like, uh, authoring in SCSS. And I think that, and, and, and you might've seen that, uh, there's proposals from the WebKit, uh, team to bring a lot of the same types of things of variables and mix-ins, uh, hierarchy, uh, into WebKit's implementation of CSS

and getting that specified so that other browsers can do it. And so there was recently a face-to-face meetup of the CSS working group, and they spent a lot of time talking about if they can make that happen in the standards process. So that's moving ahead. Um, I think part of it, as far as the CSS community getting on adopting SAS and learning how nice it is and how much time it saves is like, you know, people are scared, scared of the command line. I think that like that takes care of pretty much 90% of the problem. Um, but, but, uh, but I totally agree that, um, those tools are extremely valuable, especially for this type of work.

So it sounds like you're a SAS and compass user then. Uh, um, sort of, no, I mean, sort of enough. Yes. Not often, but I would, if I needed to server side code, you sling. Yeah. Uh, Oh, I don't, I don't sling any at all. I know JavaScript and I don't know anything else. Um, not even node. Well, I mean, I could write Node. I've done like three hours worth of Node work. So there's that. But in general, I really like being inside of a browser.

And so that's where I spend my development time. I feel the same way. Switching gears to one other thing, it seems like also with propping up HTML5 bullet plate, you're really about – the core is about standards more or less. And you've got this very cool website I just found because we're doing this interview with you, which is W3Fools. And then not only that, but you also have – what is this one called? It's Isobar?

Yeah, the Isobar Web Standards and Best Practices document. I love this. I mean, is this pretty well kept up and current? Yeah, so that was with my old agency, but they've been maintaining it, and they released a new version of it like two months ago or so. So that's being maintained. That was developed around the same time that the genesis of HTML5 boilerplate

was kind of percolating. And it just has kind of coding guidelines and things that make it easier for a team to kind of write maintainable code because they all kind of follow the same practices. And I think that's wise. But yeah, you know, I think it's important that, more important to me than the semantic class names.

I don't really care for semantic class names a whole lot. I care about, is this maintainable for me in the future? Is this maintainable for the person that takes over? And if I'm developing this on a team, I want to make sure that the team can develop it without asking all sorts of questions and that it makes sense. And so I think a lot of that is documentation

and the spreading of best practices, not only within your team, but of the entire community. Right. Yeah, from your profile, it's linked to as Front End Coding Standards, which I think is maybe a little bit better name than Isovar, but that's the name of the company.

But W3 Schools, I think, I hope nobody listening to this podcast actually uses W3 Schools, but from what you say here that they're in trouble and that they refuse to swap the name because they are not in connection with W3, I think that's just super wild. But, I mean, from a standards point of view, what is it that drives you crazy about people that do things like this or don't even follow standards or just don't have any ideas about what standards are? Like you said, semantic classes. And when people talk standards, that's nine times out of ten what they're talking about is a semantic class name or something like that. Yeah, well, you know, it's really complicated.

So I think a lot of us got into believing in web standards and learned that XHTML was the right way to do things. Tables were terrible. You should write it in XHTML. All your class names should be semantic, those sorts of things. I think that now there's a lot of people finding out that that might not have been the best use of their time. And, and so there's an interesting thing there, uh, where kind of people are running into the reality of what, uh, front end authoring means and what are actual, the consumers of, uh, that, of what we're working on. Um, and so, yeah, so I'm actually really, you know, excited about people doing things the right way and doing things the best way in a way that's time efficient for them and has a big payoff. And so I want to make sure that people are developing in the most effective way.

At the same time, I don't want to see them waste time. So I don't want to see them waste time with bad documentation. And that's how the W3Fools site came about. I should say that W3Schools has gotten better. We kind of were their bug tracker for a good number of months, and so they fixed things up, and now at the bottom of every page on W3Schools is a, if you find an error on this page, please submit this form,

and it's right there on every single page, which is a huge improvement. Before, it was just an email address that was really hard to find. So things actually are better there. At the same time, I'm still a huge proponent of people looking up documentation on Mozilla's Developer Center. I contribute to it almost daily, as do many, many other really smart people. So that's where I think people should get their reference information from. Game for some questions from Twitter? Sure.

These are always interesting. When will Chrome add View Source to the View menu? Joe Devon wants to know. Wow. I guess that makes sense. It's there if you're under Developer. Yeah, I'm looking. You view Developer developer and then

you have three options one of which is view source i i think using a mouse is pretty slow bro it's command alt j right uh command alt u for the for the source view source and then j for the i'm always going to the javascript console exactly so i don't. They're not, is my answer, and learn the keyboard shortcut and stop clicking. Red Dirt JS wants to know if you'll come and speak. That sounds like in the middle of the country somewhere, right? Oklahoma. Cool. It's just north of Texas.

I'm down to come speak as long as I can. Sure. Okay. We'll convey the message that you're down. I'm down. Brian, the coder wants to know who's going to win the GOP nomination. Wow.

Um, uh, uh, wow. Did you guys see that? Ron Paul? Yeah. You guys see what's home girl something O'Donnell-y?

The girl who walked out on Piers Morgan's interview? She was like, I don't like interviews. I'm going to stand up now. I think she's going to win it. Rosie? She's got tact with. Sure. Is that Rosie? Rosie O'Donnell?

No, no, no. Oh, a different one. She's like tact with... Sure. Is that Rosie? Rosie O'Donnell? No, no, no. Oh, a different one. She's like a Delaware Tea Party. She's not actually running. But she's got promise. DJ Combs wants to know, any chance HTML5 canvas CSS sprites will allow native animation?

Adam, you want to take this one he's got a nice uh we may have been rickrolled with this one he includes a youtube link to a mickey mouse video yeah i was i i saw this beforehand i was a little curious i really native web animation right animation, right? I mean, you can, you can animate. So CSS animation, which is in WebKit and now Firefox, uh, you can actually animate a background position of an image sprite and make it animated. And you can like have like a little contra character walking across the screen and he's like walking and you can do it only with CSS. that's pretty cool and that's native web animation of course you can animate on a canvas you can animate uh anything with css transitions so we we've seen web animation for a while now i guess what's the scoop on webM? WebM is... WebM? Dang near killed him.

I don't know. So we have WebM support in Chrome, in Firefox, in Opera. We don't have it in Safari or IE. IE and Safari support H.264. And Chrome still does, actually. But Firefox and Opera do not. And if you're doing video that you want to distribute via HTML5 video, you need to be encoding in those two formats. And those two formats only. And that's just how it you need to be encoding in those two formats and those two formats only.

And that's just how it's going to be. It's like, I don't know, just like make sure that your workflow makes it really efficient to always be encoding to two formats because that's just how it's going to be. Unless you want to like manage the the flash fallback or like or whatever um which is totally an option as well if you want to do that um but yeah or you're not going to get it on ios i suppose so it takes a little bit of work to be honest like um zen coder i know zen coder and there's a few other video serving uh video services that kind of you give it one file and it makes hml5 video work everywhere for you. Those services are actually really nice.

Save you a lot of headaches. It's like web fonts. Web fonts are also really a pain. There's a lot of edge cases. And so using things like Google Web Fonts saves you quite a bit of headaches. So, yeah. So speaking of HTML5 audio and video, what can we expect advancements in the shadow DOM and some of the below the surface things we can style? Yeah. So there's a shadow

DOM set up in WebKit, but right now none of it is really developer-facing at the moment. There is some really exciting stuff going on. It's very much related. It's called the component model. And if you check it out on the What We G, the What Working Groups wiki, you can dig into the component model. And it's kind of a new way of structuring elements into reusable components.

It's kind of what we've always been doing, but it's basically baking it into the browser as a native way to build components. And I think it's really, really exciting. So right now it's being proposed kind of to the standards community. I'd love to see developers take a look into it and see if it makes sense and post their feedback if they think there's, uh, changes that should be made or whatever. Um, but it looks really promising from here and looks like a wise way to move, kind of move the web platform, uh, forward. What about WebKit support for styling those, uh, HTML5 validation bubbles?

Ah, yes. There's a, uh, on the, uh, so the wiki, sorry, the WebKit bug tracker is hosted on track and track has a wiki there. And there's this one page called like styling form controls on the WebKit track wiki. And it has all the details on styling those things. So I know Nathan Smith who made formalize. He was working a lot on those validation things. I pointed him to that page, and he was able to figure out the last of his styling woes. So that's the page that you want to check out. Sadly, I've turned them off on our page just because Firefox doesn't allow you to style them.

Although they do look nicer by default, the black ones on Firefox, the ugly pink things that come back with WebKit. So I've just kind of turned those off for now just because they're not styling. That's fine. To be honest, I'm not too aggressive on adopting HTML5 form validation right now. I think that I would not yet really go all crazy on that just yet. All right. So we're,

we're near the end of our show, which is, has just been a pleasure to have this chat with you about HTML five, CSS three, and all these fun, fun things with browsers and the future more or less. And I particularly liked when you mentioned CSS four. So that was,

I did a back. Yeah, man. CSS level four, man. It's already in draft. It coming there you go so i imagine you have to have some sort of hero out there that you just are either dying to work with on a project or throw up one of these microsites like you do for these fun tools you make like you mentioned uh mother effing hsl and tech shadowing and uh even css3 please. So sites like this are just fun things that you do.

Is there anybody out there that is just a hero to you or somebody that you like to pair with that you can mention here on the show? The person who has been blowing my mind recently is Chris Coyier of CSS Tricks. Chris has just been dominating for the past four years, writing on his blog about totally crazy advanced CSS and also like CSS fundamentals and like tackling the entire spectrum of like, uh, of web design and development professionals. And, um, really just like puts a lot of effort into sharing everything that he learns. And I think it's really inspiring to me

that he's so, um, big into publishing everything that he learns. And I think it's really inspiring to me that he's so big into publishing everything that he learns. That's something that I try and do. And he excels at that. So he is at the top of that list right now. What do you think about that new skin he's got on his site? Oh, yeah, it's hot. I told him that. So when you resize the browser, there's all these kind of transitions when it switches into the media queries. And there's all these kinds of transitions when it like switches into the media queries. And, and there's all these transitions when things kind of rearrange and the search box at the top has a 1.2 second transition as it moves from the left to the top and back again. And I was like, Chris, you really, that's 1.2 seconds is really long. And, and, and he like vetoed it. I told him and he's like, veto. So he's not changing that.

But aside from that one terrible, terrible thing, the site's really hot. It is pretty hot. It uses the new modernizer. It uses Respond. It uses a bunch of tricks from HMPly boilerplate. It's got a lot of good stuff going on inside of it. Good stuff.

Well, I think the other question we asked, and we probably have at least one more second to do it, is there anything besides HTML5, CSS3, and the common things that you mentioned that you're well known for? Is there anything else out there in open source that if you had extra time or a free moment, you're just dying to play with

that we haven't talked about today? Anything out there in open source that I'm dying to play with? Sass, Compass Yes, both of those I would also point out that one of the projects that I don't talk about too much That I'm really keen on I have a repo on GitHub

It's called LazyWebRequests And it's just things that would be really helpful for the developer community if they existed, like a screenshotting service that you could just pass it like, um, screenshot thing.com slash, and then you pass it a URL and you like say what the width is and then it gives you a screenshot back in that width, and it takes a screenshot with a really good browser so it can handle everything. There's Jeffrey Grossenbach doing that on the Peep Code blog, except he's doing it in the command line with the WebKit to PNG.

Okay. Yeah. Well, that uses pretty old legacy stuff. I posted this as something on Lazy Web Requests, and someone actually made it with PhantomJS and Node like three days ago. So that idea is already taken. But on the repo is a bunch of other stuff

that would really help everyone. So it's kind of like a bunch of weekend projects. And what's the repo called again? Lazy Web Requests? Yeah, yeah. And so there's a lot of good stuff in there, and a lot of the projects. And what's the repo called again? Lazy Web Requests? Yeah, yeah. And so there's a lot of good stuff in there, and a lot of the projects have already been, people have taken them on and basically finished them.

And so I kind of have to clear out the bug tracker because a lot of the things are done. But there's still plenty of cool stuff in there. So if you're looking for projects. Because young programmers, a lot of times, when we first get into this, you're like, I've got all this energy. I feel like I've got some skills, but what do I make?

And as I get older, I'm like, when do I have time to do half the ideas I come up with? This is awesome. And it's actually all issue-based, and they can respond to it and do a fork and check it in. It closes it out. Yep. I love the way that GitHub has grown. I mean, give them more kudos, why don't we? But I know for a while in our day job,

we used, at least the first month, we used their issue tracking in lieu of deciding to move to Pivotal Tracker. And it worked well for us. It did its job and on commit closing issues. And they've just done a phenomenal job with this in general. Very cool. Well, Paul, I think I speak for Wynn

and probably everybody listening to this podcast. We certainly appreciate the efforts that you put into your work and your passion around it and we appreciate the mother-effing things that you do, whatever they might be out there. Just thanks for coming on the show. Cool, yeah. Thanks a lot, guys. This has been awesome