homeyou

Aninhamento

DICA: Sempre anule seus elementos HTML corretamente! Basicamente, isso significa que você deve fechar as coisas na ordem inversa, você as abriu.

As aves fazem isso, abelhas não fazem isso (eles simplesmente explodem nas colméias), e os autores HTML precisam fazê-lo se quiserem que suas páginas tenham sintaxe válida. É chamado de "aninhamento", e descreve o relacionamento estrutural de diferentes elementos delimitados pela abertura e fechamento de tags em um documento HTML.

O que é o aninhamento?

O princípio básico é que um documento HTML consiste em uma série de elementos que são contêineres, com conteúdos consistindo em caracteres e possivelmente outros elementos "aninhados" dentro deles. Existem várias regras de sintaxe sobre o tipo de elementos que podem conter o tipo de outros elementos (basicamente, elementos de "nível de bloco" como <P> e <BLOCKQUOTE> pode conter elementos de nível de personagem como <EM> e <FONT> mas não o contrário), mas a regra mais importante é que os elementos devem sempre ser contidos inteiramente em outros elementos, não sobrepostos. Eles são como as bonecas russas que contêm outras bonecas, uma dentro de outra; Você não pode ter uma boneca que está meio contida em uma outra boneca e meio contida em uma terceira. É tudo em tudo ou fora.

Os desenvolvedores da Web que não entendem esse princípio muitas vezes pensam em tags de uma maneira que os puristas do HTML ridicularizam como "Tag Soup". Nessa mentalidade, as tags são "comandos de formatação" executados sequencialmente pelo navegador, fazendo com que ações específicas sejam realizadas como "ativar negrito", "desativar itálico", etc. Tomando essa visão, pode-se produzir esse código inválido código:

<B>This is bold <I>and this is also italic</B>, but what is this?</I>

"Tag Soup "esperam que as últimas quatro palavras acima sejam mostradas em itálico não em negrito, já que boldfacing foi" desligado "por </B> mas a itálica ainda está "ligada". Mas não é assim que o HTML funciona. Os elementos B e I aqui foram configurados de forma sobreposta, o que é uma violação das regras de aninhamento de HTML. Então, é o que alguém imagina como um navegador pode realmente renderizar o texto. Qualquer renderização será baseada nas regras de correção de erros do navegador e não nas especificações HTML, nas quais a função desse código malformado como esta é indefinida. Portanto, pode variar muito entre navegadores diferentes, mesmo que todos os navegadores sigam as especificações. Algumas versões do Netscape, por exemplo, trataram a tag </B> como se fosse </I>, e a tag </I> como se fossem </B>, assim fechando os elementos em sua ordem corretamente aninhada. Assim, a parte final da frase terminou em negrito não itálico, provavelmente não o que o autor da web pretendia. Outros navegadores podem fazer outras coisas em suas tentativas de corrigir erros. Não confie neles fazendo o que quiser; use o código correto para começar!

Claro, pode-se ficar ainda pior do que o exemplo acima. Alguém postou para um grupo de notícias de autoria HTML que ele estava tendo problemas com fontes que não aparecem nas cores pretendidas em alguns navegadores. Aconteceu que seu site estava cheio de uma longa seqüência de tags como <FONT COLOR="#FF0000"> <H2>Header</H2> <FONT COLOR="#000000">... configurando a cor para vermelho, depois em preto, e assim por diante, sem uma única tag FONT de fechamento no grupo. Isso claramente derivou de uma mentalidade equivocada de que as tags eram comandos para mudar a cor, que poderia ficar preso no código em qualquer lugar onde o autor quer que algo apareça de uma cor diferente do que foi antes. Às vezes, pode funcionar de acordo com a correção de erros do navegador, mas você não pode contar com isso. No caso do site mencionado no grupo de notícias, o Firefox conseguiu obter as cores corretas para vários títulos, então alguma pilha transbordou ou algo assim, e o resto da página foi exibido com texto preto, independentemente das tags de fonte subseqüentes. A maneira correta de pensar nas tags FONT é que as tags de abertura e fecho de um elemento FONT delimitam o alcance do texto que deve ser renderizado nessa cor. Além disso, uma vez que um elemento FONT é de nível de caractere, e cabeçalhos como H2 são de nível de bloco, o último não pode aninhar dentro do primeiro. Você deve ter suas tags de fonte de abertura e fechamento dentro do elemento H2 ... ou, melhor ainda, dispensar as tags FONT e usar classes de estilo para sugerir cores de cabeçalho. (Infelizmente, o cartaz do grupo de notícias recusou-se firmemente a ter uma pista sobre isso, acho que, depois de alguns ajustes de seu site, um pouco - sorta funcionou, naquela época, mas ainda estava tão mal inserido como sempre.)

