It's time to ditch Medium for good! 🌈⚡️

Introducing Devblog by Hashnode. Blog on your domain for FREE. Highly customizable and optimized for developers.

Learn more

I am Harry Roberts. Ask me anything.

Harry is an award-winning Consultant Front-end Architect, designer, developer, writer and speaker from the UK. He writes, tweets, speaks and shares code about authoring and scaling CSS for big websites.

Ask Harry Roberts about:

  • CSS
  • Front-end Architecture
  • Performance Engineering
  • Responsive UIs
  • Scaling large codebase
  • General Front-end development

Hey all!

I’ve had a bunch of fun answering everyone’s questions! There’ve been some really good ones, thank you :)

If I didn’t answer your question quite correctly, or you’d like a little more detail, please feel free to ping me an email and we can discuss things further there: csswizardry@gmail.com

For anything shorter form, you can just fire me a tweet: @csswizardry

I hope you all enjoy the rest of your days, wherever you are in the world. Thanks for having me!

If we’re ever at an event together, come say hi and let’s grab a beer!

H

Ask a Question

63 discussions

What are a few of the simple, yet not very well known “front-end performance” tricks?

I love this question! I’m gonna focus on simple.

  1. Simply move your CSS’ link elements to as close to the top of the HTML document as you can. Seriously, it can make a difference. I did an audit for a company once and their CSS was linked on like line 81 of their HTML; this meant that touch icons, Facebook/Twitter card images, plugins’ JS, etc. were all being requested before their render-blocking CSS was. By moving the CSS up to line ~5 we managed to improve render time by a good half second.
  2. Don’t put scripts at the bottom any more: make use of async and defer attributes
  3. Make use of resource hints[1] to tell the browser to prioritise things out of regular order (or for subsequent navigation).

All of these are one-line (or less) fixes.

  1. https://www.w3.org/TR/resource-hints/

Reply to this…

Share your programming knowledge and learn from the best developers on Hashnode

Get started

Hello Harry,

Thank you for the AMA! To be honest, I am a fan of your ITCSS and BEMIT techniques (at least what I could find out in the WWW), so I really look forward to the AMA and all of your answers!

As for my questions, here are a few which I find highly interesting:

  1. On CSSWizardry, you sometimes use CSS, but you also sometimes use SCSS. Do you have any pattern when to use what?
  2. What are your most-used SCSS features, which will probably not be replaced by upcoming CSS standards in the short-run?
  3. How do you decide on responsive breakpoints? For which elements do you add special breakpoints? (images, menues,...)
  4. I sometimes read that rendering performance can be influenced by carefully writing certain CSS selector rules. Do you think something like that is plausible, or even relevant for todays highly performant devices?
  5. If you could change any one way CSS is used today with a wish to a djinn, what would it be?
  6. I have been waiting for the release of an official ITCSS spec and the Inuit framework for some time. Can we expect anything this or next year?

I really hope you could answer one question or another. Thank you for your time and motivation to do this AMA :)

Wow! Good questions.

I am a fan of your ITCSS and BEMIT techniques…

Thanks :D

On CSSWizardry, you sometimes use CSS, but you also sometimes use SCSS. Do you have any pattern when to use what?

I am a little inconsistent with this, but I recently hit upon a rule of thumb for myself: if using Sass would obscure the message, I will avoid it. Even if Sass would improve the overall code, but masks the thing we’re trying to learn, then leave it out. I hit this conclusion on an article in which I was demoing custom properties and @supports[1]: using Sass would have made the code much more terse but would have definitely detracted from the whole point of the article.

What are your most-used SCSS features, which will probably not be replaced by upcoming CSS standards in the short-run?

Honestly, probably just flat @imports. Vanilla CSS @import is absolutely evil as far as performance is concerned, so having Sass flatten them for me is great. That said, HTTP/2 will negate the need for concatenation, so maybe even that will be less important to me in future.

How do you decide on responsive breakpoints? For which elements do you add special breakpoints? (images, menues,...)

