 Continuamos ahora con Andrés Ferojosa, que nos va a hacer la siguiente ponencia. Bienvenida a la workaham, Zaragoza 2023. Un gran aplauso y todos atentos a lo que nos tengas que contar. Bueno, primero, gracias a todos por asistir. Me entiendo que había otras bastante técnicas y venir a una que... Bueno, vamos a ver cosas que teóricamente se nos enseña en el trabajo o puede ser que no. Y otras técnicas que espero que os abran también la mente, ¿no? A estructurar mejor el contenido. Antes de nada, me gustaría hacer una pequeña regañina, porque siempre que empezamos a trabajar con HTML, solemos hacer mal los metas, lo que va dentro del GAD. Y hay unos problemas que son recurrentes y siempre me los encuentro. Tanto con equipos externos como internos o alumnos cuando están iniciándose. El primero es que cuando creamos una plantilla HTML, solemos empezar con estos tres metas. ¿No? Donde tenemos el charset que indicamos los acentos, la codificación, cuál va a ser. Y esto está genial, aunque es verdad que muchos navegadores, de forma determinada, ya lo hacen por nosotros, tendremos el title para el tema de la pestaña, para el tema de los marcadores y tenemos el viewport donde, sin mirar, solemos añadir o se auto genera este contenido. Y esto está bien, es pasable. No obstante, vamos a entrar a hacer más accesible en nuestras páginas, solamente eliminando dos partes, que sería el escalado máximo y la posibilidad que el usuario no pueda hacer el pellisco. Pues mi primer consejo es este, que lo quitéis y hagáis más accesible que puedan los usuarios que tienen deficientes visuales o no comprendan qué está pasando ahí por temas de color, eso lo que sea, puedan redimensionar, puedan mejorar. Y también cuando añadimos un icono, un fabicon o un fabicon, depende de cómo pronunciemos, solemos dejar únicamente la parte de arriba, lo más fácil, muchas veces se añade el punto ICO, iros al PNG, webpict, hay más posibilidades, más fácil de trabajar y si puede ser, también añadir todos los links que van a utilizar en Apple, en dispositivos, esto se utiliza sobre todo para el tema de marcadores. Entonces, un fabicon no es esto, sino es todo esto, por favor. Al menos si queremos que sea compatible con todos los navegadores, ¿vale? Tampoco es muy difícil porque cogemos la misma imagen y vamos remensionando, vamos preparando, e incluso si tenemos algún proxy o algo que nos remensione las imágenes, vaya, qué difícil lo está pasando. Estoy seguro de que esto lo puede hacer de forma automática. También otros metas que antes eran opcionales, yo hoy en día me parecen obligatorios, es el tema del color. ¿No se conocéis este, el demcolor, que lo que hace es modificar el color de la propia interfaz de lo que sería nuestro navegador? Pues podemos definir un color hexadecimal, además también podemos con los media queries, definir cómo se va a ver en una versión light, un tema claro, y además un tema oscuro. Os puedo poner un pequeño ejemplo donde podéis ver, esto se aprecia muy bien en el Chrome dentro de Android, donde yo tengo esta página web, esta es la interfaz determinada, pero si le pongo el demcolor con este azulito que tenemos aquí, cambia, no sólo esto, sino también la barrada arriba. Funciona también en iOS, aunque los colores están un poco más delimitados, sobre todo por el tema del contraste de colores, que no siempre coincide, pero bueno, no cuesta mucho y queda más integrado en nuestra página. También se nos olviden muchas veces de añadir los metas relacionados con las redes sociales. Vale, ya acabo enseguida la regañina. Cuando estamos intentando que nuestro contenido se pueda compartir, necesitamos simplificar cómo se va a mostrar, y eso se hace rápidamente con Open Graph, y con estas cuatro como mínimo podemos indicar qué imagen va a ser la previa para que no coja la primera imagen que encuentre en la propia página, cuál va a ser el título, qué tipo de contenido nosotros vamos a mostrar, y por último, pues un enlace alternativo, en el caso que hubiera problemas, uno quisiéramos que redireccionaran aquí. Y esto podemos verlo, un clásico ejemplo, yo estoy dentro de Facebook, comparto mi enlace, no se ve absolutamente nada, puede ser que coja pues lo primero, la primera imagen que vea, esto era muy típico con la página del mundo, me acuerdo que una vez compartí un enlace de un tema científico y aparecía la foto del rey, y ya está pasando aquí, y claro, no tenían esos metas, entonces parecía que había un artículo arriba que hacía referencia, y si nosotros lo especificamos, fijaros, tengo la imagen, tengo el título, tengo la descripción, joh, qué cambio, ¿no? Y no acaba aquí la cosa, sino que también podemos añadir unos metas específicos para Twitter, donde podemos indicar el texto que queremos que aparezca, la cuenta del sitio y la cuenta también del creador, ¿vale? o no cuesta. Si os ha gustado todo esto, te lides el primer QR, podéis escanearlo y tengo una plantilla con esto y mucho más. Lo quito, lo quito. Por ahí alguien dice algo que se está sacando, vale, saca el móvil, saca. Pues le voy a hacer una foto, muy bien. Luego esto está todo subido, lo aseguro. Vale, que me voy, que me voy. Muy bien, vamos a seguir jugando. Veamos este etiqueta, ¿habéis visto muchas veces que se añade este slas al final o esta barra invertida? La pregunta del millón es, ¿hay que ponerla o no hay que ponerla? ¿Quién opina que hay que ponerla? Que sí, ¿vale? ¿Quién opina que no hay que ponerla? Vale, en realidad se considera un elemento vacío y el AW3C, a pesar que no es muy claro, sí queda algunos ejemplos, donde te dicen que no es necesario ponerla, es opcional ya que es un carácter que se va a ignorar cuando se pasea todo el contenido. Por lo tanto, la podéis poner, no pasa absolutamente nada. Incluso, en ciertos lenguajes como BIU y otros más, que lo obligan a poner por la propia sintaxis, eso ya queda en manos de vosotros. Ahora sí, ahora empieza la charla. HTML, hablemos primero de cómo podemos formatear y preparar HTML para nuestro equipo y para nosotros mismos y luego veamos cómo trabajar con el CSS. Os voy a poner un ejemplo de un input. Yo tengo aquí mi ID con el correo, el nombre, el tipo de correo, el pleaseholder, el require y dos clases. Esto podría pasar cualquier control de calidad. Si nos pondrían en el sello, iría a producción. Y me parece estupendo, pero esto puede ser mejor. Podemos, por ejemplo, añadir unos saltos de línea cuando tengamos más de dos atributos, quedando una columna que es mucho más fácil de leer. Un poquito mejor. Y además, añadimos que el primer atributo también tenga un pequeño salto de línea. Como veis, tenemos aquí una tabulación o cuatro espacios. Esa no es la charla de qué es mejor, es decir, cuatro espacios de tabulación. Y añadimos que el cierre o el mayor que esté alineado con la apertura del menor que, quedando de esta forma. Y ya lo tendríamos mucho mejor. Por lectura, porque es más fácil editar, yo puedo mover estas líneas de arriba abajo, puedo rápidamente ver si estoy repitiendo alguna. ¿Y puede ser mejor esto? Sí, lo puede ser. Cuando tengamos más de dos valores en un atributo, también podemos repetir esta estrategia. Tengo la comilla aquí que cierra. Y yo creo que ya está, esto ya más no se puede. Bueno, sí, se puede. Un comentario. Podemos añadir una pequeña descripción de qué es. Podemos añadir los estados o las diferentes clases que no estamos habiendo aquí, pero que van a alterar el diseño o le va a dar funcionalidades o va a tener un data set o, perdón, un data que le va a poder dar ciertos atributos, ciertas propiedades, pues también lo podemos describir de esta manera. Y, bueno, y tengo este QR más ejemplos de otras formas que podemos formatear el HTML, ¿vale? Continuo. Entonces, pasamos de tener esta línea donde está todo apelmazado a tener algo que es más verboso, pero tiene más aire. Y desde mi punto de vista, es más fácil de pasar un compañero y que entienda qué está ocurriendo ahí. Algo nos podemos, si queréis, nos pegamos y fuera y defendemos si es mejor una cosa o la otra. Esto es una tabla. Está bien, ¿no? Table, tiene el TR, tiene el TH, donde tenemos el título, tenemos el resto del TD. Esto está perfecto, ¿verdad? Está perfecto, pero está. Vamos a ver un navegador. ¿Qué ha pasado aquí? Añadid un tebodi aquí, pero ¿dónde ha salido? Pues lo que está ocurriendo es que el navegador, lo primero que hace es decir, tú eres un ser humano, no te creo, voy a arreglarte tu código. Entonces, te añade esto, ¿por qué? Porque en realidad deberíamos tener en la tabla un TGAP, que al final es una etiqueta que le está dando una sintagis, un contenido, está definiendo dónde empieza y acaba cada una, y también un tebodi para decir dónde está el jugo, dónde está la información importante. Y siempre habría que hacerlo de esta manera, independientemente de que el diseño sea en vertical o sea en horizontal, quiero decir, que los títulos lo tenemos en la parte arriba o lo tenemos en un lateral. Está la estructura y luego, ya con flash o con grid, lo moveis como lo queráis. Pero hay más etiquetas de contenido. Tenemos, por ejemplo, header, bueno, muchas de estas ya las conoceréis. Un breve repaso. El header sería la parte de arriba donde tenemos el logo, donde tenemos el menú principal, donde tenemos el contenido que se va a repetir en cada una de las páginas. Tenemos también el main que podría ir acompañado del header, donde va a ir de verdad el contenido, ¿no? Lo que nos interesa que cambie dinámicamente de la página a página. Y tenemos el footer que va a ir a continuación del main. Perfecto. Por cierto, dentro del footer no debería haber la etiqueta nav. Ahora luego hablamos. Del main, al ser un contenido muy amplio, normalmente no se define o no queda claro dónde empieza y acaba cada sección. De ahí que tengamos sección. Nav, podría ir acompañado dentro del header o en alguna otra parte, como la site. Si me pade definir dónde está el menú. La estructura básica sería nav-ul-li-a. Salvo ciertas variaciones como puede ser las miras de nav. Nav-ul-li-a. Me vas a matar, lo siento. Si tenemos un texto que indica el tiempo, como puede ser lo típico, una fecha y una hora, lo envolvemos con time. Si está la palabra hoy o está ayer o hace una semana, también debería estar en World Nav. Y dentro del atributo dead time, definiríamos exactamente a qué se refiere hoy. Como mañana o pasado o lo que sea. Y la formato suele ser año, guión, mes, guión, día, tema yúscula y ya la hora, separado con dos puntos. Si tenemos una dirección, adres. ¿No es difícil? Que tenemos un elemento que se repite, como puede ser un componente donde la estructura es la misma, pero cambia el contenido. Lo que son los enlaces, el propio texto interno, utilizaríamos un artículo, no solamente es para hacer artículos de blog, ¿vale? Lo que quiera que entendáis. De hecho, dentro de un artículo, puede haber un header. Perfectamente. También tenemos a site, que es cuando queremos acompañar un contenido, ¿no? Un menú auxiliar que pueda aparecer, desaparecer. Tenemos el footer que ya hemos convencido antes, el cual, no lo digo yo, ¿eh? Lo hice en la W3C. No debería tener en app. A pesar que tengáis vuestros listas, vuestros uls, como vuestros enlaces. Y hgroup. Sirve cuando tenéis un título que acompaña otra etiqueta, pero sigue formando parte del título. Por ejemplo, tenéis un h1. Las mejores conferencias son tal, ¿no? Y debajo tenéis un párrafo. Podéis ver más o la próxima será en Zaragoza. Pues todo eso forma parte de un hgroup. ¿Vale? Si ya tenemos claro cómo tenemos que estructurar el HTML para nuestro equipo, para que nos entienda y podamos seguir trabajando, estaría muy bien que ayudáramos al front. Le quitaramos tareas, cosas que podemos hacer nosotros nativamente con HTML. Y también nos dan más control, porque nos permite ya desde un inicio darle la forma y la interactividad. Me explico. Por ejemplo, ABBR. Este etiqueta, si la conocéis, lo que hace, básicamente, si yo viera esto en el navegador web, obviamente, no estaría este etiqueta. Estaría HTML con unos puntitos de bajo. Y cuando pusiera el cursor encima, aparecería una especie de mensajito, un tool tip, describiendo lo que yo tengo dentro del atributo title, una pequeña ciudad donde podemos definir acrónimos o iniciales o tal vez explicar algún concepto. También tenemos details para hacer desplegables, típico de preguntas frecuentes, donde yo tengo un texto, pulso y se despliega un contenido a continuación. ¿Qué aparecería visualmente? Simplemente la palabra factura. Pulso sobre ella y todo el HTML que yo tengo debajo, pero dentro de details, aparecería. Y sí, lo podéis editar. La forma que queráis, la añadís iconos, la hacéis redondo, lo que queráis es para vosotros. También tenemos para hacer modales, dialogue, típico mensaje que aparece en el centro de la pantalla, ocupando todo, bloqueando con un pequeño borde o lo que queráis. Te dice este etiqueta, puedo disponer todo el HTML que queréis aquí dentro, no hay ningún problema. Por defecto, si yo no pongo el atributo open va a tener un display non. En cuanto yo añada esto, open, vuelve a salir. Ya tendríamos que gestionarlo con JavaScript. Cuando queremos que aparezca ese atributo. Incluso también podemos jugar con CSS. Tenemos data list. Cuando queremos hacer un input en el cual nosotros sugerimos autocompletaciones, ¿qué texto van a aparecer? Podemos simplemente definir una especie de selector, un data list con option. Se parece mucho a un desplegable, la estructura, donde vamos poniendo los valios. Cada uno de los textos que queremos sugerir, según se vaya escribiendo en este input y lo vinculamos con su atributo ID. ¿Me dice aquí que tenemos el atributo list? Bueno, pues esto iría relacionado con esto. Entonces, esto tiene un montón de posibilidades. Porque esta lista la podemos generar con un backend, como puede ser WordPress. O incluso podríamos hacer que dinámicamente, según el usuario fuera pulsando teclas dentro de ese input, con el evento input, pudiéramos dinámicamente cargar con Ajax, rellenar todo este contenido y sería fantástico. Si ya está claro el tema de HTML, vamos a lo jugoso. Vamos al CSS. Bien, ¿cómo podemos trabajar con nuestro equipo? Todo clases. Ahí con esto, ya habéis hecho el 90% del trabajo. Intentemos diferenciar las ID, o sea, la ID, donde tendríamos una referencia única que nosotros utilizaríamos con JavaScript para capturar cada uno de los elementos y luego tengamos las clases donde nosotros vamos definiendo los estilos. Si hacemos esa separación, no debería haber ningún conflicto dentro del equipo. Claro, si tenemos que añadir clases, llega un momento en que cada uno le da el nombre que cree conveniente y eso es un problema. Porque habrá gente que es más original y otra gente, pues, que no la es. Entonces, las tres formas o las tres nomenglaturas más populares es CSS orientado a objetos donde, bueno, crea una especie de caparazón donde vas añadiendo como modificaciones. Luego tenemos Smas, se pronuncia así, lo he leído en la documentación, Smas, que lo que haces justamente de todo contrario, intenta que todo sea homogéneo, que no exista barreras. Y luego tenemos el famoso B, que por cierto está desarrollado por el equipo de Yandex, donde intenta separar todo en bloques, elementos y modificadores. De hecho, tiene muy pocas reglas, por cierto, si queréis es que no haya el QR es el momento donde tengo una explicación un poco más larga de B. La clave está en que tú tienes por un lado bloques, que sería el componente o la estructura que es única. Tenés por otro lado lo que sería los elementos, que son las cosas que están dentro de ese bloque, de ese componente. Luego, la forma de nombrar un bloque respecto a su elemento sería con dos guiones bajos, y entre un elemento y su modificador irían dos guiones simples. Yo creo que esto se ve mejor con un ejemplo. Entonces, aquí tenemos dos bloques, uno que es cesta, ¿vale? Que dentro va a tener diferentes bloques con elementos, con items, y dentro del, bueno, he dejado solamente uno, tengo el bloque de item, el elemento dentro. Y claro, ¿qué hay aquí? Pues tenemos el elemento de nombre y el elemento de precio. Y como veis, tengo item, guion bajo, guion bajo nombre, item, guion bajo, guion bajo precio. Y solamente viendo las clases, se puede intuir qué hay dentro de cada uno. No me haría falta llenar, como veis aquí, cada uno de los comentarios. Yo sé dónde empieza y acaba. De hecho, muchas veces cuando yo hago HTML, directamente pongo clases que son innecesarias, simplemente para que la persona que lo va a leer entienda. Entienda, ¿no? ¿Qué espero que haya ahí? ¿O por qué lo he puesto? ¿Cuál era mi intención? Si yo quiero crear un modificador, ahora vamos a ese concepto. Si yo tengo un botón donde todo mi sitio web tiene el mismo diseño, pues tiene un bordet, el fondo es transparente, el texto tiene un color determinado. Pero es que resulta que hay un botón, el de comprar, que es verde. Lo escácemos. Volvemos a repetir todo el contenido. No hace falta. Vuelvo a utilizar la clase de botón y añado una segunda, que por cierto, en el orden de la cascada, debería estar debajo para que sobreescribiera, donde yo le pongo guion guion verde. Y solamente modifico aquí, pues, tal vez el color del borde y el color del propio texto. Y ya está. Y con esto podemos crear todas las modificaciones que creamos necesarias. Muy bien. Y además es muy cómodo hacerlo. Pero si utilizamos un meta lenguaje, como puede ser SAS, será aún mejor. ¿Quién de aquí utiliza SAS en su día a día? Uy, qué pocas manos. ¿Y quién utiliza solamente CSS? Tenéis a aprender ya, o sea, alguien está aquí y lo SAS, por favor. Tiene cosas muy interesantes. Por ejemplo, podemos importar otros elementos desde el propio fichero y me diréis, pero eso ya se puede hacer. Yo ya puedo en CSS normal importar ya, pero hay una diferencia. Y es que cuando tú importas de otro fichero CSS, CSS a CSS, lo que en realidad estás haciendo es pedirle que lo descargue. Digamos que no es eficiente, porque digamos que se pone como un orden de cola de descarga. Mientras que aquí no. Aquí lo aglutina todo en un solo fichero. Las variables son mucho más sencillas, nos permite tener una jerarquía mucho más clara. Nos evitamos. Si utilizamos SAS y no CSS, tener que poner las llaves, el punto y coma del final. Podemos utilizar mixes, que son como funciones. Podemos tener condicionales y más historias que van muy bien cuando trabajáis en conjunto. Claro, si cogemos estos superpoderes y yo intento solucionar problemas de mi día a día como puede ser media query, pues puedo hacer cosas que están muy bien. Primero partimos de, bueno, mi título. Los media queries son sucios. ¿Por qué digo esta barbaridad? Porque es muy engorroso. O sea, yo tengo una estructura que cuando necesito modificarlo con ciertos condicionales, pues que este no es una pantalla. Cuando además sea inferior a 30 rem, pero cuando máximo tenga 50. Quiero aplicar esto. Me toca, perdonar. Necesito agua. Necesito repetir el selector y además poner la modificación. Y tengo que tener mucho cuidado también del orden de la cascada, porque no podría poner esto encima de la anterior, porque si no, una cosa estropea a la otra. Había mucho salado en la comida, ¿eh? Bien. Entonces, ¿cómo puedo mejorar esto con SAS? Así de sencillo. Me evito repetir el selector. Yo lo que hago directamente es tabular, poner mi siguiente contenido y queda todo más bonito, más fácil de trabajar. Pero esto puede aún mejorar más. Y es utilizando mixings que no lo voy a enseñar, donde tú puedes crearte una estructura la cual simplemente, con un nombre que tú te defines, añades esto de forma automática, sin tener que estar repitiendo constantemente. ¿Y por qué no os enseño ese ejemplo? Porque soy malvado. No, porque voy a dar algo mejor, que es trabajar con el tema del split media. Esta es una forma en la cual tú puedes tener únicamente 2 o 3 media queries en toda tu página. Me da igual que estemos trabajando en Wordpress, me da igual que estemos trabajando en una página sencilla como puede ser algo que habéis hecho vosotros a medida. Tú te defines unos ficheros. En este caso, tenemos la versión mobile, la versión tablet, la versión desktop. Y con un media en la propia etiqueta donde estás importándolo, estás llamando uno u otro. O sea, están activándose o desactivándose. En este caso, siempre habrá un ccs activo. Se me voy remencionando, se van activando. Claro, si yo jugo toda esta estrategia, que por cierto recomiendo que la utilicéis con SAS, y además utilizo un patrón en el cual todo el equipo trabaje de forma homogénea, como por ejemplo el patrón 7.1, que esto tiene bastante tiempo, no es una novedad. Podemos hacer lo siguiente que tenéis aquí. Una antes que nada, antes de enseñaros el resultado final de unir todas esas tecnologías, si no conocéis ese patrón, y además os he puesto aquí un breve resumen de cómo está la actualidad, tú crearías dentro de un espacio, dentro de tu sitio web, una carpeta llamada SAS, dentro tendrías la carpeta abstract con un mixing o el conjunto de todas las funcionalidades que quieres aplicar. Tendrías un fichero para el tema de variables, una carpeta llamada base con todos los estilos que van a compartir todas tus páginas. Ahí tendríamos base, pues puede ser que Bodhi no tenga margen que, bueno, lo que sea, o el fondo que tenga un color determinado. Aquí especificas, ahí importas todas las fuentes, tienes pequeños helpers, una clase para que no se muestre, una clase para definir el tamaño de algo, lo que sea. Y tipografí, pues especificas que fuentes va a tener cada uno de los apartados dentro de tu web. También tienes una carpeta cuando tienes cada SAS de cada uno de tus componentes, el componente de alerta, el componente de botón. Además tienes otra carpeta que se llama layout, donde vas definiendo la estructura global de todo el sitio. Pues normalmente suele ser footer y header. Si hay una site, pues también iría aquí. Dentro la carpeta page, yo iría poniendo ficheros por cada una de mis páginas. Lajón, preguntas frecuentes, contacto, equipo, lo que sea. De hecho, veis aquí que tengo tres puntitos, igual que componentes donde puedo haber más contenido. Si yo tengo tema oscuro, tema claro, tema rosita, tema fucsia, lo voy añadiendo en ficheros separados. Y me guardo un espacio, vendos para todo lo que sea externo a mí, normalizadores, plugins o lo que sea. Vale, pues ya hemos hecho la presentación de cómo funciona esta forma de estructurar nuestros estilos. Incluso también, si os parece demasiado engorroso, podéis utilizar una versión un poco más ligera, donde se ha quitado gran parte de las carpetas y la complejidad se ha quedado con lo mínimo esencial. Esto funciona bien para landings, para directorios o pequeñas cosas que os sea útil. No lo veo para una página, para un cliente muy extensa o para trabajar con mucha gente dentro del equipo, porque si no os vais a machacar, entre vosotros, sobre todo porque trabajaréis en los mismos ficheros constantemente de QR para descargar plantilla. Y ahora sí, juntamos todo lo que está documentando y tenemos esta estructura que puede trabajar todo el equipo a la vez, donde por un lado lo he rebajado a versión mobile, versión escritorio. Tengo la split media, donde tengo estos dos links dentro de mi GAT y tengo SAS, la carpeta Astrak, la carpeta base y la carpeta DemiVendors, que es general para todos. Estas cuatro carpetas se llamarían en dos ficheros separados, en mobile.sas y en desktop.sas. Y además, la carpeta mobile se llamaría mobile y la carpeta desktop se llamaría en desktop. Solamente hay una carpeta que diferencia un fichero de otro. Entonces, con esto conseguimos que tenemos, aquí es donde viene la parte interesante, unos estilos que solamente van a funcionar porque no les queda otra en una resolución determinada. Y puedo tener una parte del equipo trabajando en la versión mobile, otra en la versión desktop, incluso puedo tener al diseñador web jefe trabajando con cosas importantes, cosas que definan cómo se va a mostrar toda la página, y entre ellos no va a haber ningún choque. Y ninguno de ellos, en ningún momento, tendrá que aplicar un media query. Eso es lo potente. QR con todo esto también es accesible. Y algunos consejos, si trabajáis en una sola dimensión, en una sola línea, flex, no tiene más, estamos hablando de cuando tenéis una serie de componentes que pueden estar en horizontal o en vertical y tenéis que jugar con las separaciones. De hecho, ha habido varias charlas que me ha hablado el tema. Si tenéis que utilizar una estructura, una cuadrícula donde los elementos están puesto en diferentes zonas, o tiene algo que se sale de lo habitual, iros a agrid. Y si queréis 3D, iros a OGL, pero eso ya es un tema de parte. Quiero deciros que no intentéis utilizar estilos de transformación en 3D porque os vais a quedar siempre cortos por mucha perspectiva o por muchos cálculos matemáticos que hagáis. Esto es mucho más potente, sin duda alguna. También hay otras herramientas que están saliendo, como el Cascade Liar, que es muy interesante, porque hace muy poco que ya lo admite todos los navegadores como Safari, en el cual nos permite que nuestros estilos no se sobrescriban porque funcionan por capas, como una cebolla. Entonces, digamos que cuando tú tienes un elemento, un componente que está muy por encima del resto, sus estilos, van a sobrescribir al resto. Esto merece una chela aparte. No obstante, yo de momento no recomiendo que lo utilicéis porque con lo anterior también tenéis suficiente. Aquí no vais a tener problemas de que tendréis que machacar con Importance o tal vez tenéis un fichero aparte. No, no le hace falta. Porque, como digo aquí, la arquitectura CSS da fiabilidad y ayuda al mantenimiento. El resto no debe ser importante, en otras palabras. Si lo anterior funciona es sólido y el equipo, además, se acostumbra a utilizarlo, no necesites de utilizar cosas nuevas novedades que vayan saliendo en el mercado, ¿vale? Ya, con esto sería suficiente. Muy bien. Antes de, no sé cómo voy, de tiempo, 5 minutos. 10, hasta sobra. Pregunta frecuentes. Debería ser un framework CSS, por cierto, todo lo que voy a decir es mi opinión. No significa que tenga toda la razón. Vale, mi opinión es que te obliga a tener un diseño determinado por mucho que tú cambies su estilo, al final siempre se va a ver que en la base es un framework, es fácil detectarlo. Eso es un framework de bustra. Mira, eso es un tell-win, o sea, al final lo acabamos viendo. También puede ser peligroso porque llega un momento en que no puedes seguir actualizándolo. Tienes que adaptarte a una versión determinada, pero los años van transcurriendo. Y si intentas actualizarlo, puede ser que se te rompa algo. Puede ser un bastante incómodo. Y si no estás utilizando todo el framework, todas las herramientas al completo, estás dándole una carga extra o de descarga a vuestros visitantes. Y eso puede hacer que no podáis optimizar esta parte, porque no podáis hacer nada. Entonces, respondiendo, debes revisarlo. Bueno, es buena idea si no quieres documentar y no quieres invertir tiempo en crear una estructura de CSS. Si podéis dedicarles el tiempo, pues, bueno. El sucrícame a las reglas del juego que siempre está hablando, que llevan años hablando del tema, no. Simplemente ha venido a darnos la oportunidad que dentro de un grid tengas una pequeña sección con otro grid, nada más. Y, de hecho, no daría falta utilizarlo si has hecho bien tu grid principalmente. Pero, bueno, esto es mi opinión. Puedo utilizar elementos que aún no son compatibles, por supuesto, con la roba support. En este caso, podéis ver cómo yo estoy utilizando un color RGB que lo aplico a todo mi sitio. Sí, supongo que esperáis aquí un hexadecimal. Y digo, me gustaría utilizar, si es compatible, si soporta ese navegador, el color LCH, me gustaría aplicarlo. Y además, mira, si esto lo soporta, al final es una condicional, quiero que me apliques esto que está aquí debajo. El caso que no, pues, utilizará la parte de arriba. ¿En qué nada de barro debería testearlo? Veis ese pack más gigante que se está devorando el resto de la competencia, eso es crón. Entonces, empecemos por ahí y luego cogemos este quesito, que es Safari, y con eso tendremos prácticamente todo, salvo la parte naranjita que es Firefox y el verde que no sabemos lo que es. Y si no metemos con Firefox, pues, ya lo tenemos todo. Entonces, estos son los tres motores principales que tenemos hoy en día, WebKit, que podría ser si no tenéis Safari, porque nos gusta pagar dinero aquí. Podéis iros, por ejemplo, a Genome con su navegador o podéis utilizar dentro de Windows, creo que está Midori, hay una compilación. Ahí ya no me meto. Si queréis utilizar Chrome estupendo, si es libres, si no, iros a Chronium, que es lo mismo prácticamente. También tenéis el Edge, si estáis en Microsoft y no queréis instalar nada más. Y bueno, Firefox es Firefox. También tenéis aquí un QR, donde hago un estudio. Bueno, otra pregunta, React Bio o Angular? Si estáis en WordPress, obviamente, en React. Si queréis trabajar con un equipo que tiene poca experiencia en el tema del desarrollo con JavaScript y queréis llevar la lógica dentro de HTML, Bio. Y si tenéis un equipo masivo, Angular. Y si podéis elegir, ninguno. Iros a lint, hacéis un componente nativo y ya lo tenéis. De hecho, os va a sonar mucho esto a React. Aquí tienes un torcito de código, un Olamundo. Básicamente, le importo lint, meto el nombre de la etiqueta que quiero que tenga mi componente, defino el CSS, defino también una propiedad. En este caso, mundo. Lo guardo como un string dentro de un name. Por cierto, todo esto es TypeScript. Y cuando se renderice, devolvemos la parte que tenéis a la derecha, con la propiedad que tengo aquí. Entonces, pasaríamos de tener esto a esto. En realidad, automático. Semáticamente, queda bastante más claro. También, si podéis, esto ya es una sugerencia mía que me ha gustado mucho, tanto a nivel personal como dentro del equipo, es utilizar estímulos para gestionar el tema de los eventos. Porque además, si volvéis a renderizar el mismo contenido, en caso de un HTML sobre WebSockets, podríais esto lo autogestiona, evitando aquella repetición de cuando conectas un elemento. Y además, aquí, la sintaxis es bastante clara, porque estoy añadiendo este atributo hello. Entonces, está diciendo que todo esto va a formar parte de un fichero que yo voy a tener, que se llama hello.js. Aquí le estoy diciendo, oye, la acción que va a tener este botón del evento click, es así la sintaxis, no me lo estoy inventando yo, va a formar parte del fichero hello del controlador y va a llamar a la función está, de grid. Y yo dentro de mi fichero de JavaScript podría llamar perfectamente este objetivo para meter aquí el contenido que a mí me dé la gana. Y nada más, es solamente esto. Bueno, testing. Si estáis solos en el mundo, pues el CUR y el REX, pues ya podéis hacerlo y funciona bastante bien. Si vais a trabajar en equipo, pues os tenéis que ir a otra herramienta, como por ejemplo Fipers, que es totalmente visual, tanto con el click del ratón, podéis ir definiendo los pasos que debería seguir un usuario normal para ver qué funciona, como también podéis definir ficheros de JavaScript, donde vais poniendo cada punto. O sea, es muy potente, muy interesante y no es nuevo. O sea, ya va bastante en el mercado. Bueno, y antes de nada, simplemente comentaros de que yo me dedico a la docencia, por eso tengo tantos ejemplos. También soy el CTO dentro de mi equipo. Tengo un par de libros que he publicado, pues si queréis revisarlos en este QR. Y si queréis seguir más cosas de mí, pues os metéis en mi landing y ahí tengo todo mi blog, mi newsletter y todo lo que queráis. Y ahora sí, muchas gracias. Y acepto preguntas. Y si no, no pasa nada. No me siento ofendido. Hola, ¿qué tal? Hola. Yo quería preguntarte al margen de todas las funcionalidades, los diferentes lenguajes que has explicado, frameworks, cuál es el IDE que tú recomiendas para programar en tanto HTML, etcétera, o sea, en tu computador, nada más que eso. Pues yo utilizo de Macs. Pero no se os recomiendo a nadie. O sea, qué decir, eso es una manera de darte látigazos a ti mismo. Es un juguete. Tienen tantas cosas, tantas posibilidades. No me aburro, es mi juguete personal. Pero para alguien que está empezando, para un alumno, yo le recomiendo que vaya a JetBrains, a la Suite, PHP Store, a Web Store, y todos estos. Y, bueno, siempre está Visual Code, por supuesto. Gracias por la pregunta. Gracias por la charla. Me ha parecido súper interesante. Me has hecho un poco spoiler porque te iba a preguntar por los frameworks CSS, pero opuestos a tener que utilizar uno, te quería preguntar en tu opinión, en tu experiencia, ¿cuál de ellos elegirías por tener menos carga o por tener menos cosas que no puedas utilizar en un proyecto más o menos genérico o estándar, Tailwind, Pustrap, Bulma? Te puedo comentar que tuve mi época de Tailwind. Y la verdad es que me gustaba mucho. Pero al final acababas teniendo un montón de clases, que sí, que las puedes extraer y hacerte otra clase. Y esa clase la llamas. Eso está claro. Entonces, ya paso ese tiempo y me maduré, yo creo. Y vi que no era tan interesante. Entonces, también he pasado por Bustra, por Bulma, por Pico, por, no sé, por muchos. Y no te sabría responder. Es que ya he llegado a un punto en que prefiero no utilizarlos, porque he visto que antes tenía mucha más utilidad, sobre todo el tema de compatibilidad entre navegadores. Te solucionaba el tema del responsive. Bueno, lo siguen haciendo. Pero es que hoy en día tenemos tantas herramientas y están más duro el CSS que yo creo que podemos prescindir de él. Sí, ahí. Hola, fantástica presentación, como siempre. Gracias. Que yo ya que te sigo ya de tiempo. Mira, una preguntita que te quería hacer hablaba sobre el tema de HTML, CSS para equipos. ¿Cuál es tu opinión en el uso de linters, sniffers y demás en vete aplicar normativa, digamos, de palabra o de tal, si ponerlos más bien en sistemas automáticos de automatización a la hora de subir a repositorios y demás? Pues es muy buena pregunta. Yo creo que la pregunta sería más. ¿Quién tiene que hacer la revisión, el core review, una máquina que te asegura que está bien todo o lo tiene que hacer un ser humano? Nosotros actualmente preferimos que lo vea a alguien, por lo de siempre, porque así la responsabilidad está en los dos, en que se ha equivocado y en quien ha tenido que revisar. Y también porque puede haber un trato directo. Muchas veces a veces dan un mensaje que no entiendes o lo aprendes a sortearlos y entonces, a final, no sirve para nada. Y también ayuda a que haya lazos dentro del equipo, que haya más comunicación. Entonces, te podría decir que técnicamente hablando, deberíamos utilizarlos. Pero personalmente creo que une más el equipo no hacerlo. Gracias. Muy buena charla, ¿eh, Andrés? Gracias. Una pregunta, ¿existe algún servicio o algo que te puedes instalar? Por ejemplo, cuando has preguntado quién utilizaba SAS y CSS, había mucha gente que todavía utilizaba CSS. Y yo creo que una de las limitaciones es porque el SAS lo tienes que acabar compilando al final para que te devuelva el fichero final, etcétera. Sí, hay que procesarlo. No sé si existe, por eso te pregunto, ¿a alguna herramienta, alguna cosa que sea desatendida que tú tengas instalada en tu aplicación web y que hagas los cambios que tú consideres en tu fichero SAS, guardes, te olvides, y eso por detrás te precompile y te genera el fichero final para que no te tengas que montar, o sea, desplegar todo el entorno local, poder hacer los cambios y tal que cual que yo creo que es algo que es lo que le frena mucha gente. Porque aunque el Cowboy Coding no esté bien visto, no podemos negar que se utiliza y se seguirá utilizando a día de hoy porque es lo más cómodo, o sea, lo hacemos todos al final. Totalmente de acuerdo. Tienes razón de que es una barrera de entrada. Implica muchas veces meterte con el terminal. Por suerte, hoy en día tenemos interfaces gráficas. Por ejemplo, PrePros es una de ellas, aunque más software, o WIS, que te lo hacen ya. Incluso te compilan Tepescript, React. No obstante, tienes otras herramientas, que es verdad, tienes que usar el terminal como parcel, que directamente lo que te hace es te detecta, que tienes ahí el fichero SAS y ya te hace tu build. Y lo que nosotros hacemos es que no soluciona lo que tú estás diciendo, es hacer un fichero GALP, o sea, una tarea, que ya lo tenemos la plantilla, simplemente lo arrancamos, detecta que hay un cambio, refresca, también envía el navegador que ha habido un cambio. Pero yo creo que tiraría más por la WIS. Ahí estás. Sí, sí, sí, sí. Gracias a ti por la pregunta. Creo que ya no hay más preguntas. Muy bien. Gracias, Andros. Por supuesto, por la charla tan interesante. Gracias por venir a la Workham 2023, por formar parte de ella. Y te vamos a hacer la entrega de la Supertaza Workham 2023.