Last year I wrote up a wishlist of CSS features I'd love to see make there way into browsers, but it never got released. This year I've come back to it and thought I'd release it with notes of where we got to over the last year.

Got any ideas not listed? Let's talk about them in the comments.

My focus is on functionality/effects we can already achieve, but in less than ideal ways. Luckily, many of these are things that are coming soon!

Element media queries

Like media queries but at an element / selector level. This makes CSS snippets much more portable.
e.g. http://marcj.github.io/css-element-queries/
I'd also started a simple project for this back in 2012 but it used jQuery https://github.com/stilliard/jquery-responsive-containers
Which was inspired by this post from 2011: http://blog.andyhume.net/responsive-containers/
Looking at how CSS-Element-Queries does this, that's pretty close to perfect but I'd still love to see this built in as then sharing modules that auto adjust to the area you give them is amazing!

Update: There's been a lot more talk about this over the last year.
Here's a great write-up of the current state of Element Queries.

A CSS property to handle clearfix

Commonly solved issues with classes are making their way to official css property support. Such as the flexbox and css grid extensions are allowing us to go away from having to use grid classes. This new breed of properties stays more true to an original vision of CSS as being a layer over the content without needing much change to the original content to apply it.
The new display: flow-root; property gives us the .clearfix hack without needing to add class="clearfix" to all elements needing it. Sweet!

Read More:

• https://rachelandrew.co.uk/archives/2017/01/24/the-end-of-the-clearfix-hack/

Update: In 2017 we saw Chrome & Firefox implement this! -> https://caniuse.com/#search=flow-root

Section depth selector that understands document outline

e.g. first<section><h1> vs 2nd level etc.
Similar to https://github.com/w3c/html/issues/774#issuecomment-278404905
https://css-tricks.com/document-outline-dilemma/

Update: Personally this has been less of a concern for me over the last year.

:matches() / :any() pseudo-class

The ability to write a single selector that handles multiple possible inner values is very powerful.
A simple example would be table styling for td & th elements.
Rather than:

.fancy-table th,
.fancy-table td { ... }

We could write:

.fancy-table :matches(th, td) { ... }

https://developer.mozilla.org/en-US/docs/Web/CSS/:any

Update: Safari is currently the only browser to properly support this but fingers crossed for better support this year. Great write up of this feature on CSS-Tricks -> https://css-tricks.com/almanac/selectors/m/matches/

:has() / parent pseudo-class

Ever wanted to select an element that contains another?
You could select list items with sub lists inside to style, or style links that have images inside differently to other links.
https://developer.mozilla.org/en-US/docs/Web/CSS/:has

Update: Still no support for this.

Case insensitive attribute selectors

This always catches me out, attribute selectors are case sensitive by default which means if you're not sure of the case you'll either need to repeat your rule for different cases or come up with another solution, while with the feature you can simply write:

a[href^="http:" i] { ... }  

http://css4.rocks/case-sensitivity-selector.php
https://caniuse.com/#search=Case

Update: This has actually been available in Chrome, Firefox & Safari for a while now but still no Edge support.

:blank

A more useful :empty in my opinion.
Where :empty selects where the element is empty, exactly as it says on the tin. Except, sometimes, empty is too strict. Blank space seems like it's empty but that's finally covered with the new :blank pseudo selector.
http://css4.rocks/selectors-level-4/tree-structural-pseudo-classes.php

Update: No news here, but another fantastic write up of this on CSS Tricks -> https://css-tricks.com/almanac/selectors/b/blank/

@extend

Last but certainly not least, ability to extend from other classes. One of the main reasons we either reach for a CSS preprocess or dive into the HTML and throw a few classes on each element is our need to re-use modular styled css components.
https://css-tricks.com/the-extend-concept/
https://tabatkins.github.io/specs/css-extend-rule/

Update: This is probably the feature I'm most excited to see some day, but no news on this yet.

