@csswizardry
Consultant Front-end Architect
Nothing here yet.
Nothing here yet.
No blogs yet.
Ahhh this is such a good question! And you’ve inadvertently discovered/reinvented BEM mixes , which are about as advanced as BEM gets. This kind of contextual styling has a number of potential solutions, and the correct one is the exact same as you’ve come up with. The addition of the third .c-card__button class is the Mix pattern. Good work 👍🏼 H
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 :)
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 :)
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]. http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/ http://csswizardry.com/2016/05/the-importance-of-important/ https://speakerdeck.com/csswizardry/css-for-software-engineers-for-css-developers?slide=65
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 :) https://twitter.com/danielmall
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: http://www.darkcoding.net/software/facebooks-code-quality-problem/ http://csswizardry.com/2016/10/pure-css-content-filter/ http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/
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. https://www.youtube.com/watch?v=KmtgJ1d4zuY