Falando por experiência própria! Interprete os mal-entendidos da produção de páginas da web Div + CSS

Autor：Eve Cole Data da Última Atualização：2009-05-31 01:04:51

A brisa primaveril da "reconstrução" está soprando por todo o país, e a Internet está em estado de turbulência por um tempo. "div + CSS" tornou-se uma "moda". No entanto, abrir o código-fonte desses vários sites muitas vezes faz as pessoas rirem——

Vemos layouts div com 6 ou 7 camadas de aninhamento, tabelas sem tabelas, páginas compostas por div+a puro e centenas de classes de camadas de apresentação... Existem cada vez mais livros sobre padrões hoje em dia, exceto alguns livros que anunciam. "técnicas avançadas", poucas pessoas não enfatizariam tal frase nos primeiros capítulos de seus livros - "separação entre estrutura e expressão". No entanto, quantos leitores desses livros leram seriamente os primeiros capítulos? Ou você prefere pular as explicações enfadonhas da estrutura e mergulhar nas técnicas de layout e Hacks aparentemente avançados?

Na verdade, o termo div+CSS enganou muitas pessoas desde o início, e a mentalidade de ávido por sucesso rápido é a culpada desse fenômeno. O primeiro passo para quem está acostumado com a produção de páginas web de layout de tabela entrar em contato com padrões não deve ser buscar cegamente técnicas CSS para implementar diversos layouts, mas se esforçar para mudar sua forma de pensar.

Abaixo falarei sobre a forma de pensar em conformidade com os padrões com base na minha experiência pessoal. Muitos deles são desvios que fiz, espero que sejam úteis para XDJMs que acabaram de entrar em contato com os padrões.

1. “Salvar código” é uma ferramenta de marketing, não um propósito

“Usar o layout div pode economizar mais código do que o layout da tabela”, já vi essa frase em muitos livros e sites. Esta frase em si está correta. "Salvar código" é de fato um dos benefícios da padronização de páginas da web. Porém, lembre-se que é apenas “um dos benefícios”, não o “único benefício”, e não é o propósito. “Salvar código” é mais frequentemente uma estratégia de marketing que usamos para convencer chefes teimosos. O único propósito da padronização de páginas da web é "separar estrutura e desempenho" e nunca se trata de salvar código apenas por salvá-lo. Certa vez, usei uma classe unificada porque a barra lateral e até o conteúdo principal do site têm a mesma forma de apresentação (ainda existem alguns livros que ensinam isso). Isso realmente economiza mais código do que nomear os IDs separadamente. disso é que o código perde sua estrutura de boa qualidade. As consequências de perder uma boa estrutura são: 1. O código-fonte não é mais legível; 2. O site aumenta os custos de manutenção desconhecidos; Imagine só, quando um determinado conteúdo muda sua apresentação devido a necessidades, como a cor de um link, etc., temos que modificar o arquivo fonte da página e adicionar classes adicionais. A carga de trabalho é muito maior do que apenas ajustar o id. agrupamento. E se as coisas continuarem assim, a estrutura vai piorar cada vez mais, formando um ciclo vicioso difícil de reverter.

Existe outra situação que ocorre na nomenclatura dos ids, que também é um erro que cometi. Naquela época, para "salvar o código", o menu principal era denominado "mm", o menu secundário era denominado "m2" e o menu de terceiro nível era denominado "m3". a página da web foi seriamente reduzida, tornando difícil para outros colegas assumirem o controle, tentando evitar problemas, mas me cansando. Da mesma forma, não é aconselhável simplificar demais a nomenclatura de arquivos e pastas. Por exemplo, "Reconstrução de Site" recomenda armazenar todas as imagens no diretório "i". Pessoalmente, acho que não é aconselhável, a menos que você possa escrever para tal. uma estrutura de diretório altamente abreviada Explique detalhadamente e garanta que todos os envolvidos, incluindo outras equipes de produção, desenvolvedores e até mesmo chefes experientes... possam entendê-la e implementá-la, caso contrário, isso apenas adicionará problemas desnecessários a você.

2. ID é um rifle de precisão, classe é uma faca de dois gumes

Se você deseja ter uma boa estrutura de página web, tanto o ID quanto a classe devem ser dominados com proficiência. O chamado “agarrar com as duas mãos, ambas as mãos devem ser fortes”. ID é como um rifle de precisão, que pode nos ajudar a localizar com precisão os elementos que queremos carregar, estilos e classe é a espada do cavaleiro, que é mais leve e flexível na ponta dos dedos. A combinação dos dois pode resultar em uma página com boa estrutura; e desempenho rico. No entanto, agora existe uma visão errada de que o id pode ser completamente substituído pela classe. Na verdade, isso é verdade para muitos códigos-fonte de páginas da web. Quando você abre a classe inteira, não consegue encontrar um id. Há muitas razões para esse fenômeno, mas o conceito profundamente enraizado de "class=CSS" transmitido desde a era da tabela é a causa raiz. É verdade que a classe é mais versátil e flexível que o id, mas também deve ser percebido que a classe é muito menos eficaz que o id na construção de uma boa estrutura de página web. A exclusividade obrigatória do id facilita a recuperação de qualquer módulo que precisamos por meio do id, enquanto a classe não tem essa vantagem. Embora possamos definir um nome de classe exclusivo para o módulo, a premissa é que somente o próprio produtor pode alterar o estilo da página web. Caso contrário, vamos encontrar um cara um pouco preguiçoso. Vendo que os estilos são os mesmos, ele aplicará diretamente a classe anterior. O resultado é que descobrimos que existem mais de uma dúzia de módulos na página web chamados "gonggao" ou "xinwen. ", de modo que é difícil distingui-los. Sem adicionar muitos comentários html, esse resultado obviamente não é o que desejamos. Além disso, como mencionado anteriormente, o código salvo através de classes universais deve ser desperdiçado em cada classe definida individualmente.

