CSS, planeando para el futuro

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

Jose Leiva@leivajd // leivajd.com

2007 web

2010 Drupal

Objetivo

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

Objetivo

1CSS es fácil

selector

selector{ propiedad: valor;}

selector{ propiedad: valor; propiedad: valor;}

selector{ propiedad: valor;}

selector{ propiedad: valor;}

selector{ propiedad: valor;}

selector{ propiedad: valor;}

}.css

CSS es fácil, verdad?

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 especificidad• Alta dependencia HTML

• Alta especificidad• Alta dependencia HTML• Golpea performance

• Alta especificidad• Alta dependencia HTML• Golpea performance• Difícil de reutilizar

:(

• Alta especificidad• Alta dependencia HTML• Golpea performance• Difícil de reutilizar

:(

Escribir CSS es sencillo.La arquitectura no.

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

• Performance

• Performance• Reusable

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

• Performance• Reusable• Hace lo que debería?• Mantenible y escalable

• Performance• Reusable• Hace lo que debería?• Mantenible y escalable

• Performance• Reusable• Hace lo que debería?• Mantenible y escalable

:)

2Procesos & herramientas

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

Cambio & complejidad.

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.

.scss

.scss

Sass

->

.css.scss

Sass

-> ->

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

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

foo { ...}

foo zaa { ...}

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-contentimg { ...}

:(

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

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

stylesheets[all][] = css/reset.cssstylesheets[all][]=css/drupal-stuff.cssstylesheets[all][] = css/base.cssstylesheets[all][] = css/layout.cssstylesheets[all][] = css/typo.css

; FODstylesheets[all][] = css/ds_2col.cssstylesheets[all][] = css/search.cssstylesheets[all][] = css/system.menus.css

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

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

Magic en lugar FOADhttps://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

sass/|--screen.scss#PrimarySassfile|-- partials/ # Partials| |-- _base.scss| |-- _variables.scss | |-- _mixins.scss | |-- vendors/ | | |---- _drupal.scss|||----_jqueryandstuff.scss| | |---- ...| |-- patterns/| | |---- _buttons.scss| | |---- _links.scss| | |---- ...| |-- components/| | |---- _paginator.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.

Objetos son reutilizables.

.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 {}

ul.product-list li {}

.product-list li {}

.product-list .product-item {}

.product-item {}

<ul> <li class=”product-item”>Product 1</li> <li class=”product-item”>Product 2</li> <li class=”product-item”>Product 3</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.

Mo’ Devs, Mo’ Problems

• Training

• Training• Buenas prácticas

Sintaxis, formato consistente, convenciones para nombres*, etc

v

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

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

* Naming conventions

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

v

.is-touch { ...}

.is-hidden { ...}

.is-selected { ...}

v

.tab { ...

&.is-selected { ... }}

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

v

.btn { ...}

Objeto

v

.items-list { ... .item-thumb { ... }}

Padre - Hijo

v

.product-list { ...}

.product-list-thumb { ...}

Padre - Hijo

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

v

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

v

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

v

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

class=”promo-box promo-box-dark”

Subclassing

v

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

class=”promo-box-dark”

Subclassing

v

.promo-box,

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

.promo-box-dark { background: black;}

v

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

.promo-box-dark { @extend .promo-box; background: black;}

...

.promo-wrap .promo-box { margin: 0;}

v

.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.

v

.btn,%btn { ...}

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

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

v

.btn,

.btn-positive,

.btn-negative { ...}

.btn-positive { ...}

.btn-negative { ...}

v

.ui-promo-item { ...}

class=”ui-promo-item js-promo-item qa-promo-item”

v

.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 recomendadahttp://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

/* Comentarios FTW */

/** * 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.

3Aterrizando

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.

Gracias!@leivajd

http://www.slideshare.net/leivajd

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