Writing Maintainable, Modular and Scalable CSS

Slide 1

Slide 1 text

Writing Maintainable, Modular and Scalable CSS By Ahmad El-Alfy 26th November 2016

Slide 2

Slide 2 text

Who Am I • Wrote my first HTML page 18 years ago using Netscape Composer. • Converted a lot of designs, PSDs, Origamis to HTML/CSS/JS. • Worked with different sized companies and organizations as a front- end developer, a trainer and a consultant. • Currently work as head of software development and front-end developer at robusta. • When I am not fixing bugs or building web applications; I spend time trying to be a good parent.

Slide 3

Slide 3 text

Agenda • Why people consider CSS “difficult”. • Previous trials to write “sane” CSS. • Current popular methodologies for writing CSS. • Common best practices.

Slide 4

Slide 4 text

Introduction

Slide 5

Slide 5 text

Maintainable Scalable Modular

Slide 6

Slide 6 text

CSS Concepts Cascade Specificity Source Inheritance

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Creating *Layout* in Android Studio

Slide 9

Slide 9 text

Creating *Layout* in Xcode

Slide 10

Slide 10 text

• CSS is extremely simple to learn and to get started with. • One of the goals author had in mind while making CSS was backward compatibility. That meant when a parser encounter a rule it do not understand; it would simply skip that declaration and move on to the next. Unlike other languages which will throw exceptions and exit the program. • The problem with CSS is that it becomes hard to work with at any reasonable scale because picking class name is surprisingly extremely difficult.

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

What makes CSS difficult • Everything is global. Selectors are matched against everything in the DOM. We need naming strategies to combat against this and keep things efficient (which are hard to enforce and easy to break). • It’s highly dependent on Source order. What an inexperienced developer can write at the end of the document can override and break rules written before it. • CSS grows over time. Smart people on great teams cede to the fact that they are afraid of their own CSS. You can't just delete things as it's so hard to know if it's absolutely safe to do that. So, they don't, they only add.

Slide 13

Slide 13 text

Previous trials and patterns

Slide 14

Slide 14 text

CSS Patterns Resets •Undohtml.css •YUI global reset •Eric Meyer’s Reset •Normalize Methodologies •BEM •OOCSS •SMACSS •Suit UI •ITCSS

Slide 15

Slide 15 text

CSS Resets • CSS resets was an attempt from the authors to get browsers out of the equation. We began to see this popular pattern emerging. • It began in 2004 when Tantek Celik wrote a blog about a CSS snippet he's been using called undohtml.css (http://tantek.com/log/2004/09. html#d06t2354) It was a pretty light reset by today's standards.

Slide 16

Slide 16 text

CSS Resets – cont. • Two years later 2 other resets emerged, the global YUI reset and Eric Meyer's reset. • Eric continued working on his reset year after year till 2009 then he decided to stop. • In 2011 Nicolas Gallagher and Jonathan Neal started working on Normalize.css It wasn't trying to remove the browser style instead it was trying to make all browsers have the same underlying defaults. It made it lighter and made it put far less coding on the frameworks and as a result it is nearly included on almost every open source project today.

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

Structuring and Naming in CSS

Slide 20

Slide 20 text

