CSS, planeando para el futuro

Un mejor CSS
Planeando para no sufrir en el futuro.
DrupalCon Latin America - Febrero 2015

Jose Leiva
@leivajd // leivajd.com

Que nuestro “yo” del futuro
no nos odie ;)
Objetivo

selector{
propiedad: valor;
}

selector{
propiedad: valor;
propiedad: valor;
}

selector{
propiedad: valor;
}
selector{
propiedad: valor;
}
selector{
propiedad: valor;
}
selector{
propiedad: valor;
}
} .css

Escribir CSS es sencillo.
Pero...

.headerMenu ul.menu li.active-trail a {
background: #D0DFEF;
}

.view-news-and-press.news-right-side-bar-
block .views-row {
position: relative;
min-height: 60px;
}

.item-title,
#main-column .item-title,
#second-column .item-title,
.primary-lead-area .item-title,
.second-lead-area .item-title {
font-size: 18px;
border: 0;
font-family: Georgia;
margin: 0;
clear: none;
padding-bottom: 5px;
}

• Alta especificidad
• Alta dependencia HTML

• Golpea performance

• Difícil de reutilizar

• Difícil de reutilizar
:(

Escribir CSS es sencillo.
La arquitectura no.

Arquitectura
Herramientas, planear & escribir
CSS de manera que el código sea
de calidad

• Performance
• Reusable
• Hace lo que debería?

• Performance
• Reusable
• Mantenible y escalable

• Performance
• Reusable
• Mantenible y escalable
:)

Pensemos en nuestros amigos del
back-end. Organización, variables,
parciales, objetos y abstracción.

OOCSS, BEM & SMACSS, no
son librerías o framework, son
metodologías.

• Entender el todo y sus partes.
• Organización y estructura.
• Vanilla CSS o prepocesadores.

CSS preprocesadores, llenan
vacíos.

CSS preprocesadores, llenan
vacíos. Son una abstracción.

• Son excelentes, si se usan correctamente
• Dividir en pequeños pedazos
• Proveen abstracción
• No reemplazan CSS o arquitectura

foo {
...

zaa {
...
}
}

.home_page_at_work {
.views-field-field-primary-image-attachment {
.field-content {
img {
...
}
}
}
}