A identificação é um rifle de precisão e a classe é uma faca de dois gumes. Juntos, ambos nos beneficiamos e, separados, ambos perdemos.

3. Nem todo conteúdo requer div como “contêiner”

Devo usar

contém apenas um elemento

Na verdade, esta proposição pode ser estendida para - "Nem todo conteúdo precisa de elementos de bloco como contêineres" e "Nem todos os links precisam de outros elementos como contêineres", como "mais" que muitas páginas possuem. Algumas pessoas escrevem "

", enquanto outras escrevem

ou . Eles ainda precisam existir quando esses “contêineres” contêm apenas uma tag ? Escrever diretamente quebraria a estrutura? Será que faltará semântica? Isso afetará o layout? Se você pensar diferente, poderá ganhar algo diferente.

4. Alcançar a “separação entre estrutura e desempenho” no trabalho

Nesse ponto, muitos especialistas na Internet sugerem isso, ou seja, abrir primeiro o editor, escrever a estrutura completa, depois ir ao CSS para escrever a performance, e tentar não mexer na estrutura já escrita.

Porém, é difícil de entender para quem usa a leitura de livros como principal método de aprendizagem, porque a maioria dos livros sobre padrões ensina passo a passo, o que significa que devem combinar estrutura e expressão passo a passo. Embora alguns livros tenham sugestões nesse sentido, algumas frases curtas são muito inferiores aos efeitos sutis durante o processo de leitura. Quando a equipe de produção consegue ter uma boa compreensão da estrutura, a estrutura da escrita e o desempenho ao mesmo tempo não terão muito impacto nos resultados. Mas, na minha experiência, o método de trabalho de separar estrutura e apresentação é muito mais eficiente do que escrever estrutura e apresentação ao mesmo tempo, não é fácil perder elementos na página.

É claro que a chamada "separação entre estrutura e desempenho" não significa que o desempenho seja completamente ignorado. Se quiser levar o desempenho em consideração, você deve garantir que o seletor CSS possa selecionar o máximo de conteúdo possível sem destruir a estrutura. . Onde adicionar classes ou quais rótulos usar para distingui-las é uma questão de opinião. Acredito que cada um tenha sua própria experiência. Combinando diferentes rascunhos de design, às vezes é necessário fazer alterações correspondentes. No entanto, essas alterações devem ter a mesma premissa – não destruir a estrutura e a legibilidade do código.

Além disso, devemos perceber que qualquer ferramenta visual é um demônio. Os efeitos apresentados em suas interfaces visuais estão muitas vezes a milhares de quilômetros de distância dos navegadores reais. O que realmente queremos ser compatível é com o navegador, não com a interface visual do editor.

5. CSS não é uma panacéia e não é impossível viver sem CSS.

Comparado com a era CSS1.0, o CSS pode realizar mais coisas hoje. No entanto, a demanda está sempre à frente da tecnologia. O CSS não pode completar todo o trabalho da camada de apresentação das páginas da web. . Outras vezes, usar JS é muito mais simples do que confiar apenas em CSS, e o código é mais bem estruturado – o exemplo mais típico é o menu suspenso. Nessas horas, temos que convencer a nós mesmos, ou aos nossos chefes e clientes, a usar métodos mais simples e razoáveis. Como o DOM também é um componente importante dos padrões de páginas da web, isso não significa que o uso de JS tornará nossas páginas da web menos eficientes ou não mais padronizadas. Pelo contrário, este é o maior mal-entendido sobre JS. Dito isto, devo mencionar que na era atual, toda profissão é obrigada a ter conhecimentos mais relevantes do que nunca. Quem faz design deve saber um pouco sobre interação e produção, e quem faz produção também deve entender de design e programação. , especialmente Com tecnologias front-end como JS, somente dessa forma você e seus colegas poderão trabalhar melhor juntos e suas perspectivas de desenvolvimento pessoal serão melhores.
Nenhum CSS refere-se a quando nosso site falha ao carregar o arquivo CSS devido a vários motivos desconhecidos. Não entre em pânico por causa disso. Se a página da web ainda mantiver boa legibilidade sem CSS, essa conquista será muito mais digna de nosso orgulho do que passar na verificação do W3C.