CSS Moderno: escrevendo um código melhor, mais limpo e escalável

1. Introdução: Como muitas pessoas, eu entrei na web completamente por acidente. Eu pensei que seria um designer gráfico ruim por muitos anos, e eu me senti muito mais apaixonado pelo desenvolvimento do que eu nunca fiz com o design. Ei, eu sou Harry, eu sou um desenvolvedor web consultor e engenheiro de desempenho do Reino Unido. Nos últimos seis anos, tenho falado em muitos eventos. Uma grande parte disso é CSS de TI ou CSS de triângulo invertido, e é sobre isso que vamos aprender hoje. IT CSS é uma metodologia, uma maneira de pensar sobre CSS. Ele irá ajudá-lo a crescer e dimensionar projetos ao longo de um longo período de tempo. O Triângulo Invertido é uma visão geral muito diagramática de um projeto CSS inteiro. A razão pela qual temos um triângulo é porque cada um dos três lados representam um dos principais inquilinos do CSS Triângulo Invertido. Independentemente de você estar usando SaaS, ou LaaS, ou Vanilla CSS, ou Host CSS ou até mesmo um CSS na solução JS, IT CSS irá treiná-lo exatamente onde você deve colocar cada componente diferente da linha zero para a linha 15.000 do seu projeto. Então, as primeiras lições deste curso, talvez bastante teóricas, muitos diagramas, muitas coisas de desenho, e realmente colocar nossa cabeça em torno de como o CSS de TI funciona, teoricamente. Uma vez que tenhamos abordado tudo isso, vamos mergulhar diretamente em uma base de código e ver exemplos de como CSS de TI se junta no sistema de arquivos como uma linha de código. A boa notícia é que você não precisa ser um especialista em CSS já para começar a usar CSS de TI. Se você tem uma compreensão simples dos fundamentos do CSS, você pode começar a usar o CSS de TI em projetos imediatamente. Estou incrivelmente animado para começar a ensinar-lhe tudo sobre CSS de TI. Então vamos começar. 2. Os problemas com CSS: Para entender completamente o ITCSS, é importante que olhemos para os problemas que estamos tentando resolver. CSS é uma linguagem desenvolvida há mais de 20 anos. Ainda estamos usando para criar aplicativos ruins hoje. Isso não é um problema por si só, mas algumas das questões que impedem em escala, são coisas que precisamos resolver. Por exemplo, o fato de tudo funcionar globalmente, significa que qualquer regra pode potencialmente herdar de uma diferente ou passar seus estilos para outra coisa. Isso precisa ser gerenciado com muito cuidado. CSS também é incrivelmente dependente da ordem de origem. geral, o que está escrito por último é o que será aplicado. Isso significa que precisamos estar de olho muito atento na ordem em que estruturamos e construímos nossa base de código. No entanto, acrescente a isso o fato de que temos especificidade. Podemos inverter completamente essa lógica de qualquer maneira e seletores com uma especificidade maior do que outros, podem substituir as coisas de maneiras um tanto inesperadas. Podemos todas essas armadilhas em potencial. Precisamos projetar um sistema de gerenciamento de CSS, que possa formalizar e estruturar essas características de uma forma que funcione para nós e não contra nós. No entanto, seria completamente impróprio e injusto culpar tudo no CSS. O fato de que CSS tem resistido ao teste do tempo por mais de duas décadas, mostra que potencialmente há algo que nós, como desenvolvedores, estamos errando também. Os desenvolvedores têm muitos estilos de codificação diferentes. Um desenvolvedor pode escrever código que funciona exatamente da mesma forma que outra pessoa, mas parece muito diferente. Talvez, nós para lidar com isso. Então, temos uma maneira unificada de trabalhar em uma equipe. Desenvolvedores também são famosamente ruins em escrever documentação. Acho que nunca trabalhei em um projeto que tivesse a quantidade certa. E se pudéssemos fazer a documentação do nosso código? Se pudermos começar a trabalhar com uma metodologia compartilhada, talvez possamos construir projeto sem precisar de resmas e resmas de documentação. Enorme problema que as equipes em vez de indivíduos presentes, é que CSS é provavelmente a única linguagem que cada membro de uma equipe de desenvolvimento irá escrever. Eu nunca escrevi uma linha de Node.js. Eu não escrevo nenhum MySQL. Mas cada pessoa com quem já trabalhei escreveu pelo menos alguns CSS. Esta diversidade e habilidades que contribuem para uma língua significa que, não podemos garantir que todos saibam tanto quanto a próxima pessoa. Se pudéssemos projetar uma metodologia que afaste o estresse e a dor disso, poderíamos obter não-especialistas contribuindo com CSS de forma não prejudicial. Levando tudo isso em consideração e sendo solidários com a como as equipes trabalham e tendo em conta a forma como o CSS funciona, o que precisamos é de uma estrutura e uma maneira de trabalhar que ajude a resolver esses problemas. Esse quadro é o ITCSS. Vamos mergulhar. 3. CSS sem ITCSS: Então, o que vai começar com é visualizá-lo de uma forma muito diagramática, um projeto legado existente ou não ITCSS pode parecer, e onde os problemas ocorrem em folhas de estilo que não estão usando uma metodologia formalizada como ITCSS. Então, imagine se você quiser, que este retângulo aqui representa um projeto CSS inteiro existente. Este é um arquivo CSS. Agora este pode ser um arquivo CSS real de um único arquivo monolítico, ou pode ser o resultado de compilar muitos arquivos SaaS diferentes em um arquivo grande. Como chegamos a este ponto não é importante agora. Imagine que este é todo o seu projeto CSS, e para tornar as coisas um pouco mais fáceis de entender, digamos que temos a linha zero, até a linha 3.000. Digamos que é um projeto pequeno e agradável. Agora, tradicionalmente, a maneira que normalmente escreveríamos CSS, é olharmos para o design que estamos prestes a construir e identificaríamos os primeiros recursos. Podemos olhar para o design e ver bem, precisamos usar um CSS reset. Então, eu coloquei meu CSS reset em algum lugar perto do início porque isso parece fazer sentido. Então, começamos colocando alguns andaimes, talvez algum tipo de quadro preenchendo CSS para o início, e então olhar mais para o design e decidir que bem, a primeira coisa em um arquivo de photoshop ou o arquivo esboçado é um cabeçalho. Então, eu coloquei meu cabeçalho CSS aqui. Agora, estamos construindo folhas de estilo em torno de uma linguagem visual aqui. A estrutura de um projeto. Esta é uma maneira muito comum de escrever CSS, e na maior parte, especialmente em pequenos projetos, isso geralmente funcionará. À medida que um projeto começa a crescer, vamos começar a bater problemas. O que estamos fazendo aqui é escrever CSS em uma ordem muito, muito humana. Esta é a maneira como um humano olha para o CSS. No entanto, o problema que temos é que um navegador não se importa se o cabeçalho é a primeira coisa em um arquivo de photoshop ou não. Tudo o que um navegador se preocupa é o que especificidade um seletor pode ter, quão longe esse seletor pode ser, o que pode herdar desse seletor. Então, se começarmos a escrever nosso CSS de uma forma estruturada muito humana, logo teremos problemas, onde talvez o primeiro pedaço de CSS funcione bem, e escrevemos outro pedaço de CSS e isso funciona muito bem. Escrevemos um terceiro pedaço de CSS novamente, sem encontrar nenhum problema. De repente, podemos escrever um quarto pedaço de CSS mas por algum motivo é substituído por este CSS aqui. Isso pode ser causado pelas paredes de especificidade, isso pode ser causado por seletores lutando entre si até uma proeminência, poderia ser causado por qualquer número de coisas, mas sem considerar totalmente nossa arquitetura CSS escrevendo CSS no que eu consideraria uma forma muito humana. Bem, não realmente muito simpático para ajudar CSS realmente funciona ou como o navegador gostaria de receber esse CSS. Então agora temos um problema. Temos um problema aqui em que queríamos consertar algo. Poderíamos refatorar esse pedaço de CSS arrumá-lo e remover o problema, mas isso não é normalmente o que um desenvolvedor faria. Podemos ter restrições de tempo, temos prazos, mas o que é mais provável é hackear algo para corrigi-lo. Então, podemos acabar enfiando um importante aqui em baixo, fazendo algo muito desagradável. Assim que resolvermos esse problema, seguimos em frente. próximo pedaço de CSS acontece a funcionar muito bem. Próximo pedaço de CSS funciona muito bem. Próximo bit de CSS é invadido por isso, e então este bit aqui substitui este bit aqui. Então, temos um problema mais acima da pilha. Em um grande projeto, quase posso garantir que todos os desenvolvedores se depararam com uma situação como essa e essa frustração reduz a produtividade massivamente. Muito do tempo é gasto pintando-se em um canto, e depois tentando lutar contra isso, e geralmente o problema só piora. A menos que você dedique uma grande quantidade de tempo para refatorar o CSS, você vai continuar por esse caminho, e durante um período de semanas, meses , talvez até anos, o problema ficará tão ruim que você precisará começar completamente de novo. Vamos continuar. Escreva mais CSS. Isso é bom, isso é bom que substitui isso, isso é uma multa, multa, que é substituída, é substituída aqui. Esta natureza consistente ou constantemente errática, esse tipo de ineficiência é muito prevalente entre grandes projetos, e é assim que os projetos CSS começam a sair do controle. Então, depois de um tempo suficiente neste projeto amadureceu, descobrimos que temos todas essas ineficiências acontecendo com bastante frequência. Normalmente, você identificará essas frustrações em primeira mão, pois você está trabalhando em um projeto, você notará que estamos tendo esses problemas. Você vai notar que talvez um recurso de seis meses de idade, está substituindo um recurso que você realmente escreve agora mesmo. Outra boa maneira, uma maneira fácil de identificar estes no navegador, é em chromes inspector. Quando você faz clique direito e inspecionar elemento, se você vê um monte de CSS com linhas lá, um monte de tachados, isso representa tremenda ineficiência. Isso representa CSS que foi escrito em algum momento, salvo em disco, compilado em uma folha de estilo, enviado para um servidor web , enviado para um usuário, enviado para seu navegador, e nunca foi usado. É em eficiências onde estamos constantemente substituindo CSS que foi escrito muitos meses antes. Agora, se este diagrama aqui representa a primeira fase de um projeto CSS, talvez seja a construção inicial de um projeto, a série inicial de recursos para um projeto. Os problemas pioram ainda mais quando começamos a adicionar novos recursos distintos ou novas fases distintas. Então, se isso representa a Fase um, tipicamente, o lugar onde colocaríamos a Fase dois de um projeto CSS é, infelizmente, tendemos a aparafusar no final. É assim que o CSS geralmente tende a funcionar. Acabamos de sacar as coisas no final. Fase três, fique no final disso ainda. Assim, o problema é agravado onde não só o código dentro de cada fase está lutando contra si mesmo, podemos acabar com fases inteiras do projeto lutando entre si também. Agora, se olharem, acabámos com este fenómeno estranho que o nosso CSS é meio que colocado na fase um no topo, Fase 2, Fase 3, e isto lembra-me de olhar para o registo fóssil. Certo? Você tem alguns CSS cretáceos aqui, alguns CSS jurássico aqui. há absolutamente nenhuma razão para eu ser capaz cortar o seu CSS e lê-lo cronologicamente. Não há nenhuma razão pela qual seu projeto CSS deve espelhar seu roteiro de produto. Mas na maioria das vezes, se não temos uma forma estruturada de trabalhar, é exatamente o que acontece. Eu não deveria ser capaz de descobrir que nesta data você lançou este recurso puramente de olhar para uma folha de estilo. Usando CSS de TI, podemos pegar todos esses problemas e reimaginar uma estrutura na qual isso desaparece. Estes problemas que estamos testemunhando aqui, isso poderia ter atravessado este salto muito errático em torno da natureza que temos dentro do projeto CSS, pode ser causado por uma série de coisas. Especificidade mal gerida. Então, o uso de seletores que são muito pesados, ele pode ser causado por desenhar coisas em uma ordem ineficiente ou uma ordem impraticável, ou pode ser causado por projetar coisas ou escrever código que leva muito e posições opinativas Muito cedo. triângulo invertido CSS visa tomar todos esses três inquilinos principais e formalizá-los formando cada lado do triângulo. 4. Guerras de especificidade: Então, vamos dar uma olhada no que o Triângulo realmente compreende. Mencionamos brevemente especificidade. Especificidade é a ponderação inerente de um seletor, seu proeminente, sua capacidade de substituir outros seletores diferentes. Especificidade é uma das coisas mais difíceis de gerenciar em um projeto CSS em escala. Uma das primeiras regras importantes ao escrever CSS para grande projeto é, sempre evitar o uso do seletor de id. Se você quiser saber mais sobre por que banimos o seletor de id em CSS, consulte os recursos. Então, a especificidade é um enorme problema ao escrever CSS em escala. A fim de ajudar as equipes de desenvolvimento a visualizar a especificidade de todo o seu projeto, eu criei um conceito de um Gráfico de Especificidade. O que o Gráfico de Especificidade fará é pegar o diagrama anterior, [inaudível] toda a folha de estilo e traçar a especificidade de seus seletores. É um gráfico de linhas simples. Nós traçamos a especificidade de um seletor. No eixo X, plotamos o número da linha em que esse seletor aparece. Agora, começando com um projeto existente, talvez comecemos com o seletor de estrelas. O seletor de estrela carrega um valor de especificidade de zero. Então, na linha um para a linha 3.000, podemos começar com um seletor com valor de especificidade zero. Em um projeto existente ou legado, as chances são muito altas de não termos gerenciado nossa especificidade corretamente. Isso pode levar a um Gráfico de Especificidade que se parece com isso. Talvez comecemos com um seletor de estrelas, talvez alguns seletores de elementos, alguém usou um ID, talvez algumas classes entre aqui, e classe aninhada. O que veremos à medida que passamos é, traçamos os diferentes tipos de seletor e suas especificidades relativas em um gráfico que poderia acabar parecendo algo assim. É importante notar que este é um modelo puramente teórico. Este não é um gráfico de especificidade real de um projeto real. Se você quiser ver um verdadeiro Gráfico de Especificidade , consulte novamente os recursos. Existem ferramentas disponíveis que vão levar uma folha de estilo de entrada e construir um gráfico preciso. Por enquanto, no entanto, basta ver isso como um modelo mental para ajudar a visualizar o problema da especificidade mal gerenciada. Um projeto existente ou legado, sem sua especificidade adequadamente gerenciada, pode ter um gráfico parecido com este. Como você pode ver, há muito pouca consistência. Agora, o problema não está necessariamente aqui, com altas especificidades. O problema existe quando queremos contribuir com código em uma área de baixa especificidade. Se quisermos fazer algumas edições ou algumas adições ou adicionar um novo recurso a esta parte específica da base de código, temos a preocupação de que talvez este seletor aqui possa inadvertidamente nos substituir. Se for esse o caso, talvez tenhamos que introduzir algo aqui como um seletor importante ou aninhado ou algum outro tipo de hack para aumentar artificialmente a especificidade deste seletor para substituir aquele. Isso, por sua vez, nos traz outro problema, porque e se essa parte da base de código aqui precisar substituir essa? Ficamos presos nesta rua de mão única, onde não podemos fugir a qualquer momento, não podemos simplesmente optar por sair deste modelo. Estamos no que são conhecidas como as Guerras de Especificidade, onde temos que continuar lutando pelo mesmo caminho, tornando o resto do projeto progressivamente pior. Isto é o que normalmente chamamos de um gráfico de especificidade ruim. Então, em um projeto da vida real, o tipo de forma de gráfico que estamos procurando é constantemente tendência para cima. Ou seja, queremos que a especificidade em todo o projeto aumente gradualmente à medida que passamos da linha um ao final do projeto, no nosso caso, um projeto relativamente pequeno de apenas 3.000 linhas. Se quisermos visualizar isso, seria um pouco assim. Um Gráfico de Especificidade que tende constantemente para cima tem o benefício imediato do fato que qualquer coisa definida posteriormente no projeto substituirá automaticamente qualquer coisa definida anteriormente, apenas em virtude de sua localização. O resultado prático disso é que um recurso definido, por exemplo, aqui, deve substituir automaticamente qualquer coisa definida anteriormente em virtude de onde ele vive. O mesmo pode ser dito de um recurso adicionado, por exemplo, aqui. Isso imediatamente começa a remover o problema de recursos antigos ou existentes ou mesmo legados que substituem o novo trabalho. Agora que chegamos à forma do gráfico de especificidade teórico, saudável e bom, podemos começar a adaptar isso em algo mais tangível e mais viável. Podemos começar a tirar fatias desta base de código teórica e começar a criar diretórios no sistema de arquivos que irá abrigar nossos diferentes tipos de CSS. A primeira fatia ou camada em nosso Triângulo Invertido é dedicada ao tipo de reconfiguração bastante genérico de estilos, coisas como normalize.css ou seu CSS reset, qualquer tipo de caixa global, coisa que esteja muito disponível para o projeto mas tem uma especificidade muito, muito baixa. Este diretório irá abrigar este tipo de código e é nomeado genérico. Normalmente, descobrimos que a camada genérica seria idêntica em quase qualquer projeto em que você trabalha. Você provavelmente usou exatamente o mesmo normalize.css em diferentes projetos. Você provavelmente usou exatamente o mesmo reset.css em diferentes projetos. Isso significa que essa camada é muito copiada e pastável e pode ser implantada em vários projetos ou produtos diferentes. Após a camada genérica, começamos a aumentar nossa especificidade. Entramos no que é conhecido como a camada de elementos. A camada de elementos, previsivelmente, contém qualquer CSS dedicado ao estilo de elementos HTML. Por exemplo, o que um elemento parece sem uma classe nele? Como seria um elemento h1 sem uma classe sobre ele? Aumentamos ligeiramente a especificidade e começamos a mudar a função do CSS para começar a adicionar alguns estilos de design. Mas ainda é uma especificidade muito baixa e uma camada bastante ampla. Uma boa regra geral ao pensar sobre a camada de elementos é imaginar como seu site seria se ele não tivesse classes ou IDs em qualquer lugar em HTML qualquer. Como o CSS faria um simples h1 e parágrafo olhar? Como CSS faz um link simples uma lista não ordenada olhar? Além da camada de elementos, entramos no que é conhecido como a camada de objetos. A camada de objetos é a primeira camada em que estamos autorizados a introduzir especificidade de nível de classe. Assim, enquanto a camada genérica começa com algo tão baixa especificidade quanto o seletor de estrela, a camada de elementos lida apenas com seletores de elemento HTML. A camada de objetos é permitido começar a lidar com especificidade de nível de classe. Em CSS, um objeto é um padrão de design estrutural. Ele vem de uma escola de pensamento chamada CSS orientada a objetos, que foi desenvolvido por Nicole Sullivan. CSS orientado a objetos pode ser um curso de Skillshare em si, então consulte os recursos para aprendizagem extra. Mas por enquanto, tudo que você precisa saber é que a camada de objetos é a primeira camada que introduz a especificidade do nível de classe, e lida com padrões de design estrutural. São coisas como sistemas de grade. A próxima camada que encontramos no Triângulo Invertido é conhecida como a camada de componentes. Para mim, a camada de componentes é de longe a mais importante. A camada de componentes é a coisa que contém a maioria do que nós saberíamos como o site. Componentes são coisas como botões ou elementos de navegação ou carrosséis. A camada de componentes contém a coisa que o usuário iria ver e interagir com. Você deve pensar nas camadas anteriores como muito arquitetônicas. Estas são as coisas que o usuário é muito improvável de estar ciente. O usuário realmente não se importa se você usa normalize.css, o usuário não se importa com qual sistema de grade você usa. As três camadas anteriores são onde lidamos com a maioria dos problemas arquitetônicos, e a camada de componentes é onde começamos a alcançar encapsulamento. A camada de componentes seria feita de arquivos únicos que controlariam talvez um carrossel ou uma lista suspensa ou um botão. Proporcionalmente, a camada de componentes compõe a maior parte do projeto porque a maior parte do seu site seria componentes. Isso significa que você faria a maioria das alterações e adições ao seu projeto nesta parte da base de código. Muito importante, portanto, encapsulamos o código aqui muito bem. O final das camadas ITCSS padrão é conhecido como a camada de utilitários. Agora, o que você vai notar aqui é este enorme pico no final. Isso porque a camada de utilitários é reservada para todos os CSS desagradáveis que você realmente não quer falar sobre. A camada de utilitários é onde você pode soltar coisas como hacks ou suas folhas de estilo IE7. Aqui, você também pode fugir com o uso importante. Agora, se nos afastarmos e olharmos para este gráfico concluído, podemos começar a ver uma saída mais tangível e significativa. Podemos ver que, à medida que avançamos da linha um para a linha 3.000 do nosso projeto, a especificidade do nosso CSS só aumenta. À medida que passamos por esse aumento na especificidade, começamos a tirar fatias verticais do projeto e categorizar nosso CSS em torno de certas funções. 5. Os três lados do ITCSS: Agora, você provavelmente está começando a se perguntar como conseguimos chegar tão longe e nem sequer vimos um triângulo ainda. Bem, vamos ver exatamente onde isso se encaixa. Acabamos de aprender sobre gráficos de especificidade e muitos detalhes, o triângulo do inversor funciona em três princípios fundamentais e o mais importante deles é a especificidade. Agora, este diagrama mais uma vez representa a totalidade do seu projeto CSS seja um único arquivo CSS ou se isso foi o resultado de muitos arquivos SAS compilados em uma folha de estilo resultante, este triângulo representa tudo o que colocar juntos. Então, novamente, começamos a linha zero e avançamos para uma linha 3.000. Cada borda do triângulo representa um dos três princípios fundamentais. A primeira é a especificidade. A especificidade sempre aumentará à medida que avançamos através do projeto da linha zero para a linha 3.000. Nossa especificidade só deve aumentar. O segundo princípio fundamental subjacente ao ITCSS é um princípio chamado explícito. Explicidade olha para a idéia de quão opinativa uma peça de design pode ser. Por exemplo, se apenas um botão em todo o site precisar ter um fundo vermelho, você não aplicaria esse fundo vermelho a cada elemento A, você esperaria até mais tarde no projeto para identificar esse botão e aplicá-lo lá. Muitas das razões pelo projeto CSS começa a dar errado e começar a desmoronar, é porque as pessoas têm uma tendência a projetar muito cedo e, em seguida, ter que gastar o resto de seu projeto desfazendo isso. explícita força alguma restrição e faz com que os desenvolvedores apenas optem por alterações de design adicionais conforme são necessárias. O terceiro e último princípio principal orientador por trás ITCSS forma o último lado do triângulo e, de fato, reúne tudo, esse princípio é conhecido como o alcance. Agora, enquanto a especificidade e a explícita aumentam à medida que passamos pelo projeto, o alcance realmente diminuirá. Alcance lida com o quanto da página ou do componente ou de fato todo o site que um seletor específico é capaz de afetar. Um seletor de alcance muito distante, é como se o seletor de estrelas pudesse afetar todo o DOM. Também tem uma especificidade muito baixa. Por outro lado, uma única classe só pode afetar um único nó DOM de cada vez, o nó DOM ao qual está anexado, e as classes também tem uma especificidade muito maior. O alcance diminui à medida que descemos o triângulo e é o que faz um triângulo. Sem alcance, seria o quadrado invertido, que eu acho que é apenas um quadrado e quadrados não vendem oficinas. Reach reúne todo o triângulo e diminui a quantidade da página ou componente de um DOM que podemos tocar a qualquer momento. Então, como é minha intenção, tudo isso é muito alto nível. O que eu vou fazer é rabiscar rapidamente um exemplo de seletores ao lado do triângulo para mostrar que tipo de código você poderia esperar encontrar onde. Eu mencionei já é o seletor de estrela, que carrega um valor de especificidade de exatamente zero. O seletor de estrela pode afetar cada nó DOM em uma página, vaca é especificidade muito baixa e, portanto, também deve ser muito explícito. Você não iria querer aplicar a bola de peso da fonte para o seletor de estrelas. Progredindo ainda mais, podemos encontrar talvez um seletor de elemento A. O elemento A tem uma especificidade maior do que um seletor de estrela e, portanto, só pode afetar um pouco menos do DOM, apenas cada elemento âncora pode ser estilizado. Progredindo ainda mais, temos um estilo de design mais explícito, talvez não vamos estilizar um botão. Então, um botão é uma explicitação crescente. Um aumento na explícita acarreta um aumento natural na especificidade porque teríamos que usar um seletor como.button. O que você tende a descobrir é que especificidade e explícita são relativamente iguais. Qualquer coisa com uma especificidade disto teria uma explicação correspondente. Você não gostaria de aplicar explicitamente o estilo de design de um botão contra a especificidade do seletor de estrelas, o que seria muito prejudicial. Vamos imaginar por um segundo que temos um tipo específico de botão, talvez um botão que não pode ser clicado por um usuário porque ele não inseriu um endereço de e-mail correto. Teríamos que arranjar outro seletor para isso. Agora, nosso estilo de design ficou mais explícito porque não é apenas um botão, é um tipo de botão que não pode ser usado. Este aumento da explícita pode precisar trazer um aumento na especificidade. Então, podemos ter um seletor como. desabilitado, o que denota um elemento que não pode ser usado. Tomando nossa especificidade e explícita, chegamos naturalmente ao alcance desse seletor. A classe disable só seria aplicada ao botão que está desativado a qualquer momento, portanto seu alcance é muito pequeno. Se vamos olhar para o elemento A, que pode ser acima de 100 links em uma página, isso significa que ele está usando um seletor, que tem relativamente baixa especificidade, também significa que porque pode haver 100 links em uma página, nós não podemos dar a eles um estilo de design excessivamente opinativo e como poderia haver mais de 100 links em uma página, o alcance desse botão é realmente muito alto. É assim que as três métricas-chave, os três princípios fundamentais, todos jogam um no outro. Normalmente, o que você vai descobrir é que se você obedecer a dois dos três princípios, você começa a trabalhar o terceiro de graça. Sempre que você precisar adicionar código a um projeto, pergunte a si mesmo: “Quão explícito ou opinativo é o estilo de design?” Se for um estilo de design bastante opinativo, você precisaria de um seletor de opinião equivalente que, portanto, trará uma especificidade. Em virtude de ter um estilo de design bastante explícito e uma alta especificidade, você vai facilmente obter os ricos trabalhados para você. Para expandir brevemente o alcance e o que isso significa para a forma do nosso projeto, vamos reimaginar rapidamente o triângulo como forma de cone real em vez de um triângulo plano. Esta forma de funil agora representa como os seletores à medida que você progrediu da linha zero para a linha 3.000 do seu projeto afetam cada vez menos o DOM. Então, agora, o que você acha é que cada camada é responsável por estilizar cada vez menos da página à medida que você progride. A primeira camada visa quase tudo, e progressivamente menos, e menos, e menos antes de chegar ao fundo do triângulo ou agora, eu acho que o cone invertido, e seu afetando com precisão pontual nós DOM únicos de cada vez. Uma analogia útil para todo esse fluxo de trabalho é se você imaginasse um escultor fazendo uma estátua. Um escultor pode aproximar-se de uma pedreira e pedir um grande bloco de mármore. Agora, o que a pedreira faria é talvez explodir aquele pedaço de mármore para fora da face da rocha, e levá-lo para baixo para o moinho de pedra, e o moinho de pedra vai pegar aquele grande pedaço de pedra, e torná-lo em um bom cubo viável. Em seguida, o escopo para levar aquele pedaço de pedra para o estúdio, e iria obter um grande martelo e um grande cinzel, e grosseiramente fez a forma de uma pessoa. Depois de terem feito isso, eles pegarão um martelo menor e um cinzel menor, e começarão a colocar detalhes como dedos. O que seria uma maneira muito incomum de trabalhar é se essa esculpir apenas pegar um grande bloco de mármore grosseiramente posso ter apenas explodido minha cara de pedra e moda apenas o dedo perfeito saindo do topo dela. O que eu tento fazer aqui é exatamente o mesmo com CSS, cortar traços largos no início de um projeto para cobrir talvez 50% do trabalho pesado. Em seguida, o próximo bit cobre os próximos 10% e, em seguida, cinco por cento até obtermos esses bits menores e menores de trabalho visando cada vez menos nós DOM. Trabalhar desta forma permite-nos manter-nos direccionados e manter as coisas bem geridas à medida que avançamos cada vez mais no projecto. Então, nós apenas olhamos um monte de diagramas apenas lá, nós não olhamos para uma única linha de código. Vamos agora passar para o computador. Veja como essas coisas se reúnem em um projeto, no sistema de arquivos real usando CSS real. 6. ITCSS na prática: Então, passamos um monte de tempo lá olhando para diagramas muito conceituais. Não olhamos para uma única linha de código. Então, o que eu quero fazer agora é mergulhar em um projeto de exemplo que eu construí. O projeto de exemplo é chamado Discover. É um tipo simulado de site de viagens e tem um ótimo repositório ao qual você tem acesso completo, então certifique-se de verificar os recursos para isso. Ele também está hospedado no LINE URL, para que você possa ver exatamente o que estamos construindo. Mas vamos dar uma olhada, este é um pequeno tipo de projeto feito que é construído usando ITCSS. A primeira coisa que eu quero mostrar é como isso se parece no sistema de arquivos, o que isso realmente parece no Finder. Agora, é um projeto muito pequeno porque foi inventado puramente por exemplo, por causa, então você não vai ver nada complexo como qualquer tipo de tarefa ou se tem nenhum pipeline de construção, qualquer coisa assim. Aqui, podemos começar a ver os ingredientes do triângulo invertido. A primeira coisa que você vai notar é que temos um arquivo.scss principal, este é o nosso único ponto de entrada. Então, este arquivo é responsável por importar todos os outros aspectos do projeto CSS em sua respectiva ordem de acordo com o triângulo invertido. Em seguida, você verá que cada camada do triângulo tem um diretório correspondente. Agora, isso é completamente opcional. Uma das principais coisas do ITCSS é que ele deixa muitas dessas decisões para o desenvolvedor. Eu costumava ter uma configuração onde eu não tinha um diretório para cada tipo de arquivo CSS. Eu só tinha uma estrutura de diretório plana, mas eu percebi que depois de um tempo isso fica muito difícil de gerenciar, então eu passo para uma estrutura mais como esta, na qual podemos ver que cada tipo de seletor CSS, cada tipo de em um triângulo tem seu próprio diretório correspondente. Agrupei todos os arquivos para cada camada nesse diretório que é nomeado após mim, mas o que eu também faço é nomear cada um dos meus arquivos de camada.file.scss. Então, aqui, você verá elements.headings.css. Aqui, podemos ver objects.layout.scss. Ter o nome da camada dentro do nome do arquivo torna muito fácil entender em qual parte o projeto eu estou trabalhando em qualquer momento. Mas, novamente, isso é completamente até a preferência do desenvolvedor. Além de agrupar cada tipo de arquivo em seu diretório correspondente, eu também gosto de nomear cada arquivo após a camada a que pertence. Então, o que você pode ver aqui é components.avatar.scss ou neste arquivo ou pasta aqui, temos objects.layout.scss. A razão pela qual eu gosto de fazer isso, é bom ver apenas a partir do nome do arquivo sozinho, que parte do projeto eu estou trabalhando. Se eu tiver objects.layout.scss aberto no meu editor de texto, sei exatamente em que parte do projeto estou contribuindo. Agora, vamos dar uma olhada no nosso principal. scss. Este é o ponto de entrada principal. Este é o arquivo fonte único que compacta todo o resto do projeto e é esse arquivo fonte que produz main.scss mais tarde. Olhando para main.scss no meu editor de texto, a primeira coisa que você vai notar é este índice. Novamente, isso é completamente opcional, esta é a preferência do desenvolvedor. Mas eu gosto de manter um índice bastante manual no topo do meu ponto de entrada principal. O que isso me permite fazer é anotar em termos humanos exatamente o que está contido no projeto. O que você costuma encontrar é que, à medida que os projetos ficam maiores e envelhecem, muitas pessoas se tornam desfamiliarizadas com o tipo de CSS existente dentro deste diretório CSS. Eles não sabem quais recursos já existem, o que já foi construído e assim por diante. Apesar de manter este índice bastante manual, mas muito legível, os desenvolvedores são sempre conscientes do que está disponível para eles. Passando de um índice, começaremos a ver minhas diretivas @import. Então, o que você verá aqui é minha importação para as camadas de configurações e ferramentas. Estes são puramente pré-processo de camadas. Isso contém configurações globais para meu projeto , como escalas tipográficas ou paletas de cores. A camada de ferramentas contém coisas para fazer com quaisquer misturas ou funções que o projeto pode exigir. Deixe-me passar para as camadas que vimos anteriormente. São coisas que desenhamos em nossos diagramas. Se você notou o tamanho relativo de cada camada, você pode começar a entender de onde vem a maior parte do projeto. Por exemplo aqui, a camada genérica é bastante pequena. Nós realmente não temos muito aqui, nós temos nosso tamanho de caixa global, alguns tipos de estilos normalizar e redefinir e alguns estilos compartilhados também. Mas vamos olhar para a camada de elementos. Podemos ver que temos mais alguns arquivos aqui, começando a ficar um pouco maiores. É aqui que assinamos coisas como cabeçalhos, links e listas. Estes são os elementos html que compõem nossa página. Além disso, nos movemos para a nossa camada de objetos. A camada de objetos é a primeira camada em que temos permissão para introduzir classes. Isto novamente é ligeiramente maior do que a camada de elementos, mas quando avançamos para a camada de componentes, vemos que as coisas são de longe muito, muito maiores. A camada de componentes compõe a maior parte de qualquer projeto específico. A maioria do seu site será baseado em componentes, ITCSS suporta isso criando uma parte inteira do projeto para todas essas coisas ao vivo. O que você verá são nomes consistentes, components.logo, components.masthead. É nesses arquivos que encontramos a maioria de nossa UI. Finalmente, nos movemos para nossa camada de utilitários e é neste ponto que importamos qualquer tipo de arquivos de depuração ou quaisquer utilitários e tipo de classes auxiliares. É neste ponto que podemos trazer específicos do IE 7 ou fixadores diferentes para navegadores diferentes. Utilitários camada é reservado para CSS que não é completamente perfeito. Seu reservado para CSS que é bastante alta especificidade, muitas vezes até mesmo contendo importância. Vamos analisar isso com mais detalhes em breve. Ao olhar sobre este arquivo, esperamos ver que mesmo um projeto bastante grande pode ser destilado em pedaços muito gerenciáveis. Podemos ver rapidamente o que vive onde e porquê. Isso significa que procurar CSS existente torna-se trivial e isso significa que adicionar novo CSS deve se tornar bastante simples e direta. Olhando para os padrões que foram deixados por um desenvolvedor anterior, podemos continuar de onde eles pararam e criar uma base de código muito mais consistente. Como você pode ver no arquivo atual que estamos olhando, ele tem todos os ITCSS padrão relacionados no momento. Mas certos projetos podem exigir camadas diferentes ou a remoção de certas camadas. ITCSS deixa isso completamente para nós. Então, essa foi uma visão rápida de como o triângulo pode se unir em um pacote SAS importado. É claro que, dependendo do seu projeto, sua circunstância, seu processo de construção, seu pipeline de construção, as especificidades podem muito bem diferir e a beleza do ITCSS é que cabe inteiramente a você como você modifica esse fluxo de trabalho. O que eu quero mostrar a vocês, no entanto, é o arquivo SCC resultante. Todos os diagramas que desenhamos anteriormente eram da linha 0-3.000, é o que usamos, eles foram representados folhas de estilo compilação completa. Vamos ver como isso acaba. Agora, vamos ver como tudo isso se junta uma vez que foi compilado em uma grande folha de estilo. Imediatamente aqui, vamos que temos um índice familiar, que foi transportado do nosso ponto de entrada principal, nosso arquivo principal. scss. Se ultrapassarmos isso, vamos começar a ver alguns SCSS naturais. Agora, lembrem-se, os três princípios fundamentais do triângulo, baixa especificidade para alta especificidade, inexplicitamente em direção explícita e ampla estendendo até alcançar estreito. Então, imediatamente podemos ver aqui especificidade muito baixa. Você tem um seletor de estrela, nós temos o seletor de elemento html, estes são seletores de especificidade muito baixa que lançam uma rede muito ampla. O seletor de estrelas captura literalmente tudo no DOM. Então, à medida que progredimos através disso, e eu vou fazer isso relativamente rápido, o que você deve ver é o gráfico de especificidade formando diante de seus olhos. À medida que viemos através de seletores de elementos de baixa especificidade, em seguida, devemos começar a ver alguns seletores de classe aparecendo quando chegamos em direção a objetos. Aqui, temos 0-layout, então temos aquela especificidade imediata colisão em nossa camada de objetos, a primeira camada na qual temos permissão para ver classes. O que você vai notar aqui é que essas aulas são prosseguidas com um o-. Agora, esta é uma convenção de nomenclatura opcional que vem com ITCSS. Progredindo daqui, encontramos mais classes, então não temos um aumento na especificidade, mas temos uma mudança no propósito. Aqui temos que c- que denota nossas classes componentes. Componentes são os bits que compõem a maioria da interface do usuário e aqui vemos que ele está usando um bamm como convenção de nomenclatura. À medida que avançamos além das classes de componentes, vamos começar a encontrar classes de especificidade muito, muito altas. É aqui que chegamos à nossa camada de utilitários. A camada de utilitários é um caso especial. É reservado para qualquer tipo de CSS que não estamos particularmente entusiasmados. Em grandes projetos, é garantido que vai acontecer, que você terá que contribuir com alguns CSS que não é exatamente como você gostaria. Isso não é o ideal. Claro, não é o ideal, mas provavelmente vai acontecer, aconteceu em todos os projetos em que já trabalhei. Então, o que é muito importante é ter um lugar dedicado para esses bits de CSS que vivem nossa camada de utilitários torna-se um catchall, uma gaveta diversa que captura todos os CSS que não se encaixam em nenhum outro lugar. Deixá-lo no final significa que ele não corre o risco de definir o tom para o resto do projeto. Você não quer chamar seu CSS hacky no início de sua folha de estilo porque fazer isso significaria que o resto da folha de estilo tem que lutar em torno dele. Nós desenhamos todas essas coisas bem no final, para que ele possa imediatamente substituir qualquer coisa que veio anteriormente com sobrecarga muito mínima. À medida que avançamos até o final da folha de estilo, descobriremos que é aí que as coisas terminam. Terminamos com uma especificidade muito alta, com algumas classes de casos de uso único muito direcionadas. Estas são classes utilitárias que são projetadas para sobrescrever qualquer coisa que veio anteriormente com o mínimo esforço. Agora, eu exorto você a absolutamente ir e cavar em torno deste repositório porque quando você começar a separá-lo, em breve você vai encontrar todas as coisas que discutimos sentar-se imediatamente no lugar, você vai descobrir que as coisas fazem muito mais sentido. Você vai se encontrar capaz de navegar pela base de código muito rapidamente com base nas coisas conceituais que aprendemos anteriormente. Agora, é claro, isso foi apenas uma demonstração, por causa de demonstração. Era uma demonstração muito pequena, muito auto-suficiente. Não é necessariamente realista de um grande tipo de projeto. Então, o que você vai descobrir é que à medida que você implementar ITCSS no mundo real, os benefícios se tornarão muito mais aparentes, mesmo neste exemplo aparado espero que aprendamos que seguindo os três princípios fundamentais do ITCSS, podemos começar a dar coisas lugares dedicados para viver e lugares dedicados para serem encontrados. O que isso significa é que, se qualquer desenvolvedor de pára-quedas em um projeto pode facilmente localizar-se e navegar facilmente pela base de código que potencialmente nunca viram antes. 7. Considerações finais: Então, aí temos, uma introdução à arquitetura CSS do triângulo invertido. Aprendemos como o CSS, quando deixado para seus próprios dispositivos, pode rapidamente tornar-se indisciplinado e difícil de gerenciar. Mas então também aprendemos que com muita diligência e alguma formalidade, podemos facilmente escrever essas coisas de volta e ajudá-las a trabalhar em nosso benefício. Acima de tudo, o que eu realmente quero que as pessoas tirem disso é o fato de que o ITCSS não é um sistema complexo, não requer mudanças drásticas no processo ou na forma. Além disso, é um toque muito leve. Assim, você pode modificar o ITCSS para se adequar à sua pilha de tecnologia, habilidades em sua equipe, o tamanho do seu projeto, até mesmo o tipo de projeto que você está trabalhando. Em nível mais técnico, eu acho que a minha chave para você seria, eu realmente realmente importante gerenciar coisas como especificidade muito bem, porque esta é geralmente a maneira técnica em que os projetos começam a espiral O mais rápido. Então, o que vem a seguir? Bem, a primeira coisa que você poderia fazer é participar da discussão. Se você tiver alguma dúvida, alguma preocupação, algum exemplo ou downloads que gostaria de discutir ou sair em aberto, absolutamente você vai e faça isso. Ficarei de olho lá e responderei a qualquer pergunta que possa ter. Claro, fique de olho nas seções de recursos, um monte de links para os diferentes materiais de leitura e fique de olho nisso. Há muitas coisas para olhar. Então, foi isso. Muito obrigado por sair. Estou realmente ansioso para ver como você pega ITCSS, molda em seu próprio projeto e seu próprio trabalho, e eu acho que eu vou te ver na próxima vez.