Expresiones regulares para búsquedas avanzadas (minitutorial)

Las expresiones regulares son unas convenciones para las búsquedas de cadenas que van mucho más allá del uso de simples comodines *.
Se pueden usar en programas de edición, en javascript e incluso hay algo parecido en CSS.

En todos los programas serios  de edición de código hay un icono u opción para utilizar expresiones regulares en las búsquedas.  Para ello se utilizan una serie de caracteres que tienen un significado especial para acotar los resultados. Es un tema bastante complejo, a poco que refinas una búsqueda te encuentras con un chorro de caracteres que suena a klingon, pero con estos tips espero que sirvan para introduciros en el tema o sacaros de algun apuro.

El . significa cualquier carácter 
Por ejemplo, tod.s nos encontraría todos, todas, y hasta los alternativos todxs y tod@s.

[a-z] : se usa para definir un rango de caracteres.
Por ejemplo, haciendo una busqueda con thumb_[0-2][0-9] Nos va a encontrar todos los textos que tengan thumb_ y luego dos dígitos en el rango indicado, como thumb_26 , thumb_00,  thumb_16 dejando fuera terminos como  thumb_38,  thumb_a5  etc.

+ significa que coincide una o más veces con el elemento anterior.
Por ejemplo la búsqueda anterior nos devolveria todos los ” thumb_” y dos dígitos OJO y SOLO DOS DIGITOS, no nos devolveria  thumb_4 porque tiene solo uno, ni thumb_124,  pero si lo hacemos con thumb_[0-9]+ nos encontraría thumb_1 , thumb_24,  thumb_235,  thumb_283745 etc.

| sirve para separar cadenas opcionales.
Por ejemplo, si queremos buscar todos los sitios donde aparezca la cadena configuración pero hay faltas de ortografía  podríamos usar configuraci(o|ó)n  y nos devolverá tanto las búsquedas que tengan acento como las que no.

 
(?) sirve para añadir opciones a la busqueda.
Por ejemplo, si queremos que en la búsqueda nos encuentre tanto mayusculas como minúsculas añadiremos (?i) de forma que (?i) bot(o|ó)n nos encontraría Boton, botÓn, botóN, etc.