What's on your CSS wishlist for this year?

The property of the day for me is clear.

Here's an example using it to make sure we don't have sections floating to the wrong side as each timeline area is a list item in a single unordered list. You can see it prevent collisions as you resize the browser window it'll push down the items to the other side so that you don't get items on the left overtake items on the right and appear in the wrong order.

Check the code comments to see how it's built.

See the Pen CSS 2 Column Timeline - With ability to choose which side each item shows on (plus a way to join 2 together) by Andrew Stilliard (@stilliard) on CodePen.

How to structure your css.

This is not to say this is the perfect way to work. But it's the way I've been working for years and has really helped me. Inspired by others and by the book SMACSS.

Thinking in modules.

Modular design for me means to separate logical pieces of code for maintainability and reuse.

If everything you do is in one big file, no comments or anything separating parts, all code is very specific and cannot be easily re-used, then it'll be difficult to maintain.

Working in modules you'll find you work faster and more precisely: you'll become a ninja at making quick changes for the client and the client will love you, or at least you'll be happier with your own code.

Example time:

Here's some CSS maybe you've written before. Some text node colors, some buttons have a fancy style (I'll call that fancy-button for later), some text content areas with minor changes between them and a couple minor tweaks on a larger screen.

This will be a long code example but feel free to comment if you have any questions about it/

Original code / what not to do:

# File: site.css

h1 { color: #444444; }  
h2 { color: #444444; }  
h3 { color: #444444; }  
p { color: #000000; }

.header-search .button {
    background: orange;
    color: #FFF;
    padding: 1em;
}
.sidebar-filter #submit-button {
    background: orange;
    color: #FFF;
font-size: 20px;  
    padding: 1em;
}
#contact-form-button {
    padding: 1em;
}
.home-page-content {
  padding: 1em;
  *padding: 15px;
  border-top: 5px solid red;
}
.home-page-content h1 {
   color: red;
}
.about-page-content {
  padding: 1em;
  *padding: 15px;
 border-top: 5px solid blue;
}
.about-page-content h1{
color: blue;  
}

@media screen and (min-width: 35.5em) {
  h1, h2, h3 {
    border-bottom: 1px solid #CCC;
  }
  .home-page-content {
    margin: 0 1em;
  }
  .about-page-content {
    margin: 0 1em;
  }
}

To me, you can work with it, but it's not ideal, and as that grows it will get unmanageable. Lets separate it out to more modular files: (The following files would be included/imported into your site.css file)
I'll comment above each part with the file name, and then under it will be notes on what changed and why its better.

# File: base.css

/* ===== Base styles for site ===== */

/* --- main font colors --- */
h1,  
h2,  
h3 {  
    color: #444;
}
p {  
    color: #000;
}

/* --- default button style --- */
button,  
input[type="button"],  
input[type="submit"],  
.button {
    padding: 1em;
}

/* first breakpoint */
@media screen and (min-width: 35.5em) {
    h1,
    h2,
    h3 {
        /* add a clean border under headings */
        border-bottom: 1px solid #CCC;
    }
}

The above shows base styles for making the page, e.g. fonts, button styles etc..
Separating out the base styles like this helps you quickly find default style applied to all elements. It should be fairly simple, anything more complex should be it's own module or layout file.

# File: modules/fancy-button.css

/* ===== fancier designed buttons ===== */

.fancy-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
.fancy-button-large {
    font-size: 160%;
}

This module for the fancy-buttons assumes you have access to change the HTML, if that's not the case you could make the same module file, but instead of .fancy-button and .fancy-button-large you can comma separate the selectors like so:

/* ===== fancier designed buttons ===== */

.header-search .button,
#submit-button {
    background: orange;
    color: #FFF;
}

/* --- fancy button mods --- */

/* larger text version (could be abstracted further) */
#contact-form-button {
    font-size: 160%;
}

This keeps it modular in it's design, it's only the name of the selectors used that isn't as organised so that's still awesome.

Also notice .sidebar-filter #submit-button has been changed to #submit-button as an ID should be unique and the class prefix is therefore redundant.

# File: modules/page-content.css

/* ===== Page content areas styling ===== */

.page-content {
    border-top: 5px solid;
    padding: 1em;
    *padding: 15px; /* slight IE hack needed to account for a margin bug */
}

@media screen and (min-width: 35.5em) {
    .page-content {
        /* space out the content a bit when available */
        margin: 1em;
    }
}

This offers a generic module for page content, which could quickly be applied to all pages without need for copy and paste. As the design grows, this would be much more important.

# File: pages.css

/* ===== Specific page mods ===== */

/* --- home page (red theme) --- */

.home-page-content {
    border-top-color: red;
}
.home-page-content h1 {
    color: red;
}

/* --- about page (blue theme) --- */

.about-page-content {
    border-top-color: blue;
}
.about-page-content h1{
    color: blue;
}

This layout file for specific pages offers per page differences, which are now very minor and get down to exactly what is different, making maintaining and debugging much easier.

Once you've written your code like this, go back over and review it. Spending a little time re-reading, improving and re-factoring your own code is worth it. You'll learn more about the way you write code, patterns you could reuse.
Using dev tools, you can look over some of your code too, specifically you can inspect the elements you've been working on and view the style tab. Here if you see that code is being overridden a lot of the time with large amounts crossed out then you could probably re-write the code, or re-think the way that element works and the css modules you have selectors to it.

Check out these resources on truly making your css skills awesome!

• https://smacss.com/book/
• http://maintainablecss.com/

Also I've previously wrote about a reading list for modern web design.

Some best practices to take away.

• Think in modules.
• Take pride in your code, format it well.
• Understand what your code does and why and avoid magic.
• Use comments and files to organise code and additional comments to explain why some things are needed.
• Avoid specific browser hacks.

My closing comment is: invest in your knowledge now, your future self will thank you.

If you have any questions? Or found a bug ;), please leave me a comment and I'll try to reply as quick as I can.

