Recommended
Recommended
More Related Content
Viewers also liked
Similar to Lessons Learned From Building Your Own CSS Framework
Similar to Lessons Learned From Building Your Own CSS Framework (20)
Recently uploaded
Recently uploaded (15)
Lessons Learned From Building Your Own CSS Framework
- 1. Lessons Learned From Building Your Own CSS Framework Charlie Owen @sonniesedge
- 2. Who the hell am I? @sonniesedge
- 6. So, what is a CSS framework? @sonniesedge
- 8. Maybe more like Bourbon..? http://bourbon.io/@sonniesedge
- 11. How does it work? @sonniesedge
- 12. Make variables enforce your design system @sonniesedge
- 15. @sonniesedge
- 17. @sonniesedge
- 19. What did I learn from building Loom? @sonniesedge
- 20. Set an achievable aim. @sonniesedge
- 21. Be opinionated. Be proud. @sonniesedge
- 22. @sonniesedge
- 23. Don't be too rigid @sonniesedge
- 24. Learn from other people’s work @sonniesedge
- 26. @mixin padding($args) { ... // allow for processing of various combos of arguments. ... // it goes on forever ... ... ... @return $padding-values; } @sonniesedge
- 27. .selector { padding: 1rem 0.5rem; } @sonniesedge
- 30. Get a good name @sonniesedge
Editor's Notes
- Thanks for the introduction. I’m Charlie Owen. I live and work here in Berlin. Moved here about 15 months ago from London and I love it. I swear it’s a cliche, but it was the Club Mate that hooked me. Anyway, I’m a frontend developer. I specialise in design systems and large scale sass. Accessibility and ease of use are my thang.
- I’ve worked on a few big projects and at some big organisations including producing some of Rupert Murdoch’s Sky broadcast channels.
- The AAT - the Association of Accounting Technicians, based in the UK. Sounds boring, but this is actually a global membership-based organisation, serving hundreds thousands of people around the world. It was my first introduction to large-scale design systems and a huge influencing factor on this talk
- I also worked at the BBC, where I built the site for last years British national elections. You know the one where we elected David Cameron. Remember him? Nobody mention Brexit. This was an amazing technological challenge. We had to support every kind of browser out there, including the ones we hate, like IE6. This had to work on desktop, on mobile. Fantastic fun working with everything department in the BBC. All the hard work was so worth it. On election night, this was being viewed by 18 million people PER SECOND. Half of UK saw it over a 24 hour period. That was a terrifying thing where you REALLY could not fuck up.
- So, getting on to the point of this talk… First of all, what is a framework? Well, that’s something that’s not really easily defined. We’re a bit sloppy with language in this area. So many terms that we use lazily. But for the purposes of this, I’m taking a framework to be, REALLY BROADLY, “something that helps you build CSS more efficiently”.
- So does that mean something like Bootstrap? I mean, bootstrap let’s you build a website, yeah? But does it? Bootstrap is mostly just something that you drop onto a website. This may be harsh, but to me, Bootstrap is a collection of design patterns. It’s not really something that allows you to build your own code. If you’ve ever used it, you know you end up overriding everything. (Forgive me, I know about some of the mixins available. But they’re not really forefront, are they?)
- Perhaps Bourbon is a better example. It’s a collection of Sass mixins and functions that you can use to output your own CSS. But to me, although its quite amazing and I’m in awe of it, it’s not a framework framework as such. It’s more a collection of tools, that you can choose your own way of using.
- I guess to me, a CSS framework is something in-between. Something as powerful as Bourbon, that allows you to easily and quickly produce something like Bootstrap. A framework is more… opinionated. Something documented, with an input, a way of working and an output. To use a terrible analogy: a framework is not just the hammer in your toolkit. It’s not just the toolkit on its own. It’s the combination of tools, experience and manuals, such that allow you to start and finish a project efficiently for a client’s needs. Dave Ruperts said that we should be delivering a “series of mini-Bootstraps” to each of our clients. We should ideally be handing them a complete pattern library, so that they can build and extend their own websites.
- And that’s why I built my own system. It’s called Loom. It’s very new, and a work in progress, but it’s a complete framework designed to help people like me, and you, to build pattern libraries faster. It’s not like Bootstrap. It’s not a collection of pre-made patterns that can be dropped into a site. It’s not like Bourbon, which focusses on the generation tools themselves. It’s a factory. A production line. It’s a system that allows you to churn out or weave your own pattern libraries.
- I don’t want to concentrate too much here on how it works. If you’re into that, go and look it up on github and take a peek. But perhaps an overview is worth it it’s a Sass framework that takes in various variables and settings and uses them to spit out CSS. It’s built with design systems in mind, which means that It’s designed to produce components in a systematic, standardised way. It’s nothing NEW. Things like this exist already. And all the components have been around for years. But I hope that it could be come something bigger.
- Design systems are really important. On a project, of any size, standardising things like spacing, colours and font families is vital if any kind of expansion could occur, or multiple people are to work on things. So in Loom every spacing unit, every colour, every font, every text-style, comes from a variable. Even better, all collections of units come from Sass maps and lists.
- And you’d end up accessing these lists and maps via an understandable function. get-spacing. get-color. get-font-family. This means no more `margin-left: 25px` in your code. It means no more `color: #333` in your code. It means a more… organised approach to things. It means that a design system is the main definition of colours and fonts and spacing. And again, nothing new here. But this is rarely enforced. Loom tries to enforce this stuff.
- Inverted Triangle CSS. If any of you follow the work of Harry Roberts you’ll know about this. It forces your CSS to source order as the way to define specificity.
- What does that mean? All Sass partials are arranged in layers, with the most broad, the least specific, sitting at the top. As you go down the triangle, things get more specific and narrower in scope. It’s a controlled approach to selector specificity. Great for teams!
- At the same time, classes are kept as simple and as flat as possible. There’s no Sass nesting in Loom. I know it’s attractive, but it’s ultimately destructive. The lack of nesting prevents any particular chunk of CSS specificity from rising above the average. These two things together mean no more of this……..
- No more “I’ll just add something to the end of the stylesheet that beats the selector I want to override”. Source order becomes the primary mechanism of deciding what selector “wins”. Again, nothing new. Just some preexisting practises that are used in the framework.
- I’d initiated and developed another in-house framework on a previous project, and had found the process to be really useful. But that one was built with the needs of specific projects in mind, and it didn’t fulfil the needs of the broader community. I wanted to build something that worked for all potential users, however you write your CSS code. And also…. because I could. I wanted to do things better. I’d seen similar frameworks. I knew there was a better way of doing it.
- I could just stand here and go over every line of code in Loom, but you could do that yourself on github. But I think these talks are a really important place for learning process, on HOW we learn and code, not what we code. And this is really important as I guess that there’s a variety of experience levels here, and it’s really important, as a community, that we learn and grow together. So, I want to talk about what I learned while building Loom.
- Know what you want to achieve. Know what you want your tool to do. it’s really easy to get “feature creep” in your own head, as you learn about new things and new tech. For example, I kept breaking out of my assigned aim of creating a pure CSS generation library. I kept wanting to javascript helpers. But it really wasn’t helping me achieve my aim. My aim was to create a CSS library generator. Adding other things didn’t help me to get to my endpoint. It just kept pushing me further and further away.
- Be opinionated. Weigh up the pros and cons. Take some time. Evaluate things. Pick a way of doing things and stick to it. I was really nervous about my naming scheme. Folder layers prefixed with numbers. I KNEW a purist would come along and mock that. But to me it was vital - I’m a bit dyslexic and reading lists is really really hard for me. This is really important for those of us who are not white cis males. You tend to end up doubting yourself. You gotta stand up and fight that feeling and be proud. So.……… “Carry yourself with the confidence of a mediocre white man”.
- There will always be someone who comes along and tells you to do things in a different way. Little people. Always trying to undermine others. You know what, everyone has an opinion. But not all opinions were created equally, you know? Trust yourself.
- AT THE SAME TIME… Allow yourself flexibility, so that you can achieve the end result. Allow yourself to be wrong! People learn from making mistakes. If you end up going down the wrong path, allow yourself to turn back and try another route. I really painted myself into a corner with how I was using fonts. Like, I found out they would WORK, but I wouldn’t be able to use them efficiently in a project. I ended up having to remove what I’d done and restructuring half the project to accommodate a new way of fonts. That wasn’t changing direction for the sake of it. That was changing things so that stuff worked. It was a considered change induced by need, not vanity.
- Don’t ignore what others have already done. Even if you don’t agree from it, LEARN. Bourbon is amazing - learn from it. The mixins in there are so damn powerful, it’s unreal. InuitCSS is wonderful. It was what inspired me to write any kind of framework in the first place. The use of ITCSS in there is inspirational. You can draw on the pool of the community knowledge and experience. You’re not alone and you shouldn’t try to do everything alone. I was screwed for ages trying to come up with a robust media-query system. I eventually realised that I could just use something developed by someone else. Sass MQ is amazing, so why not just use it? It is licensed under MIT, so I could just pick it up and go.
- It’s possible to over engineer to death. Inspired by something I’d seen - and fundamentally misunderstood - in Bourbon I started working on a mixin like this…
- It was longwinded and awful I haven’t got the original to show you as I kinda burned it from my memory. I could have just written this….
- Know when to stop. Always bring it back to your final aim. Does your extra code add anything for the user? Or are you doing it for yourself?
- Take everything simply, and slowly. Don’t try and build something that is perfect from the start. Things are going to change. You need to be flexible, like I said before. So, make successive passes at your code. Write what you want to achieve initially. Write it as a comment. Then play, make it do something. Then make it work. Make sure it does what you want it to do. Then make it better. Not just a coding issue. People in other industries face this. A novel isn’t written grammatically perfect from the start, with everything in there. A plot framework comes first, then chapters, then editing.
- Dunno about you, but I’ve always sucked at documentation. But it’s amazing. Finding a good documentation system is like finding a good… I dunno… a good dentist. You’ll stop being afraid and you’ll want to visit again. Same with documentation. I found Sassdocs to be a wonderful tool for this. Add what your code does as comments, and Sassdocs will find those comments and build a little manual for you based on it. If you find a system like that, one that is great, you’ll *want* to document everything. It is so so so pleasing to see everything you’ve written documented in a page. And this is really important. You are not working in a vacuum. You are part of a community, or a team, and your code has to outlive you. And this community spirit doesn’t just apply to documentation. It applies to your code. Think about the people you work with. Imagine you have never seen this code before. You might have put a fancy shorthand piece of code in there.
- And finally…. Come up with a good name! You would not believe how long it took me and my partner in a bar, drinking beer and trying to come up with a name even this bad. I had a bad hangover by the end of the process, for sure. It’s genuinely fun to try and come up with one, but it’s also so important for namespacing and package naming.
- Thanks for listening. Just to note as well that I’m looking for a new position right now. Ask me any questions later on.