JM: Welcome this is the fourth interview on Web Payload and todays guest is the CSS wizard, it’s Harry Roberts
HR: Thanks for having me.
JM: Can you tell people a little bit about yourself?
HR: I’m a front end developer from the UK, i do a lot of work with CSS, front end architecture, a lot of writing and speaking about big front end, big websites and products. I now do that on a consultancy / freelance basis. I used to work at Sky for the last few years. So thats me in a nutshell.
JM: Talking about with your at Sky were you using Sass there, or version control? How did that fit into a larger team?
HR: We did use Sass, i introduced that, quite late on actually. We started using Sass in a massive code base. We had several products under the same git repository and the Sass in a tiny directory which made up part of that. I think version control was very well done at Sky, i actually learned everything i know about version control when i was there. It was an enormous project. I think the repo has over 18,000 branches, but it was handled really well the way we tied version control with tickets for new features, as well as bugs and that kind of stuff. It was a really interesting environment to work in. It was enormous, dozens and dozens of developers working on the same code base with well over now 19,000 branches.
JM: Wow! What are some of the most common newbie mistakes you see in CSS?
HR: There are so many, but the problem is, the biggest offenders that i come across probably aren’t even newbie mistakes. These are things from developers that have been working for years and years making similar kind of mistakes. The desire to avoid using more classes in your mark up, can really trip developers up and work a lot harder for people.
JM: Sorry to interrupt, do you mean using a single class and that’s it?
HR: If you think about the advice we were given way back, in 2004 when the web standards movement really took off. A lot of it was about super semantics class and ids names and using as few of them as possible. This idea that your mark up should be super neat and clean. Things like that, it was well intentioned but a lot of people that enter front end development thats the first thing they read and they cling onto that too much in my opinion. So i think, thinking in too much of a perfectionist point of view, rather than a pragmatic and powerful point of view is a big fundamental mistake i see quite a lot. Really specific things as well, someone Tweeted me the other day using shorthand CSS for things, like the background rather than using the more verbose background image property. Even things as simple as that can trip developers up. The background shorthand can completely blitzing all the other background related properties. So a lot of the things that i see as fundamental mistakes aren’t really all that newbie. More mistakes that we were told were a good idea a long time ago that people cling onto too much.
JM: So what are some of the most exciting things that are coming to css, i know there are a lot!
HR: I’m particularly interesting in Flexbox, because that solves so many problems, so many layout problems will be solved with FlexBox. But ironically a lot of the FlexBox spec has been modelled on table layouts. So it’s a new spec to head back to table based layouts. But its got me quite excited. Unfortunately with the work i do, or have done for the last few years i haven’t managed to touch most of the bleeding edge CSS stuff, so there are probably loads more that i aren’t aware of but FlexBox is a particular favourite.
JM: The problem with FlexBox in my little experiments anyway is that there is no background / you cant fall back to anything there.It’s Flexbox or nothing as far as i can see, is that right?
HR: I’m not sure, i presume you can put in some display table property to catch some of the stuff but it’s such a vast and massive change, from what we have already, that proper fallbacks would be quite complex. As well the browser support has been really shaky as the syntax keeps changing, the spec keeps changing. I think Chris Coyier has got an article that sums it all up and it’s a complete mind field. It will be cool when it gets standardised and rolled out more widely.
JM: It’s pretty cool and you can do some things that you simply cannot do with traditional CSS or CSS 2, or whatever you want to call it.
HR: Yeah i was at Frontiers and i’ve had just a complete mind wipe and i can’t remember the girls name, i follow her on Twitter and everything but she gave a fantastic talk all about FlexBox and the kind of stuff you can build is so powerful, its really cool. If you have show notes ill give you the url.
JM: It must have been over a year ago, although it doesn't seem it and you had a blog post about using only classes and not using ID’s.
HR: One of the quickest ways a front end project begins to spiral from a CSS point of view and particularly on a larger project is because of specificity. I struggle to say that word.
JM: Me too!
HR: It such a tiny but troublesome aspect of CSS, Louis Lazaris a really good dev who runs Impressive Webs once said that he wishes that specificity didn't exist. You get a selector that is really heavy, using !important to override it and !important again. It’s a sign of of getting into a specificity war. It’s a real simple quick win not to use ID’s and keeping your specificity loads lower. A lot of people get really angered by that outlook. People really cling onto this advice given 10 years ago and find it really hard to let go. A real simple bit of low hanging fruit that you can avoid using ID’s and you can save a big chunk of dev related headaches. A lot of people don’t take too kindly to that one.
JM: Zeldman came in and said something , he was pro ID’s from what i remember
HR: It unfortunately comes back to the semantics thing, he was saying things derive meaning from your classes and ID’s so you should use an ID to aid semantics. I believe this was the just of his rebuttal but unfortunately if you go and look in the hTML spec it actually says that machines derive no information from ID’s whatsoever. So neither of us are right or wrong. If you want to go and use ID’s go ahead but i advise against it but that doesn't make me right. It’s quite a hotly debated issue and i think Zeldman’s rebuttal was centred around the value importance of semantics and what an ID signals with regards to uniqueness.
JM: What about using an ID on a body tag. Same idea, you could use a class instead?
HR: I wrote another article and it didn't make sense out of context, i mentioned something on stage in Germany and it got Tweeted out of context and i tried to write a follow up article to try and capture the confusion and i said if you want to signal something is unique and something only being used once then use a name, using a class, but name space it with class=”id-classname” if you really want to show something is unique prepend it with something rather than using an id. It doesn't matter where you use an ID but it always much higher specificity than a class. Infinitely so in fact so i would always shy away from them in css. The other thing i hear is that i mean don’t use them at all, use them in js if you need to and use them in your mark up as fragment identifier but purely from a css point of view they are more trouble than they are worth in my experience.
JM: There an interesting resource with illustrations about specidctytf [specificity] (haha i can’t say that word either) ill put the link in the episode notes. What are some of the things that people can be using now that they thought they couldn’t?
HR: Well it completely depends, i haven’t been able to touch some of the bleeding css stuff because of the nature of the product i have been working with. Even at Sky where you have to support a wide array of customers and there browsers we were making use of die hard or border radius, real simple stuff that people are already using but we took a die hard stance on that if you are not using a supported browser then you can’t have your rounded corners. Things like SVG’s, i guess the tail end of IE is dieing out now, so using SVG’s a lot more
JM: One thing with SVG’s that i’ve spotted is some of these file sizes with SVG’s are ridiculous, i’ve seen some footer images and were are talking about 500k and you can get a whole site into that. So that’s 1 of the things to watch for with SVG’s. There must be ways to optimise them
HR: There is a tool called SVG’ optimiser and because they are plan text you can minify and gzip them. So you can get loads back out of them that way but i’ve never came across as any as big as that, thats quite obscene.
JM: Yeah it took me, i was like what is this. In your days at Sky what kind of browser support are you falling back to there, you wont be supporting IE5 but IE6 still a number?
HR: It’s really cool at Sky, i worked at the betting and gaming arm and we has a different set of rules to the rest of Sky. Each division of Sky was self governing from a dev point of view. As soon as i moved to Sky i said lets just not support IE6 because the numbers were so small it would of help as back too much with people in decent browsers, so we got rid of IE6 really early, pretty much straight away.
JM: When was that Harry?
HR: That would have been 2011. i say really early on but i mean in my time. About a year later we were looking into IE7 stats and all i got at first was the raw number and it was something like tens of thousands of people per month, and i was like thats too many, we cant drop IE7 support. But as it turns out and a site like Sky Bet.com tens of thousands is still only about 1%. So we managed to drop IE7 support. So we just did support IE8 which is actually a fairly decent browser in many respects. IE7 was the last bad IE, our browser support was IE8 upwards and the most common browser was Chrome which was really cool, the majority of out visits was Chrome users. Sky is investing really heavily in mobile at the moment so the last 9 months i was there i didn’t touch a single desktop browser. We worked on mobile only specific products. We were supporting Android 2.3 and above and ioS 4 upwards and outline browser either side of them. As customers went i was really impressed how switched on they seemed to be. We had a lot of users in decent browsers which is really nice
JM: What about some of your browser testing there when you are talking about Android and iPhone.i guess you were testing on native devices, how devices did you have and how did that work?
HR: So we had a lot of devices but the company was that big that we never had enough. there were always squabbles over who is using what devices on which day. Each scrum, we were working on several products in tandem and each Scrum would have their own device pool, but we would always end up borrowing each others. We had tons of devices to hand but one of the biggest things that we did on mobile Sky Bet was that we completely paired it back and went real simple, nicely designed but not over the top. So we took it back to such a simple skeleton that we could support pretty much every browser from the offset which was a really clever and wise decision. Theres a temptation to overly design things and we went the complete opposite way and took it back so simple it would have been hard to get things wrong cross browser.
JM: When a new device comes out, there is going to be quite an uptake to that but how far back do you need to go on mobile devices? When the original iPhone came out, are we talking about going back to that? What kind of numbers on those early devices, are people still using them?
HR: I couldn’t give you any numbers off the top of my head but i do know it was definitely the minority, the large minority. We noticed a really positive uptake on ios7. So the majority of out users update their browsers quite frequently. We didn't need to support much in the way of legacy. In a company like Sky the decisions have to be backed by numbers. So we can constant updates, we had a browser road map mailing list that went round. We would constantly look at the numbers and decide to snip older browsers off. We were quite lucky in that we kept a up to update browser list.
JM: You said that you got your other guys onto Sass, was that an easy sell?
HR: So a bit of a confession i messed up with the politics of this because i didn't get how big a deal it was initially. I was the only front end dev at Sky, so i was pretty much the only person writing Sass anyway. And as a result when we were starting a new project i decided to do it with Sass, and i just went ahead and started using Sass and then the problem came that our build process, and it didn’t use Ruby at all in the stack so i just introduced a dependancy on that, and completely without thinking and all the dev guys were like can you not use Less as that uses node as we already have node in the stack. We had gone a bit far at this point, the guys were real good and they sorted it out so we could start using SASS at build time, but it wasn't painless but it was entirely my fault because i didn’t realise out build process didn't have any Ruby stuff in it. We built an internal toolkit which is entirely built on Sass.
JM: So you are now Freelance, when did you leave Sky it wasnt that long ago was it?
HR: It was no quite 2 weeks ago, a week and a bit ago was the final day. Quite new to the self employed lifestyle.
JM: and you have picked up work ok?
HR: Yeah i’ve not done any client work yet, as i’m chilling out for a couple of weeks and sorting out the admin side of things but i’ve had a lot of people in touch about workshops and stuff which is really cool, because i’ve spent the last 5 years on the shop floor, a developer kind of role, in the trenches kind of thing, i’m really keen to try and take a more educator role, which sounds really pretentious, but i like the idea of doing my own workshops, so there has been a lot of interest around that which has been really nice.
JM: Fantastic, i guess you don’t want to be doing solely workshops but try and split your work i guess?
HR: Defientely, i’ve got a really nice guy got in touch the other day and we had the best Skype call, it was only 15 minutes. It was like “Hey do you want to come and work on a product with me in Germany” and i was like “Oh yes, great” and he said “End of the month”, “Yeah ok”, and he booked my flights. So i’m going out to work with the guy and i still get to do some hands on dev which i’m really excited about which is inter dispersed with workshops and talks.
JM: You have a great blog and you blogged that you had a mini break down unfortunately, can you go into a bit about that? And give advice to people that are potentially going to run in to the same problems.
HR: I don’t know if you call it a breakdown or a tipping point. I had been working flat out for a while. As well as working a full time job with Sky, every CSS Wizardly thing, every talk, every bit of open source was completely on the side and it was nothing to do with my day job at all. I was working a full day, coming home and writing talks then going to give talks in other countries and then coming back to work the next day. It was all a bit hectic and i had a particularly full on 2 weeks and i was literally all over the place as well as working my day job. It all came to a head unfortunately on stage at a talk i was giving in Liverpool.
JM: The worst place
HR: Yeah i know and the irony is that, the talk i was going to give was going to be about not working too hard and making sure everything you do counts towards something. The irony was that i didn't get to give the talk. I got on stage and within about 3 minutes, i said to the audience that i think i’m going to feint and they all laughed because they thought i was referring to the temperate in the room, but no guys i’m really going to and i didn't get to finish my sentence and i went and some guys caught me from the front row, it was pretty embarrassing.
JM: They could have thought it was part of your talk.
HR: Yeah a bit of PR, it was insane, and to add to it i had handed in my notice at Sky that afternoon and i was still reeling from that, and leaving a steady full time job, and it didn't help that i had to hand in my notice into someone that had become such a good friend, and i was straight on a train over to Liverpool and then it all came to a head on stage.
JM: Yeah an absolute nightmare.
HR: Yeah and you mentioned advice to people to avoid the same thing. The whole thing i was going to speak about at the talk was that you can do all this stuff, this open source, talks and everything but i wasn’t making it count for me, i wasn’t doing anything to make it pay off. I was running myself into the ground but i was going to the same office every day, getting paid the same amount of money every month. It didn’t matter if i talked at a conference or watched Eastenders i would have still got paid the same amount of money. So all the talks i was giving weren’t amounting to anything.
JM: You say that but now that you have gone freelance you are seeing the pay off now?
HR: Yeah totally, so right there and then it wasn’t doing anything for me, i was having this weird double life of flying and giving a talk, it’s an amazing privilege but then i would come back and just work a regular job. It was this weird double life that i needed to start making things count for me and that’s why i handed in my notice and started enjoying things more. So my advice is if you are writing blog posts and giving talks or doing open source work make sure its going to amount to something before you end up pouring hundreds of hours into something and wearing yourself out.
JM: Yeah, don’t work to hard folks.
HR: Yeah, there is a massive difference between working hard and working too hard and you should never work too hard.
JM: Yeah totally agree. You also have a little side project called Inuit, can you talk a little about that?
HR: Inuit is a Sass based, object oriented CSS framework that i gave it’s first proper proper release about a year ago. I really into object orientated CSS when i moved to Sky and liked the problems it solved, so i decided to write a framework around it. I hadn’t realised until recently how well inuit had taken off. It’s just a tiny little unopinionated library that doesn't do any design work that doesn't style anything visually because i believe that should be left to the person implementing it. So i built it and i haven’t touched it in 5 months and i feel so guilty, but i’ve just been so busy to work on it but in the past few weeks i’ve started to hear things like a recruiter got in touch with me and they said “Listen Harry , we have got someone here that wants someone with inuit.css experience and we thought we would come straight to you” “holy smoke thats amazing” There are people out there that are hiring that can work with inuit. And the guy that wants me to work on his site in Germany wants to rebuild his app on inuit. So im really amazed it has taken off so well and in the same breath i’m feeling guilty that i have left it untouched for so long.
JM: Your hard work is definitely paying off now?
HR: It’s starting to which is good.
JM: Great, so you mentioned something interesting there, that the styling should be left to designers, so your against a boilerplate or something like that? Or Twitter bootstrap. I personally agree with what you have said, there are a lot of guys that will just chuck in your third designs and thats the design and thats not the way it should be. Whats your thoughts?
HR: Each have their own use cases. I wouldn’t every charge a client that i had built something on bootstrap. It just doesn’t seem right to use something off the shelf.
JM: Totally agree.
HR: However, if you look at the number of Github projects and you have a software engineer and a genius when it comes to programming but completely useless when it comes to being a designer. Bootstrap is useful when it comes to something like that, because they can put together a half decent looking user interface. It’s nice they can get something off the shelf. So it’s definitely got it’s use cases. The reason i shy’d away from packaging up any cosmetic design because if you want to use a framework to any real benefit you don’t want to be deleting styles that are already there from the developer or person that runs the project left in. A lot of frameworks become hard to use because they come so opinionated and design focused. I think a framework should be, well it should be just a framework and allow you to work how you want.
JM: Modifying your own is slightly different, i’ve heard horror stories of agencies passing of modified boot straps as unique design and that’s non sense.
HR: There are use cases for each, the problem with Bootstrap and things like that is not the project itself but the fact they are reffered to as frameworks and i wouldnt say that bootStrap is a framework, i’d say it is a component library, it comes already designed, it’s not a framework at all it’s a library of components. So yeah i think Inuit tries to be a framework in its truest sense.
JM: Yeah, we better wrap this up soon and i’ve one last question and it’s very open ended but it’s something you have learned from a recent project?
HR: I won’y so a specific project if that’s alright but what i will say is my stint at Sky has taught me a lot of things and the best thing i learned at Sky and every developer should learn this at some point is that you are not there to write code, you are employed to be a developer and to write code to an extent but there is a lot more to websites that the code behind them. You have to be a lot more product focused and pragmatic. I entered Sky with the thought that every line of code should be perfect and it should be a joy for someone to read, whos poking through view source. i think the big thing i learned was how much i didn't know and how much more there is to being a developer. That’s the thing i’m really keen to get across to people when doing workshops. Yuo might be employed as a developer but there is so much more to your job, at the end of the day we are all focused at building a site or a product and we not focused on writing the code itself. It sounds a bit pretencious now i say it out loud but something along the lines of that, thats the biggest thing i learned in my recent work.
JM: Great advice Harry, You were talking about your workshops, you have got one planned at the end of the month and any others?
HR: Yeah i’ve got one at the end of the month in Leeds, which is handy because im based in Leeds and i’ve got one at the begining of next month in Zurich which i’m really looking forward to, that’s with the Smashing magazine guys.
JM: Oh yeah great stuff.
HR: I’ve never been to Zurich either, so i’m really looking forward to that.
JM: That will be fun.
HR: Yeah it will be.
JM: We better knock this on the head. How do people keep up with you?
JM: Thank you very much Harry, i really appreciate it.