• In 2002 Tantek Celik wrote a blog post called A Touch of Class (http://tantek.com/log/2002/12.html#L20021216). His article recommended a few practices to write what he called "Good CSS". He suggested a few things like ₋ using semantic HTML. ₋ using context before classes. ₋ using structural class names over presentational class names like sidebar instead of right-bar and error instead of redtext. ₋ lowercase class names.

Slide 21

Slide 21 text

A Touch of Class - examples

Slide 22

Slide 22 text

A Touch of Class - examples

Slide 23

Slide 23 text

Using structural class over presentational class

Slide 24

Slide 24 text

Using structural class names over presentational class names

Slide 25

Slide 25 text

Using structural class names over presentational class names

Slide 26

Slide 26 text

BEM

Slide 27

Slide 27 text

• BEM was presented back in 2007 in a Russian CSS conference. A naming convention that means (Block, Element & Modifier). It looks bizarre and ugly at the beginning but it's the basis for building a great, solid and scalable CSS. • BEM consists of: - Block is the root class like a tweet - Elements are the elements inside a block ... The pieces that construct that block. Like (tweet author, tweet text, tweet buttons) ... It consists of the block class name in addition to __ - Modifier can be added to a block or element and is meant to provide alternative states for the element (like promoted tweets) and they consist of the block/element name in addition to --

Slide 28

Slide 28 text

BEM - example

Slide 29

Slide 29 text

BEM - example

Slide 30

Slide 30 text

Even easier BEM-ing with Sass 3.3

Slide 31

Slide 31 text

Problems solved by BEM • Address the most complex and difficult problem with CSS; naming. • Gives you context for what this selector is used for. BEM unambiguously defines which CSS belongs to a piece of interface and so using it gives answers to questions "Can I remove this piece of code?”. • Provide self documented code. • Promote modularity and reusability. • Provide common terminologies between developers. • Eliminate subtree matches

Slide 32

Slide 32 text

Example vs We clearly can identify that the second example selectors belong to the search in the header area.

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

Common FAQ • Can a block modifier affect elements? Although BEM advice against using nested selectors, this particular case using nested selector is very reasonable.

Slide 35

Slide 35 text

Common FAQ – cont. • Is this good to name modifiers corresponding to what they have in CSS? .block__element--border-bottom-5px Naming the modifiers corresponding to their CSS representation is not recommended. Indeed it looks not very nice but there are also practical reasons against it. Lately then the view of your components is changed, you will need to fix not only CSS but also the selectors.

Slide 36

Slide 36 text

Common FAQ – cont. • What would be a class name for an element inside another element? .block__el1__el2? According to BEM method, block structure should be flattened; you do not need to reflect nested DOM structure of the block. So, the class names for this case would be: .block {} .block__elem1 {} .block__elem2 {} .block__elem3 {}

Slide 37

Slide 37 text

Why BEM is awesome? BEM help us overcoming the cascading problem. BEM challenges the cascade by forcing the authors (us) to be incredibly mindful when it comes to naming limiting the wrong number of CSS classes through block namespaces and establishing relationships between blocks and elements rather than writing generic complex names.

Slide 38

Slide 38 text

OOCSS

Slide 39

Slide 39 text

OOCSS • In 2009 Nicole Sullivan presented what she was calling OOCSS. Nichole was saying that CSS authors where trying to protect themselves from the cascade by sandboxing their styles using ID driven modules. Nicole encouraged people to start writing low level reusable components. • Nichole explained on her post how she saved hundreds of lines of code by the module component. (http://www.stubbornella.org/content/2010/06/25/ the-media-object-saves-hundreds-of-lines-of-code/)

Slide 40

Slide 40 text

OOCSS

Slide 41

Slide 41 text

OOCSS focuses mainly on 2 points 1. Separation of structure from skin

Slide 42

Slide 42 text

OOCSS focuses mainly on 2 points 2. Separation of container from content. Avoid nesting selectors and DOM coupling.

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

SMACSS and SUITCSS

Slide 50

Slide 50 text

SMACSS In 2011 Jonathan Snook wrote a post called Thinking about CSS architecture introduced a project he was working on called SMACSS (Scalable and Modular Architecture for CSS) SMACSS is all about categorization: 1. Base -> Basic style for the elements (like links, paragraphs, headers) 2. Layout -> For the components that divide the page into sections and they have the (l-) prefix 3. Module -> Components on the webpage and they have no prefixes 4. State -> (is-) prefixed classes like (is-open, is-active) when a module is in a particular state. 5. Theme -> for other different styles that cannot really fit within the previous categories.

Slide 51

Slide 51 text

SUIT CSS SUIT CSS defines itself as a methodology for writing component- based UI development. Nicolas Gallagher was trying to combine all these efforts by using BEM and state/utility prefixes (is- and u-) like SMACSS!

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

Inverted Triangle CSS ITCSS is defined by Harry Roberts as a group of thoughts for writing a sane, scalable and managed architecture. It is compatible with CSS methodologies like BEM, SMACSS or OOCSS. The key principles of ITCSS is that it separates your CSS codebase to several sections (called layers), which take form of the inverted triangle

Slide 54

Slide 54 text

• Settings – used with preprocessors and contain font, colors definitions, etc. • Tools – globally used mixins and functions. It’s important not to output any CSS in the first 2 layers. • Generic – reset and/or normalize styles, box-sizing definition, etc. This is the first layer which generates actual CSS. • Elements – styling for bare HTML elements (like H1, A, etc.). These come with default styling from the browser so we can redefine them here. • Objects – class-based selectors which define undecorated design patterns, for example media object known from OOCSS • Components – specific UI components. This is where majority of our work takes place and our UI components are often composed of Objects and Components • Trumps – utilities and helper classes with ability to override anything which goes before in the triangle, eg. hide helper class

Slide 55

Slide 55 text

The specificity graphs

Slide 56

Slide 56 text

With ITCSS • You can remove or add layers as you need them. No preprocessors? Remove the first two layers Want to add a testing layer? Add it before the Trumps • No longer have to worry about the end of the file. • Things never get more complicated, only bigger. • The specificity graph keep going upward.

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

كع

Slide 59

Slide 59 text

ATOMIC CSS

Slide 60

Slide 60 text

People even suggested moving CSS to JavaScript

Slide 61

Slide 61 text

Coding best practices

Slide 62

Slide 62 text

What you already know … • Using structural over presentational class names. Example: .side-bar over .right-bar • Avoid using ID selectors. • Avoid nesting too deep. Example: .article > p:first-child > a + span[lang=“en”]

Slide 63

Slide 63 text

What you should also do … • Understand the basic CSS feature will prevent you from writing redundant unnecessary code like: 1. applying display block or width 100% to a block element. 2. setting an element position to absolute value or floating it automatically shift its display to become a block. You don’t need to declare that it is a block again. 3. inline elements are not affected by width and height values. You shouldn’t apply width or height to an inline element. 4. vertical margins have no effect except on absolutely positioned elements and items inside a flex container.

Slide 64

Slide 64 text

• Don’t use libraries that add a lot of styling to your stylesheet. Examples: 1. jQuery UI 2. Libraries that lack the flexibility to define your mark up for the elements (e.g. sliders, tabs … etc). 3. Libraries with poorly written CSS. You should check its stylesheet and be picky. • When using a framework, make sure that you are not including something it already include (like a reset). • Use only the parts of the frameworks that you need. Don’t include additional 100KB file just because you need a tooltip. • Use SVG or icon fonts for icons. They are super simple to style.

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

Use CSS Writing Style Guide

Slide 69

Slide 69 text

Use a Shame file

Slide 70

Slide 70 text

Harness the power of modern features. Use modern technologies like Flexbox to achieve layout enhancements instead of manually adding specific markup or magic numbers here an there. Don’t waste your time on old browsers

Slide 71

Slide 71 text

On “the site must look the same across all browsers”

Slide 72

Slide 72 text

Example: Sticky Footer

Slide 73

Slide 73 text

Example: Equal height columns

Slide 74

Slide 74 text

Example: Sticky content

Slide 75

Slide 75 text

Perfectly separated content

Slide 76

Slide 76 text

The “Pixel Perfect” Dilemma

Slide 77

Slide 77 text

Disclaimer The following points are based on my experience. They are my opinions which you can disagree with. It’s perfectly fine. I encourage you to stop me and discuss whatever you would like.

Slide 78

Slide 78 text

The process of converting a design into HTML and CSS is not complicated. Most of the elements the designers create can be easily converted to HTML and CSS. The complexity lies in doing it with maintainable and reusable code with few “magic numbers”. Design isn’t anything but a reference. It’s a document that provide guidelines. We lose a lot by treating it as a contract.

Slide 79

Slide 79 text

Just because you can, does not mean you should

Slide 80

Slide 80 text

Countless hours are wasted on every company on arguments and fights between graphic designers and user interface developers. They both hate each other instead of working together. Your job as a user interface or front-end developer is to help the graphic designer understand why adding this particular component with shadows is bad for maintainability and the graphic designer job is to listen to you and help you find a less complicated solution.

Slide 81

Slide 81 text

Normalize and Abstract If you have multiple similar colors that you cannot differentiate between with your eye and can only spot the differences with the eye dropper; use only one.

Slide 82

Slide 82 text

Normalize and Abstract Same goes for the font sizes. There are no significant differences between 11px and 12px; pick one. The numbers go higher for padding and margin. There aren’t significant difference between 18px, 20px and 22px on padding.

Slide 83

Slide 83 text

Normalize and Abstract Discuss with the designer the possibility of reducing the used font weights and styles to improve performance

Slide 84

Slide 84 text

Normalize and Abstract Develop a style guide to limit the colors and the dimensions of the elements you are using. “Can we make *this* button bigger”? It’s a common question we get everyday. It isn’t technically difficult. But it would require me to add one class just to satisfy this request. Why? Is it really worth it?

Slide 85

Slide 85 text

https://dribbble.com/shots/1121606-Admin-Dashboard

Slide 86

Slide 86 text

https://dribbble.com/shots/615232-Dropdown-Menu

Slide 87

Slide 87 text

https://dribbble.com/shots/524735-Header

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

Thank you! ahmadalfy ahmad@alfy.me