Porque no me gusta BootStrap

En mi actual puesto de trabajo se utilizaba BS por doquier, y progresivamente lo vamos retirando y ahora las paginas son más  sencillas  y fáciles de mantener al estar basadas las plantillas y soluciones propias, solo con el código que necesitamos y NO MÁS de lo que necesitamos,  el código extra, aunque “no haga nada”, siempre molesta y obliga a mantenimiento de una forma u otra.

Entiendo que BS tiene su uso adecuado (al principio el propio BS recomendaba no usarlo en producción, solo para prototipar), pero se ha universalizado y se usa en sitios donde causa más problemas que ventajas.
En mi opinión BS tiene su utilidad para gente que no sabe CSS, te ofrece un sistema sencillo de utilizar donde no te tienes que pelear con los paddings, plantear un grid, etc. Sigues sus normas y te aseguras un resultado aceptable y consistente, pero si eres mínimamente competente con CSS, no hay motivo para usar BS por los siguientes problemas (en mi opinión, ojo). Vaya por delante que hablo de la versión 3 de BootStrap, que es la que conozco y la que se usa mayoritariamente.

Bootstrap liga contenidos y presentación.

Aunque últimamente esta en discusión, o simplemente desechada, me sigue gustando el viejo paradigma de no ligar el marcado HTML a un diseño determinado, el “enfoque Css Garden”.
En el código html solo debería haber referencias a la función de los contenidos, no a su presentación, eso es tarea del CSS.  En el html un titular deberia bastar con poco mas que un <h1> y alguna clase que nos informe de su función en un momento dado, como si titular de un destacado, del cuerpo de una noticia, etc., no deberiamos añadirle clases para indicar si es de un determinado color, o se alinea a un lado u otro. BS nos devuelve a los tiempos en que se usaba <center> para centrar un contenido o <font> para indicar el color de un texto. Con BS, si trabajas de la forma correcta,  tienes que editar el html para cambiar la presentación, lo que, en ámbitos empresariales por ejemplo,  a veces implica la intervención extra de un programador, aprobación por parte de terceros del cambio de contenidos, etc. complicando una labor que debería ser sencilla y trivial.

Bootstrap es poco eficiente.

Las soluciones de amplio espectro nunca son eficientes, como una navaja suiza, son validas para situaciones de emergencia (prototipos)  pero no para resolver un problema real (producción). Con bootstrap arrastras cientos de clases que no vas a utilizar nunca y que añaden Kb a la fase mas importante de la carga de la pagina, html, js y css. Te puedes beneficiar del CDN, pero difícilmente no necesitaras ningún cambio ni clase extra. Casi “obligatoriamente” tendrás que usar una versión propia de BS o añadir una nueva hoja de estilos, con lo que esta ventaja se pierde

El responsive funciona a saltos fijos y está anticuado.

Se ha quedado muy anticuado en este aspecto, y el responsive está pensado en unos saltos de ancho que pueden convenirte o no según tu target. Quizá quieras más atención a los formatos móvil y para tu público apenas sean importantes las pantallas de escritorio y quisieras refinarlo mas en esos tramos. Por ejemplo bootstrap trata igual a todas las pantallas por debajo de 480px y a veces conviene afinar mas en segun que targets.
Ademas las medidas son en pixels, y apenas se utilizan soluciones “fluidas”, propiedades como flex ni siquera están incorporadas, etc.
Entiendo que algunas de estas cosas se pueden corregir pero…

Es DIFÍCIL de modificar.

Como pasa muchas veces con los css producidos con preprocesadores como less, sass, etc. las clases en BS están hiperdefinidas. Las herencias son enrevesadas y si modificas directamente una clase, nunca puedes estar muy seguro de que repercusiones puede tener en otras partes de la web o con otras combinaciones de clases. No esta pensado para realizar modificaciones directamente en el css, o machacando propiedades con un css posterior, sino editando su archivo less, pero me extrañaria que uses bootstrap si usas preprocesadores css a no ser que estes en una situación muy especifica.

Bootstrap es un desarrollo ajeno.

Con todo lo que ello conlleva, puede ser positivo o negativo. Puede ser positivo porque te beneficias de las actualizaciones y soporte de un sistema estandarizado. O negativo cuando anuncian la versión 4 y no es compatible con la anterior. Y todo el aprendizaje que requiere BS, que no es difícil pero si necesario, ya no sirve para nada. Si quieres actualizar tus webs a los “nuevos tiempos” tendrás que rehacer el código por completo. Es mejor dedicar ese aprendizaje y ese tiempo en un sistema propio adaptado a tus necesidades que puedas ir actualizando rutinariamente.

