Never, I can't imagine writing code while listening to music, I'd find that very distracting. Background noise that isn't related to me isn't a problem - I work very well in coffee shops and on planes.

I think if you work on the web you need to know HTML, CSS and JavaScript to some extent. It's great to specialize and to get really good at your core skills but just to be able to work with the rest of your team well it is worth becoming reasonably well-rounded. HTML, CSS and JavaScript are the bit the browser sees, and you can have the most amazing backend but it will be let down if the frontend is clunky.

I'd also say that often people who have managed to avoid the frontend for a while are pretty surprised when they see what is now possible. I love presenting on CSS to groups of backend folk, as quite often they are blown away by the stuff we can now do on the frontend, and get quite excited about it.

Thanks :)

And the next 10 years? I really have no idea. 10 years ago we were imagining a future where everyone had fast connections and huge screens. What happened? Everyone got tiny mobile screens and started accessing the web via mobile data. I hope however that whatever comes next is still as interesting and exciting and that I'm still involved in it as I am now - that would be cool.

At this point the specification has become a Candidate Recommendation and so is not going to change hugely at this point. There are very comprehensive implementations behind a flag in Chrome, in WebKit and in Firefox. When grid is shipped in browsers it is going to be shipped in a very solid state cross browser, so there will be no reason not to start using it with appropriate fallbacks for older browsers.

CSS itself has built in support with Feature Queries that will mean we can write code for browsers without grid support and progressively enhance for those who do. So I dont think you will need to wait until 2018 assuming we see grid shipping in early 2017. As with everything though that will depend on the profile of the people who visit the sites that you build, and the kind of designs you are implementing.

In terms of learning however, you won't be able to make the assessment as to whether you can or can't use Grid if you haven't yet learned it, so it is definitely not too early to start to learn how it works. I've provide a whole heap of resources, including videos over at http://gridbyexample.com.

I began right back when CSS was first introduced in browsers. I remember telling Drew (my husband, and other half of my company) that I wasn't sure it would catch on as it seemed a bit weird compared to using font tags. However I was converted by being able to make a change to fonts in one place and it change everything on the site!

I don't think I have a favourite browser, I don't use Safari because it's not a great browser to develop in but I use Chrome and Firefox fairly interchangeably. I agree with Lea that Safari is an issue because it is forced on people, and is now slow to update in comparison to the other browsers. I think browsers becoming Evergreen has been a great thing for the web, it would be good if Safari also started working to a faster release schedule.

I just continue to work when I'm away, I essentially just shift my office to a hotel room somewhere.

The biggest issues are really around planning for not having connectivity. So I have tasks in OmniFocus that have all of their related materials collected so I can work on those if I can't get online, and I make sure I keep that list topped up when I'm on the road.

I think it's the difference the software has made to the people who use it. I often speak to people at conferences or they send us an email and tell us that Perch has transformed their business. Perhaps they have been able to offer a CMS for the first time, or it has enabled a more efficient way of working. Often people tell us that they don't spend half their day handholding clients through using their CMS since they started using Perch, that gives them time back for more fun and profitable work.

As a software developer and business owner seeing the thing we make help other people build great solutions and run a better business is an amazing thing. We're not changing the world, but we're helping some folk do good stuff, and I like that :)

I'm not actually all that keen on the idea of magical, instant support. Watching the development of grid layout over the last four years has shown me how specifications get better for having time spent on them by a range of parties. I wrote a bit about that process last year rachelandrew.co.uk/archives/2015/11/03/three-year…

If I can change one thing, I'd like more people to get involved with that process. I'd like to see more web developers and designers taking a good look at emerging specs, the things that are hidden behind flags, and offering their thoughts and feedback.

If anything CSS is becoming far more complex and capable and I think there will always be roles for true specialists in HTML and CSS, architecture and accessibility. The key thing is that if you are going to specialise you need to really specialise, you need to be a real expert in your thing and be able to demonstrate why an organisation needs that specialism as opposed to having someone who is more of a generalist.

I think the biggest challenge for us with Perch comes in terms of what we think is great about the solution and what the average customer values.

For example we initially shipped without any kind of "WYSIWYG" editor, we personally think that Textile or Markdown in combination with structured content is a far better solution. However a lot of our customers want to put something that looks more like a Word Processor in front of clients, so ultimately we offer those things as plugins. We try and be opinionated and develop what we feel is the best solution, but also give people different ways to use the system.