Tags de fechamento opcionais

Algumas marcas de fechamento podem ser omitidas. Por exemplo, um parágrafo é iniciado com <P> e finalizado com </P>, mas a tag de fechamento pode ser deixada de fora. A razão é que os parágrafos não podem ser aninhados dentro de outros parágrafos, então a abertura <P> Para o próximo parágrafo pode ser assumido pelo navegador para fechar também o parágrafo anterior. Qualquer outra tag de abertura ou fechamento de nível de bloco também pode assumir que feche qualquer parágrafo que esteja em andamento quando essa tag for atingida, uma vez que violaria as regras de nidificação para que o parágrafo continue em uma dessas tags.

Aliás, na primeira implementação do HTML, às vezes referido como "HTML 1.0", embora nunca tenha havido uma especificação formal para essa versão (isso não aconteceu até o HTML 2.0), a tag do parágrafo era uma "quebra de parágrafo" vazia gostar <BR> é uma quebra de linha. Não existe uma tag como </BR>, uma vez que a quebra de linha é uma "tag vazia" que não é um recipiente. A tag de parágrafo costumava ser assim, mas em HTML 2.0 foi alterado para ser um contêiner, pois permanece agora. No entanto, alguns dos primeiros tutoriais em desenvolvimento de HTML foram baseados em HTML 1.0 e tratados <P> como um "intervalo de parágrafo" vazio, e pessoas suficientes aprenderam dessa forma e ensinaram aos outros o mesmo (muito tempo depois disso era obsoleto) de que o uso indevido de <P> como uma "pausa de parágrafo" em vez de um "contentor de parágrafo" ainda é desenfreado. Eu até usei isso dessa forma, desde o início, mas para me forçar a usar a tag corretamente, eu comecei a praticar sempre usando o fechamento </P> tag, mesmo que isso seja opcional, para garantir que mantenho a mentalidade adequada em relação ao elemento como um recipiente com um começo e um fim. Você pode dizer que um desenvolvedor do site tem a atitude obsoleta sobre tags de parágrafo se você achar que a tag <P> estão sempre no fim de parágrafos, e não há um antes do primeiro parágrafo.

Outras tags de fechamento opcionais são </TR> e a tag </TD> no fim da tabela linha e elementos. Mas você não deve omiti-los de qualquer maneira, uma vez que alguns navegadores foram conhecidos por bagunçar na apresentação de mesas com eles ausentes. E lembre-se que a tag de fechamento </TABLE> para a mesa não é opcional e alguns navegadores (mais notavelmente o Netscape) não mostrarão ao usuário nenhum conteúdo da tabela se a tag de fechamento for omitida.

Eu consegui um pouco de um argumento on-line uma vez com alguém que defendeu que os padrões HTML deveriam ser alterados para permitir uma sintaxe mais indulgente nas áreas de nidificação e as tags de fechamento necessárias. O problema é que as mudanças que ela queria eram basicamente mutuamente exclusivas; Se você for mais indulgente ao permitir um ninho ruim, então é ainda mais difícil determinar inequivocamente o ponto em que se pode inferir o fim de um elemento na ausência de uma marca de fechamento explícita. E, a julgar pela sintaxe real de algumas de suas próprias páginas da web, ela aparentemente acreditava que a tag de fechamento </TABLE> deve ser inferido pela presença da tag de abertura <TABLE> tag da próxima tabela na página. Mas isso é impossível, uma vez que as mesas podem aninhar umas nas outras; quaisquer novas regras de sintaxe que inferiram tabela fechadores desta forma "quebrar" milhares de páginas existentes que dependem de tabelas aninhadas. Se o uso de tabelas aninhadas para o layout da página é uma boa idéia é outro assunto para o debate (aquecido), mas o fato é que existem muitas páginas que o fazem, e não é uma boa idéia apresentar um novo padrão HTML que faz com que todos parem de funcionar; isso viola o conceito de maximizar a compatibilidade entre as versões de padrões sucessivas para que, na medida do possível, os navegadores antigos ainda possam visualizar novas páginas, e os novos navegadores ainda podem visualizar páginas antigas, com o conteúdo básico intacto, mesmo que os últimos sinos e assobios tenham ganhado Trabalhar nesses casos.