Complica el código

En BS para utilizar una columna tienes que meterla dentro de un div con la clase .row para que se anulen mutuamente sus paddings positivos/negativos. Ese div.row no existe para indicar una categorización del contenido, ni tiene otra función que corregir un problema de diseño (el centrado visual correcto de las columnas). Usando BS te obligas a introducir código html extra para resolver tareas de diseño, y una ristra de clases para cada etiqueta que tampoco tiene sentido (fuera de la obligación de usar una solución de amplio espectro)

El maravilloso em como unidad de medida (y parte 2)

Lo bueno del em es que podemos usarlo como unidad de medida casi en cualquier propiedad css. Pongamos que tenemos la típica lista de thumbs que van a  contener miniaturas de diversas fotos de las que no conocemos sus dimensiones. Lo más fácil seria seria darles a todas las imágenes un ancho del 100%,  damos un ancho del <li> en porcentaje y dejar que el alto del <li> se ajustara solo al escalarse la imagen, pero como cada imagen tendrá una relación ancho/alto distinta, nos formara escalones que descuadran la retícula. ¿como podemos poner un alto “fijo” relativo al ancho?

(El tema de encajar la imagen lo resolveríamos poniéndola como position:absolute ( y overflow hidden al <li>), o como a mi me gusta, usandola de background del <li>y tirando de background-size:cover)

No podemos usar altos en porcentaje, porque son muy problemáticos, y exigen que esté definidos todos los altos de todos los padres donde se localice hasta llegar en la jerarquia del DOM a HTML. Los anchos en porcentaje funcionan, los altos no.

Podríamos usar el ancho de ventana (vw) como referencia (li{ height:20vw}, por ejemplo), con limitadores media query por arriba y por abajo, pero vw exige ser limitada cada vez que se utilice para evitar los problemas que comentaba en la primera parte. 

Podriamos usar una imagen “dumb”, un gif transparente vacio con las proporciones que queramos, pero es una solucion un poco sucia, y con ello solo podemos escalar el alto del <li> (o <div> o lo que sea) que la contenga.

Recordemos que em es una referencia (ojo, acumulable y relativa, como comento al final del articulo anterior) al tamaño del texto definido en el <body>, y como lo hemos definido tal que así:

body {
 font-size: 3.2vw;
 line-height:1.2;
 }

@media (max-width: 360px) {
 body {font-size:10px}
 }

@media (min-width: 800px){
 body {font-size25px}
 }

Estamos definiendo que em valga:
• 10px hasta 360px de ancho de ventana.
• El 0.032% del ancho de ventana hasta 800px de ancho de ventana (con una ventana de 480px, em valdria 15.36px).
• 25px en adelante.

Inciso: No necesariamente el tamaño que definamos en el body tiene que usarse para los textos, yo habitualmente uso una definición de <p> independiente del tamaño de fuente definido en el body y uso este ultimo lo utilizo para los titulares y las dimensiones gráficas (margenes, relaciones alto/ancho, etc). Y me facilita mucho las cosas poder tener una referencia única que usar en el máximo numero de situaciones posible.

Volvamos al principio, recordemos que esto era para solucionar el alto de los <li>, una vez definido lo anterior, podemos  ajustar el alto de los<li>s asi:

li{ width: 20em; height: 1.5em}

Y tendremos una web que escala los contenidos correctamente sin más complicación.

Lo suyo seria poner el media query limitador “por arriba” en la misma medida que el max-width del contenedor padre que tenga la web o del <ul> que tenga los thumbs.

Esta forma de trabajar no es la panacea, y tiene sus propios inconvenientes, pero es otra herramienta más que tenemos a nuestra disposición para resolver problemas que nos puedan surgir.

Y en fin, solo recordar que con CSS siempre hay mil formas de hacer las cosas y elegir una u otra solo depende del caso concreto, del target de la web o al final, del gusto personal.

Tengo pendiente preparar un codepen o algo por estilo para que todo esto se vea mucho mas claro hasta entonces, podéis consultar cualquier duda en los comentarios, que para eso están ;).

El maravilloso “em” como unidad de medida (parte 1)

Antes usaba pixels como unidad de medida para las fuentes. Llegó el responsive y hacia como muchos, usaba saltos media query para ir cambiando el tamaño conforme lo hacia el tamaño de pantalla… (perdón, mejor “ventana” en vez de pantalla porque habitualmente no podemos disponer de todo el tamaño de pantalla por las áreas de interfaz y otras cuestiones)

