Episode 151 of The SitePoint Podcast is now available! This week our regular interview host Louis Simoneau (@rssaddict) interviews Rachel Andrew (@rachelandrew), one of the co-author of Everything You Know About CSS is Wrong and the author of The CSS Anthology (about to go into it’s fourth version) about the ongoing vendor prefix saga and how that affects the future of Web standards.
Listen in Your Browser
Play this episode directly in your browser — just click the orange “play” button below:
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
Louis and Rachel cover Mozilla considering supporting the WebKit vendor prefixes for certain CSS properties Firefox already supports and how that could lead us away from having an effective set of Web Standards for the future.
Louis: Hello and welcome to another episode of the SitePoint Podcast coming to you a little bit late this week, we had a little bit of trouble getting the schedule together, but I hope it was worth the while because we have with us today on the show Rachel Andrew; hi, Rachel.
Louis: So Rachel is a web developer, will be well known to any long time SitePoint fans, she’s the author of a few of our books actually, co-authored Everything You Know About CSS is Wrong with Kevin Yank, who was the former host of the podcast, and also wrote The CSS Anthology, and you’re currently working on a fourth edition, is that right?
Rachel: That’s right, yeah.
Louis: Just putting the finishing touches now, if I understand it.
Rachel: That’s right, yeah.
Louis: We’re expecting that in a month or two maybe.
Rachel: Hmm-mm, yeah, I believe so.
Louis: Fantastic. I want to talk to you a bit about what’s new in the book a bit later, give you the chance to plug it a little bit, but before that, the main reason I wanted to talk to you is this ongoing I guess you could call it a drama concerning vendor prefixes, which came out of a W3C meeting recently, and you wrote a blog post on it about the issue for the Web Standards Project’s blog.
Louis: So, we talked about this a little bit on the podcast last week, but for anyone who’s either just tuning in, or to get a more complete breakdown of the issue, do you want to just go over sort of what happened and why it’s important.
Rachel: So what’s really happened is that because of the mobile web particularly being very WebKit-centric, you know, most of the browsers that people are using on mobile devices are running some form of WebKit, or the ones people are caring about, they’re thinking about iPhones and Android devices as well. So, web developers are implementing the new features of CSS3 using these vendor prefixes and only using WebKit prefix, when in fact we’ve got prefixes for Mozilla, for other browsers as well, but these aren’t being used. And so what’s happening is that obviously in the browsers that have support for these CSS features with their own prefix, people aren’t seeing the site in the same way they’re seeing it on WebKit browsers, which obviously for those other browser they want the site to look as good. So the danger is that what will happen is that other browsers will start implementing WebKit prefixes rather than allowing people to use their own prefixes or the standard feature, and this is becoming a real sort of problem, and so developers have been asked to really do something about it and to think about what they’re doing.
Louis: Right. So the issue came up at a W3C CSS Working Group.
Rachel: That’s right, yeah.
Louis: And I think it was someone from Mozilla who was making the point that at some point in the future Mozilla would need to implement the WebKit prefixes in Firefox just because they were so widely used.
Louis: Even for features that Firefox did support in its own version.
Rachel: That’s right, yeah. And really, as someone who’s been involved in sort of Web Standards for a very, very long time, you know this sort of brings us back to the point of a browser or an implementation sort of hanging around for an awful lot longer than it really should do, we’ve really just got to a point where we’re kind of getting rid of IE6, which has hung around for over 10 years; it was a great browser when it first came out. And we were, as developers at the time, were really excited about IE6, it might be hard to think if you’re a newer developer, because we could use a lot of CSS2, so people were just supporting IE6. You know at one point it had huge market share, there was really nothing else out there in sort of common use, and so we just built sites, or a lot of people just built sites for IE6 which is why IE6 has hung around for as long as it has. So I think those of us who are sort of the old geeks on the Web are slightly worried now that we’re going to see this happen again but with WebKit browsers and with WebKit extensions sort of hanging around for much longer than they really need to because of this.
Louis: So there are a few separate issues here. I guess one of the points that people make is that this to some extent bypasses the Standard’s Project, because a few of these WebKit properties aren’t actually in the CSS spec at all.
Rachel: That’s right, yeah.
Louis: They’re simply properties that have been added by developers at Apple or at Google; has Google also been involved in that?
Rachel: I’m not too sure, I think the common things are stuff which really are I guess making experience of mobile websites better, and so have been added for that purpose, but of course you know we do have mobile — Firefox, and Opera, of course, is important mobile browser. So, I think sort of going off and people just deciding to implement WebKit means that, yes, you know, sort of the WebKit process and Apple perhaps, or maybe Google, could start to pull the development of the Web and make it very proprietary rather than it going through the W3C process.
Louis: Right. So the idea here is that if someone — or if Apple implements a new property in WebKit doesn’t bother submitting it through the W3C to be included in the CSS spec, all the other browsers adopt it because other developers start using it, suddenly you don’t have a Standard’s process, you have various browsers implementing things willy-nilly, and if it catches on so be it, and if not, too bad.
Rachel: You know I’m all for browsers implementing features and coming up with new features, I mean obviously Apple have got a huge amount of stuff to add in terms of mobile web, and where we are now is very much being led by sort of iPhone and things; it’s not a bad thing for browsers to be implementing features and thinking of new features, but what we need is for things to then come back to that Standards process so that we can all sort of move along together and we don’t end up with a situation where we end up having to either build separate sites for different, you know, I can remember doing that sort of back in the browser wars days.
Louis: Right. An example that I’ve seen thrown around, for example to support this argument, is the case of the WebKit gradient syntax where the initial version was extremely verbose and complicated and so hard to use that people didn’t really understand it. And so that was the WebKit version, Mozilla developed a separate version, eventually the Standards process settled on something that was very close to the Mozilla version, and because they had been separately vendor prefixed it became pretty easy for developers moving forward to settle on the standard version.
Rachel: Yes, yeah.
Louis: Whereas if Mozilla had just implemented the WebKit version, or worse, had implemented their own syntax under the WebKit prefix, we never would have been able to make that kind of progress.
Rachel: Yeah. I’m quite a fan of vendor extensions, I think sort of coming from having worked through the sort of browser wars era with their version 4 browsers, I can understand why the vendor extension and things are kind of a good way forward, kind of the only way forward for browsers to be able to start implementing this stuff, try it out, let us try it out, let us feedback and say, no, that doesn’t work very well or that’s very confusing, and then come to eventually a sort of standard implementation of that feature. And I think it’s great, you know I enjoy trying out these different features even when they don’t really work in much; you know (laughter) I can’t really use it on real projects, but being able to have a play-around, see how something might work, and then feedback as well if possible to say that doesn’t work so well or what the problems are with it, because then we’re moving things on.
Louis: Yeah. Coming back to the idea of developers using these WebKit prefixes exclusively, do you have any sense of how widespread this is, because I get the feeling when I look at, for example, educational materials on the Web, that usually the authors of these materials are very clear in saying, you know, you use all the prefixes and you follow it with the un-prefixed one to make it future-proof. Now there are some cases of these cool demos of emerging WebKit features where people will just use the WebKit one and not bother to put in the un-prefixed one because it just isn’t supported anywhere else. But in the real wild of the Web is this something that’s really widespread?
Rachel: I’ve certainly seen it. I think it’s really difficult, you know, you have to sort of get out of the kind of Standard’s bubble; I think those of us who are very sort of keen on Web Standards, very keen on the open web, are going to be trying to do things the right way because we kind of care about that. But I think for a lot of people who are just building websites and they’re seeing mobile as being WebKit, which I think is often quite a reasonable assumption to make, have a quick look at the stats of the sites that I’m involved with, you know, many of which the traffic isn’t sort of web people, it’s just regular folk, you know, and the mobile landscape is very WebKit-centric, you don’t see very much else. And so I think it’s kind of a reasonable assumption for people to make to say, well, we hardly ever see Opera, we hardly ever see any of the mobile browsers so why bother. So unless people actually realize why it’s important to bother, and that it’s not just the browser support today isn’t just the issue, you know, then I think people aren’t really going to sort of engage with that as an issue at all.
Rachel: It works. I mean that’s always been the problem, you know, if something seems to work in the browsers that you know visit your site, unless you actually understand what the underlying issues are then why would you do anything else?
Louis: Right. So we’ve seen this kind of educational approach with web developers sort of work in the past, the initial push towards standards was largely driven by developers, but there was also a roll played by the browser vendors themselves.
Louis: Do you feel like they have in some sense or responsibility to not go down the road of supporting WebKit prefixes? I know, for example, I quoted in the last episode of the podcast of Eric Meyers’ blog post on the topic.
Rachel: Yes, yeah.
Louis: Where he very nicely put it from the point of view of the browser makers; obviously their concern is for the users, and if the users aren’t seeing the site as pretty as it can be then that’s the step. But do you feel that that’s entirely right? Do you feel that there might be some greater sense of responsibility from the browser makers?
Rachel: Yeah, I mean I would like there to be a sense of responsibility from the browser makers, but also I understand that their sort of businesses or their browser has to sort of be front and center for them, they have to do what people want and what will ensure people carry on using their browser, so I can kind of understand the problem that they’re in, the quandary; do they make a stand and say, no, we’re not going to do this because it’s bad for the Web, or do they say, yeah, users want to be able to see the site the same, we can do the same as WebKit, we don’t want to look inferior to WebKit because people haven’t bothered to use the extensions.
Rachel: I think that’s the sort of issue that browser makers are in, and I think that’s the point at which developers hopefully can make a difference because we can say well, no, we’re going to make sure we’re using these prefixes and makes sure every browser looks as good as it can do. But, yeah, I can see where they’re stuck and, you know, just as businesses and organizations wanted to make sure that their browser carries on being used and isn’t seen as some sort of lesser thing.
Rachel: Which, you know, I really feel — I have a real sense that we in recent years, and I guess with IE9 coming out, looking towards IE10, we’ve really got what we asked for with WaSP, you know, we asked for browsers to implement all the standard features in the same way so that we could build a site — I’ve been involved in a sort of big responsive web design project at the moment which I’ve been working on, and essentially I built is using Firefox because that’s the browser I developed it in, and I’ve looked at in IE9, I’ve looked at it in all the current browsers, and it just works, it’s all the same (laughs), and that’s what we asked for, that’s what we wanted, and it would be such a shame if having got to that point, got to the point where the standard features are pretty much implemented in the modern browsers in the same way, and new features being pushed forward through the sort of vendor extensions and in appropriate ways, it would be a real shame if we then kind of took a big step backwards with this issue.
Louis: Yeah. It would be largely a big step backwards that was prompted solely by over-enthusiasm and wanting to use all of these new features that we now have access to and that are now coming into browsers at a very fast rate after all these years of essential stagnation.
Rachel: Yes, I mean, you know, it’s a really exciting time, and I think we just need to temper that with remembering that we can actually cause some damage, you know.
Louis: Yeah, that’s a very valid point. So there’s a few various initiatives that you linked to from your blog post on The WaSP site, so one of them is Prefix the Web, which is an initiative I think which was started by Christian Helmut?
Louis: So this is an attempt to sort of go through a lot of these fancier demos on GitHub that are sort of trying to show web developers what’s possible with CSS3, and a lot of those if those are using only WebKit obviously then anyone who goes and tries to find how to do something by looking at this code might fall into the same trap.
Rachel: Hmm-mm. Yeah, I mean I said, yeah, there’s a lot of people that will just copy and paste code as well, you know, so this works.
Louis: Yeah, definitely. And there’s also a petition which is being run on change.org, sort of a pledge to the browser makers asking them to not do this, and also pledging to not do this on our sites.
Rachel: Yeah, that’s right. Yeah, I think we can do a lot by making sure people understand what the issue is, you know, and it’s not just a kind of academic thing, that there is a real problem here that we can kind of solve if we make sure that we’re doing — writing things in the right way, and hopefully we can kind of head this off.
Rachel: Saying to the browser makers, look, this is why it’s important, and we think it’s really important.
Louis: Yeah, I’ve seen a few different suggestions thrown around for ways that might help to avert this sort of vendor prefix clash, and so I don’t know what do you think about this? So one of them was to have everyone use the same thing but not be vendor specific prefix, so something like beta.
Louis: One of them was — and this is one that I kind of think makes sense, is that once a browser adds a non-prefixed version of a property, that it should remove support for the prefixed version.
Louis: Now that makes sense to me. I can see, again, how it puts the browser makers in a tight position, obviously, because removing support for something that developers are using is going to make some sites out there look broken.
Rachel: Yeah, and that’s the problem is that we should feel safe to use — I mean there are people who say, well, just don’t use vendor prefix stuff on production work, but I don’t think that’s a reality. And part of that is because the actual standard’s process is pretty slow, and, you know we’re not getting the non-prefixed version as quickly maybe as we could, you know, you sort of have things that have really been stable for a very long time, and yet still we have to use a prefixed version. So I think really what we want to see is once things have been decided on and generally everything’s using the same implementation, it would be best to be using obviously the Standard version. But, you know, I could understand that browsers aren’t going to want to pull out those prefixed versions just in case people aren’t using them in the way they’re intended and are using them for things that worked in a slightly different way originally, you know, on sites that are sort of hanging around.
Rachel: Yeah, so I think there’s various things; I think the idea of a sort of beater-type extension if we’ve got something where everyone has agreed on it, that’s kind of cool, but, as you say, that sort of stops thing where manufacturers can implement things in slightly different ways as we’re coming down on what is going to be the final standard. See, I mean we don’t want to stop.
Louis: Yeah, obviously it makes sense for these different implementations.
Louis: Again, coming back to gradients, if it had been the case where WebKit was using a beta prefix and Mozilla also wanted to use a beta prefix, it couldn’t go and completely change up the syntax.
Louis: Which I think anyone who’s worked with gradients can be thankful of the way things played out.
Rachel: (Laughs) yeah. And I think, you know, we want to encourage the browser manufacturers to put all there skills behind coming up with great implementations of this stuff, and coming up with new ideas, absolutely. We’ve got some very, very clever people, you know, working at each of these browsers, and we want all that (laughs) to be thrown into our daily work, essentially, and to come through.
Louis: So we can come to the conclusion that the best course of action for developers is to go through your sites and ensure that you’re using every available prefix and a non-prefixed version.
Rachel: Yeah, definitely.
Louis: To make sure that their stuff will go on working and to ensure that the browser makers will never be — or won’t feel pressured to support other vendors’ prefixes.
Rachel: I think so. And especially if you’re writing articles and tutorials and that sort of stuff to be — you know, I fully understand that you’re trying to keep the amount of code down, you’re trying to keep an article under a word count or whatever, but I think it’s really important that when people have cut and paste code that it’s correct, and that it won’t just lead them down this route of thinking, oh well, it doesn’t matter because it works in WebKit so it’s fine.
Louis: Yeah. And there are, of course, a number of tools available to make this easier, both preprocesses on the server side, which will run over your CSS and output it with all the required vendor prefixes so that you write it without prefixes.
Louis: So, no excuse, and I think the first step is the petition, and after that the witch hunt starts and we start pointing fingers; is that right, am I getting that right?
Rachel: I mean I think if we do — if we spot stuff that is particularly high-profile articles or sites that we’re seeing, and we know this is the case for them, I think yeah, you know, drop them a line and say, hey, this is important, can you change this, especially for people who are educating, who are writing and speaking and teaching, I think we have to sort of hold ourselves to the highest level of Standards compliance, I think that’s really important.
Louis: Entirely. So speaking of writing and educating, that segues me perfectly into talking a little bit about the upcoming book. So, for anyone who’s not familiar with The CSS Anthology, so you’re on the fourth edition now, so it’s —
Rachel: It makes me very old (laughs), yeah.
Louis: Definitely part of The Web Standards canon, it’s been around forever, and it’s a fantastic resource, but you want to explain a little bit for anyone who’s not familiar with the book how it’s structured and what it has gone into in the past and maybe what’s different about the new one.
Rachel: Okay, well, the original idea of CSS Anthology is that it would be a collection of tips and tricks, so essentially it’s all question and answer, how do I do whatever. And so it’s essentially something to dip in and out of; you’ve got a CSS problem and hopefully it will have an answer for it and essentially a copy and paste solution within an explanation of how it works. In the first edition we talked about dealing with Netscape 4, so it’s goes back a long way (laughter); it’s very funny looking through the progression of the editions and the sort of different browsers that have come and gone and been important. So, when I came to write this fourth edition, and obviously it’s a revised edition, and sometimes you do a revised edition and you really don’t have change that much, you tighten things up, you make it a bit more modern; however, as I sort of read through the table of contents from the third edition, I said, you know, this is a rewrite, we’re going to have to start again because so much has changed. And it’s not just that, obviously we’ve got a lot of CSS3, which is now possible for us to use in production, and one thing I’ve always thought with this book is it should be stuff that I would use myself, I’d happily use in a client project, because ultimately that’s what I am, I’m just a web developer, I work with client projects and other products, but I wanted this stuff in the book to always be things that people can use, not sort of experimental CSS, not stuff that needs to be used with a whole load of provisos. But, you know, we’re at a point where we can use a lot of CSS3, and there is a chapter in the book which deals with what to do if you have to support older browsers, and particularly the very old browser, things like IE6 and 7.
Louis: And 8 (laughs).
Rachel: IE8 for an awful lot of the stuff actually isn’t too much of a problem so —
Louis: Rusty, archaic clunkers like IE8.
Rachel: (Laughs) well, um, I mean, you know, I think an awful lot of the stuff that we cover actually works reasonably well in IE8, the real problems really the sort of old dinosaurs, certainly in my work I’ve had projects fairly recently where we’ve had to have very good IE6 support just because of the type of people viewing the site, so unfortunately it’s not completely gone away.
Rachel: But you know generally it’s forward thinking, it’s using stuff that works very solidly across modern browsers, of course, you know we’ll be looking forward to IE10 being released hopefully before too long, and IE8 then becomes a two-versions old browser, which hopefully will help things move on a bit. So, yeah, and not only have we got CSS3, we’ve also got a real change in approach in terms of how we’re building sites; I’m sort of really talking about responsive design. And I think although we haven’t actually got any real new ways of laying out sites, you know the actual techniques we’re using we’re still having to use floats, we’re still having to lay things out in very much the same way we have been, there’s some new stuff on the horizon which is very interesting in terms of layout, but it’s not there yet. However, while we’re still using the same tools, I think the way we’re thinking about layout is very different, and how we’re thinking about providing layouts that work for mobile devices and, you know, having sort of one web approach to design. And so I’ve covered a lot of that in sort of the chapters with layout, I’ve assumed that people are going to be thinking about working in a responsive or adaptive way.
Louis: Right. And that, I mean that’s increasingly becoming the standard, we’ve only seen maybe a few very high-profile sites adopt it, but I can’t imagine it’d be very long before we’d see a whole slew more.
Rachel: Yeah, that’s it. And obviously in this book these sorts of layout solutions are essentially one chapter, I can’t teach everything that I know about responsive design or everything that’s out there, but what I’ve tried to do is show people how to get started with making a site responsive, the sort of key tools they need. And that’s very much the approach of the whole book, you know, I get people started, I show a technique, and I hope that then people will use that and start experimenting from that point and play around a bit and see how things work.
Louis: Right. I imagine some of the stuff that must have been a lot of fun working on this book is seeing techniques that were five pages worth of delicate, nested div background image placement that became a one-line CSS declaration.
Louis: It’s one paragraph, exactly.
Rachel: (Laughs) I mean it’s brilliant, and, yeah, I mean stuff like that, so that’s been, yeah, great fun actually in doing a new edition is sort of seeing all the bits I’ve just gone, nah, we can throw that away now (laughs), which is, yeah, it’s fascinating. And, you know, sometimes people say, oh, everything — things don’t change very quickly, but actually what we’re doing has changed hugely in the last few years; I think it’s only a couple of years since I wrote the third edition, and this stuff was all just on the horizon, you know, it was there but we couldn’t really use it.
Louis: Yeah, absolutely, and no one was thinking about responsive design or —
Rachel: No, no.
Louis: — we had fluid layouts but a lot of people didn’t like fluid layouts for a number of reasons.
Rachel: Well, I think, yeah, it got to that point where people were doing fixed width because they understood people had enormous screens, and so fluid layout just didn’t really work for that, and I mean, yeah, that kind of whole debate about fixed width versus fluid, it sort of got to the point where people were saying, yeah, I don’t like those long line lengths (laughs), and so actually responsive design has kind of turned all that round now, and we can have things which work well for large screens and small screens without having that horrible long line of problem and designers getting upset about that. So, you know, I think it’s great, I love working with responsive designs as a developer, I really enjoy it.
Louis: Yeah, it’s definitely a bit more work up front because you have to think a lot more about where things go.
Louis: But once it’s accomplished you can just drag that window around forever. And I find that the — well, anyway, the weirdest thing for me is showing it to people who aren’t involved in web development, and I drag the window around, “see, look how it fits in all sizes,” and they’re like “I didn’t know that was a thing, is this good?”
Rachel: Well, the issue, and I’ve got a 14 year old daughter, and I always show — I’m showing her the site I’m currently working on and saying look at this, and she’s got an iPad and a Blackberry, because that’s what all the teenagers like, so, but I was showing and I was dragging the window around, and she’s like, “Doesn’t everything do that?” “Is that not just normal?” Because she kind of — you know, she sees websites very differently, I think, as a child, and being very used to mobile devices, and it seemed logical to her that some things should display differently no matter what you’re using.
Rachel: It seemed strange to her that things don’t (laughs), and I thought it was quite interesting, you know, sort of kids coming up and just get used to the fact that things work on phones, and to me it’s quite exciting, quite amazing.
Louis: Yeah, well I guess that’s true in any technology or any field, right, you come to it as a user expecting it to just work, but when you’re the implementer you get interested in all the little tricks that are required to make something feel like it just works.
Rachel: Yeah, and, you know, it’s really nice, at the moment I’ve got this little stack of devices on my desk which I’m constantly going through and looking at the site that I’m working on, and it’s actually really enjoyable to feel that you are presenting that nice experience no matter what people are using, and that’s something we’ve always tried to do, but I think we’re really kind of getting to a point now where we’ve got more tools to do that, and I think there’s sort of new things coming up for CSS layout as well that will make that even easier, so we are somewhat tied at the moment to things like source order and where we can actually put things. So, yeah, it’s an exciting time, it really feels at the moment like we’ve got so much new stuff, you know, going back to the vendor prefix issue I think it’s just making sure we use this new stuff responsibly and still care about the things that we’ve always cared about, caring about standards and caring about accessibility and the things that, you know, well, we get excited about all the new shiny, to do that in a responsible way in a way that moves the Web forward all the time.
Louis: And not forward off a cliff, forward in the direction we want to go in a safe and productive future.
Rachel: Yeah, I mean that’s it, and you know I’m really excited about the Web at the moment, I think that there’s lots of really interesting stuff happening.
Louis: Yep, and I keep saying this every time someone comes on basically, and we end sort of at the same place where the guest is just saying this is all great and wonderful and I’m really excited, and it’s fantastic to hear this sentiment echoed so consistently across such a wide range of people working in so many different areas of the Web.
Rachel: Yeah, and I’ve been to the Web Conference and things recently, and talking to a lot of people who were sort of around my age or have been doing this for as long as I have, and everyone just seems really kind of, yeah, reinvigorated and excited about what’s going on at the moment, which there are some really great minds out there in terms of people thinking about the Web, and it’s good to see older people as excited as sort of new people coming in who you kind of expect to be enthusiastic and excited because they’re new and they’ve just found out about all this stuff. But I think that mix of younger people and new people coming in with all their sort of ideas and enthusiasm, and those of us who’ve been around a long time and perhaps can temper that with a bit of we don’t want to go down this route because we did last time (laughter). I think that’s great, and the fact that everyone’s excited about it from all their different viewpoints is really important, and I think will sort of push things forward in good ways.
Louis: Yeah, that’s fantastic. So, I wanted to thank you so much for taking the time to come on the show, I know it’s a little hard to work out time zones, especially with Australia and the UK are particularly difficult, but very much appreciate it, I want to wish you all the best of luck on the book if you’ve got any work left.
Rachel: Yeah, it’s getting there.
Louis: Fantastic. So to anyone listening, The CSS Anthology fourth edition will be out soon with SitePoint, so keep your eyes and ears peeled. If people want to find you online do you want to drop some links to either your website, Twitter?
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.
Louis 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.
7 Habits of Successful CTOs
"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.