Peter Szerzo
Cph Frontenders, April 12th, 2016
I write front-end at Airtame.
I go by pickled-plugins on GitHub.
You can also find me at peterszerzo.com.
class Person > ActiveRecord::Base
field :first_name
field :last_name
has_many :hopes
has_many :dreams
end
class PeopleController > ActionController
end
import Task exposing (Task, andThen)
import TaskTutorial exposing (getCurrentTime, print)
port runner : Task x ()
port runner =
getCurrentTime `andThen` print
RuntimeException:
- awkward selector div#header > button ~ p
a button
has 6px padding
has standard border radius
is blue by default
is red in primary state
is green in success state
the header contains buttons spaced 10px apart
Does this resemble the way your designer describes a mock-up?
.button {
padding: 6px;
border-radius: $standard-border-radius;
background-color: blue;
&--primary { background-color: red; }
&--success { background-color: green; }
.header & { margin: auto 10px; }
}
Writing CSS is a bit like writing poetry in Danish. I need:
=>
we don't really ever know what's coming.==
, null
, undefined
, NaN
with straaange behavior.class Fellow {
constructor() {
this.name = "Jake";
this.opinion = "The class syntax is kinda nice.";
}
}
Object.create({}, {
name: "Frank",
hardPolicy: "Never hire guys like Jake."
});
use strict
.ESLint
, JSHint
.Flow
, TypeScript
.React
, Cycle.js
.Elm
, Clojure
, Scala
, CoffeeScript
.They are a little bit:
=>
spelling & syntax=>
writing paragraphs=>
writing pro paragraphs=>
writing essays=>
the spellchecker>
Block, Element, Modifier=>
on tablethe=>
the tableonWe agree on grammar rules for a reason.
>
The CSS/* A block. */
.header {}
/* Its element. */
.header__nav {}
/* Its modifier. */
.header--compact {}
>
The HTML<header class='header header--compact'>
<div class='header__content'>
<nav class='header__nav'></nav>
</div>
<div class='header__overlay'>
</div>
</header>
>
SASS syntax.header {
&__content {} /* .header__content */
&__overlay {}
&__nav {}
&--compact {}
}
>
Some house rules/* Flat element structure */
/* Too nested. */
.header__content__button {}
/* The BEM way. */
.header__button {}
>
Some house rules<!-- No global modifiers. -->
<!-- Not encapsulated and slower. -->
<header class="header expanded"></header>
<!-- The BEM way. -->
<header class="header header--expanded"></header>
>
The benefits__
, --
.>
Incentives/* Against BEM rules. */
.header__content__button {}
/* Better - and also reusable across the project. */
.flat-button {}
>
AlternativesAlso worth checking out:
Separate structure from skin.
Separate container from content.
>
Structure and skin.element {
background-color: teal;
border-radius: 2px;
display: block;
font-size: 14px;
margin: 25px;
padding: 5px;
width: 100px;
}
>
Structure and skin.structure {
/* background-color: teal; */
/* border-radius: 2px; */
display: block;
/* font-size: 14px; */
margin: 25px;
/* padding: 5px; */
width: 100px;
}
>
Structure and skin.skin {
background-color: teal;
border-radius: 2px;
/* display: block; */
font-size: 14px;
/* margin: 25px; */
padding: 5px;
/* width: 100px; */
}
>
Container and content#main .title {
display: block;
font-size: 36px;
font-weight: bold;
color: blue;
margin: auto;
text-align: left;
}
>
Container and content.title {
/* I want some styles too! */
}
>
Container and contentBy minimizing nesting:
>
Traditional OOIs any of this applicable to CSS?
>
Traditional OOHow many blocks do I need to change for each minor change in the design?
How easily do I find these blocks?
Am I overriding too much in nested rules?
Is it clear what I'm overriding, and does it make sense with the naming?
>
Code example>
Key pointsIn React, each component:
state
).props
).>
Key pointsIn equivalent CSS, each module:
Categorize styles and set up rules for each:
>
Base rulesUsually applied using the element selector; no classes, id's or !important
.
@import 'normalize.css';
body {
overflow-x: hidden;
overflow-y: scroll;
}
>
Layout rulesstructure
from OOCSS.>
Module rules>
State rules!important
is appropriate here.(current trends might move these rules inside module rules)
>
Theme rules>
Wrap-upThese 5 categories and their rules, as they are, will probably not make sense for your next project.
Write your own Bootstrap.
Tons of alternatives: ITCSS, InuitCSS, Bootstrap, Foundation, Skeleton.
Main goals:
They are:
>
Pre- and postprocessors>
Linters>
Linters{
"selector-no-id": true,
"selector-class-pattern": "/foo-[a-z]+/",
"max-nesting-depth": 3,
"declaration-no-important": true,
"declaration-block-no-shorthand-property-overrides": true,
"color-hex-length": "long",
"declaration-block-trailing-semicolon": "always",
"property-no-vendor-prefix": true,
"value-no-vendor-prefix": true
}
>
TemplatesCSS changes require changes the HTML ...% of the time.
If changing the markup is tedious and error-prone, we won't do it.