Perch is based on a very traditional PHP & MySQL stack, because that was what was available on the shared hosting most people used when we launch and that they still use now. I don't think there would be a better stack to launch something brand new on now, assuming you want mass adoption.

Things that have changed in a big way however are that we launched Perch pre-responsive design. The idea that people might want to edit sites from a mobile device wasn't on the radar 7 years ago. That has obviously changed and we've had minor redesigns over the years to help with that but our current redesign puts editing from phones and iPads as a first class citizen alongside desktop, so we are looking forward to shipping that.

The basic difference between Flexbox and the CSS Grid Layout module is that flexbox is designed for 1 dimensional layout, that is laying things out as a row OR a column. Grid is designed for 2 dimensional layout which means columns and rows at the same time.

Rather than repeat myself, I have a blog post and code on this very issue which you can find here rachelandrew.co.uk/archives/2016/03/30/should-i-u…

However I'm not sure whether by "traditional CSS grid layouts" you were thinking about a float based layout. The difference between flexbox and floats tends to be most apparent if you want to align things, which is what flexbox will give you. You need to take some care with flexbox that you don't get the content shifting issue that Jake describes here jakearchibald.com/2014/dont-use-flexbox-for-page-…

Until we have grid layout in browsers then I think most of us will content to use a mixture of float based grids and flexbox, and just test to make sure that what we are doing works well on slow connections and also with older browsers. I don't have a "decision checklist" because every project is different. You have to look at the audience for the site you are working on and the design you need to implement and make those choices on a case by case basis.

1. CSS was new when I started with it, so really when it started to appear in browsers I began to play around with it!

2. Perch came from a need we have as a company, we mostly did client work for design agencies rolling out custom CMS projects based on a larger framework we had developed. There kept coming up a requirement for something that had the same focus on structured content but was quick and simple to drop in. Solving that problem meant developing Perch v1. So it really was our requirement that we then realised might be useful to other people as a standalone project. The first customers were people who signed up to a mailing list we put on the holding page - some of those people still use Perch 7 years later.

3. It's very important. Firstly for your own career, if all of your skills are tied up in one framework and that stops being popular you are going to be back to square one having to learn something new. Learn the core technologies and you can have a lot of confidence that you'll be able to move between things.

Also, if you don't understand the technology, it is very hard to be creative and come up with truly new and innovative solutions working with an abstraction that gives you a limited subset of the power of the underlying technology.

Lastly, unless you understand the edges of what is possible with CSS, you are unable to offer feedback to make CSS better. The CSS Working Group are keen to hear what people want out of CSS, browser vendors want to know if you find bugs or which parts of the platform they should be focussing on. If your view of CSS is only what is provided by a framework then you aren't in a position to do that, and this all gets better the more of us push to get the tools we need to do our jobs.

I'm not a huge reader of technical books these days, mostly because the most up to date information can usually be found better online. That said I read pretty much anything that comes out of A Book Apart and not just because I'm one of their authors. I like the short, focussed approach of those books.

I like books about planes and travel, I recently read Skyfaring by Mark Vanhoenacker, who is an airline pilot and writes about travel and the business of flying in a lovely way.

I read books about running, Eat and Run: My Unlikely Journey to Ultramarathon Greatness by Scott Jurek is excellent. Also Life Without Limits: A World Champion's Journey by triathlete Chrissie Wellington is a good read.

Fiction, I have always loved the books by Colette. I studied music theatre at college and wrote a musical based around her life and some of her earlier books.

I think every project needs to be assessed according to what is best for that project. Sometimes a third party CSS framework makes complete sense. Most recently I used Foundation for the Perch documentation, the important thing for that project was to have something straightforward that would burn up time better used improving the actual documentation.

I think the issue with frameworks comes when they are used without considering if they are the right tool for the job, or if developers are learning how to use a particular framework rather than learning CSS.

I think the frameworks fulfil different purposes for people. It is easy to think that these things are used by non-coders or people with less experience with code who want to avoid having to deal with CSS issues. In my own case, as a developer rather than a designer, the reason I like using them is because I feel as if they will save me from whatever I'm building becoming all a bit "designed by programmer"! I'd love to have a "framework" that didn't involve any code at all but instead gave me some rules about typography, the grid, colour choices and so on that I could follow.