"CSS is quick to learn, but takes years to master".
- Not sure where I first read this but it's still true today.

It's difficult to give years of experience as training. People expect designers to know things after a day of training that you'd normally learn with months or years of experience. Some patterns I'll talk about in this post only reveal themselves as bad decisions later on. The best I can do is show you mistakes I've made, and other designers have made. Hopefully you can learn from where we went wrong ;).

Anti-patterns.

Anti-patterns explained: What not to do and why.
Found something controversial? Leave me a comment and we can discuss it further :).

1. Avoid separating styles for the same things.

A case of this I've seen before is separating into different device groups, e.g. mobile.css, tablet.css, desktop.css.
Similar used to be done on sites with a ie7.css file etc.

On the face of it, it sounds like a good idea. Everything is separated out, but it's separated in the wrong way and ultimately it's a naive approach. It often encourages duplication because the blocks of style are separated. This makes it difficult to track down specific styles for an element as they then span multiple files, which often ends in code being copied for each file as it's forgotten it's already set and inherited.

Instead my advice is to build specific module css files, we'll come back to how you do this later in the post.

2. Don't copy paste chunks of code.

This one seems obvious when thinking about most coding languages, but maybe not so with your css.
While working on your css, think about how some styles can be joined together. Remember you can join css selectors with commas so code such as:

.banner p {
  margin: 0 0.5em;
  color: #222;
}
.banner h3 {
  margin: 0 0.5em;
  color: #444;
}

Can become this, which is much easier to maintain and keep consistent:

/* ===== Banner module ===== */
.banner h3,
.banner p {
  margin: 0 0.5em;
}
.banner p {
  color: #222;
}
.banner h3 {
  color: #444;
}

Yes the above code is longer but maintainability is what we are aiming for.