This is really difficult. Usually a designer will have picked them already, loosely around ‘traditional’ screen sizes (480, 1024, etc.). This isn’t ideal, but it’s kinda just how things are: just make sure you convert the values to ems[2].

Any piece of UI that needs a tweakpoint should get one, so custom breakpoints should be used as soon as the design starts to look strained.

I sometimes read that rendering performance can be influenced by carefully writing certain CSS selector rules. Do you think something like that is plausible, or even relevant for todays highly performant devices?

Selectors do have an inherent performance value[3], but it should be the very last thing on our list to optimise.

If you could change any one way CSS is used today with a wish to a djinn, what would it be?

Honestly? I wish that only people who wanted to write good CSS would actually write it. Too many people openly don’t care about quality CSS, and that’s where we get problems. That said, I’d be out of a job if everyone did it properly!

I have been waiting for the release of an official ITCSS spec and the Inuit framework for some time. Can we expect anything this or next year?

I have a great team of contributors working on inuitcss at the moment, and we’re fast approaching a beta. ITCSS… it’s hard to say. I might publish it as an eBook, but that’s going to take more time than I currently have I’m afraid :(

  1. http://csswizardry.com/2016/10/pragmatic-practical-progressive-theming-with-custom-properties/
  2. https://zellwk.com/blog/media-query-units/
  3. http://csswizardry.com/2011/09/writing-efficient-css-selectors/

Reply to this…

What are some of your favourite technical and non-technical books? Who is a developer you admire the most?

Souders’ books[1][2] are some of my favourite technical ones.

My favourite non-technical books… hmmm. Grid Systems in Graphic Design[3] is a beauty. I love The Savoy Cocktail Book[4].

Honestly, though… I’m not much of a reader. If I’m not on my computer I’m playing out in the hills :)

  1. https://www.amazon.com/dp/0596529309?tag=stevsoud-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0596529309&adid=00GNM1ZWW77KSD0RERXN&
  2. https://www.amazon.com/dp/0596522304?tag=stevsoud-20&camp=213381&creative=390973&linkCode=as4&creativeASIN=0596522304&adid=09TZDJ7Z5GDMJPAM6XC6&
  3. https://www.amazon.co.uk/Grid-Systems-Graphic-Design-Communication/dp/3721201450
  4. https://www.amazon.co.uk/Savoy-Cocktail-Book-Harry-Craddock/dp/1626540926

Reply to this…

What are your recommended resources for getting an almost “complete” knowledge of CSS?

  1. Read specs.
  2. Focus on one thing at once.
  3. Find the people who specialise in areas the most (e.g. Hugo Giraudel for Sass, Rachel Andrew for grid, Ana Tudor for math, Sara Soueidan for SVG, Paul Lewis for rendering performance, Rachel Nabors for animation, Lea Verou for basically everything else).
  4. Take things apart. Seen something cool/intriguing? Take it apart and then put it back together, but better. Learn by (un)doing.

Reply to this…

Do you advocate the use of CSS frontend frameworks like Bootstrap, Foundation, etc.? Have you used them?

I have opinions on this that will keep us here for more than two hours!

Firstly, I want to make a rather pedantic point that Bootstrap, Foundation, etc. are not frameworks. They’re toolkits. That’s not a criticism, but it’s important to note that, where a framework offers guidance and standards, toolkits like these go a step further and offer bits of styled/opinionated UI.

The comparison I make is that Symfony is a PHP framework, whereas WordPress is a blogging platform written in PHP. The difference there is the difference between a framework in its truest sense, and a UI toolkit like Bootstrap, Foundation, etc.

Do you advocate the use of CSS frontend frameworks like Bootstrap, Foundation, etc.?

If you need a UI out of the box (e,g. internal dashboards, reports, etc.), definitely. If you have your own design to implement, use a true framework, or start from scratch.

Have you used them?

I have, but via clients who’d realised that they weren’t the right thing to have used.

For more opinions like these: https://www.youtube.com/watch?v=xR6V9bHlrx0

Reply to this…

Load more responses