Front End - CSS Practices

Web Front End

CSS methodologies and performance

SMACSS

But really,

CSS?

Scalable and Modular

Architecture

SMACSS

Usually used in large scale projects

I.E. Yahoo web mail

A set of rules that lets you ensure CSS scalablility and modularity

• Organising your CSS into 5 specific categories:
• Base - generic rules (i.e. body, h1, h2, p, ul, dl, a...)
• Layout - layout based rules (header, footer, content area, aside,...)
• Modules - imagine modules of style-guide (buttons, navigation,...)
• State - elements with changeable states (menu with states)
• Themes - for different visual themes of site (color, accessibility)

• Modular and scalable
• Simple set of rules is easy to understand
• Easy to maintain

• Is quite loose set of rules, might require team to define it's naming conventions
• Might become a little confusing when separated into too many pieces

These categories and structure can be re-defined according to project needs and team decision

Module with state brief example

Popular CSS methodologies

Before we continue...

Possible reaction after all...

BEM CSS

Any questions?

WAT?

Block, element, modifier

BEM CSS

Good for frequently changing DOM

BEM CSS

Basic naming example

BEM provides a strict set of rules on how to name your CSS classes.

Your CSS modules made up of ‘blocks’, ‘elements’ and ‘modifiers’, with underscores to separate.

• Provides strict naming guide, so everyone understands what everything means
• Easy to do OOCSS
• Works well without pre-processor

HTML markup examples

• Very WET (We enjoy typing)
• Markup is overly verbose
• Unsemantic
• Can't reuse easily (complicated scalability)

• ACSS
• DRY CSS
• OOCSS
• BEM
• SMACSS
• Messy CSS

Web Layout

OOCSS

Object orientated CSS

About OOCSS

OO CSS

It's about creating modular components with singular concerns, they can be swapped and shared amongst other CSS modules.

• Reuse same styles for different selectors
• Add additional style to particular elements by defining only differences depending on context

• Define abstract pieces of layout
• Wrap object inner element styles with a wrapping class or ID

• Let's you be DRY
• Isolation of styles per logical element
• Modular
• Easy to maintain

• Might become quite complex
• Changes may lead into unexpected layout issues

Principles and thinking

Base layout with placeholders

Base layout frames

Layout with placeholders and modules

Modules with content and states

Just modules with content and states

Actual preview

Layout

Grid, placeholder

Module

State, variation

Looks like SMACSS

Messy CSS

DRY CSS

Solution? Things to consider

When things are confusing...

AND often inefficient as well!

• SMACSS categorisation + BEM code structure idea?
• __ and -- does not BEM make BEM (can be re-defined)
• Project structure and module types/categories
• Namespacing for classes and IDs
• Max style nesting level before it has to be separated
• Team work: communicate to clarify and improve
• Decisions and guides should land in README.md

Don't repeat yourself

Example

Messy CSS

& we do it as well...

What happens in CSS

These innocently-guilty looking commas turn out into following:

Might cause further tree re-draw

Then it takes browser to render it and then paint it on the screen

Without this unconsidered decision in SASS, it could have been

20.8 ms

32.6 ms

It's only 10 ms - it isn't a big deal. But consider 10x expressions like the one above, 100x?

Found almost everywhere

- Because of quick workarounds

- Different people using different methods

- Lack of communication and team defined standards

- Repetitive code to re-do existing nearly same things from the ground

- Inconsistent layout, overriding of rules

- Long useless selectors because we like to NEST in SASS :-)

10 ms isn't a big deal

Override

But then there are a bit more complex pages

Loans List

Checkout

What is DRY CSS about?

DRY CSS

Evil of comma

• Group reusable CSS properties together
• Name these groups logically
• Add your selectors to the various CSS groups
• Avoid specificity by harnessing the cascade

• More efficiency
• No repetetive CSS properties
• Better naming, easier to understand
• When changing style, you just need to move selector from one group to another, no HTML edit.

ACSS

• Hard to maintain large amount of selectors
• Can't use variables or mixins from SASS (repetition)
• It's more about plain CSS...

Atomic CSS

Example

Atomic CSS

Single responsibility CSS declarations

And... class-rich HTML

• Everything is defined only once
• Good for prototyping / layout
• Very dry

• Small changes may cause broken layout
• Difficult to debug
• Hard to maintain
• Large number of classes applied to the same element

A deeper look

What happens in the browser

CSS rendering efficiency

Selectors from fastest to slowest

Web page rendering cycle

Resources for more knowledge

• Build the DOM
• Calculate CSS property values
• Build the rendering tree
• Calculate layout
• Paint
• Composite

Detailed overview of do's and dont's

https://css-tricks.com/efficiently-rendering-css/