\ significa escape, o sea, “no interpretes el carácter siguiente como un comando”
Pongamos que estamos buscando el carácter +, como hemos visto que + significa una o más veces, ponemos la barra invertida delante para que sepa que buscamos el carácter y no lo interprete , o si buscamos las aperturas de paréntesis haríamos \( 

\s representa un espacio en blanco y * significa cero o mas veces el elemento anterior
Pongamos que queremos buscar las propiedades de la  pseudoclase header, pero solo cuando sea un nombre de clase, no un tag, no queremos que nos encuentre <header> en el html, sino las clases header{ que están puestas inline , tendríamos que hacer header{  pero no sabemos si los css están correctamente formateados, a veces está como header{ o header { , luego haremos la búsqueda como header\s*{ y al buscar cero o más espacios entre el nombre y la llave nos los encontrará todos. Aun podría pasar por alto resultados, cuando la definición de header estuviera agrupada con otros nombres de clases de forma parecida a .container, header, footer { 

Ademas para rizar el tirabuzón, vamos a buscar todos los sitios donde header tenga la propiedad display:none para lo que nos hará falta usar unos caracteres de control más
\n \r son retorno de carro y retorno de linea y (?!loquesea) se utiliza para excluir
Para empezar, añadiremos los retornos de carro y de linea entre header y display:none, y los espacios opcionales  para esquivar el mal formateado
header(.|\r\n|\r|\n)*display\s:\snone
o sea,header más los caracteres, los retornos y saltos de linea que haya más display:none
El problema es que nos podría devolver esto porque se limita a encontrar un display:none que aparezca después de un txtprecio: sin importar lo que tengan en medio.

header{ display:block}

 .logo{display:none}  
Para evitarlo, le decimos que no nos devuelva los resultados si en medio no hay un } que cierre la clase.
txtprecio((?!}).|\r\n|\r|\n)*display\s:\snone

Esto nos encontraría todos los casos de los que hablábamos antes, incluyendo cuando header se encuentra en una lista de clases compartiendo propiedades.

Todo esto apenas es la punta del iceberg, hay muchos mas carácteres de control, para ampliar la información podéis empezar por:

Y algunos sitios donde poder probar los regex de forma que pegais un texto y al escribir una regex os iluminará las coincidencias para experimentar  interactivamente.

Mi forma de trabajar maquetando HTML/CSS

La que expongo es mi forma de trabajar a la que he llegado de forma personal después de muchos años editando html/css. Es la que me gusta y no puedo afirmar que sea la mejor, es la mejor para las características de mi trabajo y posiblemente en otras circunstancias no sea adecuada o no sea posible seguir. Por ejemplo si usas mi odiado Bootstrap, directamente puedes pasar de leer lo siguiente porque su filosofía es totalmente opuesta, y para cambiar el diseño exige editar el contenido y modificar la estructura del HTML, sin tocar el .css y yo soy partidario de lo contrario.

Una de las premisas en que me baso es que el código, tanto HTML como CSS sea lo mas corto y sencillo posible y una forma de conseguir ambas cosas es aprovechar las convenciones web en las etiquetas, con lo que ademas el código es más fácil de leer y “universal”. Otra de las premisas es que “todo” lo referente a diseño debe estar en el .css, utilizamos la cantidad mínima de clases necesarias para poder acceder a cualquier elemento sin tener que añadir código extra.

De esta forma, un titular no sera un div con una clase especifica sino que siempre será un <h1>, un subtitular un <h2>,  las cabeceras estarán en un <header> y el pie de página no sera un div con la clase .footer sino un <footer>
Utilizaremos toda la gama de etiquetas indicadoras de la función de elementos que tenemos en HTML5, las etiquetas semanticas  main, article, section, nav, etc.

Para definir las características concretas de cada elemento según el lugar donde esté, aprovecharemos al máximo la herencia de propiedades y las medidas relativas en em´s en vez de absolutas en pixels.

De esta forma, un titular <h1> tendria una font-size de 2em, pero si está dentro de un articulo en vez de en portada, su tamaño seria disminuido con un 0.6 em, por ejemplo. Nunca utilizaremos dos clases distintas tipo .titular_home y .titular_articulo.

Si tuviéramos que cambiar una propiedad de un titular, no lo haríamos añadiendo/modificando una clase en el propio h1, sino que lo haríamos usando la jerarquía del DOM, teniendo en cuenta donde está, por ejemplo:
.featured article h1{

Esto también nos facilita modificar todos los tamaños de la web de golpe cambiando el font-size del body, bien por asuntos de accesibilidad o en función del responsive.

Evitaremos en lo posible utilizar tags para funciones de diseño, en un mundo ideal, las etiquetas (y los nombres de clases)  solo deberían indicarnos la función de los elementos, y deberíamos poder cambiar totalmente el aspecto de una web solo modificando su .css.

No deberíamos (en lo posible) utilizar divs vacíos para cosas como distribuciones o espaciados, hoy en día tenemos muchísimas herramientas, como flex, para evitarlo.

Si tenemos que poner elementos que sean de diseño, aunque “aparenten” ser contenido, como las viñetas de los <li>, iconos e imagenes de adorno utilizaremos :before y :after.
Huimos de cosas como las colecciones de fuentes en .css tipo fontawesome que exigen introducir tags vacíos para insertar un icono, siempre podemos importar la fuente con un font-face y colocar el carácter donde sea necesario con un :before sin necesidad de añadir otra hoja de estilos que no aprovecharemos al 100% y de meter código innecesario en el HTML.

Si la imagen es pequeña, incluso podemos incluirla directamente en el .css convirtiéndola a base64 optimizando la velocidad de carga (si la imagen es grande, aunque sigue siendo posible, ya no es “rentable”en Kb.)

[continuara…]

Ventajas de usar SASS aunque no sepas SASS

Pongamos que por algún motivo no quieres o no puedes  aprender SCSS (o LESS, o SASS, etc. son basicámente lo mismo). No vas a utilizar anidaciones, mixins, variables ni ninguna otra de las ventajas que ofrece y quieres seguir trabajando con CSS “plano”.
Aun así, tendrías que considerar usar SASS en tu flujo de trabajo por las siguientes razones:

Trabajarías exactamente igual

Los archivos .css son archivos validos para SCSS. No tendrías que aprender ninguna sintaxis nueva y puedes seguir usando los archivos que ya utilizas.

Mejorarías  mucho la carga con archivos css modulares

Pongamos que cargas en tu web el ubicuo Bootstrap, el archivo .css de tu pagina y dos o tres .css externos, ademas de los @import con las fuentes que utilices de Google Fonts. Todos esos archivos hay que cargarlos por separado antes del render de la pagina y ralentizan mucho la fase más importante de la carga de una web. Si los incluyes como @imports de SASS en una hoja .scss y luego compilas, tendrás un único archivo .css (y una única llamada al servidor con todo lo que necesitas.

Te olvidas de los fallbacks

Si compilas con GULP en vez de con el propio SASS, ademas de compilar mucho más rápido,  puedes incluir el plugin autoprefixer que añade los -webkit-,  -moz-,  -msfilter- etc. necesarios para visualizarse correctamente en todos los navegadores que le configures. Escribes el código de una forma mas rápida y limpia y te olvidas de tener que andar consultando caniuse.com e incluyendo manualmente los prefijos, que es un coñazo. Utiliza los dotas del propio caniuse.com y puedes incluso configurarlo cronológicamente. Yo lo configuro para todos los navegadores de los últimos 7 años.

Avisa de los errores.

Trabajando con .css puedes olvidar un punto y coma, o equivocarte en la ortografía, y no te darás cuenta hasta que visites la parte de la web afectada, SASS  no te permite compilar un archivo si contiene errores, avisándote de su localización.

En fin, no necesitas aprender SASS/SCSS para empezar a utilizarlo y aprovechar muchas de sus ventajas. Luego empezaras a utilizar variables, anidaciones, etc. y te preguntaras como podías trabajar antes sin el.

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)

Usando GULP

Estoy usando GULP como gestor de tareas y es una maravilla. Es como tener un becario (que dios y los becarios me perdonen…) para encargarle tareas repetitivas.

Antes usaba SASS para compilar archivos .scss, pero los hace uno a uno, y cuando tenia que compilar un modulo que empleaban 30 o 40 archivos .css se hacia lento esperar a que acabara. GULP carga todos los archivos en memoria antes de trabajar con ellos y es mucho mas rápido. Además, me permite utilizar plugins como autoprefixer, que añade los prefijos para asegurar compatibilidad con los navegadores que le configures, incluso cronológicamente, yo lo tengo configurado para que me ponga los prefijos necesarios hasta 7 años de antigüedad. Así puedo escribir código mucho más rápido sin tenerme que preocupar de los moz- y los webkit-

Tambien lo uso para concatenar y minificar los .js, de esta forma acabo generando un único .css y un único .js para toda la pagina web y carga como un tiro.

Al ser la sintaxis de sass como la de .css puedo introducir en la compilacion css ajenos , como los de los reproductores de video, ahorrandome archivos y llamadas al servidor.

También sirve muy bien para realizar tareas repetitivas que no pueden ser conseguidas con un simple batch. Tuve un caso similar al siguiente en el trabajo, localizar una serie de archivos html que hacían referencia a una imagen map.png que no estaba en su carpeta /img, generando un error 404.

Podría haber localizado los .html con un buscador por contenido, pero luego habría tenido que mirar carpeta por carpeta si el map.png se hallaba ahí, hablamos de unos 400 archivos html de los cuales la mitad podían estar en esa situación.

Os pongo el codigo utilizado en el script GULP que utilicé para localizarlos, con una explicación paso a paso de lo que hace:

 var gulp = require('gulp');  //carga gulp
 var contains = require('gulp-contains');  //carga plugin para buscar textos
 var fs = require('fs');  //carga plugin para buscar archivos
 var counter = 0;  //variable contador de archivos
 gulp.task('busca', function() {  //abre proceso 'busca'     
 gulp.src('es/**/trivia.txt')    //carga archivos sobre los que trabajar, todos  los html de todas las subcarpetas en la carpeta /es
 .pipe(contains({   //añade plugin contains
     search: 'map.png', //busca esta cadena
     onFound: function(string, file, cb) { //cuando la encuentre....
     try {
         fs.accessSync(file.path.slice(0, -10) + "img/map.png"); //...a partir del path del archivo, busca el archivo map.png
     } catch (e) { //si no lo encuentra...  
         counter ++;//actualiza el contador...
         console.log(counter +":"+ file.path.slice(0, -9)); //...y muestra la ruta  en la consola ("restando" map.png)
         return false }  //cierro  fs.accessSync                 
     return false;} //cierro search           
     }))    //cierro  contains
    .pipe(gulp.dest(function(file) {return file.base;})) });  //path de destino de los archivos *
gulp.task('default', ['check']);  //arranca al hacer gulp en el terminal

* en este caso, no seria necesario porque no realizo ningún proceso con los archivos, pero GULP lo necesita para funcionar correctamente, sino, detiene la búsqueda en los 16 primeros.

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-size: 25px}
 }

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

Algunas utilidades online que uso a diario

O sino a diario, casi.

www.caniuse.com
La que más utilizo. La uso para consultar el estado de soporte de propiedades css y usarlas o no según el target. Te indica el nivel de soporte de los navegadores, cuando es necesario utilizar prefijos y, si ordenas por fecha, desde cuando están soportadas. De esta forma, si una propiedad no es universal desde hace al menos 4 años (es difícil que un móvil aguante tanto) no la uso.
Si el target es un público más especializado, o de alto nivel, se puede ser más flexible. Ojo con Opera móvil, no acepta nada.

https://autoprefixer.github.io
Esta es la siguiente estación despues de pasar por la anterior. Puedes poner tus definiciones css y automaticamente les añade los prefijos webkit y moz necesarios. Porque no siempre es tan fácil como añadir -moz- a las propiedades, muchas veces tienen cambios de sintaxis específicos y con un copipaste del código te aseguras que se vea bien en el maximo de navegadores posible.

https://userstyles.org
Esta no es una pagina, sino una extensión para el navegador. Permite añadir una hoja de estilos personalizada que se superpone a la del dominio a la que la asignes. Puedes “corregir” el estilo de una pagina de forma que cada vez que entres se le aplicará, o probar una corrección de css sobre una página antes de introducirla en su .css

http://waifu2x.udp.jp
Esta no la uso practicamente, pero no deja de ser muy interesante tenerla a mano. Hay veces que no necesitamos una imagen, un logo habitualmente, en un tamaño más grande pero no disponemos de los archivos fuente. Esta página utiliza no se que algoritmos para doblar el tamaño minimizando el pixelado y los resultados son muchas veces sorprendentemente buenos y perfectamente utilizables.

https://codepen.io/pen/
Para probar código en tiempo real y de forma muy rápida, tres ventanas donde incluir html, css y js y una ventana de resultados donde comprobar las cosas al momento y de forma muy rápida.

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