Antes que nada, el día anterior cometí un error importante con esta línea en app.js:
app.get('*', routes.error404);
La idea en sí es buena, el resultado... no. Además de todas las url no válidas esto impide que accedamos a todos los archivos del directorio público, así que hay que comentarla y ya se buscará una solución posteriormente.
¿Qué son los preprocesadores de CSS?¿Qué es Stylus?
Cualquiera de vosotros que haya visto un poco de programación y haya estado haciendo CSS se preguntará ¿Por qué no hay variables en CSS? Los preprocesadores CSS nos permiten trabajar con un código que permite usar variables, módulos, funciones, anidamiento y un sinfín más de ventajas que CSS no nos ofrece de base y luego convierten ese código a CSS.A fecha de hoy si eres un Front-End la pregunta que debes hacerte no es "¿Debería usar un preprocesador?" sino "¿Qué preprocesador debo usar?". Si todavía quieres vivir en la "Edad de Piedra del Front-End" es cosa tuya, pero estarás siendo poco productivo en comparación a las ventajas que tiene usar un preprocesador.
Aprender a usar un preprocesador es fácil (en menos de 1 día he aprendido a usar Stylus, otra cosa es el tiempo que tardaré en sacarle el máximo probecho), todo este tema se merece no uno sino varios post de momento voy a limitarme a dejaros la web de Stylus y una comparativa de SASS vs Stylus que ayudará a asentar algunos conceptos.
Instalación de Stylus
Una de las características de Stylus es que practicamente no necesita instalación. Usaremos npm install -g stylus y npm install -g nib. A diferencia de otros módulos que en cierta forma se relacionan entre sí, Stylus al ser un preprocesador de CSS es independiente sólo necesitamos el CSS por lo que no necesitamos instalarlo como un módulo adicional en nuestro proyecto.Una vez instalados de forma global, creamos una carpeta stylus donde guardaremos los archivos .styl y después usaremos el siguiente comando:
stylus -u nib -w style.styl -o ..\public\stylesheets
Los parámetros son:
-u nib: Con u indicamos que vamos a usar un plug-in y luego indicamos que sea nib
-w archivo.styl: El precompilador esté observando ese archivo y sus includes
-o directorio: Indicamos dónde queremos compile el resultado
-c : Comprime el css eliminando espacios, comentarios y demás. De momento no se va a usar
-C origen [destino]: Convierte un css a stylus
Lo dejamos corriendo y a partir de ahí si detecta algún cambio en el archivo vigilado o en alguno de sus includes lo vuelve a compilar automáticamente, así que podemos estar por un lado editando los .styl y por otro probando como se ve en el navegador sin esfuerzo adicional.
Empezando a maquetar
Lo primero a hacer es descargarme la última versión de normalize y convertirla a stylus, gracias a la modularidad podemos añadirlo con un include y estamos realizando 1 petición al servidor en lugar de 2 de archivos css.Lo primero a hacer es retocar los headers, cada página tiene un id similar, crearé un bloque en los que le doy los estilos comunes y luego a cada uno le doy un color distinto. El ancho será 100% (estamos empezando con el diseño móvil).
El nav,como ya se vio en el wireframing para la versión móvil usaré iconos. A la hora de buscar iconos he pasado un rato intentando buscar algunos, al final uso glifos con fuente desde css, he incluido font-awesome que es una especie de bootstrap (de hecho lo han hecho compatible con la versión 3 de Bootstrap) pudiendo agregar iconos directamente a través de clases.
En el futuro quiero buscar otra opción, ya que intuyo de que es un incremento importante en la carga sólo por los iconos. Al lado de los iconos he agregado el texto, sin embargo, lo he ocultado para la versión móvil y lo muestro a tamaños mayores usando media queries. También les aplico un color más oscuro cuando el ratón está encima (hover).
Finalmente agregué el footer con otro color distinto.
Media Queries
De momento son pocos los cambios, los iconos para la versión móvil quedan muy bien, pero cuando se aumenta el tamaño son "poca cosa" así que dejé los nombre y lo que hice fue ocultarlos, cuando llegue al primer breakpoint (660px) se muestran, pero el resto de página sigue igual.Al aumentar más aún la página se estiraba demasiado la información, eso no es nada recomendable salvo que esté la información dividida en subcolumnas porque dificulta la visibilidad. Así que usé la caja inicial, el wrapper para ajustar la información, esto lo hago con el segundo breakpoint a 960px.
Además de evitar que aumente el ancho de las zonas del texto, uso un fondo gris y la parte central la encierro en una zona más legible y con un ligero bordeado de las esquinas.
Hay bastantes osas que retocar y mejorar, pero ya se nota un "ligero" cambio de aplicarles estilos.
Si queréis echarle un vistazo "in situ" además del código en github he hecho un deploy con lo que tengo en http://shinfduran.jitsu.com/
Creando nuestro propio framework CSS
Si habéis echado un vistazo a github veréis que hay un montón de archivos. Si tenemos los imports, que nos permiten fragmentar el código en zonas facilitando la estructura y visibilidad ¿Por qué no usarlo? Total al final el resultado compilado será el mismo, pero posteriores cambios nos resultarán mucho más fáciles. El proceso inicial de crear la estructura conlleva un cierto tiempo, pero una vez terminado podemos reutilizarlo en futuros proyectos a modo de framework css.Estoy generando más código css de la cuenta, sin embargo, quiero que de primera vez esté bastante modularizado y las modificaciones en cualquier color me resulten fáciles de realizar así, que inicialmente va a primar la versatilidad sobre la eficiencia.
No hay mucho código, podría implementarlo directamente en un solo archivo sin dedicar tanto tiempo a estructuras y demás, cierto. También podría seguir usando sólo CSS y podría usar sólo páginas webs y subirlas sin usar Express.
Existen frameworks CSS que su principal virtud es justamente estar bien estructurados y modularizados (la estructura que estoy realizando está basada en buena parte por 320 and up), de forma que sean fácilmente portables de un proyecto a otro y nos ahorren MUCHO tiempo no sólo al hacer la maquetación inicial, sino en posteriores retoques, el código es mucho más claro y mantenible y eso a medio e incluso corto plazo nos puede suponer un ahorro enorme de tiempo.
No hay comentarios:
Publicar un comentario