Skip to content

Latest commit

 

History

History
508 lines (294 loc) · 26.1 KB

README.md

File metadata and controls

508 lines (294 loc) · 26.1 KB

CSS

  1. Requisitos gerais
  2. Regras
  3. Fontes
  4. BEM
  5. Possíveis erros

Requisitos gerais

  • 1.2 Não inclua estilos de fontes remotas - apenas de nossos servidores.

  • 1.3 CSS é uma força perigosa.

    Todos os estilos conectados à página são globais e, se isso for abusado, você poderá facilmente levar o projeto a um estado de introdução extremamente dolorosa de qualquer novo elemento ou alteração do antigo. Isso acontece com mais frequência quando classes "gerais" são criadas e anexadas a diferentes elementos da página (um exemplo banal é um cabeçalho que possui um formulário de pesquisa dentro, que está em todas as páginas com as mesmas classes) e, como resultado, quando, de acordo com o design, em páginas diferentes aparecem pequenas diferenças no cabeçalho, as classes que reescrevem as propriedades se multiplicam. E assim para quase todos os elementos de cada página. Como resultado, alterando o link mais à direita na barra lateral da página de notícias, você pode quebrar o layout de toda a barra lateral em alguma outra página, por exemplo, na página da conta pessoal.

    Para evitar que isso aconteça, existem diferentes metodologias, por exemplo, BEM (leia sobre isso pelo menos em termos gerais) ou, por exemplo, rscss. Para começar, você pode estudar uma pequena abordagem que os caras do Isobar usam - está descrito dentro do padrão deles e consiste em 7 pequenos parágrafos.

  • 1.4 Recuo com espaços, um nível — 2 espaços.

  • 1.5 Use aspas simples.

  • 1.6 Antes de começar, certifique-se de conhecer claramente todas as prioridades do seletor e todos os 4 tipos de relacionamentos possíveis.

    As relações entre os elementos podem ser:

    • div p - elementos p que são filhos de div
    • div > p - apenas filhos imediatos
    • div ~ p - vizinhos à direita: todos p no mesmo nível de aninhamento que vêm depois de `div
    • div + p` -primeiro vizinho direito: p no mesmo nível de aninhamento, que vem imediatamente após div (se presente)

    quanto às prioridades podem ser lidasaquie em muitos outros lugares.

  • 1.7 Não use @import dentro de arquivos.

    Isso significa que ofinal css arquivoque o cliente recebe não deve conter essas construções. Mas se WebPack e css-loader forem configurados, que trata apenas deste caso, ou análogos compilados são usados ​​que podem substituir o conteúdo direto de arquivos em vez de importações, então as importações são possíveis, já que o navegador não as verá de qualquer maneira e nunca os receberá em trabalho real.

    Existem algumas razões pelas quais você não deve usar @import:

    • Alguns navegadores mais antigos não suportam o uso da regra @import, e os estilos que carregamos através desta regra serão perdidos
    • @import blocoscarregamento paralelo de estilos, e isso significa que o navegador aguardará a conclusão do download do arquivo importado antes de processar o restante do conteúdo.
    • Mais detalhes podem ser encontrados aqui.

  • 1.8 Todas as regras devem ser divididas em arquivos diferentes por páginas e blocos, cada arquivo não deve ter mais de 1000 linhas.

  • 1.9 Cada regra CSS deve estar em sua própria linha.

    Isso ajudará muito, pelo menos ao visualizar diferenças no sistema de controle de versão. Além disso, evitará a rolagem horizontal.

  • 1.10 Para todos os elementos interativos (links, botões, dropdowns, inputs, selects), o designer pode desenhar estados separados e ocultá-los na camada mais próxima - sempre verifique para cada elemento, se há um estado renderizado.

  • 1.11 Designers podem cometer erros - às vezes você precisa fazer solicitações para alterar o layout se eles desenharam algo muito complicado.

    Por exemplo, um layout pode ter uma faixa centralizada verticalmente em relação ao texto:

    | Exemplo | | :------------------------------------------------- -------------------------------------------------- ----------: | | essa foto é apenas um exemplo, não o fato de que existe apenas um erro |

    O designer pode apenas colocar visualmente essa faixa no nível médio das letras inferiores do texto, no entanto, como designers de layout, basta aplicar vertical-align: middle e você verá que a faixa está acima/abaixo do nível que o design mostrou, e Pixel Perfect destaca isso claramente. Na maioria das vezes, você não precisa codificar algum recuo não óbvio, apenas para combinar perfeitamente com o layout - é melhor dizer ao designer que a tira é colocada automaticamente em um local diferente e é melhor deixá-la lá. Um designer para aprender tipografia.

  • 1.12 Tente tornar o site o mais fluido possível (defina a largura como uma porcentagem e defina max-width, min-width) - use um elemento fixo largura somente se o layout não tiver como fugir disso.

    Se você precisar de um site de largura fixa, verifique o lado direito de cada página em telas pequenas. Um erro muito comum iniciantes não fazem todos os elementos com min-width, e a rolagem horizontal é obtida assim:

    image

  • 1.13 Ao construir um projeto na ausência de design (em estruturas CSS, por exemplo), evite "esculpir".

    Se você estiver desenvolvendo um projeto que não tem design (usando frameworks CSS, por exemplo), tente evitar a escultura.

    As regras são as mesmas que ao escrever módulos de programa: tente dar espaço entre os componentes, limite-os visualmente um do outro (o acoplamento fraco é realizado), mas, ao mesmo tempo, os próprios componentes devem parecer auto-suficientes, ou seja, tem todas as funcionalidades necessárias, mas sem redundância, para que possa ser chamado de componente completo (é realizada uma forte conectividade).

    O BEM é um bom detector aqui: tente recuar entre os blocos pelo menos duas vezes mais do que dentro do bloco entre os elementos.

  • 1.14 Todos os estilos de um bloco devem estar no mesmo lugar e classificados por ordem na página.

    Ou seja, se houver um cabeçalho e dentro dele houver um formulário de pesquisa, em arquivos .css você não poderá definir primeiro os estilos de cabeçalho, depois vários estilos de corpo de página e, em seguida, os estilos de formulário de pesquisa de cabeçalho. Os estilos do próprio cabeçalho devem ir, e logo abaixo dele, os estilos do formulário.

    Ao mesmo tempo, estilos de barra lateral não podem preceder estilos de cabeçalho e estilos de rodapé não podem preceder estilos de barra lateral. É melhor espalhar esses estilos em arquivos diferentes.

  • 1.15 O rodapé da página deve sempre ser pressionado na parte inferior da página, mesmo que haja pouco conteúdo na página (5 maneiras de fazer isso).

  • 1.16 Nomes.

    Use minúsculas com hifenização (ou seja, nãomySuperAwesomeElement não my_super_awesome_element) Os

    nomes devem refletir o significado, ao invés da descrição dos estilos("carregando",não` "big-yellow-spinny-)

Regras

  • 2.1 Não use !important.

    Em 99% dos casos, o problema pode ser resolvido usando BEMmódulos CSSoucom sabedoria. Em casos raros difíceis, é melhor aumentar a prioridade dos seletores (por exemplo, quando você precisa redefinir estilos de biblioteca).

  • 2.2 Não use position: absolute para estilizar onde poderia ser substituído por outras abordagens.

  • 2.3 Não mova o elemento com top, left, right ou bottom quando position: relative, onde pode ser substituído por outras abordagens.

    Você pode usar o próprio position: relative (sem as propriedades top, left, right ou bottom) para o z-index e para dar um ponto de referência aos descendentes do elemento.

  • 2.4 Não use margens negativas.

    De fato,negativas margins são regras válidas, elas são suportadas pela especificação CSS, e são usadas até mesmo por gigantes como Bootstrap (veja os estilos para .row).

    Mas essas são regras muito não óbvias, difíceis de detectar e quase sempre podem ser substituídas por propriedades mais fáceis e previsíveis.

  • 2.5 Evite fixar a altura.

    Quase sempre, usar uma fixa em pixels, porcentagens e outras unidades 'altura' é um sinal de código ruim. Isso torna o comportamento de elementos que seguem uma altura fixa muito obscuro, e o conteúdo pode ser recortado ou sobreposto em elementos subsequentes.

    Quando ainda pode ser necessário:

    • As alças do elemento devem ser ajustadas à altura dos descendentes que foram "retirados" do fluxo geral. Você pode "remover" do stream por meio de position: absolute, por exemplo. Este pode ser um slider, cujos descendentes giram apenas pelo posicionamento em vez de offset marginth

    • Por design, é necessário ajustar todos os elementos de uma certa altura e o conteúdo sai da borda, apara.

  • 2.6 Evite alinhamentos fixos.

    Se o bloco precisar ser centralizado (horizontal ou verticalmente), centralize-o dinamicamente em vez de um margin-top fixo.

    Por exemplo:

    Exemplo

    Aqui a imagem, o texto e a faixa devem ser centralizados usando vertical-aligne não top: 55px para a faixa.

    Muitas vezes, casos de centralização mais complexos aparecerão - quase todo mundo tem seu próprio método, você precisa estudá-los separadamente.

    Artigo sobre alinhamento vertical

    O que precisa ser feito para centralizar a altura de element1 dentro de element2:

    • Ambos os elementos devem ser quaisquer elementos embutidos

    • element2 deve têm o tamanho da fonte ou a altura da linha especificados. Element2 será centralizado apenas com base no tamanho da fonte ou na altura da linha e não se importará com a altura.

  • 2.7 Defina a cor de fundo padrão, cor da fonte, font-sizefont- efamily para html.

    A partir de agora, o tamanho da fonte será a referência para todos os elementos que usam rem para suas unidades de tamanho.

  • 2.8se de observar a cor doao testar Certifique-:visited link.

    O navegador padrão torna esses links roxos, o que geralmente é inaceitável no design.

  • 2.9 Adicione um elemento cursor: pointerse for clicável e não for compatível por padrão.

  • 2.10 Remova todas as regras não utilizadas e regras que não afetem a exibição de forma alguma (por exemplo, propriedades padrão duplicadas ou null marginjá, se não forem definido ) - eles podem posteriormente apresentar um comportamento não óbvio ao editar e, por causa deles, é difícil entender o projeto.

  • 2.11 Palavras totalmente maiúsculas devem ser preferencialmente feitas usando o estilo text-transform: uppercase em vez de digitar letras maiúsculas.

  • 2.12 Ao definir um elemento para outline: none, certifique-se de definir estilos para :focus nesse elemento.

    outline é muito útil quando o usuário preenche um formulário usando a tecla tab para alternar entre entradas e botões. Se outline for removido, ficará menos perceptível (ou até invisível para botões) qual elemento está selecionado no momento.

  • 2.13 Todos os usos de @media devem vir imediatamente após as regras principais do elemento, para que você possa ver todas as regras e todos os estados possíveis do elemento elemento em uma tela sem rolagem.

  • 2.14 Os prefixos do fornecedor devem vir antes do estilo genérico.

    A regra padrão deve estar sempre sob as regras específicas para cada motor.

    Exemplo:

    .thing {
  -webkit-transition: all 100ms;
  -moz-transition: all 100ms;
  -o-transition: all 100ms;
  transition: all 100ms;
}

Fontes

  • 3.1 Se o cliente forneceu layouts com fontes personalizadas, verifique se estão disponíveis e, caso não estejam, solicite os arquivos de fontes adquiridos.

  • 3.2 A menos que seja necessário suporte para navegadores mais antigos, as fontes devem estar nos formatos .woff2, .woff. Primeiro inclua .woff2 fontes, depois .woff (exemplo abaixo).

  • 3.3 Se o projeto deve suportar caracteres não latinos (por exemplo, russo), verifique se o arquivo de fonte contém esses caracteres.

  • 3.4 Conecte diferentes estilos da mesma fonte com o mesmo nome, mas para diferentes pesos dafont-weight e font-style.

    @font-face {
 font-family: "Lato";
 src: url("../fonts/lato-regular.woff2"), url("../fonts/lato-regular.woff");
 font-weight: 400;
 font-style: normal;
}
@font-face {
 font-family: "Lato";
 src: url("../fonts/lato-italic.woff2"), url("../fonts/lato-italic.woff");
 font-weight: 400;
 font-style: italic;
}
@font-face {
 font-family: "Lato";
 src: url("../fonts/lato-light.woff2"), url("../fonts/lato-light.woff");
 font-weight: 300;
 font-style: normal;
}
@font-face {
  font-family: "Lato";
  src: url("../fonts/lato-lightitalic.woff2"),
  url("../fonts/lato-lightitalic.woff");
  font-weight: 300;
  font-style: italic;
}

  • 3.5 Sempre use pelo menos uma fonte de fallback e uma família de fallback.

    Eles são separados por vírgulas em font-family, então cada uso de font-family deve seguir o padrão:

    block {
 font-family: Helvetica, Arial, sans-serif;
}

    Aqui Helvetica é uma fonte de plugin não padrão.

    Arial é a fonte padrão usada por quase todos os clientes, ela será usada senão incluir Helvetica.

    sans-serif é a família de todas as fontes sem serifa (que são Helveticae Arial). Mesmo se não houver 'Arial-a' no computador, alguma fonte sans-serif padrão do sistema será instalada. A escolha aqui deve ser feita de "serif," "sans-serif," ou "monospace". Para fontes sem serifa, use o padrão Arial, para fontes com serifa, Georgia (não Times New Romanfontes), e paramonoespaçadas, "Courier New"

  • 3.6 Nomes de fontes contendo espaços, números ou pontuação que não sejam hífens devem ser colocados entre aspas.

    Exemplo:

     block {
  font-family: 'Times New Roman', serif;
}

BEM

  • 4.1 A nomenclatura das entidades BEM deve seguir as seguintes restrições:

    Bloco, elemento - sempre um substantivo (substantivo)

    Modificador - deve satisfazer as propriedades de modificador do inglês. Sempre adjetivo ou frase adjetiva.

    Assim, frases em inglês "$BLOCK_NAME [é] $MODIFIER_NAME", "$ELEMENT_NAME [é] $MODIFIER_NAME" ou "$MODIFIER_NAME $BLOCK_NAME", "$MODIFIER_NAME $ELEMENT_NAME", "$ ELEMENT_NAME WITH $MODIFIER_NAME $MODIFIER_KEY" devem ser frases sintaticamente corretas.

    Exemplos de nomes corretos:

    • input_selected - entrada selecionada - entrada selecionada ou entrada selecionadaentrada selecionada -
    • header_size_large - header with large size - cabeçalho com tamanho grande.

    Exemplos de NÃOnomes válidos:

    • form__save_small, para o elemento save (que, por exemplo, é pendurado em um botão) - small save - save small, economize pequeno - economize pouco. Seria correto usar um substantivo em vez de verbo e renomear o elemento para save-button; pequeno botão salvar- um botão salvar pequeno

    • entrada_focus - entrada foco de-foco ou entrada deentrada é foco - entrada é foco. É correto usar adjetivo em vez de substantivo/verbo e renomear o modificador para focado; input_focused - focada entrada- entrada focada

    • row_error - linhalinha erro de- erro deou linha é erro - linha é um erro. É correto usar frase adjetiva em vez de substantivo e renomear o modificador para com-erro. row_with-error - row with error - linha com erro.

    Justificativa: sempre seremos capazes de interpretar a essência do elemento de layout e as propriedades que lhe são impostas de forma inequívoca e sem custos de energia desnecessários.

  • 4.2 Sempre fazemos o layout de acordo com o BEM, a arquitetura do layout deve ser baseada em componentes.

    Cada bloco deve estar em sua própria pasta.

    As pastas de bloco não podem ser aninhadas.

  • 4.3 Cada componente é um bloco separado da metodologia BEM.

  • 4.4 Cada componente deve ter apenas dependências explícitas, ser autocontido.

    Faça todas as dependências explicitamente importando no início do componente e inserindo-o no lugar certo no layout.

    Auto-suficiência significa que cada componente deve conter tudo o que é necessário dentro de si - todo o layout, todos os estilos e todos os scripts js.

    Não deve haver nada extra no componente:

    • Não deve haver definições de outros blocos dentro deste bloco
    • Não deve haver estilos que afetem outros blocos de alguma forma
    • Não deve haver estilos globais (por exemplo, em todos ostags span)
    • O componente não deve afetar o DOM de outro componente (alterações de layout são estritamente proibidas)

  • 4.5 Personalize componentes apenas por meio de modificadores, sem mixins.

    Em quase qualquer projeto, há a necessidade de customizar os blocos. Por exemplo, há um layout de 20 páginas. Quinze dessas páginas têm cabeçalho, sendo que 10 delas têm cabeçalho azul, três delas cinza e duas transparentes. Isso significa que o componente de cabeçalho deve ser personalizável, e esse tipo de personalização é feito adicionando modificadores ao bloco, e não passando classes separadas com estilos.

    Vamos supor que a página promocional tenha um vídeo em segundo plano e, por design, precisamos fazer um cabeçalho transparente com uma fonte clara (escuro por padrão).

    Seriamente:

    .promo-page
  +header({ classname: 'promo-page__header' })

    Bom:

    .promo-page
  +header({ theme: 'transparent', font: 'light' })

    Com a abordagem correta, é claro, você precisará aprender como aceitar esses dois parâmetros, adicionar modificadores às classes necessárias e escrever regras para esses modificadores no CSS do componente.

    Esta regra foi introduzida após uma dolorosa experiência de manutenção de um projeto de média complexidade, e aqui estão os solavancos que são recheados com o uso de mixins:

    • O encapsulamento está quebrado - o uso de estilos externos dentro do componente leva a problemas de manutenção no futuro. O fato é que os estilos do componente são parte integrante dele e não devem afetar o que o cerca. O oposto também é verdadeiro - estilos externos não devem afetar o componente. Em outras palavras, o componente deve ser autossuficiente. Ao recorrer ao uso de estilos externos, criamos uma dependência entre dois estilos - externo e interno. Cada estilo precisa saber do que o outro é composto para que o estilo global não quebre o estilo do componente. Esta é uma violação de encapsulamento.

    • Se um componente for usado em 20 páginas diferentes, depois de alterar uma propriedade no próprio componente, você terá que percorrer todas as 20 páginas manualmente e verificar se nada está quebrado, pois não se sabe quais estilos podem ser pendurados nos lugares de uso por meio de classes personalizadas, e você precisa verificar todas as combinações

    • Um aditivo geralmente é pendurado apenas no nível superior do componente, mas às vezes você precisa personalizar algo interno, então acontece que você precisa enviar e receber dois aditivos no componente, um aditivo para as propriedades do bloco inteiro , o segundo - para algum elemento, e quando você precisar de outro elemento para personalizar, terá que adicionar uma terceira impureza :)

    • Não será possível compilar claramente uma lista de todos os estados possíveis do componente, e ao abordar com modificadores, vemos claramente todos os parâmetros possíveis na entrada, e quando seu número sair da escala, podemos chutar o designer que ele está muito fantasiado e seria hora de passar para um único guia de estilo

  • 4.6 Você também não precisa usar mixes para posicionar o bloco no container pai - este problema é resolvido adicionando containers especiais.

    Digamos que haja um bloco pai, ele contém um bloco filho, que precisamos posicionar. Para posicionar o bloco interno, criamos um elemento wrapper no elemento pai e simplesmente configuramos as propriedades (margin, padding, position etc) para este container. Assim, o posicionamento do bloco fica no arquivo do bloco pai e não afeta os estilos do próprio bloco.

    Este método permite que você posicione o bloco filho sem usar mixagens.

    Por exemplo, no cabeçalho temos um botão azul normal, mas aqui mesmo, no cabeçalho, ele deve estar recuado do lado esquerdo, para isso adicionaremos div.header__button:

     div.header
   div.header__button
     +button({ color:blue })

    E nos estilos de cabeçalho, basta adicionar:

    .header__button {
  margin-left: 3rem;
}

Possíveis erros

Existem algumas regras muito não óbvias em CSS, é melhor estudá-las na teoria com antecedência do que quebrar a cabeça por horas por que o layout vai

  • 5.2 Os pais ignoram todos os filhos que têm float: left ou float: right

  • 5.3 A propriedade z-index só funciona em elementos que têm um valor de posição de absolute, fixed ou relative.

  • 5.4 E z-indexVocê também pode afetar sobre isso aqui.

  • 5.5 height como porcentagem não funciona se a altura do pai for derivada do conteúdo.

    Em learn.javascript.ru existe até um artigo .

  • 5.6 Verifique cuidadosamente todos :hover em dispositivos móveis em uma ordem separada se o projeto for compatível com telas móveis.

    Em diferentes navegadores, os hovers se comportam de maneira diferente e isso deve ser acordado com os designers separadamente - às vezes, para que funcione, você precisa, por exemplo, fazer um toque separado no elemento. Assim, para que o clique funcione, você precisa tocá-lo duas vezes, o que também será muito estranho para alguns elementos.

  • 5.7 Pseudo-elements (::after/before) não funciona com tags de fechamento automático (<img />, <input />, etc.).

  • 5.8 Não use um simples :hover para exibir novos elementos que não são fáceis de alcançar com o mouse.

    Menus suspensos implementados através da :hover, não apenas este menu é praticamente inoperável em um dispositivo móvel, mas também causa muitas dores de cabeça para usuários de desktop. A solução neste caso é usar JavaScript.

    imagem

  • 5.9 Em alguns navegadores (Chrome, Opera, Edge, Firefox 62-, Safari 10-), tags de formulário como button, fieldset e legendnão pode se tornar contêiner flexível.

    possível solução é usar um elemento wrapper dentro da tag (por exemplo, span class="button__text" dentro de um botão), e já definir a display: flex:

    <button class="botão">
  <intervalo class="button_text">...</span>
</button>
    .button_text {
  display: flex;
  ...;
}

    Você pode ler mais sobre este e outros bugs que ocorrem ao trabalhar com flex em Flexbugs.

    Para resolver problemas com flex, você pode usar um bom [postcss-plugin] (https://github.com/luisrudge/postcss-flexbugs-fixes), que corrige automaticamente alguns bugs na escrita de estilos para flex.