3. Avoid naming classes just by their current properties

Such as .red, because what is red? Will it always be red, what if we change to green... Do we go round everywhere changing the class name to green, or do we change the property and will red now mean green.
Ok this one seems obvious especially with my example, but often when designing more modular css you can get carried away and go too abstract to the point of classes for everything like .red, .font-serif, .text-align-right which leads to even worse code.

Instead, try to think of what the element is, such as a block on the sidebar for latest news. you could have a module called .latest-news, but then you could go further and make that a generic .sidebar-block which can be reused for all your sidebar blocks. On top of this you could then still have .latest-news or .sidebar-block-latest-news for specific extra changes on top of the default .sidebar-block, but consider how this could be shared with other blocks on the page too.

4. Don't just slap !important on it ;)

I find !important is very rarely needed, but too often designers try a selector, find it doesn't work and is somewhere overridden. So they give up and slap an !important on it.
Learn about how selectors and inheritance works!

The topic of CSS specificity deserves its own post, luckily there's several out there that do great jobs. Specificity Wars is a fun introduction to it, along with articles on CSS-Tricks, Smashing Magazine and the Mozilla Developer Network

Tools such as Specificity Calculator are also helpful for you to work out why a selector is more specific.

If you don't bother to learn about it, you'll be forever doomed to fight your forest fire of !importants later.

5. Read the source code!

While you're working in systems or you have build scripts that generate a main/master css file from all your other files, don't be afraid to jump in and take a look to work out why an issue is happening or to check your code is being built the way you expect.
Systems sometimes also have to place some css in page, maybe because of their current module architectures, whatever the reason, if that's the system you work within, you'd better be confident you can find where some css comes from. (Luckily dev tools will tell you if css is from a file or on the page). CSS like this deserves care and attention to override. The source code wont lie to you.

6. Dev tools is your best friend, know it inside out!