.home_page_at_work .views-field-field-prima-
ry-image-attachment .field-content img {
...
}
:(

• No anidar == HTML
• Un ojo en el output
• Si podemos, no anidar
• Regla 3 niveles

stylesheets[all][] = css/reset.css
stylesheets[all][] = css/drupal-stuff.css
stylesheets[all][] = css/base.css
stylesheets[all][] = css/layout.css
stylesheets[all][] = css/typo.css
; FOD
stylesheets[all][] = css/ds_2col.css
stylesheets[all][] = css/search.css
stylesheets[all][] = css/system.menus.css

stylesheets[all][] = css/screen.css

stylesheets[all][] = css/screen.css
Magic en lugar FOAD
https://www.drupal.org/project/magic

// Screen
// =======================
// Variables, Mixins, functions
@import “partials/base”;
// Page
@import “partials/page/screen”;
// Patterns
@import “partials/patterns/screen”;
// Layout
@import “partials/layout/screen”;
// Modules
@import “partials/modules/screen”;
screen.scss

// Links
// ===================
a {
color: $blue; text-decoration: none;
&:hover,
&:active {
color: $black;
}
}
_links.scss

• Son excelentes, si se usan correctamente
• Dividir en pequeños pedazos
• Proveen abstracción
• No reemplazan saber CSS

Pensar en objetos o abstracciones, y
desgranar esos componentes en piezas
pequeñas.

.promo-box {}
.promo-box h3 {}

.promo-box {}
.promo-box h3,
.promo-box h4 {}

.promo-box {}
//mi heading puede ser cualquier elemento
.promo-box .promo-box-h {}

.product-list .product-item {}
.product-item {}

<ul>
<li class=”product-item”>Product 1</li>
</ul>
<p class=”produt-item”>Product 1</p>
<div class=”product-item”>
<h3 class=”produt-item-h”>Product 1</h3>
<p>Detalles</p>
</div>

Cuidado con los dogmas, siempre le
hemos tenido miedo a la clasitis, pero
si nos funciona no hay porque
descartarlo.

Sentido común. Escribir patrones una
vez, reusar esos pedazos.

• Training
• Buenas prácticas

Sintaxis, formato consistente,
convenciones para nombres*, etc

.promo-item {
background-color: #000;
color: #fff;
padding: 10px;
}

https://github.com/ahmednuaman/grunt-scss-lint

There are only two hard things in
computer science: cache invalidation and
naming things. - Phil Karlton

• SMACSS - http://bit.ly/1ILqWwb
• BEM - http://bit.ly/1CPXvpb
• OOCSS - http://bit.ly/1zGLVdH

OOCSS Principios:
• Claridad
• Semántico
• Genérico
• Breve

.is-touch {
...
}
.is-hidden {
...
}
.is-selected {
...
}

.tab {
...
&.is-selected {
...
}
}
//output
.tab.is-selected {
...
}

.items-list {
...

.item-thumb {
...
}
}
Padre - Hijo

.product-list {
...
}
.product-list-thumb {
...
}
Padre - Hijo

Contexto. Asignar cambios de estilo
sólo a elementos que cambien por
página, no a objetos.

.cart {
.main-content {
...
}
.sidebar {
...
}
}

.promo-box {
background: red;
color: white;
}
// atados a la estructura
.sidebar .promo-box {
background: black;
}

.promo-box {
background: red;
color: white;
}
// usamos la Cascada
.promo-box-dark {
background: black;
}
class=”promo-box promo-box-dark”
Subclassing

.promo-box {
background: red;
color: white;
}
.promo-box-dark {
@extend .promo-box;
background: black;
}
class=”promo-box-dark”
Subclassing

.promo-box,
.promo-box-dark {
background: red;
color: white;
}
.promo-box-dark {
background: black;
}

.promo-box {
background: red;
color: white;
}
.promo-box-dark {
@extend .promo-box;
background: black;
}
...
.promo-wrap .promo-box {
margin: 0;
}

.promo-box, .promo-box-dark {
background: red;
color: white;
}
.promo-box-dark {
background: black;
}
.promo-wrap .promo-box,
.promo-wrap .promo-box-dark {
margin: 0;
}
:(

Cuidar el output.
%placeholder es una buena
alternativa.

.btn,
%btn {
...
}
.btn-positive {
@extend %btn;
...
}
.btn-negative {
@extend %btn;
...
}

.btn,
.btn-positive,
.btn-negative {
...
}
.btn-positive {
...
}
.btn-negative {
...
}

.ui-promo-item {
...
}
class=”ui-promo-item js-promo-item qa-
promo-item”

Tenga una convención,
documéntelo y adhiérase a ella.

Lectura recomendada
http://24ways.org/2014/naming-things/
http://nicolasgallagher.com/about-html-semantics-
front-end-architecture/

• Training
• Buenas prácticas
• Documentar

http://codepen.io/chriscoyier/blog/codepens-css

/**
* Contents
* =========
* 1. Reset
* 2. Base
* 3. Layout
* 4. Modules
**/
...
/*
* =Reset
*/

/**
* Titulo
* 1. Descripción del comentario,
* detalles de porque se necesita,etc
**/
.foo {
overflow: hidden; /* [1] */
}

// En cada bloque de reglas, los
// @include o @extend se incluyen
// de primero, para evitar sobre
// escribir declaraciones.
// .foo {
// @include mixin-name;
// propiedad: valor;
// }
_mixins.scss

// Tip
// --------------------
// Create a rectangle-triangle to be
// used as a tip.
@mixin tip($color: $orange) {
...
}
_mixins.scss

CSS no es siempre el problema:
trabajamos con otros devs, falta de
conocimiento, diferentes técnicas.

Pragmatismo sobre perfección. Mejor un
“good enough” hoy, que un “perfecto”
mañana.

El código del equipo debe ser un libro que
cualquiera puede leer, no un diario personal.

Escribamos menos CSS. Cada parte es un
potencial punto de falla, reducir features y
código.

Modularidad en CSS no es realmente la meta.
vMantenibilidad es. Si CSS es modular pero
es difícil de mantener, entonces es malo.

http://www.slideshare.net/leivajd

Evalúa la sesión.
https://latinamerica2015.drupal.org/node/4083

CSS, planeando para el futuro

Más contenido relacionado

Similar a CSS, planeando para el futuro (20)

Último (20)

CSS, planeando para el futuro