I’d argue that you need to a) be a differentiator and b) solve problems that people are actually having. Solve those before you worry about popularity and popularity should follow.

I’d also consider why you want Blaze to exist—if you want it to be a promotional tool to raise your own profile (and hey, there’s absolutely nothing wrong with that at all!) then I’d probably apply to speak at meetups and confs about how it works and what it does. Also send some stickers or whatever to people who have either inspired or helped you, or who might be able to help you in promotion or some sort.

If you’re building Blaze to solve actual problems for people, just keep your head down and keep doing good work :)

Allllll the time!

!important: 3 seconds to type, 3 years to remove.

Use important proactively: apply it to Utility classes, e.g.:

.u-text-center {
  text-align: center !important;
}

We’d literally never want this class to do anything other than text-align: center; so we force it to always win by using !important.

Never use !important in anger. Don’t use it to get out of specificity wars. Instead, hack the specificity of your existing selectors around[1].

I’ve written and spoken quite a lot about !important, actually[2][3].

1. csswizardry.com/2014/07/hacks-for-dealing-with-sp…
2. csswizardry.com/2016/05/the-importance-of-importa…
3. speakerdeck.com/csswizardry/css-for-software-engi…

Hmmm… interesting.

To understand the two, I usually say that ITCSS is an architecture, and inuitcss is the embodiment of it. They share the exact same philosophies.

ITCSS: flat file structure vs. Inuit: directory-based

ITCSS doesn’t actually prescribe a directory structure; you can use whatever you wish. For a while I had a demo which was flat, but most people do (and can) implement it in directories. The primary idea of ITCSS is that it’s flexible enough that the implementor gets to make a lot of decisions.

ITCSS: DRY vs. Inuit: Node install requiring potential overrides (a la Bootstrap)

ITCSS aims for reduced redundancy, but can never completely eliminate it. That’s why inuitcss does often require a few overrides, they are definitely minimal. inuitcss also has a lot of preconfiguration which would hopefully reduce the amount of unused CSS in there.

So yeah, the intention is that they’re not really different in approach at all: inuitcss is just what you get when you put ITCSS’ theory into practice :)

Excellent timing! I wrote this just yesterday: csswizardry.com/2016/10/continue-normalising-your…

I’m gonna cheat and answer with features and specs, and what I would like to see implemented more widely:

• Grid
• Web Components
• all: initial;
• Custom Properties

Best: I live in the best place on earth.

Worst: Sometimes I have to leave it.

(For anyone not familiar with Yorkshire, it’s breathtaking[1] and enormous and diverse and beautiful and no it’s not London. We’re also remarkably proud of it.)

1. google.co.uk/search

I love this question! We’ve learned recently that the best performance practices of yesteryear are a little more nuanced.

To my mind, the advice ‘Reduce HTTP requests’ should now be given as ‘reduce HTTP requests that will keep the user waiting’. If we can render the page in 3s with 30 requests, or in 2s with 40 requests, it’s clear that the more requests version is the better option.

I’d love to see a writeup or demo of the technique you’re describing, if you can share one…?

It's simple really. In header's <style> I put CSS to hide root elements of each section targeted by separate stylesheets, which are loaded via https://github.com/filamentgroup/loadCSS . Of course one would want to minimalize code repetition in their styles so that the styles are not repeated for no good reason. CSS that is used across all pages such as utilities/objects/other global styles is loaded the standard way. One also has to watch for bloat from style libraries, since usually it is desirable to have access to all mixins, variables and such in all of your separate stylesheet sources.

Not sure if that is enough to create write up or some sort of blog post + I am not that great of a writer so I hope this does the deed.

Thanks!

I'm wondering, what's your take on creating and especially maintaining a style guide?

I’m absolutely all for it!

I had this exact discussion with a client today. Most (if not all, I imagine) of the styleguides that are actually successful have their own backing and funding from the business—they’re run as their own product.

Unfortunately, for most companies, this is unlikely to happen. This means the styleguide is maintained in spare time, or alongside product work, or isn’t maintained at all. What happens then is the exercise looks (on paper, at least) like a failure. This is really disheartening, but understandable.

So for a styleguide to really shine, it has to be treated as its own product/project. Or, at the very least, all design work should be carried out styleguide-first[1]. That is to say, we don’t build a new component for X page; we build a new component for the styleguide and then deploy it to X page.