Better than reading the source code (though that's still important) is using dev tools.

You need to learn dev tools for the browser you're working on. No two ways about it, go learn them now, at least the inspector :).
Here's a link for Chrome and Firefox.

The inspector will save you minutes, hours, days, weeks and more in trial and error.

7. Avoid fixing height & widths when you can.

This often happens when you have a mockup in photoshop and then you try to match the exact dimensions, which is great, except that this likely wont work as the screen size decreases.
Try to make your modules fluid, then they can fit into a grid or take the widths of the container. Patterns like this are core to responsive design.

8. Designing for desktop down or mobile up?

Instead try to think of mobile and up where you can. Often this will lead to simpler css breakpoints and less cruft around content. With this you can think about what's really needed in the design, without too much extra that on mobile wouldn't make sense.
Read more on Mobile First here, or check out Luke Wroblewski's Mobile First book

9. Clearfix the containers of your floats.

The clearfix class is somewhat magical, but really it's very simple. There's a few implimentations of it, but generally the practice involves adding a hidden pseudo element at the bottom of the content that clears the floats.
Sometimes you'll find this called ".clearfix", or ".cf".
Read more about one great example of this here

10. Avoid magic.

Maybe this seems weird when I just said clearfix is magic. But clearfix is simple when you understand how it works. Try to avoid code that seems to magically make things better if you don't understand why. Otherwise, how can you trust it will always work? How do you customize around it without breaking it?
Clearfix is a great example of this as if you did not understand how it works, you may try and add a pseudo element after it in your own css and find the clearfix no longer works.

11. Use the appropriate method for layout.

Often grids or inside blocks instead of floats for layout.
E.g. if you have 3 columns of evenly sized text next to each other, a grid is perfect. If you have a navigation list or boxes next to each other that are sized by their content, normal grids would be a terrible solution. Inline blocks are best for that as they are sized based on the content. If you have a title with a link to the right, float the link to the side, grids again are not really the best for that. There's no one way of doing things right, don't just follow one specific method, think about how it looks and what would really make the most sense. It may take a little longer to stop and think about each part. But if you do it will save you so many headaches later.

12. Don't style every thing as unique.

Try to reuse modules, again this is not to copy and paste, instead create a generic look for basic elements within content, and then create re-usable classes / modules for applying different styles.

13. Opt for relative measurements over fixed when you can.

Simple one, relative measurements such as em, %, rem etc. are more flexible and will often work better with your responsive design than px.
Not that you should cast aside px as a dirty relic, instead, consider the best measurement for the use case. Often in responsive design this will be relative measurements though.

14. Remember not all interactions require jQuery.

:hover, :active, :focus and more. Learn them, wield them like the awesome tools they are.

You probably already use these and know them well. But if you're working on something in javascript, it's easy to forget and use jquery or similar to do it instead.

15. Combine properties

Properties such as font and background can be combined. It's worth using the combined versions for simplicity such as:

background-color: rebeccapurple;  
background-image: url(/images/logo.png);  
background-repeat: no-repeat;  
background-position: top left;  

Could be:

background: rebeccapurple url(/images/logo.png) no-repeat top left;  

16. Avoid unnecessarily long selectors

Sure, referencing body #content .sidebar a works, but would .sidebar a work just as well?

17. Always test your ideas.

Developer tools allow us to test our ideas live, why wait to compile or ftp a file to a server to test your idea for a fix. Change it live in the developer tools and you'll have instant feedback.

18. Browser test too!

With complex modules, check ideas for them as you're going in browsers you think may be problematic, this will make things a lot easier when you return to fully browser check it later.

I've written more about browser testing here.

You can also use Can I Use... to find out browser support for new CSS properties etc. to find which browsers are likely problematic to start with.

19. Avoid specific browser hacks.

Try to find the cause of the problem, rather than a quick fix that may lead to further problems. You may find it's a problem in your CSS and you can work around a problem easier than just hacking it.
If you have to use a hack, explain why in a comment, make sure that in a month when you return to this project you'll know why you added it in.

20. Format your CSS in a clear and uniform way.

This one is a somewhat personal preference, but I try to always write CSS in the same way. I use 4 spaces for indentation (some people use tabs), I separate each selector onto a new line as I believe selectors are kind of the most important part of the css definition, and each property onto a new line.

You can see more of my style choices for CSS in the following post.

Can you expand this list past 20? Leave a comment with your own anti patterns or advice.

Enough with what not to do...

Continue to Part 2 for how to structure your CSS and more tips.

If you disagree with this list or do you have your own suggestions? Leave a comment below and I'll try to reply quickly.

These books are fairly up to date but the methods used are solid and still valid into tomorrow.
By no means am I saying "read these and you're ready", or a definitive list of books I've read or think you should read. But if you're looking for books to tune your skills, this list may help.

I'd also encourage you to leave comments below to share books on web design you've enjoyed and have helped you too.

Books

In case you've not stumbled onto this gem before, A List Apart is a great source of useful information. Their series of short books on A Book Apart offer great core skills such as:

HTML5 for web designers by Jeremy Keith.

Looking to get up to speed on HTML5? A core skill of modern web design is being able to use these new HTML elements with purpose.

CSS3 for web designers by Dan Cederholm.

Also a core tool on your belt is CSS3. Techniques such as rounded corners (with border-radius) and background gradients and more are all common place in modern design. These are made simpler with this book.

Responsive web design by Ethan Marcotte.

A brilliant intro to responsive web design, very useful techniques from the guy that coined the term "responsive web design"!

The above are just 3 of their books, it's worth checking out more. Hopefully this is a nice taste of books they offer and should help you learn the core skills needed to get started with modern web design.

On to other ranges of books, the following focus more on techniques, patterns, usability and inspiration.

Scalable and Modular Architecture for CSS (SMACSS) by Jonathan Snook.

Another short book but front to back a great read full of useful info on writing and structuring css.
The patterns he talks about are simple and easy to follow, but make all the difference in creating maintainable css designs.
I can't recommend this book enough.

Any from the "Smashing Book" series.

Full of the latest modern techniques, inspiring articles and more.
Personally read books 1 & 3 but I'd bet the 2nd is worth wile too.
The Smashing Magazine website has been a constant source of useful info and inspiration for years.

Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug.

If being able to build a site is the first step, then building it right is the second. This book goes over common web usability and is definitely worth the read.

Ready to dive into Javascript?

Eloquent JavaScript: A Modern Introduction to Programming by Marijn Haverbeke.

This book came out around 2011 but I wish it had been there back in 2008 when I first started Javascript. It's useful for getting started with Javascript, or fine tuning your skills and filling in any blanks.

JavaScript: The Good Parts by Douglas Crockford.

Douglas Crockford gives a great run through of the language and the syntax to give you a solid understanding of programming with it.

Looking for something a bit deeper? Something for improving your developer skills?

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas.

If you're interested in levelling up your skills then this book may be for you. It covers patterns, methodology, solid ideas and tools to take your code to the next level. It's also surprising easy to follow as it's often ultimately about common sense.

Newsletters

I like a good newsletter or 10 for keeping up to date on the modern web. They're one way that's really helped me stay up to date especially over the past year. Maybe they will work for you too.

Sitepoint's Versioning newsletter is worth subscribing to if you're interested in a daily digest of latest web news.
Though this can be too frequent, Web Design Weekly, or Responsive Design Weekly are 2 great weekly newsletters also.
There are many others like this such as HTML5 Weekly, CSS Weekly, Javascript Weekly and eWebDesign newsletter.
My advice is to pick one and see if you like it. If not you can always un-subscribe :).

