Como não escrever modelos para inicialização

Agora, poucas pessoas estão projetando um site do zero - por que, se houver um monte de excelentes estruturas CSS? O mais popular entre eles é o bootstrap. No entanto, todo mundo quer que o site pareça único, não como os outros - é por isso que eles costumam manter (com o melhor de suas habilidades) um modelo gratuito ou pago ou seu próprio kit de interface do usuário.

Quero falar sobre alguns problemas que (infelizmente) ocorrem mesmo em modelos pagos, sem mencionar minhas soluções. O texto abaixo não afirma ser exclusivo e é improvável que seja do interesse de desenvolvedores experientes, mas pode ser útil para desenvolvedores iniciantes de front-end, designers de layout e desenvolvedores da Web de base ampla. Então, se você ainda estiver interessado, seja bem-vindo!

Temos tão historicamente ...

Como regra, se um site for desenvolvido há muito tempo, os requisitos para sua aparência mudam regularmente. Se, além disso, os programadores o alteram regularmente, o código (no nosso caso, css) se transforma em uma confusão. Em algum lugar, classes de inicialização, às vezes classes de modelos, tudo isso é diluído com muletas de várias gerações de designers de layout e temperado com estilos em linha. Tentativas de mudar alguma coisa ou adicionar uma nova leva a longos jogos mágicos em "adivinhe quais classes você precisa colocar nesse bloco html!". Quero jogar tudo fora e reescrevê-lo do zero. Mas aqui, na verdade, procurei apenas adicionar novos campos rapidamente ao formulário, tenho tarefas suficientes pelo back-end ... Na verdade, consideraremos o motivo que me levou a escrever este artigo, no primeiro exemplo.

Tamanho de entrada

Portanto, temos uma visão padrão dos elementos do formulário, que queremos mudar um pouco, por exemplo, reduzir a altura. Quais são as maneiras de fazer isso para que as entradas correspondam à baleia da interface do usuário?

Você pode inserir estilos embutidos! Vai ser muito divertido - copie todo esse calçado em cada entrada!

Alguém rirá, mas eu vejo regularmente essas decisões. Felizmente não neste caso, mas sim. O que acontece se fizermos isso? Você precisará copiar descrições longas de estilo em cada entrada, inflando o modelo e tornando-o menos legível.

Vamos escrever nossa própria classe, na qual descreveremos as configurações de altura necessárias e, ao mesmo tempo, alteraremos o tamanho da fonte!

Sim É ele. "H40_px-16". Pelo nome da turma, fica imediatamente claro o que ela faz? Encontrei algo assim quando estava tentando entender por que as novas entradas são um pouco mais espessas do que o necessário. Eu olhei para o código no mesmo modelo e o encontrei. Que consequências nos esperam neste caso? Em princípio, nada crítico. Em cada classe de elementos de formulário, além de "controle de formulário", adicionaremos "h40_px-16". Precisa lembrar, ou documento. E se houver um requisito para fazer todos os elementos do formulário com um fundo verde? Basta adicionar outra classe, "b_g". E então mais um ...

Estender classes existentes para elementos de formulário?

É extremamente raro ver essa solução, embora me pareça que ela esteja na superfície. E na minha opinião - o mais correto. Isso nos permite economizar no número de classes que precisam ser especificadas no elemento, mas o mais importante é que reduz a quantidade de perplexidade entre os desenvolvedores que estão tentando trabalhar com esse código. Se a alteração necessária afeta todos os elementos desse tipo, simplesmente adicionamos nosso próprio conjunto de regras para "controle de formulário" e todas as entradas alteram sua altura, fonte, plano de fundo etc.

Solução Personalizada

De acordo com o kit de interface do usuário, você precisa adicionar uma solução inovadora que nunca foi vista antes no site! E está escrito do zero. Sério? Não, posso permitir isso se você usar o pureCSS - uma estrutura boa, mas minimalista - e precisar implementar algo que não está incluído nela. Mas se você usar o bootstrap - com uma probabilidade extremamente alta, você só precisará reler a documentação.

Vejamos uma situação extremamente negligenciada em que o site possui sua própria implementação de emblemas. Com o bootstrap conectado. E assim, um dos desenvolvedores que não participou da criação desses emblemas precisou adicioná-los em algum lugar do site.

1. Primeiro, ele analisa a documentação do bootstrap e copia a solução a partir daí.
2. Vendo que visualmente isso não corresponde à baleia da interface do usuário, ele procura documentação sobre a solução inovadora usada.
3. Se essa documentação não estiver (e provavelmente não está), ele pesquisará no código exemplos de como isso é implementado.
4. Depois de copiar a classe beijik desejada, ele vê que o crachá agora está correto, mas azul, e ele precisa de vermelho.
5. Tendo encontrado o arquivo css que descreve as classes para a interface do usuário da baleia, ele detecta que a cor vermelha não foi colocada e o suspiro adiciona a classe "beijik-red"

Agora, vamos comparar isso com a situação em que a classe de emblema foi redefinida para sua própria implementação de emblema e a implementação de cores foi descrita na documentação:

1. Primeiro, ele analisa a documentação do bootstrap e copia a solução a partir daí.
2. A documentação mostra como adicionar red: badge-red

Aqui examinamos um exemplo em que é necessário não apenas alterar a solução pronta, mas também expandi-la, pois não estamos satisfeitos com a funcionalidade pronta para uso (os crachás no bootstrap3 não têm uma cor personalizada). Nesse caso, mesmo assim, resta a melhor solução para substituir a classe existente e, somente depois disso, adicionar a sua.

Obviamente, os exemplos que dei são bastante refinados, mas realmente me deparei com uma situação em que procurei uma solução na documentação para bootstrap, depois na documentação para o modelo usado no site (felizmente, havia documentação para ele), depois procurei arquivos css onde e como o comportamento padrão foi redefinido e como o analógico foi implementado - mas, no final, escrevi meus próprios estilos para retornar (!) as possibilidades que eram originalmente.

Se você não quer prejudicar seus colegas e deseja acelerar o trabalho da equipe como um todo, siga as seguintes regras ao criar seus próprios estilos para o site:

• Verifique como a funcionalidade necessária é implementada na estrutura usada (você se lembra - provavelmente ela está lá).
• Descubra quais classes precisam ser redefinidas para trazer a aparência desejada.
• Se a funcionalidade não for implementada ou não estiver totalmente implementada - coordene com os colegas uma maneira conveniente de expandir a funcionalidade e tente documentá-la para o futuro.
• Se a funcionalidade não for necessária em qualquer lugar, mas apenas em uma página específica - coloque-a em um arquivo separado e conecte \ colete-a para ela (sem estilos embutidos, por favor)

Posfácio

Todas as opções acima são minha opinião pessoal. Não sou desenvolvedor profissional de front-end e geralmente encontro html e css quando adiciono alguma nova funcionalidade - é mais conveniente configurar imediatamente a frente e a parte de trás e dar uma olhada no design. Se sua equipe estabeleceu processos, descreveu as regras de bom código, compilou diretrizes para todos os desenvolvedores e tudo passa por uma revisão de código - você pode apenas rir deste artigo, não me importarei. Se o artigo se mostra útil para alguém, não foi em vão que expus meus pensamentos confusos.