 La sesión de las cinco es un mejor CSS, planeando para no sufrir en el futuro. Si hay alguien que anda perdido, dos minutos y si no empezamos, o empezamos. Ok, mi nombre es José Leiva, soy de Costa Rica. Más o menos en el 2007, empecé a trabajar en web haciendo dos sitios. En el 2007, entré con Drupal y durante más o menos tres años, estuve trabajando en diferentes Drupal shops en Costa Rica haciendo temin y site building. Tengo alrededor de dos años de trabajar en Backcountry. Es una empresa de e-commerce. Y básicamente lo que hacemos es acercar a las personas a sus pasiones. Los invito desde ya, el Drupal Camp en Costa Rica es en julio. Son el 29 del 31 de julio. Quedan invitados. Desde que empecé a trabajar con Drupal, me involucré en la comunidad. Dando charlas y compartiendo un poco de lo que iba aprendiendo. El objetivo de la charla de hoy es que nuestro yo del futuro no nos odie. Como le dije antes, básicamente mi rol desde que empecé a trabajar ha sido en front end. CSS, JavaScript, site building. He trabajado como freelance escribiendo verdad CSS solo en mi casa, sentado en la mesa. Y tengo del 2010 que he formado parte de diferentes equipos. Equipos de dos personas, de cinco personas. Ahora trabajo en esta empresa y somos alrededor de seis equipos que se encargan de diferentes partes del sitio. Y se imaginarán lo complicado que puede ser tocar por ejemplo los mismos archivos y no echarlo a perder verdad. Entonces lo que vamos a hablar hoy o lo que les voy a compartir hoy es parte de mi experiencia de lo que yo he aprendido tanto en la empresa actual como en las anteriores tanto trabajando con proyectos Drupal como no Drupal. Ok, punto número uno, CSS es fácil. Eso lo dicen todos los debakend. No hacen front end porque el CSS es demasiado fácil. Y CSS 101, verdad, tenemos un selector que puede ser prácticamente cualquier elemento que esté en nuestro documento de HTML. El selector le podemos pasar una propiedad de un valor. Entonces la propiedad puede ser algo digamos para cambiar el tamaño de la fuente. Font size y el valor, la unidad sencillo. Nuestro bloque de reglas puede tener uno, dos, n cantidad de propiedades y valores. Y nuestro archivo CSS está formado por n cantidad de bloque de reglas. Pácil, verdad. CSS lo usamos entonces para qué? Para darle estilos, trabajar la presentación de nuestros sitios o de nuestras aplicaciones. Ok, es que CSS es muy sencillo, pero algunos ejemplos de la vida real para los que conocen, por ejemplo, un poco de Drupal pueden ver hacia dónde vamos. Uno, dos, tres, cuatro selectores para poner un color de fondo. Eso es, o sea, de un proyecto real. Los que conocen Views, o sea, uno y dos, tres selectores, dos de los cuales están concatenados. Igual agrupamos selectores, lo cual es una buena práctica y no tiene nada de malo, pero para qué tener un, dos, tres, cuatro, cinco selectores diferentes si podríamos tener solamente uno. ¿Qué es lo que pueden ver ahí? Bueno, alta especificidad. Yo asumo de los que están acá tienen conocimiento de CSS, así que el viaje que vamos a hacer es un panorama desde arriba. No vamos a entrar a cosas específicas. Entonces, esos ejemplos, ¿qué problemas tienen? Alta especificidad, ¿verdad? Por ejemplo, en este, la segunda selector, tenemos un class y un ID. Si yo quisiera por una u otra razón, sobre escribir una de estas reglas tendría que elevar la especificidad, ¿verdad? Alta dependencia del HTML. Si vieron, por ejemplo, cualquier caso, por ejemplo, el de views, si quitamos uno de los selectores, la regla deja funcionar. O sea, por ejemplo, tocamos nuestro código HTML y modificamos, limpiamos un poco el views, ya no va a funcionar tampoco. Golpea performance. Todos saben que el browser lee de derecha y izquierda y entre más rápido haga un match con la regla que anda buscando el selector para aplicar los estilos, es mayor la performance. Y son difíciles de reutilizar. O sea, todos esos ejemplos que les mostré están amarrados a un caso o a un bloque de HTML específico y una carita trista. Otra vez, escribir CSS es sumamente sencillo. O sea, cualquiera con la pequeña introducción que les di lo podría hacer. ¿Qué es lo que pasa? La arquitectura de un proyecto no es sencillo. Eso conlleva tiempo, conlleva planeación y conlleva cierta organización. Y cuando hablemos de arquitectura, que es un tema que está muy de moda hoy en día, nos vamos a estar refiriendo a que son herramientas, a que es planeación y que es escribir código, o CSS en nuestro caso, de manera en el que sea código de calidad. Y algunos elementos que podrían decir que nuestro código de calidad es, por ejemplo, performance, otra vez, que tan reusable es ese código que tenemos. Nuestro código hace lo que debería hacer y si es mantenible y escalable. Esos son algunos elementos para decir si nuestro código es de calidad o no. Para mí, lo más importante es la mantenibilidad y la escalabilidad del código. Y a eso le vamos a poner una carita feliz. Entonces, para poder llegar a ese código de calidad que ocupamos, en muchos casos lo que vamos a ocupar es repensar, incluso desde los procesos, y nuestro flujo de trabajo. Piensen en la gente de backend. O sea, la gente de backend tiene una gran planeación. O sea, si ustedes van a escribir un widget, digamos, de JavaScript, difícilmente se van a sentar, van a empezar a volar código y ver si funciona. Y si no funciona, lo vuelven a hacer. Y si no funciona, lo vuelven a hacer. Es una pérdida de tiempo, una pérdida de recursos. Normalmente planeamos y organizamos cómo vamos a trabajar. ¿Qué tienen los amigos de backend? Son variables y en parciales. Tienen objetos. Ahora todo es orientado a objetos. JavaScript es orientado a objetos. Y manejan todo lo que es la parte de la extracción. Eso que les da. Les da la posibilidad de enfrentarse al cambio y a la complejidad de los sistemas de hoy en día. El front-end no se queda atrás. O sea, construir un sitio web ahora es mucho más difícil que hace cinco años. Ahora cada vez tenemos más capas. Cada vez es más importante el performance. Cada vez es más importante que nuestro proyecto sea mantenible y escalable. Y eso le mete elementos de complejidad. Entonces, parte de las metodologías que se están utilizando para la parte de CSS es o CSS, BEM y SMAX. Esos tres no son librerías, no son frameworks. Son metodologías de trabajo. Y lo que nos plantean son cómo entender el todo y sus partes. Cómo organizar y cómo estructurar nuestro código. Y funciona tanto para CSS, digamos, vainilla normal o puede funcionar con preprocesadores de CSS. Entonces, retomando, cualquiera de estas tres metodologías, otra vez, o sea, no es de que si decimos, vamos a trabajar con SMAX. Y simplemente porque traemos con SMAX, se nos van a solucionar los problemas. Sería un error. Donde yo trabajo, usamos un mix de los tres. Básicamente es estudiar, agarrar la información que está en la web gratis. Hay cantidad de libros, artículos, videos, etc. Y es podernos apropiar de las partes que más nos interesan y las partes que se ajustan a nuestro proyecto. Estábamos hablando también sobre preprocesadores, ¿verdad? Al inicio les decía que los amigos de backend tienen variables, tienen constantes, tienen parciales, tienen un montón de cosas que en CSS normal no tenemos. Entonces, los preprocesadores vienen a llenar esos vacíos. Ahora, con SaaS o con Les o con Stylus, podemos tener variables, podemos tener mixings, podemos trabajar con parciales. Y es más fácil atraer el código que nos interesa o solucamos a trabajar. Para los que no tengan claro que es un preprocesador, es básicamente una capa más en nuestros CSS, por así decirlo. Si vamos a trabajar con SaaS, que en este caso la sintaxis es SSSS, escribiríamos prácticamente en sintaxis de SaaS, que es muy parecido a CSS. SaaS compilaría lo que escribimos y el output va a ser CSS normal. Es simplemente una capa más y esta capa de abstracción otra vez nos da funcionalidades que CSS no nos da. ¿Qué pasa con esos preprocesadores? Son excelentes, son una excelente herramienta siempre y cuando los hacemos correctamente. Podemos dividir nuestro código en pedazos más pequeños, nos proveen abstracción y, muy importante, no reemplazan saber CSS, ni tampoco van a reemplazar qué tanto entendamos sobre arquitectura. ¿Son excelentes si se usan correctamente? Muy sencillo, un selector FU y después tenemos otro bloque de reglas en el que tenemos un selector descendiente que es SaaS. FU es el selector padre y uno, si tuviéramos más elementos adentro de FU tendríamos que seguir haciendo FU es selector, FU es selector, FU es selector. Les o SaaS nos dan esta funcionalidad que es de añadir. Podríamos hacer algo como esto. Dentro de FU yo podría declarar las reglas que aplican a SaaS. Es super sencillo, es una de las funcionalidades básicas cuando no entiendes a tratar con propios sabores y es bastante útil para qué más sirve y nos ahorra tiempo. ¿Qué es lo que pasa? También es una de las que es más mal utilizadas. Esto, igual de un proyecto real SaaS están añadiendo y están añadiendo cuatro niveles, ¿verdad? Y ese sería el output una vez de que ha sido compilado nuestro código. Yo creo que difícilmente si estuvieramos escribiendo SaaS vainilla SaaS vainilla haríamos algo como esto. Nos dispararíamos en un pie si estuvieramos algo como eso con cada bloque de reglas. Entonces, hay que tener mucho cuidado con la anidación. No anidar exactamente a cómo está la estructura de nuestro HTML. Es algo muy común. O sea, podemos tener un bloque y adentro del bloque tenemos diferentes elementos y empezamos a anidar nuestro código para que haga un match con el HTML. Ahí lo que estamos haciendo es ligando o amarrando cada vez más nuestra regla de CSS con el HTML. Hay que tener mucho cuidado con el output. Otra vez cuando estamos escribiendo es muy sencillo hacer esto. Es muy, muy, muy fácil. Si no estamos vigilando el output vamos a seguir construyendo reglas como estas. Si podemos evitar anidación y una regla general que es como que uno no debería anidar más allá de tres niveles. Estos últimos dos puntos por qué? Porque es una manera de mantener la especificidad de nuestro código a un nivel similar. Ok. Otro de los puntos importantes de los preprocesadores es que nos permiten dividir en pequeños pedazos nuestro código. No sé cuántos de ustedes los Drupaleros han hecho cosas como estas. Esto lo saqué de uno de, no sé, un Drupal 6 o uno de los últimos Drupal 7 que hice sin SAS. Y para mí esto era como muy, muy era pan de cada día. Creaba archivos de CSS específicos para cosas específicas. Entonces, por ejemplo, tenía uno para CSS, uno para cosas relacionadas con Drupal, digamos, sobre escribir paginador o, no sé, los menus tenía un CSS para como base, para layout, para typos, todo lo que ha tipografías. Y si había algo que me estaba incluyendo un módulo y que yo no quería usaba, por ejemplo, esta técnica que le decían foto. ¿Cuántos lo han usado? ¿Nadie? Ok, básicamente FOT es fokofendai. Ahí lo que le estamos diciendo desde el archivo.info es busqueme este archivo en este folder. Como el archivo no existe y básicamente no hay un request, no lo van a llamar y no lo incluye. Entonces, el primer archivo es de el módulo de display suite y para no tener que estar sobre escribiendo todo lo que venía de ese archivo, simplemente mataba el llamado de ese archivo. Cuando empiezo a trabajar con SAS, básicamente la sección de mi CSS queda en una línea y el FOT lo movía Magic. Magic, si alguno fue a la charla anterior de Iancar Rico, es una pequeña intro de Magic y Magic es un módulo bastante interesante en la parte de foment. Una de las funcionalidades de Magic es que podemos indicarle cuáles archivos de CSS no queremos cargar. Ok, esto es básicamente un pantallazo de lo que es myscreen.scss Como vieron en el slide anterior yo solamente cargo un archivo pero toda la lógica de dividir en pequeños pedazos mis CSS lo puedo hacer por medio de parciales. Entonces en un parcial simplemente cargo lo que son variables, mixings en otro, lo relacionado con páginas, lo relacionado con patrones, con layout, con módulos etc. Y esto es como una radiografía de la estructura básica para uno de los proyectos Igual, solamente tengo un archivo que es el que se va a compilar que es el screen.scss los otros archivos que tienen una raya abajo antes se llaman parciales esos archivos si yo no los llamo no se van a compilar eso que significa que no van a generar código. Yo podría desgranar toda la estructura de mi sitio en diferentes parciales y si no los llamo de un archivo que se va a compilar todo eso es código que no vamos a tener por ejemplo este es lo que yo tendría en uno de los archivos más pequeños que tengo que es parte del folder de patrones que simplemente es una regla relacionado con mixings si tuviera componentes mi componentes podrían estar formados por diferentes patrones cuál es la ventaja de tener parciales archivos tan pequeños piensen por ejemplo otra vez trabajando en equipo si tenemos un malmerch si tenemos un malmerch un archivo de este tamaño encontrar el error y solucionar el malmerch es sumamente sencillo ahora piensen en solucionar un malmerch en un archivo de 1000 líneas de CSS otra de verdad es como para matarse solo ok otro de los buenos puntos de los preprocesadores es que nos proveen abstracción pensar en objetos o abstracciones y desgranar esos componentes en piezas pequeñas debería ser como nuestra meta cuando empezamos a trabajar con un proyecto en una charla anterior que era sobre UX el speaker decía que la parte de scibuilding y teming no empieza en el momento en el que instalamos Drupal en un servidor de pruebas sino que empieza desde el mismo momento en el que hablamos con el cliente porque una vez que hacemos el primer contacto con el cliente levantando requerimientos podemos empezar a pensar como queremos estructurar el proyecto cuando hemos trabajado o cuando yo he trabajado en equipos en los que me ha tocado hacer scibuilding y teming normalmente uno levanta un documento y empieza a decir ok para este tipo de contenido vamos a tener estos campos y va a estar estructurado de esta manera una vez con eso listo empezamos que a limpiar el hpml muchos muchas veces nos quejamos de Drupal y de su markup y de su cds hinchado de que tan sucio es etc etc etc pero si no hacemos nada para limpiar eso y ese problema siempre cuando yo trabajo con estos equipos normalmente lo que hacemos es tomar un tiempo una vez que hemos planeado y ya sabemos como saber cada tipo de contenido como van a hacer las vistas como van a hacer los bloques ahora si empezamos a usar las mismas funcionalidades de Drupal para que para limpiar ese markup ya vuse3 con Drupal7 todos los que han trabajado con Drupal7 tenemos opciones que nos permiten elegir para un campo que markup queremos o si queremos ponerle una clase tenemos módulos como bloc class que nos permite ponerle a cada bloque una clase específica tenemos módulos como display suite que son super poderosos porque es importante pensar entonces en objetos sin abstracciones bueno porque son reutilizables y lo que le decía de vuse en este caso eso es un pequeño ejemplo de un objeto o sea mi objeto va a tener una clase que se llama promo box y adentro de promo box yo tengo un título que es un h3 es una manera bastante sencilla de darle estilos por ejemplo a un título pero que pasa si resulta que en cierta sección del sitio no van a hacer h3 sino que van a hacer h4 una solución super sencilla sería hacer esto agrupar otra vez selectores pero seguimos amarrados al markup que pasa si va a ser un h5 o si va a ser un p o si va a ser uno de los expand defaults de Drupal nuestro bloque de selectores se va a hacer gigante como uno de los primeros ejemplos que vimos una de las opciones sencilla sería por ejemplo ponerle un class y ahora si el titular puede ser cualquier elemento que es lo único que tendría que hacer ponerle a ese titular o a ese elemento el class un ejemplo más esto también es super común y el primer selector es una de las cosas que tenemos que evitar ahí estamos sobre calificando selectores estamos diciéndole para poder utilizar esta clase solamente va a funcionar con elementos ul que pasa si pasa a ser un ol ya mis reglas no van a servir esto lo estaríamos mejorando un poco ya no estaría amarrado el primer selector al markup pero sigue siendo un poco tallado o amarrado al markup vamos el selector key o el selector que estamos en tu target es un li que pasa otra vez si no queremos que sea un li el primer caso sería una buena solución podríamos igual tener un class y le aplicamos ese class a los elementos que queramos o del todo dejarlo como un elemento solo ¿por qué? porque puede ser que lo vayamos a usar en diferentes partes vean que el ejemplo número de eso es un p y en el ejemplo 3 es un div el primer ejemplo muchas veces esto se ve como una mala práctica empezar a ponerle clases a todo y a eso normalmente le hemos llamado divitis y lo que yo he aprendido a golpes y leyendo y viendo es que hay que tener mucho cuidado con los dogmas durante mucho tiempo le hemos tenido la divitis pero si algo como lo que vimos en el slide pasado nos funciona y sirve para el proyecto y sirve para el equipo no hay una razón para descartarlo y solamente importante sentido común ¿verdad? si lo utilizamos patrones hacerlo una vez y que esos patrones sean reutilizables por ejemplo podríamos tener para proyectos como de tipo multisite podríamos tener un tema base y en ese tema base tener n cantidad de patrones cada uno en su parcial y solamente crear estructuras sin estilos por así decirlo relacionados con branding o como de skin y después en los temas hijos nada más tendríamos que agregar las partes relacionadas con el branding del sitio específico otro punto muy importante que tenemos que tener en cuenta es los equipos de trabajo ¿por qué? porque entre más gente esté trabajando vamos a tener más problemas es muy fácil para mí si estoy trabajando solo en un proyecto escoger qué preprocesor voy a utilizar escoger cómo voy a nombrar las clases, escoger cómo voy a organizar mis archivos es sumamente sencillo pero qué pasa si somos 10 o 20 personas que estamos trabajando es importante que nuestro equipo de trabajo todos tengamos un conocimiento similar y una manera es por medio de charlas o tech talks entre el equipo otro punto muy importante para disminuir ese problema de más gente tocando el código es buenas prácticas y por buenas prácticas me refiero por ejemplo a sintaxis a cómo vamos a darle formato a nuestro código cómo son las convenciones para nombrar etcétera cualquiera que haya entrado a Drupal puede ver que Drupal lleva ciertas convenciones si ustedes van a contribuir un tema un módulo tienen que seguir y cumplir con las convenciones con el código de estándar cosas tan sencillas como los espacios hay gente que para intentar usar dos espacios, cuatro espacios hay gente que usa tabs y es todo un debate alrededor de eso con algo tan insignificante pero cuando estamos trabajando en equipo cosas tan insignificantes son importantes ¿por qué? porque mi código debería poder ser interpretado por cualquiera de mis compañeros y yo debería de poder leer el código de mis compañeros de arriba abajo y por entender qué es lo que están haciendo esto es una regla y este bloque tiene por ejemplo está siguiendo una convención para nombrarse hay un espacio entre el selector y el bracket cada propiedad o cada declaración está en su propia línea si lo pueden ver está ordenado alfabéticamente y usa short hands para colores otra vez es bastante tonto poner un ejemplo como esto pero cuando estamos trabajando en proyectos grandes es todo marcar la diferencia de qué tan rápido o qué tan lento podemos hacer un cambio o podemos hacer un ajuste en el código y si ya tenemos definidos nuestro código de standards a nivel de equipo y estamos usando SAS gron tiene un task que se llama ssslind y básicamente nosotros podemos configurar qué opciones queremos que valide al momento de compilar cosas tan sencillas como vamos a usar doble code o single code cada propiedad va a estar en su propia línea si trabajamos en equipo otra vez y hacemos code reviews esto podría ser una herramienta muy útil para que cuando estamos compilando localmente poder validar las cosas básicas del código de standards del equipo y una vez que llega el código a code review nos podemos enfocar en las cosas importantes digamos en la lógica del código en la reutilización del código y no desviarnos con cosas como hey, cambia de dos a cuatro tabs la identación que hiciste o hey, recuerda que cada propiedad tiene que ir en su propia línea dentro de la misma línea algo importante que tenemos que tener dentro del equipo son los naming conventions este es un code que forma parte de la documentación interna del equipo en el que trabajo y es como el encabezado antes de entrar la descripción de cómo vamos a manejar los nombres de cada clase o de cada evento es Max, Ben y OOCCS cada uno de ellos tiene principios que nos pueden ayudar y facilitar el nombrar elementos nosotros seguimos OOCCS y básicamente los principios son cuatro claridad cada selector que nombramos tiene que ser sumamente claro tiene que ser semántico en el sentido de HTML cuando decíamos semántico es si voy a tener un bloque de texto y es un párrafo debería marcarlo con un p no con un div de ese lado lo que nos referimos con semántico es que ese selector o ese clas que estoy nombrando debería de representar algo y debería ser bastante sencillo de saber que es tiene que ser genérico porque debería de poderse ser reutilizado no solamente en el sitio en el que estamos trabajando sino prácticamente en cualquier sitio piensen en los clases de views si ustedes piensan mover su código CSS a otro proyecto en el que no tengan instalado views y no pueden reutilizar ningún componente y tiene que ser breve porque por performance y cada bit cuenta claro aquí hay que hacer señalar algo importante que nunca tenemos que modificar claridad por brevedad es mucho más importante ser claro que alguien más del equipo puede entender que usar nombres cortos estos son algunos ejemplos de cómo nombrar por ejemplo estos son clases que vienen siendo como modificadores por ejemplo el primero si estamos trabajando y no sé vamos a habilitar alguna funcionalidad para touch podemos usar una clase como es touch si tenemos algo que desde JavaScript le vamos a agregar una clase en elemento para poderlo ocultar se puede llamar isHiding y así sucesivamente un ejemplo podemos tener un tap y dentro de ese bloque dentro de ese objeto tap y select it aquí lo importante es que al momento del output lo que yo estoy declarando dentro de isHiding solamente va a afectar a cuando esté concatenado con un tap yo podría tener 20 clases y select it para diferentes objetos pero si los encapsulos de esta manera no se van a ver afectados unos con otros un ejemplo de un objeto este es mi objeto botón una clase sencilla cualquiera de mi equipo que lo vea se llama punto btn sabe que es un botón un par de clases padre e hijo hay una relación y eso lo podríamos simplificar mal eso no está mal pero lo podríamos simplificar podría funcionar de esta manera hacer más específicos el objeto product list tener sus propias reglas y en un bloque de reglas aparte tener lo relacionado con nuestro objeto product list Tom otra vez porque de esta manera podemos mantener la especificidad a un mismo nivel si yo hiciera algo como esto y por output b quisiera sobre escribir lo relacionado con item Tom tendría que elevar el nivel de especificidad de mi selector para poder sobre escribirlo hay que tener en cuenta también el contexto en el que estamos trabajando y recordar de que los cambios de estilos solamente deberían de afectar a elementos que cambien por página y no a objetos esto es muy común en Drupal en el body tenemos clases como cart o como cuando se ha logueado o cuando no y puede ser que en la página de cart yo quiero que la columna de cybar o la columna de my content tengan un diseño o ciertas reglas diferentes a lo que está en el resto del sitio es completamente válido que no es una buena idea hacer algo como esto si yo tengo mi objeto promo box aquí en el cybar quiero sobre escribirle el color de fondo por ejemplo porque aquí nos estamos amarrando a la estructura es más fácil realizar algo que se le llama subclassing que es básicamente a mi elemento agregarle una segunda clase en este caso lo que estamos haciendo es uso de la cascada la segunda clase promo box dark va a sobre escribir el color por cascada en este caso estamos amarrándonos a que la clase cybar exista si la clase cybar no existe no va a funcionar en este caso otra vez usando algo como el module class el blog class perdón podríamos agregar diferentes clases a nuestro blog y ya no importa si ese blog que está en el cybar o si está en el head las reglas van a aplicar siguiendo lo mismo de subclassing sas tiene una funcionalidad que se llama extend si ustedes vieron en el cyb anterior tengo que tener dos clases diferentes en este caso yo tengo dos bloques de clases pero mi elemento solamente va a recibir una clase porque en promo box dark yo estoy extendiendo lo que está en promo box el output de eso sería algo como esto extend agrupa tanto la clase base que en este caso es promo box como la clase promo box dark en la cual estamos extendiendo promo box exactamente la idea sería que ese blog que pueda estar en cualquier lado y no dependa del cybar algunos cuidados que hay que tener con el extend es algo como esto digamos de que los tres puntos entre la última clase entre el último blog y los demás es un archivo completamente aparte va a pasar esto promo rap promo box dark no existe si ustedes lo ven acá pero extend por la manera en que funciona hace un extend de todo lo que tenga que ver con promo box y eso es devolverse loco si usamos el extend de manera extendida a lo largo del codebase si por a o por b quisiéramos usar extend hay una alternativa que es mucho más limpia y mucho más sencilla de usar que se llama placeholder o silent class a diferencia de en el extend que lo que extendemos es una clase en este caso lo que usamos es un art person eh perdón un porcentaje y en el primer blog que ahí declararíamos todas las reglas que queremos que sean como generales y después para acá unos mismos botones voy a extender el placeholder que es la que tiene el porcentaje ok y dentro de cada uno de esos bloques únicamente agregaría cosas diferentes digamos para el positive no sé un background verde y para el negativo un background rojo y el output sería algo como esto es mucho más limpio que el extend y incluso este ejemplo tiene más sentido que el ejemplo del anterior por qué porque todos tienen una relación muchas veces queremos tener nombres únicos por alguna razón piensen por ejemplo cuando trabajamos con JavaScript y le ponemos un id a un elemento para que sirva como ánculo eh pero que pasa si ese selector que queremos utilizar para JavaScript se va a repetir en más de un en más de un elemento una solución para eso sirve de utilizar prefijos en este ejemplo tengo dentro de mi clase tengo tres clases pero tengo diferentes prefijos tengo uno con el prefijo UI uno con el prefijo JS y uno con el prefijo QA al interno del equipo nosotros lo que utilizamos es QA para las pruebas de Selenium entonces esos son los selectores que utilizan si ocupa un hook para JavaScript utilizamos el selector con el prefijo JS y si el elemento con el que estoy trabajando ocupa los estilos únicamente utilizaría el clases que tenga el prefijo UI esto para qué nos sirve si en algún momento se necesita hacer un cambio en ese elemento nosotros sabemos qué podemos borrar o qué no podemos borrar si un widget se va a sacar del codebase simplemente se busca los elementos que tengan estas clases y se pueden eliminar sin ningún problema y uno sabe de qué no vas a matar o qué no vas a echar a aprender digamos ningún otro parcial o que ningún otro objeto ningún otro componente se va a ver afectado qué es importante de todo esto hay que tener una convención tenemos que tener la documentada y es importante y lo más difícil de eso es adherirse a esa convención un par de lecturas recomendadas sobre nombrar cosas punto número 3 entonces documentar internamente nosotros usamos una herramienta que se llama conference hay gente que lo pone abierto como los de copen y es como su código de estándar pero lo que yo he visto que funciona más son los comentarios porque ya sea que lo tengamos en nuestro sitio web toda la información o que tengamos una herramienta en internet como conference es muy fácil que se desactualice porque mes a mes pueden cambiar alguna información y si no lo modificamos la gente no va a llegar y no va a saber en cambio si trabajamos directamente con comentarios en nuestro código es sumamente sencillo es sumamente rápido y siempre lo tendremos a mano estos son comentarios default o estándar para CSS y por ejemplo a mí me ha gustado mucho tener como una tabla de contenidos al inicio y nombrar cada una de las secciones en las que tengo reglas relacionadas y después en el momento en el que yo voy a crear los bloques para esa sección tengo un título de sección y es el mismo nombre que la tabla de contenidos arriba pero aprendí que si uno le pondría un carácter que no tenemos en el CSS o que no vamos a utilizar como en este caso el igual si yo voy a hacer una búsqueda o control f igual reset o igual r y me brinca de una vez ahí es como bastante simple pero tengo un amigo que dice que los mejores developers son los más vagos o sea que nos gusta todo como fácil y rápido títulos específicos con comentarios específicos para un bloque si ocupamos sobre escribir algo si tenemos una regla en la que estamos tratándole un importan podemos tener una descripción de por qué estamos usando importan o por qué esa regla o ese bloque está en algún lugar en el que debería estar ya estos son con comentarios de sintaxis para SaaS en mi parcial de mixing puedo tener un mixing y tener una breve descripción de lo que hace ese mixing con un ejemplo de cómo llamar el mixing si tuviera parámetros podría decir que hay cuáles son los parámetros y cómo los paso como en este caso y eso es documentación que día a día podríamos si hay un cambio para sacar simplemente se borra si metemos un mixing se mete directamente en el parcial se pone el comentario como funciona un ejemplo y nuestra documentación siempre está al día tomando los puntos anteriores podemos ver que CSS no es el problema y no siempre es el problema muchas veces el problema es que trabajamos con muchas personas y hay falta de conocimiento entre los diferentes miembros del equipo entre los diferentes miembros del equipo usamos diferentes técnicas o usamos un approach diferente para escribir CSS ahí radica el problema ahora sí, aterrizando todo lo que hemos venido hablando es importante el pragmatismo sobre la perfección tener un good enough, hoy es mucho mejor que tener algo perfecto mañana ya sea que empecemos a trabajar con alguna de las metologías que mencioné antes que usemos preprocesadores o no es importante repensar cómo estamos trabajando y preparar nuestro codebase para los cambios y para el futuro el libro, el código del equipo debe ser un libro que cualquiera puede leer no un diario personal que solamente yo entiendo o que solamente alguien más entiende porque es muy frecuente que el que sabía cómo funcionaban las funciones del codebase lo despidieron o se fue y ahora cómo hacemos para modificar digamos un mixing si no entendemos cómo funcionan las funciones escribamos menos CSS entre más abstrigamos nuestro código y lo simplifiquemos vamos a tener menos partes movibles y esto nos da la ventaja de que podemos reducir las fallas ¿por qué? porque cada parte movible es una falla potencial entonces cada vez que podamos reducir features o código eso es bienvenido y la modularidad en CSS no es realmente la meta mantenibilidad es la meta CSS es modular pero es difícil de mantener entonces no estamos logrando lo que queremos ¿por qué? porque otra vez el objetivo es que en el futuro que dentro de un mes o dentro de un año cuando estemos trabajando en este mismo proyecto darle mantenibilidad o escalar el proyecto tiene que ser sencillo o sea nos podemos pensar solamente en hoy y en usar por ejemplo las últimas funcionalidades de SaaS o de lezo o lo que sea y olvidarnos de la parte importante y muchas gracias eso es lo que les traigo los slides van a estar en esta dirección otra vez que han invitados al Drupal Cam y pueden evaluar la sesión cuando tengan preguntas un poco era ver si nos puedes dar una sugerencia cómo organizar la parte de responsive si partes en componentes le partirías por los breakpoints que tiene o dentro del componente en el caso que tengas que utilizar media queries especialmente vamos a ver una de las cosas de las funcionalidades que tiene SaaS es que podemos anidar dentro de un mismo bloque media queries normalmente con CSS normal o con CSS de vainilla escribíamos como todas las reglas y después abríamos como la parte de media queries y adentro de esa sección sobre escribíamos o ampliábamos las reglas SaaS o les nos permiten extender esas funcionalidades, usar variables para manejar los breakpoints y anidar dentro de un mismo selector en donde entre un mismo bloque lo que sea relacionado con ese objeto normalmente yo no manejaría digamos en un archivo aparte lo relacionado con responsive porque se puede volver un poco complicado al momento de darle mantenibilidad o hacer un cambio porque tendrías que ir a otro archivo a hacer el cambio y yo tengo un bloque y ese bloque es el header dentro de las reglas de mi header y dentro de mi archivo no sé header.scss ahí escribiría lo relacionado ya sea para responsive o no responsive igual ya a hoy 2015 hay que dejar de pensar como en responsive ya eso debe ser parte de nuestro flujo hay gente que todavía quiere cobrar extra diciendo que quiere que su sitio sea responsive ya pasó ya jugó hace cuatro años y era como válido ahora los breakpoints es como la parte más fácil de un proyecto responsive hay cosas más complicadas y más complejas por las que aún no le pagan realmente que definir o no un breakpoint bueno mi pregunta es acerca de las herramientas y como las usas y mi experiencia por ejemplo ha sido de que yo no soy Drupath Zimmer no soy front end developer pero más bien soy backend developer entonces yo hago las cosas digamos que trato de hacerlo todo en el CSS o en el iOS en ningún lugar más pero por ejemplo si utilizamos esa técnica de CSS o SaaS y hago un cambio en algunos de los módulos o en algunos de los parciales el problema para mi representaría que si hago ese cambio yo no lo puedo ver automáticamente hasta que yo recompile todos los demás parciales entonces hay alguna forma alguna herramienta en la cual si hago un cambio en algún elemento digamos que rápidamente vamos a ver si tenés algo como si tenés algo como esto y digamos de que vos haces un cambio en en las variables variables es un parcial si o sea ya por default cuando vos corres SaaS para que compile tiene una funcionalidad que se llama watch donde él ve o detecta un cambio en en variables automáticamente corre el compilador y por default si ya tenés un archivo como el screen donde estoy importando todos mis parciales el homólogo que sería screen.css va a tener el cambio que si vos crees que sea todavía más rápido puedes utilizar una herramienta como Live Reload o sea vos instalas Live Reload y en el momento en el que él detecta un cambio o sea en la página que tengas abierta en el que estés trabajando se va a refrescar saludos una pregunta yo trabajo con SaaS pero trabajo en ambiente de desarrollo cómo lo haces trabajas con SaaS también en producción o si no lo haces en producción trabajas css duro cuando tienes que hacer algún cambio y pues te olvidas de sitio en desarrollo pues ya si haces un cambio en css arriba vas a estar un poco no vas a estar sincronizado los sitios de desarrollo en producción como lo haces en ese caso que recomiendas o se utilizan producción o solamente en desarrollo listo respuesta corta local digamos en ambiente de desarrollo o sea me parece demasiado peligroso estar siendo cambio directamente en producción es una mala práctica en algún momento en algún momento de todos lo hemos hecho es como normal a golpes a uno aprende que no hay que hacerlo pero lo mejor es trabajar local ya sea que trabajes solo trabajas en equipo trabajar local tienes toda tu configuración local tienes SaaS local compilando local y una vez que tengas todo listo únicamente subís a tu servidor de producción el archivo compilado o sea yo no haría un cambio en producción digamos ya hoy con todo lo malo que me ha pasado yo no haría un cambio directo en producción o sea por más pequeño que sea trataría de hacerlo local otra vez compila preguntas quejas todo bien ok gracias por venir