Workshop SASS for BEM development
1 like176 views
This document summarizes a workshop on using BEM methodology and SASS for frontend development. The workshop covers installing and using BEM for layouts and components, the principles of BEM naming conventions, and best practices for writing scalable, maintainable CSS code with SASS. Attendees will learn about blocks, elements, and modifiers in BEM, how to avoid deep nesting in CSS, and techniques for refactoring code to reduce duplication while keeping selectors simple. The presentation emphasizes writing semantic, modular CSS through proper application of BEM and use of mixins and extends in SASS.
Workshop SASS for BEM development
- 1. Workshop SASS for BEM development by Vittorio Vittori
- 2. Hi, I’m Vittorio 2 I do frontend stuff @ ideato Mainly CSS and HTML vit.to/about github.com/vitto linkedin.com/in/vittoriovittori
- 3. Workshop contents Practice ● Installation ● Let’s make some layout ● Now it’s components time ● Scalability conclusions Theory ● What is BEM ● What to DO and NOT to do ● Exercise: Let’s draw some BEM ● Some CSS and SASS ● What to DO and NOT to do 3
- 5. A brief history BEM was created at Yandex by Vitaly Harisov as main author en.bem.info/methodology assortment.io/posts/introducing-bem-css-naming-convention smashingmagazine.com/2016/06/battling-bem-extended-edition-common-problem s-and-how-to-avoid-them/ 5
- 6. Block Block Block Block Block Block Block Block Block Block Block Encapsulates a standalone entity that is meaningful on its own. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well. getbem.com/naming 6
- 7. Block Encapsulates a standalone entity that is meaningful on its own. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well. getbem.com/naming .header .control-panel .slideshow .menu .post .news .share .footer .social .login 7
- 8. Block Encapsulates a standalone entity that is meaningful on its own. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well. getbem.com/naming Block Block Block Block 8
- 9. Block Encapsulates a standalone entity that is meaningful on its own. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well. getbem.com/naming .header .control-panel .post .share 9
- 10. Block Encapsulates a standalone entity that is meaningful on its own. While blocks can be nested and interact with each other, semantically they remain equal; there is no precedence or hierarchy. Holistic entities without DOM representation (such as controllers or models) can be blocks as well. getbem.com/naming .header .control-panel .post .share Model Context Action 10 Layout
- 11. Block Be atomic, if you find a context, probably this is a block 11 .header .header-menu ContextLayout Atom Atom
- 13. Block Be atomic, if you find a context, probably this is a block .header 13 Layout .header-menu .header-menu__item .header-menu__item Layout Context ContextAtom Atom
- 14. Element Parts of a block and have no standalone meaning. Any element is semantically tied to its block. getbem.com/naming 14 Block Element Element
- 15. Element Parts of a block and have no standalone meaning. Any element is semantically tied to its block. getbem.com/naming Post Title hr 15 go Date body infos
- 16. Element Parts of a block and have no standalone meaning. Any element is semantically tied to its block. getbem.com/naming .post .post__title .post__hr 16 .post__go .post__date .post__body .post__infos
- 17. Element Parts of a block and have no standalone meaning. Any element is semantically tied to its block. getbem.com/naming .post .post__title .post__date .post__hr .post__body 17 Model Model property .post__infos.post__go Action ContextLayout
- 18. Don’t Don’t use deeper nesting. BEM is designer to keep stuff simple and clean. Only blocks has elements, there aren’t element’s elements. .modal 18 .modal__header .modal__header__title
- 19. Do If elements are nested, just nest them without use naming concatenation. 19 .modal .modal__header .modal__title
- 20. Modifier Flags on blocks or elements. Use them to change appearance, behavior or state. Block + Block’s modifier 20 Element + Element’s modifier Element + Element’s modifier
- 21. Modifier Flags on blocks or elements. Use them to change appearance, behavior or state. 21 Button + Warning Button + Featured Button + Close Button + Disabled
- 22. Modifier Flags on blocks or elements. Use them to change appearance, behavior or state. 22 .button .button--warning .post .post--featured .button .button--close .button .button--disabled
- 23. Modifier Flags on blocks or elements. Use them to change appearance, behavior or state. 23 .button .button--close .button .button--warning .post .post--featured Meaning Model property .button .button--disabled State Action
- 24. Don’t Don’t use style infos as modifiers, doesn’t help devs to understand how layout element works. If this happens, it means you need more infos about the project. .post .post__header .post__title .post__title--bold-underline .post__title--move-bottom .post__title--margin-top 24
- 25. Do Use meaning by state, model property or state and reduce style naming on modifiers when you can. .post .post__header .post__title .post__title--featured 25
- 26. Don’t Don’t use alone modifiers. They suffers of abandonment syndrome. Modifiers are meant to modify, not to be. .post .post__header .post__title--featured 26
- 27. Do .post Modifiers are meant to modify things, not to be things. Every modifier has it’s block or element and they can be concatenated. .post__header .post__title .post__title--featured .post__title--old 27
- 28. Exercise Let’s find blocks on this paper. 28
- 30. Don’t Don’t nest selectors in CSS, doesn’t give anything more of what we need, just makes overriding more difficult. 30 // CSS .modal { background-color: rgba(0, 0, 0, 0.85); } .modal .modal__window { background-color: white; }
- 31. Do Keep selectors specificity as low as you can, when you can. 31 // CSS .modal { background-color: rgba(0, 0, 0, 0.85); } .modal__window { background-color: white; }
- 32. Don’t Every day, when someone mixes coding styles and country languages, somewere in the world, a good front-end developer dies. 32 // CSS .modal { background-color: rgba(0, 0, 0, 0.85); } .modal__finestra { background-color: white; } .modal__Pulsante--Close { background-color: black; color: white; }
- 33. Do Keep selectors specificity as low as you can, when you can. Consistency is the key to work inside a team. 33 // CSS .modal { background-color: rgba(0, 0, 0, 0.85); } .modal__window { background-color: white; } .modal__button--close { background-color: black; color: white; }
- 34. Don’t Avoid !important, it should be used only on modifiers, if needed. 34 // CSS .modal { background-color: black !important; } .modal--problem { background-color: red; }
- 35. Don’t Avoid !important on modifiers, if they don’t give anything more to your code. 35 // CSS .modal { background-color: black; } .modal--problem { background-color: red !important; }
- 36. Do The !important is not the enemy, it should be used just when needed. 36 // CSS .modal { background-color: black; } .modal--problem { background-color: red !important; } @media (max-width: 768px) { .modal { background-color: blue; } }
- 37. SASS Syntactically Awesome Style Sheets 37
- 38. BEM coding Write code as simple as you can. sassmeister.com 38 .item { background-color: white; max-width: 400px; width: 100%; &--wide { max-width: 600px; } &__title { color: black; font-size: 24px; font-weight: 700; &--warning { color: red; } } }
- 39. Don’t Nesting is your enemy. This outputs a monster. sassmeister.com 39 .item { background-color: white; max-width: 400px; width: 100%; &__title { color: black; font-size: 24px; font-weight: 700; &--warning { color: red; } &__icon { margin-right: 10px; } } }
- 40. Do BEM naming convention is your friend. 40 .item { background-color: white; max-width: 400px; width: 100%; &__title { color: black; font-size: 24px; font-weight: 700; &--warning { color: red; } } &__icon { margin-right: 10px; } }
- 41. How decrease nesting errors? Write SASS mixins that helps you to keep code clean. Go to GitHub and start play: github.com/vitto/workshop-bem-and-sass#play-examples 41
- 42. Do not duplicate code, it can became an hell when you need to scale it. Don’t 42 .body { font-family: Helvezia, Aria, sans; font-weight: 400; } .button { font-family: HelveziaBold, Aria, sans; font-size: 12px; font-weight: 700; } .title { font-family: HelveziaBold, Aria, sans; font-size: 18px; font-weight: 700; }
- 43. Do not exagerate with refactoring or you’ll just write code twice. Don’t 43 %buttons { font-family: HelveziaBold, Aria, sans; font-size: 12px; font-weight: 700; } %titles { font-family: HelveziaBold, Aria, sans; font-size: 18px; font-weight: 700; } .button { @extend %buttons; } .title { @extend %titles; }
- 44. Do not exagerate with refactoring or you’ll just write code twice. Be forced to override properties is a bad smell of bad scaling. Don’t 44 %buttons { border-radius: 8px; ⬅ font-family: HelveziaBold, Aria, sans; font-size: 12px; ⬅ font-weight: 700; } .button { @extend %buttons; } .button-nice { @extend %buttons; border-radius: 0; ⬅ font-size: 16px; ⬅ }
- 45. Do When you find duplicates, it’s time to make some refactoring. 45 %bold { font-family: HelveziaBold, Aria, sans; font-weight: 700; } .body { font-family: Helvezia, Aria, sans; font-weight: 400; } .button { @extend %bold; font-size: 12px; } .title { @extend %bold; font-size: 18px; }
- 46. Question Have I done something wrong due to the fact I need to do some refactoring to my code? Should I write my code scalable proof by the beginning of the project? No, it’s ok, it’s the right way a developer does, organize code when needed. Only if your project needs to be scalable, this doesn’t mean write bad code, but write the code you need. 46 Answer
- 47. Question Should I be generic when I write a component? So using something like .grid for the layout and use it everywhere in the project? The more you are generic, the more you need to make it flexibile. This is a bad smell. A component with a lot of purposes is a bad component. If you notice you are adding a lot of code, maybe it’s time to split it on two different grid components. 47 Answer
- 48. Pros ● Your project is scalable ● Devs will understand how the HTML template works very fast ● Just one level class selectors ● Conflict proof selectors ● Flexible end reusable components ● Nice for teams ● It’s time consuming ● It’s hard to naming things ● Verbose selectors naming 48 Cons
- 49. Now go to the project And let’s make some code
- 50. Thank you to be here Have a nice 2018!