Esto tenia varios problemas, uno de ellos la inconsistencia entre el tamaño de la ventana y la fuente. En determinados tamaños de pantalla (y ahora hay cientos) un titular se salia del marco, o aparecia un salto de linea que desmaquetaba la pagina y afeaba el conjunto.

Descubrí “vw” (ViewportWidth) como unidad de medida. Perfecto, con h1{ font-size:2vw} Hacias que el tamaño de la fuente fuera el 2% del ancho de pantalla. Ahora si, escalabas la ventana y la fuente escalaba en la misma proporción, se acabaron los saltos de linea ocultos. Los textos se ampliaban como si fuera fotosop.

Problema: Al estar ligados al tamaño de la ventana cuando la pagina habia terminado de escalar (el tipico .container{max-width:…) el texto seguia aumentando. Además, a partir de determinado tamaño, la fuente adquiria proporciones horribles.

Solución : Limitar con media querys tanto el mínimo como el máximo del tamaño. Por debajo de 479 el mínimo legible, por arriba del ancho total de la página el máximo estético o funcional. Pero surge un nuevo…

Problema: Es un coñazo tener que añadir media querys a todos y cada uno de los tamaños de texto, h1, h2, h3, p, etc.

Solución: Aquí acude en nuestra ayuda el viejo “em”. El em es una referencia relativa al tamaño de fuente heredado. Toma como valor el inmediatamente definido  anterior. De esta forma, si definimos en el body un font size de 14px y al h1 le aplicamos un 2em, h1 valdrá 28px. Si metemos el h1 en un div que tenga como font size 1.5em, el h1 tendrá 42px de tamaño (14px * 1.5 * 2). Si el div tiene un tamaño en pixels, el em se calculara en base a ese tamaño, no el del body.

Ya tenemos todas las herramientas que necesitamos.

Aplicamos al body un font-size basado en vw limitado por arriba y por abajo con media querys. Pongamos 1.7em, 12px por debajo de 479px y 18px por encima de 1024px. Si calculamos el tamaño en el momento de corte del media query (1024/100*1.7= 18px aprox.) el cambio de em’s a pixels sera continuo y quedara mas fino.

El resto de fuentes las definimos con sus proporciones en em’s y solo nos ha hecho falta dos media querys para definir los tamaños de todas las fuentes de la web, y se escalaran de forma continua con el ancho de la ventana. Además todos los tamaños de fuente estarán referenciados a un único valor, el del body,esto hace muy fácil aumentar o disminuir todas las fuentes a petición del usuario, según dispositivo, etc.

Esto de tener un valor relativo a un ancho limitado de pantalla nos da juego para más cosas que contare en el próximo capítulo.Hay que tener siempre en cuenta el efecto acumulativo de los em’s. Todos los textos que metamos en un div con font-size:0.5em tendrán la mitad de tamaño. Podemos usar la variante “rem”, está un pelin menos soportada, y hace referencia “directa” al tamaño definido en el body (RootEm) independientemente de los tamaños intermedios.

Esto de tener un valor relativo a un ancho limitado de pantalla nos da juego para más cosas que contare en un próximo articulo.

Algunas utilidades poco conocidas del inspector

El inspector es una verdadera maravilla, no sé como podíamos trabajar antes sin el. Os muestro algunos tips y funciones que no son demasiado evidentes y que facilitan el día a día. Casi todos los navegadores tienen su inspector, Firefox, Opera y la versión developer de Safari. Me baso en el inspector de Chrome (en ingles) , a otros les gusta más el de Firefox, es mas una cuestión de gusto y sentirse cómodo con uno u otro más que otra cosa, las diferencias son pequeñas.

Cambiar valores con los cursores.

valores

Cuando seleccionamos un Campo numérico (incluido uno hexadecimal) podemos cambiar los valores de 1 en 1 con las teclas de cursor vertical, de 10 en 10 con control + flechas  y a intervalos de 0.1 pulsando alt+ flechas.

Editor de curvas de animación.

curvasç

Cuando aplicamos una transición, pulsando en el icono de easing accedemos a un editor de curvas para cambiar los valores de suavizado de la animación. Tenemos incluso una animación que nos permite previsualizar el efecto.

Editar .css desde el propio navegador.

work

Podemos editar estilos directamente desde la ventana de sources o elements., siempre y cuando los archivos sean accesibles en local. Para conseguirlo, en settings > work spaces podemos añadir directorios con “permiso” para escribir archivos.

A partir de entonces un icono nos avisara de los archivos modificados sin guardar y haciendo control +s podemos guardar los cambios.

Mover elementos del DOM.

mover

Ademas de editar elementos (doble click sobre ellos) y borrarlos una vez seleccionados en la ventana de elements, pulsando y arrastrando elementos podemos moverlos, para anidarlos y desanidarlos para localizar errores en  la maquetación.

Formatear código minificado

formatearcodigo
Cuando en la ventana de sources nos aparece el código minificado (por ejemplo al pulsar sobre el nombre de un fichero en la propia ventana del inspector, como un .css o un .js) , podemos formatearlo para facilitar su interpretación pulsando las dos llaves de la esquina inferior izquierda

Elegir hoja de estilo al añadir clases

css

Al pulsar el simbolo “+” podemos añadir una clase  al elemento seleccionado, por defecto se añade como un <style> en el propio documento, con lo que se priorizara sobre las hojas de estilo. Pero podemos elegir añadirlo a alguna de la hojas de estilo de la pagina web manteniendo pulsado el icono y seleccionando del desplegable que nos aparece.

Menú desplegable sin JS

Cada vez más aprecio las webs ligeras, especialmente cuando me quedo sin datos en el móvil o estoy en un sitio con mala conexión. Hace poco no pude leer un articulo porque el “leer más” iba por javascript y no llegaba a arrancar a pesar de que el contenido ya estaba cargado, seguia cargando .js y cosas que bloqueaban el arranque de JS (que no ocurre, en principio, hasta haber cargado todos los contenidos de la pagina).

Puede ser muy frustrante que un visitante no pueda desplegar un menú para llegar a la sección que le interesa porque la pagina está bloqueada cargando cosas que no necesita (y no vamos a entrar en las estadísticas discutibles de Google sobre los 3 segundos que puede aguantar un navegante esperando una carga)
Para evitarlo, esta es una forma de crear interacción que funciona desde el momento en que se renderiza la pagina, sin tener que esperar la carga de jquerys y demas y quedarse bloqueada la funcionalidad.

Se basa en el los selectores  “~” que significa “aquellos elementos que comparten padre” (ojo, DESPUES del elemento referenciado) , y en “input:checked” .

El tema es colocar un <input> con opacity:0 para que no se vea, y colocado de forma absoluta dentro del elemento de menu con medidas al 100% para habilitar el pulsado de todo el botón. A partir de ahí, podemos aplicarle propiedades a sus “hermanos”  así:

input ~ div: (sin pulsar, plegado)
input:cheked ~ div : pulsado(desplegado).

Combinado con transition se hacen animaciones suaves para el desplegado.

Esto tiene un problema, y es que si hay varios items de menú desplegables, no podemos hacer mediante css que al pulsar  uno se plieguen los demás. He intentado hacerlo con elementos radio button, que solo permiten seleccionar uno de entre varios, pero hasta el momento no lo he conseguido.
Para resolverlo si que debemos usar una pequeño JS que deseleccione los demás items al pulsar uno de ellos, lo mas cómodo es usar .siblings() de Jquery en una función que deseleccione los demás inputs al seleccionar uno.

Si, acabamos usando JS, pero al menos ya se puede desplegar el menú sin esperas innecesarias desde el primer render de la pagina.

Aquí teneis un codepen sencillo explicando el concepto, en este caso se ha cambiado la opacidad del menu, pero se podria haber cambiado cualquier otra propiedad del <ul> o de los <li>s

Mejor no useis el @import de Google fonts

Cuando queremos usar una fuente de google fonts se nos proporciona un código para incorporar al .css o mediante una etiqueta <style> , por ejemplo:
@import url(‘https://fonts.googleapis.com/css?family=Roboto‘);

Esto tiene tres problemas.

* Con el import lo que haces es cargar un archivo .css externo. Es poco peso, pero no deja de ser un archivo mas, otra llamada al servidor, etc.

* Meter un css dentro de otro ralentiza el render de la pagina, al cargarlos de forma secuencial y tener que esperar a estar todos cargados para empezar con el render de la pagina.

* Carga a veces fuentes innecesarias.

El codigo anterior por ejemplo, si abrimos directamente la url en el navegador podremos ver que carga versiones de la fuente en cirilico, vietnamita, griego, etc. hasta 7 versiones distintas.

Se supone que estas fuentes especificas por idioma solo se cargan cuando son utilizados caracteres del idioma en cuestion, pero si tu web no la tienes traducida a esos idiomas es innecesario meter todo ese codigo.

Es mas sensato copiar solo los font-face del codigo de google que vayamos a utilizar, usualmente, algo así:

/* latin */
@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  src: local('Roboto'), local('Roboto-Regular'), url(https://fonts.gstatic.com/s/roboto/v16/CWB0XYA8bzo0kSThX0UTuA.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2212, U+2215;
}

.