If you're working on an REC, here's some more links that may be of use for keeping up to date: http://design.reallyeasycart.co.uk/up-to-date.html

Please leave comments with books or posts online you'd recommend :), I'd love to hear about books that you've read and have helped you, along with inspiration for what I should read next.

Contents

1. Tips while coding
2. Selecting browsers to test
3. Why BrowserStack
4. Testing like a pro

Tips while coding to make your browser testing easier

1. Don't focus too much on making your designs pixel perfect in every browser.

   "While some designers strive for cross-browser pixel perfection, proponents of fluid design do not think that layouts have to look identical across all platforms and screen resolutions."
   - The Smashing Book (Chapter on the Art & Science of CSS Layouts)

   Often clients (or our own OCD's) will want a design to be pixel perfect across multiple browsers and sizes, but there's very little need for this. I'm not saying make them drastically different in each browser, but if they have minor differences then this is good enough for me. The important thing is the design is able to adapt to the available screen size, and look good enough in browsers where support for some features isn't easily available. E.g. rounded corners with border-radius, these days it's pretty much all browsers, but if you go back to IE8 it doesn't support border-radius. Though if you look at your design, does the fact it doesn't have rounded corners cause any problems? no? great, leave it, no fancy polyfills etc needed. Which nicely brings me to my next point.

2. Don't fear vendor prefixes, but also don't fret about them either.
   That sounds confusing, I probably could word that better.
   What I mean is, feel free to use vendor prefixes in your code. But make your own decisions of when to and not to use them. E.g. flexbox is a great case of where it's needed, especially because of IE10's alt syntax. But css gradients, if you set a fallback background-color then this will likely be fine if you don't bother adding the vendor prefixed versions too as they will use the fallback.
   There are many sites out there that offer automatically adding prefixes to your code. But simpler than this, you can get editor plugins (for Sublime, Atom, etc.) which can run right in your editor with a single command. One rule to remember with these new css properties & vendor prefixes is, always use the real property too, don't just style for webkit prefixes, make sure you style for all and then add prefixes for added support. Also, think about browsers that don't even have prefixes. Make sure your design degrades gracefully without them, or better yet, build without them where you can and add them on top after, so you know the base is already nice and this progressively enhances the design in newer browsers.

3. Avoid browser specific hacks.
   Ok yes, very unlikely if you're supporting IE7 or 8 maybe. But 9+ and most other modern browsers, do you really need that hack? In the case that you super need a hack, browserhacks.com is a great resource for it. But is it needed?

4. Avoid adding lines of code you don't understand.

   Sure use libraries and snippets, in fact I encourage it, but try to look and learn how they work. Especially if it's a few lines in your own css. Sometimes when you copy other peoples code you can be left with properties that don't appear to make sense. Best case is if they are not explained somewhere, try taking them out, does it break, if so you'll learn why they were added, and if not, maybe you can remove them to simplify the code. You can always add them back in later if needed. But try to avoid seeing some code as magic. Magic hides reality, and often I've found magic can lead to bugs.

5. Resize your browser often while developing.
   This is one of the fastest ways to quickly catch problems fast, and to prove your designs adapt to the screen size available.

6. Learn to master your browsers dev tools
   Each of the major browsers have developer tools that help you build sites. Its really worth investing time in learning these tools. Most of them offer some sort of emulation for browser modes, screen sizes, user agents etc. So this is useful for browser testing. But the tools are also useful during testing because you can use them to inspect elements style to see exactly why something isn't working. Rather than the old methods of try this property, refresh browser maybe it'll work. Instead you can try your ideas live!

   Spend some time familiarising yourself with the top browser tools: Chrome, Firefox, Opera, Safari, IE, Edge.

   Here's a free course on the chrome dev tools, really worth a watch.

Selecting browsers to test

Always test the latest browsers, versions & platforms.
Chrome latest, Firefox Latest, IE11, Edge Latest. Android Chrome latest, IOS Safari latest etc.
This is the quickest way to be extra safe with your design.

Working with an existing site

If your existing site has analytics, this is the perfect place to start to make sure you cover it's most used devices, browsers and versions.
For example, just because you've tested on the latest IOS safari version, doesn't mean that's the version that's currently most in use for this site.
It's really worth checking the browsers that bring the most visitors and importantly the most conversions.

Login to Analytics > Audience > Technology > Browser & OS.
Then you can also click on a specific browser to then find a tab to see specific versions of that browser.

Be sure to set the date range for last month, and then also compare to last 6 months.

You can check out device/browser sizes if you click the Screen resolution tab at the top, though my personal recommendation is to make your design adapt to all screen widths rights down to 320px (or 240px if you can but not always so easy).

If it's an ecommerce store & revenue is stored too then you can see which devices, browsers and versions generate revenues. This is important, as if a specific older browser is bringing in thousands, maybe a couple big customers use it, it may not even be a popular browser but if it brings in the bucks, you'd better be supporting it ;).