Any thoughts on deeper design systems like Rizzo from Lonely Planet, who kinda works as an API for production and their style guide?

Things like Rizzo[2] and Origami[3] are great, and were built by some very clever people indeed. The API-style of deliver really helps to keep things in sync, whilst also dogfooding your work. But, again, there’s an entire team dedicated to maintaining Origami, which I would argue is a large part of its success. Same with the other forerunner, Salesforce’s Lightning Design System[4].

1. https://www.youtube.com/watch?v=ldW7zVmqu5g
2. rizzo.lonelyplanet.com/styleguide/design-elements…
3. http://origami.ft.com/
4. https://www.lightningdesignsystem.com/

Ohhhhh man, I can’t answer that 😂

There have been one or two. It’s hard to convince the business to spend money on a complete rewrite (the cost of six months of work just to get back to (visually) sqaure one is a tough one to sell) but the first ever high profile project I worked on was a total rewrite jobbie. It was all the better for it :)

Hey! That’s really nice to hear, thanks for taking the time to let me know. That’s very humbling :)

What are your plans for http://inuitcss.com/ and http://itcss.io/ ?

Would you mind if I was real lazy and just pointed you to this answer?

Do you mean what do I think do doing the design and build work at the same time?

I think that it’s usually impractical to do both in parallel, but getting close to parallel is a huge advantage. I don’t necessarily advocate designing in the browser, but I definitely share my buddy Dan’s[1] sentiment of decide in the browser.

Get into the browser as soon as you can, whether you’re the designer and FED on the project, or even if those are two separate people. Having the design phase then the build phase only sets everyone up for disappointment.

If that wasn’t what you were asking, well, you can have that one for free! if you want to reword it then I’ll gladly take another stab at answering :)

1. https://twitter.com/danielmall

Hmmm. This is interesting. I still really, really value Sass, so what I have been doing is a bit of both:

Sass » CSS » PostCSS (cssnext) » CSS

This means we can use standardised syntax for variables (--foo: bar;) but still transpile that down to static CSS for old browsers. As soon as we can use custom properties everywhere, we can transition over more easily, but still leave other things to Sass.

I was a little unsure about CSS Modules until I saw Mark (who’s a really great guy, by the way!) deliver a very compelling talk on them at Front-Trends (which is a really great conference, by the way!)[1].

It made me realise that ITCSS and CSS Modules can quite happily coexist. All of the layers except Components can be written in Sass or whatever (this is like your ‘global’ CSS), then as soon as you get to your Components layer you could write that 100% in CSS Modules if you like.

1. https://www.youtube.com/watch?v=KmtgJ1d4zuY

I wish we’d got scoped CSS[1] :(

1. http://keithjgrant.com/posts/save-scoped-css.html

Thank you for hosting this AMA!

You’re welcome!

Because of you our company is now using ITCSS + BEM to create scalable and maintainable web applications!

Awww yis!

How do you normally make ITCSS 'components' responsive? […] do you ever use media queries within your component's CSS?

If a specific component needs to have a different appearance over several breakpoints, I write MQs inside of it. Responsive classes are usually reserved for utilities where responsive behaviour can be abstracted.

Further, I always write the MQs in the file that they affect (e.g. _components.buttons.scss) and not in a mega MQ toward the end of the project. Encapsulation :)

Thanks for all the questions!

What are your opinions on utilising data attributes for styling? (such as http://codepen.io/SudoCat/pen/wzBzoG - shameless plug, I know, but a prime example of what I'm talking about)

The purist in me doesn’t like it. Data attributes, as per the spec, are:

to store custom data private to the page or application.

They’re a store, not a hook.

However, I’m starting to soften that stance a little. If you want to style something because it contains certain data, it might be a good idea[1]. However, using them where a class could/should have sufficed is probably not the right way to go.

A lot of people slam unqualified attribute selectors and wildcard attribute selectors, but they provide a huge amount of power to us devs, especially helping make our CSS more Object Orientated - where do you stand on the matter? (Kind of related to the above question)

As above, if a class could have done the job, and you’re not actually storing data, then a class it should be :)

I know you're a huge BEM advocate, but what about SUIT?

