CSS moderno: escribe un código mejor, más limpio y escalable

1. Introducción: Al igual que mucha gente, me metí completamente a la web por accidente. Pensé que iba a ser una diseñadora gráfica de mal culo durante muchos años, y me sentí mucho más enamorada del desarrollo de lo que nunca lo hice con el diseño. Oye, soy Harry, soy desarrollador web consultor e ingeniero de rendimiento del Reino Unido. hace seis años, he estado hablando en muchos eventos. Una gran parte de eso es CSS de TI o CSS de triángulo invertido, y eso es de lo que vamos a estar aprendiendo hoy. El CSS de TI es una metodología, una forma de pensar en CSS. Te ayudará a crecer y escalar proyectos en un periodo de tiempo muy largo. El Triángulo Invertido es una visión general muy diagramática de todo un proyecto CSS. La razón por la que tenemos un triángulo es porque cada uno de los tres lados representa uno de los inquilinos centrales del Triángulo Invertido CSS. Independientemente de si estás usando SaaS, o LaaS, o Vanilla CSS, o Host CSS o incluso una solución CSS en JS, IT CSS te entrenará exactamente donde debes poner cada componente diferente desde la línea cero hasta la línea 15,000 de tu proyecto. Entonces las primeras lecciones de este curso, tal vez bastante teóricas, un montón de diagramas, un montón de cosas de dibujo, y realmente poniendo nuestra cabeza torno a cómo funciona el CSS de TI, teóricamente. Una vez que hayamos cubierto todas esas cosas, nos sumergimos en una base de código y buscaremos ejemplos de cómo CSS de TI se une en el sistema de archivos como una línea de código. La buena noticia es que no necesitas ser ya un experto en CSS para empezar a usar CSS de TI. Si tienes una simple comprensión de los fundamentos de CSS, puedes empezar a usar CSS de TI en proyectos de inmediato. Estoy Increíblemente emocionado de empezar a enseñarte todo sobre TI CSS. Entonces, empecemos. 2. Los problemas con CSS: Para entender plenamente el ITCSS, es importante que nos fijemos en los temas que estamos tratando de resolver. CSS es un lenguaje desarrollado hace más de 20 años. Todavía estamos usando para construir aplicaciones malas en la actualidad. Eso no es un problema en sí mismo, pero algunos de los temas que impiden a escala, son cosas que necesitamos abordar. Por ejemplo, el hecho de que todo funcione globalmente, significa que cualquier regla podría heredar potencialmente de una diferente o pasar sus estilos a otra cosa. Esto necesita manejarlo con mucho cuidado. El CSS también depende increíblemente del orden de la fuente. Por lo general lo que se escribe último es lo que se va a aplicar. Esto significa que tenemos que estar para mantener muy de cerca el orden en el que estructuramos y construimos nuestra base de código. No obstante, sumar a eso el hecho de que tengamos especificidad. Podemos invertir completamente esa lógica de todos modos y selectores con mayor especificidad que otros, pueden anular las cosas de formas algo inesperadas. Podemos todos estos posibles trampas. Necesitamos diseñar un sistema de gestión de CSS, que realmente pueda formalizar y especie de estructurar estas características de una manera que funcione para nosotros más que en contra de nosotros. No obstante, sería completamente inadecuado e injusto culpar todo a CSS. El hecho de que CSS haya resistido la prueba del tiempo por más de dos décadas, demuestra que potencialmente hay algo que nosotros como desarrolladores nos estamos equivocando también. Los desarrolladores tienen muchos estilos de codificación diferentes. Un desarrollador podría escribir código que funcione exactamente igual que otra persona, pero se ve muy diferente. mejor, nosotros para manejar esto. Entonces, tenemos una forma unificada de trabajar a través de un equipo. Los desarrolladores también son famosamente malos en la redacción de documentación. No creo que alguna vez haya trabajado en un proyecto que tuviera justo la cantidad correcta. ¿ Y si pudiéramos hacer nuestra documentación de código? Si podemos empezar a trabajar con una metodología compartida, quizá podamos construir proyecto sin necesidad de resmas y resmas de documentación. Enorme tema que presentan los equipos en lugar de los individuos, es que CSS es probablemente el único lenguaje que cada miembro de un equipo de desarrollo va a escribir. Nunca he escrito una línea de Node.js. No escribo ningún MySQL. Pero cada persona con la que he trabajado ha escrito al menos algo de CSS. Esta diversidad y habilidades todas contribuyendo a un solo idioma significa que, no podemos garantizar que todos sepan tanto como la siguiente persona. Si pudiéramos diseñar una metodología que aleje el estrés y el dolor de eso, podríamos conseguir que los no expertos aporten CSS de manera no perjudicial. Tomando todo eso en consideración y siendo simpáticos con cómo trabajan los equipos y teniendo presente la forma en que funciona CSS, lo que necesitamos es un marco y una forma de trabajar que ayude a resolver estos problemas. Ese marco es ITCSS. Vamos a bucear en. 3. CSS sin ITCSS: Entonces, lo que empezará con es visualizarlo de una manera muy diagramática, cómo podría ser un proyecto heredado o no ITCSS existente, y dónde ocurren los problemas en hojas de estilo que no están utilizando una metodología formalizada como el ITCSS. Entonces, imagina si quieres, que este rectángulo aquí mismo representa todo un proyecto CSS existente. Este es un archivo CSS. Ahora esto podría ser un archivo CSS real de un solo archivo monolítico, o podría ser el resultado de compilar muchos archivos SaaS diferentes en un archivo grande. Cómo lleguemos a este punto no es realmente importante ahora mismo. Imagínese que este es todo su proyecto CSS, y para hacer las cosas un poco más fáciles de entender, digamos que tenemos la línea cero, hasta la línea 3,000. Digamos que es un bonito proyecto pequeño. Ahora tradicionalmente, la forma en que normalmente escribiríamos CSS, es que miraríamos el diseño que estamos a punto de construir e identificaríamos las primeras características. Podríamos mirar el diseño y ver bien, necesitamos usar un restablecimiento CSS. Entonces, puse mi reset CSS en algún lugar cerca del principio porque eso se siente tener sentido. Entonces, empezamos por poner algunos andamios, tal vez algún tipo de framework llenando CSS hacia el principio, luego buscar más en el diseño y decidir eso bien, lo primero en un archivo de photoshop o el archivo esbozado es un encabezado. Entonces, pongo mi encabezado CSS aquí. Ahora, estamos construyendo hojas de estilo alrededor de un lenguaje visual aquí. La estructura de un diseño. Esta es una forma muy común de escribir CSS, y en su mayor parte, sobre todo en proyectos pequeños, esto suele funcionar. A medida que un proyecto empieza a crecer, comenzaremos a golpear problemas. Lo que estamos haciendo aquí es que estamos escribiendo CSS en un orden muy, muy humano. Esta es la forma en que un humano mira al CSS. No obstante, el problema que tenemos es que a un navegador no le importa si el encabezado es lo primero en un archivo de photoshop o no. Todo lo que le importa a un navegador es qué especificidad podría tener un selector, qué tan largo podría ser ese selector, qué podría heredar de ese selector. Entonces, si empezamos a escribir nuestro CSS de una manera estructurada muy humana, pronto nos encontraremos con problemas, donde quizás el primer bit de CSS funcione bien, y escribimos otro poco de CSS y esto funciona bien. Escribimos un tercer bit de CSS otra vez, sin encontrar ningún problema. De repente, podríamos escribir un cuarto bit de CSS pero por alguna razón queda anulado por este CSS aquí. Esto podría ser causado por las paredes de especificidad, esto podría ser causado por selectores peleándose entre sí por una prominencia, podría ser causado por cualquier número de cosas, pero sin considerar plenamente nuestra arquitectura CSS escribiendo CSS en lo que yo consideraría de una manera muy humana. Bueno, realmente no muy simpático para ayudar a CSS realmente funciona o cómo el navegador agradecería recibir ese CSS. Entonces ahora tenemos un problema. Tenemos un problema aquí donde queríamos arreglar algo. Podríamos refactorizar este bit de CSS ordenarlo y eliminar el problema pero eso no es típicamente lo que haría un desarrollador. Podríamos tener limitaciones de tiempo, tenemos plazos, pero lo que era más probable que hiciéramos es simplemente hackear algo para arreglarlo. Entonces, podríamos terminar metiendo un importante aquí abajo, haciendo algo bastante desagradable. Una vez que hayamos resuelto ese problema, seguimos adelante. Siguiente bit de CSS sucede que funciona bien. Siguiente bit de CSS funciona bien. Siguiente bit de CSS se ve invadido por esto, y luego este bit aquí anula este bit aquí. Entonces, tenemos un problema más arriba de la pila. En un proyecto grande, casi puedo garantizar que cada desarrollador se ha topado con una situación como esta y esta frustración corta la productividad de forma masiva. Mucho del tiempo se pasa pintándote a ti mismo en una esquina, y luego tratando de luchar contra ella, y normalmente el problema sólo se pone peor. A menos que dediques una gran cantidad de tiempo a refactorizar el CSS, vas a seguir por este camino, y durante un periodo de semanas, meses, tal vez incluso años, el problema se pondrá tan malo que necesitarás volver a empezar por completo. Sigamos. Escribe algo más CSS. Esto está bien, esto está bien que anula esto, eso es una multa, multa, que se anula, se anula aquí. Esta naturaleza consistente o constantemente errática, este tipo de ineficiencia es muy frecuente entre los grandes proyectos, y es así como los proyectos CSS comienzan a salir de control. Entonces, después de un tiempo suficiente en este proyecto ha madurado, encontramos que tenemos todas estas ineficiencias ocurriendo con bastante frecuencia. Por lo general, identificarás estas frustraciones de primera mano, ya que estás trabajando en un proyecto, notarás que estamos recibiendo estos problemas. Notarás que tal vez una característica de seis meses de antigüedad, está anulando una característica que realmente escribes hoy mismo. Otra buena manera, una forma fácil de identificar estos en el navegador, es en chromes inspector. Cuando haces clic derecho e inspeccionas elemento, si ves mucho CSS con líneas ahí, muchos tachados, esto representa una tremenda ineficiencia. Esto representa CSS que se escribió en algún momento, se guardó en disco, se compiló en una hoja de estilo, se envió a un servidor web, última instancia se envió a un usuario, envió a su navegador, y nunca se utilizó. Es en eficiencias donde constantemente estamos anulando CSS que se escribió muchos meses antes. Ahora bien, si este diagrama de aquí representa la Fase uno de un proyecto CSS, tal vez sea la compilación inicial de un proyecto, la serie inicial de características para un proyecto. Los problemas empeoran aún cuando comenzamos a agregar nuevas características distintas o nuevas fases distintas. Entonces, si esto representa la Fase uno, típicamente, el lugar donde pondríamos la Fase dos de un proyecto CSS es desafortunadamente, tendemos a pernos en el extremo. Es así como generalmente el CSS tiende a funcionar. Simplemente atornillamos las cosas al final. Fase tres, pegarse al final de ese todavía. Por lo que el problema se agrava donde no sólo está el código dentro de cada fase luchando contra sí mismo, podríamos terminar con fases enteras del proyecto peleándose entre sí también. Ahora si miras, hemos terminado con este raro fenómeno donde nuestro CSS es una especie de puesta a la fase uno en la parte superior, Fase dos, Fase tres, y esto me recuerda mirar el registro fósil. ¿ Verdad? Tienes algo de CSS cretáceo aquí, algo de CSS jurásico aquí. No hay absolutamente ninguna razón para poder rebanar tu CSS y leerlo cronológicamente. No hay razón para que su proyecto CSS refleje su hoja de ruta de producto. Pero la mayoría de las veces, si no tenemos una forma estructurada de trabajar, eso es exactamente lo que pasa. No debería poder averiguar que en esta fecha publicaste esta función puramente de mirar una hoja de estilo. Al usar CSS de TI, podemos tomar todos estos problemas y reimaginar una estructura en la que esto desaparece. Estos problemas que estamos presenciando aquí, esto podría haber rayado a través de este jumpier muy errático alrededor de la naturaleza que nos metemos dentro del proyecto CSS, pueden ser causados por una serie de cosas. Especificidad mal administrada. Entonces, el uso de selectores que son demasiado pesados, podría ser causado por dibujar las cosas en un orden ineficiente o en un orden poco práctico, o podría ser causado por diseñar cosas o escribir código que tome demasiadas posiciones y opinionadas demasiado temprano. Triángulo invertido CSS tiene como objetivo tomar a todos esos tres inquilinos centrales y formalizarlos formando cada lado del triángulo. 4. Guerras de especificidad: Entonces, echemos un vistazo a lo que realmente comprende el Triángulo. Mencionamos brevemente la especificidad. especificidad es la ponderación inherente de un selector, su prominente, su capacidad para anular otros selectores disímiles. especificidad es una de las cosas más difíciles de manejar en un proyecto CSS a escala. Una de las primeras reglas clave a la hora de escribir CSS para proyecto grande es, siempre evitar el uso del selector id. Si quieres saber más sobre por qué hemos prohibido el selector de id en CSS, consulta los recursos. Entonces, la especificidad es un enorme, enorme problema al escribir CSS a escala. Con el fin de ayudar a los equipos de desarrollo a visualizar la especificidad de todo su proyecto, me ocurrió un concepto de un Gráfico de Especificidad. Lo que hará el Gráfico de Especificidad es, tomar el diagrama anterior, [inaudible] toda la hoja de estilo, y trazar la especificidad de sus selectores. Se trata de un simple gráfico de líneas. Trazamos la especificidad de un selector. En el eje X, trazamos el número de línea en la que aparece ese selector. Ahora, comenzando con un proyecto existente, quizás comenzamos con el selector de estrellas. El selector de estrellas lleva un valor de especificidad de cero. Entonces, en la línea uno a la línea 3,000, podríamos empezar con un selector con valor de especificidad de cero. En un proyecto existente o heredado, las posibilidades son muy altas de que en realidad no hayamos manejado correctamente nuestra especificidad. Esto podría llevar a un Graph de Especificidad que se vea algo así. mejor empezamos con un selector de estrellas, tal vez algunos selectores de elementos, alguien usó un ID, tal vez algunas clases entre aquí, y clase anidada. Lo que veremos a medida que pasemos es, trazamos los diferentes tipos de selector y sus especificidades relativas en una gráfica que podría terminar luciendo algo así. Es importante señalar en este punto que se trata de un modelo puramente teórico. Esto no es una Gráfica de Especificidad real de un proyecto real. Si quieres ver un verdadero Gráfico de Especificidad, nuevo, consulta los recursos. Hay herramientas disponibles que tomarán una hoja de estilo de entrada y te construirán un gráfico preciso. Por ahora, sin embargo, sólo ven esto como un modelo mental para ayudar a visualizar el problema de la especificidad mal administrada. Un proyecto existente o heredado, sin que su especificidad se maneje adecuadamente, puede tener una gráfica que se vea así. Como se puede ver, hay muy poca consistencia. Ahora bien, el problema no está necesariamente aquí, con altas especificidades. El problema existe cuando queremos aportar código en un área de baja especificidad. Si queremos hacer algunas ediciones o algunas adiciones o agregar una nueva característica a esta parte en particular de la base de código, tenemos la preocupación de que tal vez este selector aquí podría anularnos sin darse cuenta. Si ese es el caso, puede que tengamos que introducir algo aquí como un selector importante o anidado o algún otro tipo de hackeo para aumentar artificialmente la especificidad de este selector para anular ese. Esto a su vez nos trae otro problema porque ¿y si esta parte de la base de código aquí necesita ahora anular esta? Nos quedamos atrapados en esta calle de un solo sentido, donde no podemos simplemente salir bajo fianza en ningún momento, no podemos simplemente optar por este modelo. Estamos en lo que se conoce como las Guerras de Especificidad, donde tenemos que seguir luchando por el mismo camino exacto, empeorando progresivamente el resto del proyecto. Esto es lo que típicamente llamamos un mal Gráfico de Especificidad. Entonces, en un proyecto de la vida real, el tipo de forma gráfica que estamos buscando es constantemente tendencia al alza. Es decir, queremos que la especificidad a lo largo de todo el proyecto aumente gradualmente a medida que pasemos de la línea uno al final del proyecto, en nuestro caso, un proyecto relativamente pequeño de apenas 3 mil líneas. Si vamos a visualizar eso, se vería un poco así. A Specificity Graph que constantemente tiende hacia arriba tiene el beneficio inmediato de que cualquier cosa definida posteriormente en el proyecto anulará automáticamente cualquier cosa definida previamente, sólo en virtud de su ubicación. El resultado práctico de esto es que una característica definida, por ejemplo, aquí mismo, debe anular automáticamente cualquier cosa definida previamente en virtud de dónde vive. Se puede decir lo mismo de una característica añadida, por ejemplo, aquí. Esto comienza de inmediato a eliminar el problema de las características antiguas o existentes o incluso heredadas que anulan el trabajo nuevo. Ahora que hemos llegado a la forma de la Gráfica de Especificidad teórica, sana , buena, podemos empezar a modernizar esto en algo más tangible y algo más viable. Podemos empezar a tomar rodajas de esta base de código teórica y comenzar a crear directorios en el sistema de archivos que albergarán nuestros diferentes tipos de CSS. El primer corte o capa en nuestro Triángulo Invertido está dedicado a reset-type bastante genérico de estilos, cosas como normalize.css o tu reset CSS, cualquier tipo de box-sizing global, cosa que esté muy ampliamente disponible al proyecto pero tiene una especificidad muy, muy baja. Este directorio albergará este tipo de código y se nombra genérico. Normalmente, encontraríamos que la capa genérica sería idéntica en casi cualquier proyecto en el que trabajes. Probablemente usaste exactamente el mismo normalize.css en diferentes proyectos. Probablemente usaste exactamente el mismo reset.css en diferentes proyectos. Esto significa que esta capa es muy copiosa y pasteable y se puede desplegar en muchos proyectos o productos diferentes. Después de la capa genérica, comenzamos a aumentar nuestra especificidad. Entramos a lo que se conoce como la capa de elementos. El capa de elementos, predeciblemente, contiene cualquier CSS dedicado al estilo de elementos HTML. Por ejemplo, ¿qué aspecto tiene un elemento sin una clase en él? ¿ Cómo sería un elemento h1 sin una clase en él? Hemos aumentado ligeramente la especificidad, y hemos empezado a cambiar la función del CSS para empezar a agregar algunos estilos de diseño. Pero sigue siendo una especificidad muy baja y capa bastante amplia. Una buena regla general a la hora de pensar en la capa de elementos es imaginar cómo sería tu sitio si no tuviera clases o identificadores en cualquier parte de HTML. ¿ Cómo haría el CSS un simple aspecto h1 y párrafo? ¿ Cómo hace CSS que un enlace simple se vea una lista desordenada? Más allá de la capa de elementos, entramos en lo que se conoce como la capa de objetos. El capa de objetos es la primera capa en la que se nos permite introducir especificidad de nivel de clase. Entonces, mientras que la capa genérica comienza con algo tan baja especificidad como el selector de estrellas, la capa de elementos trata solo con selectores de elementos HTML. Se permite que la capa de objetos comience a tratar con la especificidad de nivel de clase. En CSS, un objeto es un patrón de diseño estructural. Viene de una escuela de pensamiento llamada CSS Orientada a Objetos, que fue desarrollada por Nicole Sullivan. CSS orientado a objetos podría ser un curso de Skillshare en sí mismo, así que por favor refiérase a los recursos para un aprendizaje extra. Pero por ahora, todo lo que necesitas saber es la capa de objetos es la primera capa que introduce la especificidad de nivel de clase, y trata de patrones de diseño estructural. Estas son cosas como sistemas de cuadrícula. A la siguiente capa que encontramos en Triángulo Invertido se le conoce como la capa de componentes. Para mí, la capa de componentes es, con mucho, la más importante. El nivel de componentes es lo que contiene la mayoría de lo que conoceríamos como la página web. Los componentes son cosas como botones o elementos de navegación o carruseles. El capa de componentes contiene lo que el usuario vería e interactuaría con. Se debe pensar en las capas precedentes como muy arquitectónicas. Estas son las cosas de las que es muy poco probable que el usuario sepa. Al usuario realmente no le importa si usas normalize.css, al usuario no le importa qué sistema de cuadrícula utilices. En las tres capas anteriores se encuentran donde manejamos la mayoría de los problemas arquitectónicos, y la capa de componentes es donde comenzamos a lograr la encapsulación. El nivel de componentes estaría hecho de archivos individuales que controlarían quizás un carrusel o un desplegable o un botón. Proporcionalmente, la capa de componentes constituye la mayor parte del proyecto porque la mayoría de su sitio web serían componentes. Esto es sinónimo de razonar que harías la mayoría de los cambios y adiciones a tu proyecto en esta parte de la base de código. Muy importante, por lo tanto, encapsamos muy bien el código aquí. El final de las capas ITCSS predeterminadas se conoce como la capa de utilidades. Ahora, lo que notarás aquí es este enorme pico hacia el final. Eso se debe a que la capa de utilidades está reservada para todo el desagradable CSS del que realmente no quieres hablar. El nivel de utilidades es donde podrías soltar cosas como hacks o tus hojas de estilo IE7. Aquí, también puedes salirte con la tuya usando importante. Ahora bien, si damos un paso atrás y miramos esta gráfica terminada, podemos comenzar a ver una salida más tangible y significativa. Podemos ver que a medida que avanzamos de la línea uno hacia la línea 3,000 de nuestro proyecto, la especificidad de nuestro CSS sólo aumenta nunca. A medida que pasamos por ese aumento de especificidad, comenzamos a sacar rebanadas verticales del proyecto y categorizar nuestro CSS en torno a ciertas funciones. 5. Las tres caras del ITCSS: Ahora, probablemente estés empezando a preguntarte cómo hemos logrado llegar tan lejos y ni siquiera hemos visto un triángulo todavía. Bueno, vamos a ver exactamente dónde encaja esto. Acabamos de aprender sobre los gráficos de especificidad y bastante detalle, el triángulo inverter trabaja en tres principios básicos y el más importante de esos es la especificidad. Ahora, este diagrama representa una vez más la totalidad de su proyecto CSS si ese es un solo archivo CSS o si ese fue el resultado de muchos archivos SAS compilados en una hoja de estilo resultante, este triángulo representa todo eso poner juntos. Entonces, nuevamente, iniciamos la línea cero y avanzamos hacia abajo a una línea 3,000. Cada borde del triángulo representa uno de los tres principios básicos. El primero siendo la especificidad. especificidad siempre aumentará a medida que avanzamos por el proyecto de la línea cero hacia la línea 3,000. Nuestra especificidad sólo debe aumentar nunca. El segundo principio básico que sustenta el ITCSS es un principio llamado explícito. explícito mira la idea de lo obstinado que podría ser una pieza de diseño. Por ejemplo, si solo un botón en todo el sitio web necesita tener un fondo rojo, no aplicarías ese fondo rojo a cada elemento A, esperarías hasta más adelante en el proyecto para identificar ese botón y aplicarlo allí. Muchas de las razones por las que el proyecto CSS empieza a salir mal y empieza a desmoronarse, es porque la gente tiene una tendencia a diseñar demasiado temprano y luego tienen que gastar el resto de su proyecto deshaciendo eso. explícito obliga a cierta moderación y hace que los desarrolladores solo opten por cambios de diseño adicionales a medida que se requieren. El tercer y último principio rector básico detrás ITCSS forma el último lado del triángulo y de hecho reúne todo, ese principio se conoce como el alcance. Ahora bien, mientras que la especificidad y la explicitación aumentan tanto a medida que pasamos por el proyecto, alcance en realidad disminuirá. Alcanzar tratos con cuánto de la página o el componente o de hecho todo el sitio web un selector específico es capaz de afectar. Un selector de muy lejos alcance, es como si el selector de estrellas pudiera afectar a todo el DOM. También tiene una especificidad muy baja. Por el contrario, una sola clase solo puede afectar a un solo nodo DOM a la vez, el nodo DOM al que está adjunto, y las clases también tienen una especificidad mucho mayor. El alcance disminuye a medida que bajamos por el triángulo y es lo que hace un triángulo en absoluto. Sin alcance, sería la plaza invertida, que supongo es sólo una plaza y las plazas no venden talleres. Reach reúne todo el triángulo y disminuye la cantidad de la página o componente de un DOM que podemos tocar en cualquier momento dado. Entonces, como es mi intención, todo esto es de muy alto nivel. Lo que voy a hacer es garabatear rápidamente un ejemplo selectores junto al triángulo para mostrarte qué tipo de código podrías esperar encontrar dónde. Ya mencioné es el selector de estrellas, que lleva un valor de especificidad de exactamente cero. El selector de estrellas puede afectar a cada nodo DOM en una página, vaca es de especificidad muy baja, y por lo tanto también debe ser muy explícito. No querrías aplicar bola de peso de fuente al selector de estrellas. Progresando aún más, tal vez encontremos un selector de elementos A. El elemento A tiene una especificidad mayor que un selector de estrellas y por lo tanto sólo puede afectar un poco menos del DOM, sólo se puede dar estilo a cada elemento de anclaje. Progresando más, obtuvimos un estilo de diseño más explícito, tal vez no le peinemos un botón. Entonces, un botón es una explícita cada vez mayor. Un aumento en la explicitalidad conlleva un aumento natural especificidad porque tendríamos que usar un selector como.button. Lo que tiendes a encontrar es que la especificidad y la explicitación son relativamente igualitarias. Cualquier cosa con una especificidad de esto tendría una explícita correspondiente. No querrías aplicar el estilo de diseño de un botón explícito contra la especificidad del selector de estrellas, lo cual sería muy perjudicial. Imaginemos por un segundo que tenemos un tipo específico de botón, tal vez un botón en el que un usuario no pueda hacer clic porque no han ingresado una dirección de correo electrónico correcta. Tendríamos que conseguir otro selector para eso. Ahora, nuestro estilo de diseño se ha vuelto más explícito porque no es solo un botón, es una especie de botón que no se puede usar. Este aumento de la explicitación puede necesitar traer un aumento en la especificidad. Entonces, podríamos tener un selector como. desactivado, que denota un elemento que no se puede utilizar. Tomando nuestra especificidad y explícito, naturalmente llegamos al alcance de ese selector. La clase de desactivación sólo se aplicaría al botón uno está deshabilitado en un momento dado, por lo tanto su alcance es muy pequeño. Si vamos a mirar el elemento A, que podría ser arriba de 100 enlaces en una página, esto significa que está usando A selector, que tiene una especificidad relativamente baja, también significa que debido a que podría haber 100 enlaces en una página, no podemos darles un estilo de diseño excesivamente obstinado y debido a que podría haber más de 100 enlaces en una página, el alcance de ese botón es en realidad muy alto. Es así como las tres métricas clave, los tres principios básicos se juegan entre sí. Normalmente, lo que encontrarás es que si obedeces dos de los tres principios, obtienes el tercero elaborado de forma gratuita. Siempre que necesites agregar código a un proyecto, pregúntate: “¿Qué tan explícito u obstinado es el estilo de diseño?” Si se trata de un estilo de diseño bastante obstinado, necesitarías un selector equivalentemente opinionado que, por lo tanto, traerá una en especificidad. En virtud de tener un estilo de diseño bastante explícito y una alta especificidad, fácilmente vas a conseguir que los ricos trabajen para ti. Para ampliar brevemente el alcance y lo que eso significa para la forma de nuestro proyecto, reimaginemos rápidamente el triángulo como forma de cono real en lugar de un triángulo plano. Esta forma de embudo ahora representa cómo los selectores a medida que avanzó de la línea cero a línea 3,000 de su proyecto afectan cada vez menos del DOM a la vez. Entonces ahora, lo que tu hallazgo es cada capa es responsable peinar cada vez menos de la página a medida que avanzas. La primera capa se dirige a casi todo, y progresivamente menos, y menos, y menos antes de llegar al fondo del triángulo o ahora, supongo que el cono invertido, y tu afectando con precisión precisa nodos DOM únicos a la vez. Una analogía útil para todo este flujo de trabajo es si se imaginara a un escultor haciendo una estatua. Un escultor puede acercarse a una cantera y pedir un gran bloque de mármol. Ahora bien, lo que haría la cantera es quizá sacar ese trozo de mármol por el lado de la cara de la roca, y llevarlo al molino de piedra, y el molino de piedra tomará ese gran trozo de roca, y lo convertirá en un bonito cubo viable. Entonces, el alcance para llevar ese pedacito de roca al estudio, y conseguiría un martillo grande y un gran cincel, y más o menos hacía la forma de una persona. Después de que hayan hecho eso, obtendrán un martillo más pequeño y un cincel más pequeño, y comenzarán a poner detalles como dedos. Lo que sería una forma muy inusual de trabajar es si ese esculpt acaba de tomar un gran bloque de mármol más o menos puedo haberme disparado mi rockface y la moda sólo el dedo perfecto que sobresale de la parte superior de la misma. Lo que trato de hacer aquí es exactamente lo mismo con CSS, cortar trazos amplios al principio en un proyecto para cubrir tal vez el 50 por ciento del levantamiento pesado. Entonces, el siguiente bit cubre el siguiente 10 por ciento y luego el cinco por ciento hasta que obtenemos estos bits de trabajo más pequeños y más pequeños que apuntan a cada vez menos nodos DOM. Trabajar de esta manera nos permite mantenernos enfocados, y mantener las cosas bien gestionadas a medida que avanzamos cada vez más en el proyecto. Entonces, simplemente miramos muchos diagramas justo ahí, no miramos una sola línea de código. Pasemos ahora a la computadora. Vea cómo esta cosa se une en un proyecto, en el sistema de archivos real usando CSS real. 6. ITCSS en la práctica: Entonces, acabamos de pasar un montón de tiempo ahí mirando diagramas muy conceptuales. No miramos ni una sola línea de código. Entonces, lo que quiero hacer ahora es sumergirme en un proyecto de ejemplo que he construido. El proyecto ejemplo se llama Discover. Es un tipo de sitio web de viajes simulado y tiene un gran repositorio al que tienes acceso completo, así que asegúrate de revisar los recursos para eso. También está alojado en la URL de LINE, por lo que puedes ver exactamente lo que estamos construyendo. Pero echemos un vistazo, este es un pequeño tipo de proyecto compuesto que se construye usando ITCSS. Lo primero que quiero mostrarte es cómo se ve esto en el sistema de archivos, cómo se ve esto en realidad en Finder. Ahora bien, es un proyecto muy pequeño porque fue inventado puramente por ejemplo sake, así que no vas a ver nada complejo como cualquier tipo de tarea o uno tiene alguna construcción de ductos, nada por el estilo. Aquí, podemos empezar a ver los ingredientes del triángulo invertido. Lo primero que notarás es que tenemos un archivo main.scss, este es nuestro único punto de entrada. Entonces, este único archivo es responsable de importar todos los demás aspectos del proyecto CSS en su respectivo orden según el triángulo invertido. A continuación, verá que cada una de las capas del triángulo tiene un directorio correspondiente. Ahora bien, esto es completamente opcional. Una de las cosas clave del ITCSS es que sí deja muchas de estas decisiones en manos del desarrollador. Solía tener una configuración donde no tenía un directorio para cada tipo de archivo CSS. Acabo de tener una estructura de directorio plana pero me di cuenta que después de un tiempo eso se pone realmente difícil de manejar, así que paso hacia una estructura más como esta, en la que podemos ver que cada tipo de selector CSS, cada tipo de capa en un triángulo sí tiene su propio directorio correspondiente. He agrupado todos los archivos para cada capa en ese directorio que lleva el nombre de mí pero lo que también hago es ponerle nombre a cada uno de mis archivos capa.file.scss. Entonces, aquí, verás elements.headings.css. Aquí, podríamos ver objetos.layout.scss. Tener el nombre de la capa dentro del nombre del archivo hace que sea muy fácil entender en qué parte estoy trabajando el proyecto en un momento dado. Pero de nuevo, esto se reduce completamente a la preferencia de los desarrolladores. Además de agrupar cada tipo de archivo en su directorio correspondiente, también me gusta nombrar cada archivo después de la capa a la que pertenece. Entonces, lo que puedes ver aquí es components.avatar.scss o en este archivo o es carpeta aquí mismo, tenemos objetos.layout.scss. El motivo por el que me gusta hacer esto, es que es agradable ver solo por el nombre del archivo, qué parte del proyecto estoy trabajando. Si tengo objects.layout.scss abiertos en mi editor de texto, sé exactamente a qué parte del proyecto estoy contribuyendo. Ahora, echemos un vistazo a nuestro main.scss. Este es el principal punto de entrada. Este es el único archivo fuente que cierra todo el resto del proyecto y es este archivo fuente el que produce main.scss más adelante. Buscando main.scss en mi editor de textos, lo primero que notarás es esta tabla de contenidos. Nuevamente, esto es completamente opcional, esto es preferencia de desarrollador. Pero me gusta mantener una tabla de contenidos bastante manual en la parte superior de mi punto de entrada principal. Lo que esto me permite hacer es apuntar en términos humanos exactamente lo que está contenido en el proyecto. Lo que a menudo encuentras es a medida que los proyectos se hacen más grandes y envejecen, mucha gente se desconoce qué tipo de CSS existe dentro de este directorio CSS. No saben qué características ya existen, qué ya se construyó y demás. bien se mantiene esta tabla de contenidos más bien manual pero muy humana legible, los desarrolladores siempre se hacen conscientes de lo que están a su disposición. Pasando de una tabla de contenidos, comenzaremos a ver mis directivas @import. Entonces, lo que verán aquí es mi importación para las capas de configuración y herramientas. Estos son puramente pre-proceso de capas. Esto contiene configuraciones globales para mi proyecto como escalas tipográficas o paletas de colores. El nivel de herramientas contiene cosas que hacer con cualquier mezcla o función que el proyecto pudiera requerir. Permítanme pasar a las capas que vimos anteriormente. Estas son cosas que dibujamos en nuestros diagramas. Si notaste el tamaño relativo de cada capa, puedes empezar a entender de dónde proviene la mayor parte del proyecto. Por ejemplo aquí, la capa genérica es bastante pequeña. Realmente no tenemos mucho aquí, tenemos nuestro tamaño global de caja, algunos normalizan y restablecen tipo de estilos y algunos estilos compartidos también. Pero echemos un vistazo a la capa de elementos. Podemos ver que aquí tenemos unos cuantos archivos más, empezando a hacerse un poco más grandes. Aquí es donde estamos firmando cosas como encabezamientos, enlaces y listas. Estos son los elementos html que conforman nuestra página. Más allá de esto, nos movemos a nuestra capa de objetos. El capa de objetos es la primera capa en la que se nos permite introducir clases. Esto de nuevo es un poco más grande que la capa de elementos pero cuando avanzamos a la capa de componentes, vemos que las cosas son mucho, mucho más grandes. El capa de componentes constituye la mayor parte de cualquier proyecto dado. La mayoría de tu página web estará basada en componentes, ITCSS apoya esto al crear una parte completa del proyecto para todas estas cosas en vivo. Lo que verás es nombres consistentes, componentes.logo, componentes.cabezal. Es en estos archivos donde encontramos la mayoría de nuestra UI. Por último, nos movemos hacia nuestra capa de utilidades y es en este punto importamos cualquier tipo de archivos de depuración o cualquier utilidades y especie de clases de ayudante. Es en este punto que podemos traer fijadores IE 7 específicos o diferentes fijadores para diferentes navegadores. capa de utilidades está reservada para CSS que no es del todo perfecto. Su reservado para CSS que es bastante alta especificidad, muchas veces incluso conteniendo importancia. Esto lo veremos con más detalle en breve. Al mirar este archivo, esperemos ver que incluso un proyecto bastante grande puede ser destilado en trozos muy manejables. Podemos ver rápidamente qué vive exactamente dónde y por qué. Esto significa que buscar CSS existente se vuelve trivial y significa agregar nuevo CSS debe volverse bastante simple y sencillo. Al mirar los patrones que han dejado un desarrollador anterior, podemos retomar donde lo dejaron y crear una base de código mucho más consistente. Como puedes ver en el archivo actual que estamos viendo, tiene todo el estándar ITCSS relacionado en la actualidad. Pero ciertos proyectos podrían requerir diferentes capas o la eliminación de ciertas capas. El ITCSS nos deja esto completamente a nosotros. Entonces, esa fue una mirada muy rápida de cómo el triángulo puede unirse en un paquete SAS importado. Por supuesto, dependiendo de tu proyecto, tu circunstancia, tu proceso de construcción, tu ducto de construcción, los detalles bien pueden diferir y la belleza del ITCSS es que depende enteramente de ti cómo modificas este flujo de trabajo. Lo que quiero mostrarles a continuación, sin embargo, es el archivo SCC resultante. Todos los diagramas que dibujamos anteriormente eran de la línea 0-3,000, es lo que usamos, se representaron hojas de estilo compilar completas. Echemos un vistazo a cómo resulta eso. Ahora, veamos cómo todo esto se une una vez que se ha compilado en una gran hoja de estilo. De inmediato aquí, vamos a que tengamos una tabla de contenidos familiar, que arrastrada desde nuestro punto de entrada principal, nuestro archivo main.scss. Si batimos más allá de eso, vamos a empezar a ver algún SCSS natural. Ahora, recuerden, los tres principios básicos del triángulo, baja especificidad hacia alta especificidad, manera inexplícita hacia el alcance explícito y amplio hasta el estrecho alcance. Entonces, de inmediato podemos ver aquí especificidad muy baja. Tienes un selector de estrellas, tenemos el selector de elementos html, estos son selectores de especificidad muy baja que lanzan una red muy amplia. El selector de estrellas captura literalmente todo en el DOM. Entonces, a medida que avanzamos por esto, y lo voy a hacer relativamente rápido, lo que debes ver es la gráfica de especificidad que se forma ante tus ojos. medida que avanzamos a través de selectores de elementos de baja especificidad, continuación deberíamos empezar a ver algunos selectores de clase apareciendo cuando llegamos hacia los objetos. Aquí, tenemos 0-layout, así que tenemos ese golpe de especificidad inmediato en nuestra capa de objetos, la primera capa en la que se nos permite ver clases. Lo que notarás aquí es que estas clases se proceden con un o-. Ahora bien, esta es una convención de nomenclatura opcional que viene con ITCSS. Progresando desde aquí, encontramos más clases, por lo que no obtenemos un aumento en la especificidad pero sí conseguimos un cambio de propósito. Aquí tenemos a c- que denota nuestras clases de componentes. Los componentes son los bits que componen la mayoría de la IU y aquí vemos que está usando un bamm como convención de nomenclatura. A medida que avanzamos más allá de las clases de componentes, vamos a empezar a encontrar clases de especificidad muy, muy altas. Aquí es donde llegamos a nuestra capa de utilidades. La capa de utilidades es un caso especial. Está reservado para cualquier tipo de CSS que no nos emociona particularmente. En grandes proyectos, está garantizado que va a suceder, que tendrás que aportar algo de CSS que no es todo como te gustaría. Ahora bien, eso no es ideal. Por supuesto, no es ideal pero probablemente va a suceder, ha pasado en cada proyecto en el que he trabajado alguna vez. Entonces, lo que es bastante importante es tener un lugar dedicado para estos bits de CSS que viven nuestra capa de utilidades se convierte en un catchall, un cajón misceláneo que captura todo el CSS que no encaja del todo en ningún otro lugar. Dejarlo hacia el final significa que no corre el riesgo de establecer el tono para el resto del proyecto. No quieres llamar a tu hacky CSS al principio de tu hoja de estilo porque hacerlo significaría que el resto de la hoja de estilo tiene que pelear a su alrededor. Dibujamos todo esto justo al final, por lo que de inmediato puede anular cualquier cosa que venía previamente con una sobrecarga muy mínima. Conforme avanzamos justo hasta el final de la hoja de estilo, encontraremos que ahí es donde terminan las cosas. Terminamos en una especificidad muy alta con algunas clases de casos de uso único muy, muy dirigidas. Estas son clases de utilidad que están diseñadas para sobrescribir cualquier cosa que venía previamente con un mínimo esfuerzo. Ahora, te instaría a ir absolutamente a cavar alrededor este repositorio porque a medida que empiezas a separarlo, pronto encontrarás que todas las cosas que hemos discutido se sientan inmediatamente en su lugar, encontrarás que las cosas tienen mucho más sentido. Te encontrarás capaz de navegar por la base de códigos muy rápidamente en base a las cosas conceptuales que aprendimos antes. Ahora, claro, eso fue sólo una manifestación, por el bien de la demostración. Fue una demo muy pequeña, muy autónoma. No es necesariamente tan realista de una gran especie de bestia de un proyecto. Entonces, lo que encontrarás es que a medida que implementas el ITCSS en el mundo real, los beneficios se harán mucho más evidentes, incluso en este ejemplo recortado ojalá aprendamos que al seguir los tres principios básicos del ITCSS, podemos empezar a dar cosas lugares dedicados para vivir y lugares dedicados para ser encontrados. Lo que esto significa es, si algún desarrollador que haga paracaídas en un proyecto puede localizarse fácilmente y navegar fácilmente por la base de código que potencialmente nunca habían visto antes. 7. Reflexiones finales: Entonces, ahí lo tenemos, una introducción a la arquitectura CSS del Triángulo Invertido. Aprendimos cómo CSS, cuando se deja a sus propios dispositivos, puede volverse rápidamente ingobernable y difícil de manejar. Pero entonces también aprendimos que con mucha diligencia y cierta formalidad, podemos escribir fácilmente esas cosas de vuelta y ayudarlas a trabajar a nuestro favor. Por encima de todo, lo que realmente quiero que la gente le quite a esto es el hecho de que el ITCSS no es un sistema complejo, no requiere cambios drásticos de proceso o forma. Además de eso, es un toque muy ligero. Entonces, puedes modificar el ITCSS para que se adapte a tu pila de tecnología, habilidades en tu equipo, el tamaño de tu proyecto, incluso el tipo de proyecto que estás trabajando. A nivel más técnico, creo que mi clave para llevar para ti sería, i'ts realmente realmente importante manejar cosas como la especificidad muy bien, porque esta suele ser la forma técnica en la que los proyectos empiezan a espiral el más rápido. Entonces, ¿qué sigue? Bueno, lo primero que podrías hacer es unirte a la discusión. Si tienes alguna pregunta, alguna inquietud, algún ejemplo, o descargas que te gustaría discutir o salir al aire libre, absolutamente vas y haces eso. Yo mantendré un ojo ahí y contestaré cualquier pregunta que pueda tener. Por supuesto, mantener un ojo en las secciones de recursos, un montón de enlaces a los diferentes materiales de lectura y mantener un ojo en eso. Hay un montón de cosas que mirar. Entonces, eso fue todo. Muchas gracias por pasar el rato. Tengo muchas ganas de ver cómo tomas el ITCSS, moldea en tu propio proyecto y en tu propio trabajo, y supongo que te veré la próxima vez.