Find out more details on using Google analytics to find browser support here.

Browser testing with BrowserStack

Ok, I cannot stress the importance of this tool: BrowserStack

This may sound like an advert for BrowserStack, I just really love their tool.

Here's my 5 favourite features it has!

1. Test on all the major browsers & versions,

2. On all the major platform versions of Windows, OS X, Android, IOS & Windows Phone. - It's not just about the browsers, its also about the different versions of them, and the different platforms they are on.
   When a client calls up saying they have a problem on IE 10 on Windows 8, you can fire up BrowserStack and test the same as them.
   Speaking of which, tools like Findmebyip.com offer urls you can share with your clients to find out what browser they are currently using as often people don't know.

3. These are not emulators, real browsers on real platforms! I've had designers tell me before they don't trust services like this because it's not the real device, which i understand, but with BrowserStack you really have access to real instances of windows and OS X with the real browsers installed. Also for mobile they have "Physical Devices" which are real devices in a device farm BrowserStack have so you're really on the device testing! They also offer emulators for some mobile devices they don't have, but the physical devices cover most cases.

4. Their mobile features are top notch. Access to dev tools on mobile devices is more important than I can express! This one feature really is worth the subscription on it's own.

5. Zero setup & it boots up super fast! Starting up a test laptop or VM can take longer and on a good connection BrowserStack feels fairly smooth!