At the risk of trivialising the work that both Yandex and Nicolas do, I’d argue they’re both different flavours of the same thing. The only thing I’m interested in is the fact that you’re using a naming convention at all (and you’re using it uniformly and consistently).

How do you deal with the horrors of JavaScript/CMS plugins injecting their nasty markup into your projects?

Usually I just Deal With It™—there’s probably something more important to be worrying about. However, if the HTML is littered with IDs that we can’t get rid of, opt to use an attribute selector to style it instead (e.g. [id="foo"] {} instead of #foo {} because then at least we’re not using an ID’s worth of specificity[2].

Is the dream of a truly clean, tidy, maintainable code base really achievable? I feel like my FED life is spent fighting for nearly unattainable goals - is there a light at the end of the tunnel?

Until every developer on the team is a clone of a very talented developer, then it’s not realistic to have a completely perfect codebase. As soon as we recognise and acknowledge that, we can start focusing on good enough, and that’s where we can make value: It’s not perfect, but we can work with it; we have tech debt, but we have a plan to repay it; it could be neater, but it’s not slowing us down.

Whenever I write or get on stage, I’m talking principles and ideals and theory—even applying them word for word isn’t enough when you’re working in the real world. They exist to make life easier, not perfect.

Agencies or Products?

Each have their own merits, but I absolutely prefer products. Agencies give you diversity and variety, but there is little incentive from anyone (clients, managers, us) to focus on code quality. The client just wants it working for as cheaply as possible; your manager can’t sell ‘code quality’ like they can sell social media integrations; developers will be on a different project in eight weeks anyway.

When you work for a product, however, the tables are turned! You’re both the client and the developer, so it is absolutely in your interests to write better quality code. You’re going to be looking after this in two years time, so do your future-self favour and do a good job. As soon as you hit Save, you’re leaving legacy—make sure it’s worthy.

As an aside, here’s an interesting piece I read on code quality recently: darkcoding.net/software/facebooks-code-quality-pr…

1. csswizardry.com/2016/10/pure-css-content-filter
2. csswizardry.com/2014/07/hacks-for-dealing-with-sp…

Hey!

This site has been a bit of a talking point lately, eh?

I like it. I think it’s a good idea. I’m also a stickler for wording, so when I see ‘you might not need JS’, I read ‘you might not need JS’. A lot of these perhaps should be best left to JS, and the project itself doesn’t make any claim otherwise.

I recently had a bit of fun making a pure CSS content filter[1] which I ultimately decided should be done with JS, but the process of at least trying it was a bunch of fun, and taught me some things about CSS that I didn’t know.

Experiment, have fun, do things just because, but make sure you’re fully aware of the implications of making it public (which I think youmightnotneedjs.com did, but still took heat for it).

… especially using the radio/check buttons and :checked "hack"

There are documented issues with this, and we already know that it’s bad because we all call it the Checkbox Hack. Don’t use it :)

1. csswizardry.com/2016/10/pure-css-content-filter

Hah!

I suppose it is an ask me anything.

Are you married?

I’m not.

Am I invited to Harry's Bar?

When I open Harry’s Bar for real, I’ll do a tech industry night. You can all come!

What's your favorite drink?

Either a split rye/cognac Sazerac[1] or an Aviation[2] with decent violette.

Have been following following your talks, you are awesome! :)

Thank you :)

1. https://en.wikipedia.org/wiki/Sazerac
2. https://en.wikipedia.org/wiki/Aviation_(cocktail)

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

I like it! I used it once with a huuuuuuuge client, and they were getting great mileage out of it. It’s effectively a polyfill for Web Components, so I’m all for something that is paving the way for a standard.

Shadow DOM, encapsulation, bundling, etc. are wins in my book.

I’m aware of React.

I think packaging your styles with your components is, philosophically, a good idea. This is what Web Components will give us. What I am hesitant about, though, is writing your CSS as JS objects. Writing your styles actually as JS doesn’t sit too well with me. Keith Grant puts it best[1] when he says:

If in 14 months you find a new view library or framework you want to try out, you're out of luck. You will have to invest a lot of time into pulling styles back out of JavaScript modules and into stylesheets again.

By all means, bundle them together, but I’m all for keeping each language/syntax separate.

What do you think of styled-components.com?

I don’t have enough knowledge about it to comment I’m afraid.

1. keithjgrant.com/posts/against-css-in-js.html

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/