Bonus feature: Built in issue tracker, I haven't used this feature much but on a project where you're testing but not the developer, you can use this to keep screenshots as a list of issues for the designer/developer to fix.

Aside notes on testing apps

I'll mention here BrowserStack is not the only tool out there for this, It's the one I use most and personally I believe it's the best tool for the job. It's worth knowing about other similar tools such as: Browsershots, turbo.net/browsers and Browserling

It's no replacement if you already have the device in front of you, but you wont have all the different versions in front of you. You may have a couple iphones in the office, maybe even different models. But are they on different IOS versions and therefore different mobile safari versions? Don't forget about people who haven't upgraded their phones yet, and no, saying "they should just upgrade" is not an excuse! (Something a friend once said to me with his design after I pointed out an IOS 5 issue, sighs).

Also worth noting, if browserstack is not available to you, or it's too slow, you can use VMs for windows / IE / Edge debugging, in fact Microsoft provides these free.

For mobile device debugging, you can use dev tools with chrome's remote debugging feature. Follow this tutorial on how to set this up.

Testing like a pro

These are some brief tips to testing, but all this boils down to using the site like a real user.

1. Resize in and out on every page.
2. Scroll up and down while resizing, don't just load it on small screen and assume because the top of the page is ok that the rest will be too.
3. Click every link, to the point of trying to break the site.
4. Following on from the previous tip, try to break the site! Don't just test the things you already know work, try to think outside the box, your users certainly will.
5. Pay special extra attention to custom interactions you've added to the site. Just because it looks nice, doesn't always mean it works.
6. When you do find bugs, use the browser dev tools like mentioned above, especially the console if it's an interaction / javascript issue.
7. After testing, accept that you can't test everything perfectly, over time your testing skills will be better, but it's important you’re aware reports of bugs will come in. You need to be ready for those reports, ready to find out which browser has the issue if possible like we talked about above, and try to reproduce it in the same browser version.

Additional testing for bonus points

1. Test performance with Google Page Speed.
2. Test mobile friendliness using Google’s tool.
3. Check the SEO of pages, such as title tag, meta tags, single <h1> tag, alt tags on images etc. Moz offer some great information on this.

I hope this has been useful, please leave a comment below with any of your own tips on browser testing to help improve this resource for others.

And even some tools that offer excellent detection of media queries / breakpoints and then automatically create iframes of each so you can quickly view them, such as: http://breakpointtester.com/ and http://re-view.emmet.io/

The 1st set of tools are great, especially when demoing to clients to help them see different specific devices.
While the 2nd set of tools are also really useful when developing to see the different breakpoints built in and to quickly demo them side by side too.
The minor downside to these 2nd set of breakpoint tools however is they are either browser plugins or bookmarklets, which for some clients will not make a lot of sense.

Instead we need a tool like the 1st ones where you can link to it, but with breakpoint detection like the 2nd set of tools.

And so, here's a new tool you can use:
http://responsive.stapps.io/

Like the other tools, this only works on sites that don't block iframe access, e.g. google blocks it's site from being viewed in an iframe.

Also, unlike some of the other tools, it currently only works on sites with css breakpoints / media queries.

It has 2 display modes, the default one is a slider of each display size, you can use the arrows on the side or keyboard to navigate between them.
Then the other display mode is to show all the sizes next to each other, like the other breakpoint based tools, which is useful for quick comparisons.
You'll need to click "run" again to change the display modes.

It's pretty new so message me about any bugs, but enjoy :).

If you're an REC user, you can find a link to this under the preview url in Admin > Templates > Open/Edit Template