HTML: incluir ou excluir tags de fechamento opcionais?

149

Algumas tags de fechamento HTML ¹ são opcionais , ou seja:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

Nota: Não confunda com tags de fechamento que são proibidas de serem incluídas, ou seja:

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Nota: xhtml é diferente do HTML. xhtml é uma forma de xml, que requer que cada elemento tenha uma tag de fechamento. A tag de fechamento pode ser proibida em html, mas obrigatória em xhtml.

As tags de fechamento opcionais

idealmente incluído , mas nós os aceitaremos se você os esqueceu, ou
idealmente não incluído, mas nós os aceitaremos se você os colocar

Em outras palavras, devo incluí-los ou não ?

A especificação do HTML 4.01 fala sobre o fechamento de tags de elementos sendo opcional , mas não diz se é preferível incluí-las ou preferível não incluí-las.

Por outro lado, um artigo aleatório no DevGuru diz :

A tag final é opcional. No entanto, recomenda-se que seja incluído.

A razão pela qual pergunto é porque você sabe que é opcional por motivos de compatibilidade; e eles os teriam tornado ( obrigatórios | proibidos ) se pudessem.

Em outras palavras: o que o HTML 1, 2, 3 fez com relação a essas tags de fechamento, agora opcionais. O que o HTML 5 faz? E o que devo fazer?

Nota

Alguns elementos em HTML são proibidos de ter tags de fechamento. Você pode discordar disso, mas essa é a especificação, e não há debate. Estou perguntando sobre tags de fechamento opcionais e qual era a intenção.

Notas de rodapé

¹ HTML 4.01

html html4

— Ian Boyd
fonte

4

Pergunta difícil ... algumas das recomendações do w3c incluem exemplos que fazem os dois: w3.org/TR/html401/struct/global.html#id-and-class O primeiro exemplo tem </p>tags de fechamento e o segundo as omite!

— Richard JP Le Guen

Só para esclarecer - no caso de marcas proibidas em HTML5, o / solução válida XML "explícito" é para fechá-las com um />, como <meta charset="utf-8" />mesmo que <meta charset="utf-8">é HTML5 válido?

— cboettig

@cboettig Sim. <meta charset="utf-8" />é html inválido , deve ser <meta charset="utf-8">. Por outro lado <meta charset="tuf-8">é inválido xhtml, ele deve ser<meta charset="utf-8" />

— Ian Boyd

@IanBoyd realmente? em HTML5? O rascunho do manual do W3C para poliglota html / xhtml diz para uso <meta charset="UTF-8"/>com a tag de fechamento. Caso contrário, como o poliglota ou o xhtml poderiam ser validados como html5 e xml?

— cboettig

@cboettig Você está certo. A marcação poliglota ( por exemplo, documentos XHTML compatíveis com HTML ) não pode ser um HTML 4.01 válido. O HTML5 (ainda um trabalho em andamento) tem a noção de elementos Void - elementos que não podem ter uma tag final . Presumivelmente, a maioria dos navegadores é gentil e perdoa seus erros de marcação.

— Ian Boyd

49

Os opcionais são todos que devem ser semanticamente claros onde terminam, sem a necessidade da tag final. Cada EG <li>implica um </li>se não houver um logo antes dele.

Todas as tags finais proibidas seriam imediatamente seguidas por sua tag final, portanto seria meio redundante digitar <img src="blah" alt="blah"></img>toda vez.

Eu quase sempre uso as tags opcionais (a menos que tenha uma boa razão para não o fazer), porque empresta um código mais legível e atualizável.

— aslum
fonte

18

eu vejo agora. <LI>é como uma bala. Ninguém iria querer envolver um ponto inteiro com marcadores <LI>...</LI>. Dessa forma, LIcorresponde ao que as pessoas escreveriam naturalmente durante a marcação. Sames usa uma marca de parágrafo ( <P>); no processamento de texto, você adiciona uma marca de parágrafo no início de um parágrafo; e não no final de cada um também. Portanto, nessa interpretação, as tags de fechamento são opcionais porque nenhuma pessoa normal pensaria em tê-las. Além disso, o próprio elemento não tem conteúdo - o elemento é o conteúdo.

— 11558 Ian

8

O que você quer dizer com quase sempre uso as tags opcionais - você quer incluir a tag final ou deixá-la de fora ? (Eu tenho a impressão de que você incluir isso, quando li a sua resposta - mas o comentário acima por Ian Boyd me dá a impressão de que você exclui -lo.)

— KajMagnus

3

@IanBoyd E para o último parágrafo?

— Pacerier 15/07/12

22

@ Pacerier As pessoas escrevem parágrafos de texto há centenas de anos. Ninguém nunca ficou confuso quando um parágrafo termina.

— 22812 Ian Boyd

4

Link relevante para HTML5, para quem encontrou esta resposta enquanto tentava encontrar a documentação de referência real: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Há casos em que as tags explícitas ajudam, mas às vezes é pedantismo desnecessário.

Observe que a especificação HTML especifica claramente quando é válido omitir tags, portanto nem sempre é um erro.

Por exemplo, você nunca precisa </body></html>. Ninguém nunca se lembra de colocar <tbody>explicitamente (ao ponto que o XHTML fez exceções).

Você não precisa, a </head><body>menos que tenha scripts de manipulação de DOM que realmente pesquisem <head>(é melhor fechá-lo explicitamente, porque as regras para o fim implícito <head>podem surpreendê-lo).

Listas aninhadas são realmente melhores sem </li>, porque é mais difícil criar uma ul > ulárvore incorreta .

Válido:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Inválido:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

E lembre-se de que as tags finais estão implícitas, se você tenta fechar todos os elementos ou não. A colocação de tags finais não tornará a análise automaticamente mais robusta:

<p>foo <p>bar</p> baz</p>

analisará como:

<p>foo</p><p>bar</p> baz

Só pode ajudar quando você valida documentos.

— Kornel
fonte

4

Aguarde, por que <p>foo <p>bar</p> baz</p>não é analisado como duas ptags aninhadas ?

— Eric

19

Porque um <P>elemento não pode conter elementos no nível do bloco e <P>é um elemento no nível do bloco. De ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "O elemento P representa um parágrafo. Ele não pode conter elementos em nível de bloco (incluindo o próprio P)."

— Ian Boyd

1

@IanBoyd Você quer dizer que não pode conter elementos em nível de bloco, independentemente das regras CSS?

— Pacerier 13/07/12

6

O CSS @Pacerier não pode influenciar o DOM de forma alguma. O DOM é analisado primeiro e, em seguida, o CSS o exibe. A blockexibição de CSS é uma coisa completamente diferente do conteúdo no nível de bloco do HTML (acontece que a maioria dos elementos no nível de bloco HTML é exibida como blocos CSS por padrão).

— Kornel

2

@ anton1980 Não, isso não é o mesmo. O tratamento das tags de fechamento opcionais omitidas é claramente especificado e funciona de maneira confiável em todos os navegadores compatíveis. OTOH uma maquiagem <t>não vai funcionar <title>.

— Kornel

18

Estou adicionando alguns links aqui para ajudá-lo com a história do HTML, para você entender as várias contradições. Esta não é a resposta para sua pergunta, mas você saberá mais depois de ler esses vários resumos.

Alguns trechos de Dive Into HTML5 :

[O] fato de que a marcação HTML “quebrada” ainda funcionava em navegadores da Web levou os autores a criar páginas HTML quebradas. Muitas páginas quebradas. Segundo algumas estimativas, hoje, mais de 99% das páginas HTML da Web têm pelo menos um erro. Mas como esses erros não fazem com que os navegadores exibam mensagens de erro visíveis, ninguém nunca os corrige.

O W3C viu isso como um problema fundamental com a web e decidiu corrigi-lo. O XML, publicado em 1997, rompeu com a tradição de perdoar clientes e determinou que todos os programas que consumiam XML devessem tratar os chamados erros de "boa formação" como fatais. Esse conceito de falha no primeiro erro ficou conhecido como "tratamento draconiano de erros", após o líder grego Draco, que instituiu a pena de morte por infrações relativamente pequenas de suas leis. Quando o W3C reformulou o HTML como um vocabulário XML, eles exigiram que todos os documentos servidos com o novo application/xhtml+xmltipo MIME estivessem sujeitos ao tratamento draconiano de erros. Se houvesse mesmo um único erro de formação na página XHTML […] os navegadores da web não teriam outra opção a não ser interromper o processamento e exibir uma mensagem de erro para o usuário final.

Essa ideia não era universalmente popular. Com uma taxa de erro estimada de 99% nas páginas existentes, a possibilidade sempre presente de exibir erros ao usuário final e a escassez de novos recursos no XHTML 1.0 e 1.1 para justificar o custo, os autores da web basicamente ignoraram application/xhtml+xml. Mas isso não significa que eles ignoraram o XHTML por completo. Oh, definitivamente não. O apêndice C da especificação XHTML 1.0 deu aos autores da web uma brecha: "Use algo que se parece com a sintaxe XHTML, mas continue servindo-o com o text/htmltipo MIME". E foi exatamente isso que milhares de desenvolvedores da Web fizeram: eles “fizeram upgrade” para a sintaxe XHTML, mas continuaram servindo-o com um tipo MIME text / html.

Ainda hoje, milhões de páginas da web afirmam ser XHTML. Eles começam com o tipo de documento XHTML na primeira linha, usam nomes de tags em minúsculas, usam aspas em torno dos valores de atributos e adicionam uma barra final após elementos vazios como <br />e <hr />. Mas apenas uma pequena fração dessas páginas é veiculada com o application/xhtml+xmltipo MIME que acionaria o tratamento draconiano de erros do XML. Qualquer página veiculada com um tipo MIME text/html- independentemente do estilo de tipo , sintaxe ou codificação - será analisada usando um analisador HTML "perdoador", ignorando silenciosamente quaisquer erros de marcação e nunca alertando os usuários finais (ou qualquer outra pessoa), mesmo que as páginas estão tecnicamente quebrados.

O XHTML 1.0 incluiu essa brecha, mas o XHTML 1.1 a fechou, e o XHTML 2.0 nunca finalizado continuou a tradição de exigir tratamento draconiano de erros. E é por isso que existem bilhões de páginas que afirmam ser XHTML 1.0 e apenas algumas que afirmam ser XHTML 1.1 (ou XHTML 2.0). Então você está realmente usando XHTML? Verifique seu tipo MIME. (Na verdade, se você não souber qual o tipo MIME que está usando, posso garantir que ainda está usando text/html.) A menos que você esteja servindo suas páginas com um tipo MIME application/xhtml+xml, o chamado "XHTML" é XML apenas no nome.

[As] pessoas que propuseram o desenvolvimento de formulários HTML e HTML enfrentaram duas opções: desistir ou continuar seu trabalho fora do W3C. Eles escolheram o último, registraram o whatwg.orgdomínio e, em junho de 2004, nasceu o WHAT Working Group .

O grupo de trabalho que estava silenciosamente trabalhando em algumas outras coisas também. Uma delas era uma especificação, inicialmente apelidada de Web Forms 2.0 , que adicionava novos tipos de controles aos formulários HTML. (Você aprenderá mais sobre formulários da Web em A Form of Madness .) Outra era uma especificação de rascunho chamada “Aplicativos da Web 1.0”, que incluía novos recursos importantes, como uma tela de desenho em modo direto e suporte nativo a áudio e vídeo sem plug-ins .

Em outubro de 2009, o W3C encerrou o Grupo de Trabalho XHTML 2 e emitiu esta declaração para explicar sua decisão :

Quando o W3C anunciou os Grupos de Trabalho HTML e XHTML 2 em março de 2007, indicamos que continuaríamos monitorando o mercado do XHTML 2. O W3C reconhece a importância de um sinal claro para a comunidade sobre o futuro do HTML.

Embora reconheçamos o valor das contribuições do Grupo de Trabalho XHTML 2 ao longo dos anos, após discussão com os participantes, a gerência do W3C decidiu permitir que o estatuto do Grupo de Trabalho expire no final de 2009 e não o renove.

Os que vencem são os que são enviados.

— Srikar Doddi
fonte

12

O motivo pelo qual pergunto é porque você sabe que é opcional por motivos de compatibilidade; e eles os teriam tornado (obrigatórios | proibidos) se pudessem.

Essa é uma inferência interessante. Minha leitura é que, sempre que uma tag pode ser inferida com segurança, a tag é opcional. O design sugere que a intenção era torná-lo rápido e fácil de escrever.

O que o HTML 1, 2, 3 fez com relação a essas, agora opcionais, tags de fechamento.

O DTD para HTML 2 está incorporado no RFC que, juntamente com o DTD HTML original , possui tags de início e fim opcionais em todo o local.

O HTML 3 foi abandonado (graças às guerras do navegador) e substituído pelo HTML 3.2 (que foi projetado para descrever o estado atual da web).

O que o HTML 5 faz?

O HTML 5 foi voltado para "pavimentar os caminhos" desde o início.

E o que devo fazer?

Ah, agora isso é subjetivo e argumentativo :)

Algumas pessoas pensam que as tags explícitas são melhores para facilitar a leitura e a manutenção em virtude de estar diante dos olhos dos leitores.

Algumas pessoas pensam que as tags inferidas são melhores para facilitar a leitura e a manutenção devido a não sobrecarregar o editor.

— Quentin
fonte

1

+1 eu não tinha pensado na noção de "inferido com segurança". Então isso defende a ideia de que não havia realmente nenhuma intenção de uma maneira ou de outra. presumi que a especificação estivesse tentando ser o mais compatível possível com o conteúdo HTML existente e as especificações HTML.

— Ian Boyd

Desculpe Dave, eu dei para aslum; ele precisa do representante :) Mas você tem a mesma idéia, com mais conteúdo vinculado e citado. Mas boa resposta.

— 11558 Ian Mcdonald

8

O que o HTML 5 faz?

A resposta a esta pergunta está no rascunho de trabalho do W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

E o que devo fazer?

É uma questão de estilo. Tento nunca omitir tags finais, porque isso me ajuda a ser rigoroso e não omitir tags necessárias.

— ghoppe
fonte

+1 no link para o rascunho da especificação HTML 5 e a seção apropriada. Mas o html 5 não diz de um jeito ou de outro.

— Ian Boyd

6

Se for supérfluo, deixe de fora.

Se ele serve a um propósito (mesmo um propósito aparentemente trivial, como apaziguar seu IDE ou apaziguar seus olhos), deixe-o dentro.

Em uma especificação bem definida, é raro ver itens opcionais que não afetam o comportamento. Com exceção de "comentários", é claro. Mas a especificação HTML é menos uma especificação de design e mais um documento do estado das principais implementações atuais. Portanto, quando um item é opcional em HTML e parece não ter nenhum objetivo, podemos supor que a natureza opcional seja apenas a documentação de uma peculiaridade em um navegador específico.

Observando a seção RFC de especificação do HTML-5 vinculada acima, você vê que as tags opcionais estão estranhamente vinculadas à presença de comentários! Isso deve lhe dizer que os autores não estão usando chapéus de design. Eles estão jogando o jogo de "documentar as peculiaridades" nas principais implementações. Portanto, não podemos levar as especificações muito a sério a esse respeito.

Então, a solução é: não se preocupe. Vá para algo que realmente importa. :)

— John
fonte

5

Acho que a melhor resposta é incluir tags de fechamento para legibilidade ou detecção de erros. No entanto, se você tiver muito HTML gerado (digamos, tabelas de dados), poderá economizar largura de banda significativa, omitindo tags opcionais.

— Gabe
fonte

2

Richard: Quando você tem estruturas profundamente aninhadas, é muito mais fácil encontrar erros porque as tags de fechamento fornecem mais informações sobre a intenção.

— Gabe

1

Eu acho que "tags de fechamento fornecem mais informações sobre a intenção" é a melhor resposta concisa para essa pergunta. Argumenta uma boa razão clara de uma maneira ou de outra.

— Squarecandy

4

Minha recomendação é que você omita a maioria das tags de fechamento opcionais e todos os atributos opcionais com os quais você pode se safar. Muitos IDEs irão reclamar, portanto, talvez você não consiga omitir alguns deles, mas geralmente é melhor para um tamanho de arquivo menor e menos confusão. Se você tiver geradores de código, definitivamente omita as tags finais porque poderá obter uma boa redução de tamanho. Normalmente, isso realmente não importa, de um jeito ou de outro.

Mas quando isso importa, aja de acordo. Em algum trabalho recente, pude reduzir o tamanho do meu HTML renderizado de 1,5 MB para 800 KB, eliminando a maioria dos atributos gerados de final e valor redundante para a tag aberta, onde o texto do elemento era o mesmo que o valor. Eu tenho cerca de 200 tags. Eu poderia implementar isso de alguma outra maneira, mas isso seria mais trabalhoso ($$$), portanto, isso me permite tornar a página mais responsiva.

Por curiosidade, descobri que, se eu removesse aspas em torno de atributos que não precisavam deles, eu poderia economizar 20 KB, mas meu IDE (Visual Studio) não gosta. Também fiquei surpreso ao descobrir que o ID realmente longo que o ASP.NET gera é responsável por 20% do meu arquivo.

A idéia de que poderíamos obter qualquer fração relevante do HTML estritamente válida foi equivocada em primeiro lugar, assim como o que funciona melhor para você e seus clientes. A maioria das ferramentas que eu já vi ou usei diz que elas geram xhtml, mas na verdade não funcionam 100% e, de qualquer maneira, não há nenhum benefício para a aderência estrita.

— user1777246
fonte

Mal posso aceitar a omissão de tags finais opcionais, mas acho uma péssima idéia omitir aspas nos atributos. Você está arriscando seu site para invadir alguns navegadores dessa maneira. Se você tem arquivos html de 800kb, está fazendo algo muito errado.

— Christoph

2

@Christoph: Omitir tags finais opcionais (como </p>ou </li>) é perfeitamente adequado de acordo com a especificação HTML. Se o navegador não entender isso, será um problema com o navegador.

— precisa saber é o seguinte

2

Pessoalmente, sou fã de XHTML e, como o ghoppe, "tento nunca omitir tags finais, porque isso me ajuda a ser rigoroso e não omitir tags necessárias".

mas

Se você estiver usando deliberadamente o HTML 4.n, não se pode argumentar que a inclusão deles facilita o consumo do documento, pois a noção de boa formação em oposição à validade é um conceito XML e você perde esse benefício quando proibir determinadas tags fechadas. Portanto, o único problema se torna validade ... e se ainda é válido sem eles ... você também pode economizar a largura de banda, não?

— Richard JP Le Guen
fonte

2

O uso de tags finais facilita o tratamento de fragmentos, porque seu comportamento não depende de elementos irmãos. Só este motivo deve ser convincente o suficiente. Alguém mais lida com documentos html monolíticos?

— CurtainDog
fonte

1

Em algumas linguagens de colchetes, como C #, você pode omitir os colchetes em torno de uma instrução if, se tiver apenas duas linhas. por exemplo...

if ([condição])
[código]

mas você não pode fazer isso ...

if ([condição])
[código]
[código]

a terceira linha não fará parte da instrução if. isso prejudica a legibilidade, e os bugs podem ser facilmente introduzidos e difíceis de encontrar.

pelas mesmas razões, eu fecho todas as tags. tags como a tag img ainda precisam ser fechadas, mas não com uma tag de fechamento separada.

— MiguelR
fonte

Você poderia dar um exemplo de HTML tão complicado? Na minha experiência, as tags finais opcionais não são tão enganosas.

— Kornel

Lembro-me de ter um problema com o IE7 há alguns anos atrás, onde encontrei uma tag li de abertura em uma linha separada do texto que continha, sem li de fechamento, o IE7 tratava todas as balas como uma grande bala. colocar a tag e o texto em uma linha ou fechar a tag resolveria o problema. No entanto, não consigo reproduzir isso agora, então provavelmente também tinha algo a ver com o CSS em jogo. mas eu não culpo você por considerar isso como um "eu tenho uma namorada totalmente ... no Canadá!" história.

— MiguelR

0

Se você estivesse escrevendo um analisador de HTML, seria mais fácil analisar o HTML que incluía tags de fechamento opcionais ou o HTML que não? Acho que a presença de tags de fechamento opcionais facilitaria, pois não seria necessário inferir onde deveria estar a tag de fechamento.

Por esse motivo, sempre incluo as tags de fechamento opcionais - na teoria de que minha página pode renderizar mais rapidamente, pois estou criando menos trabalho para o analisador HTML do navegador.

— Joel Mueller
fonte

1

Discordo; a noção de boa formação em oposição à validade é um conceito somente XML e se torna irrelevante quando você tem elementos cujas tags de fechamento são proibidas .

— Richard JP Le Guen

1

Entendo isso, mas o elemento DOM renderizado tem um começo e um fim, mesmo que sua tag HTML não. Se você incluir uma <li>tag sem tag de fechamento, em algum momento o navegador terá que decidir onde o elemento termina e agir como se você tivesse colocado uma tag final nesse ponto. Isso pode ser uma quantidade relativamente trivial de lógica, mas "alguns" ainda é mais que "nenhum" e não acho irracional supor que deixar de fora as tags finais opcionais faça mais trabalho para o navegador do que incluí-las.

— Joel Mueller

É um ponto interessante, mas ainda discordo; as tags de fechamento são opcionais, pois seriam necessárias e, portanto, implícitas de acordo com as regras de validação ... portanto, quando o analisador chega a um ponto em que deve haver uma tag de fechamento de acordo com a validação, não se pode argumentar que a tarefa de consumir uma tag de fechamento (quando presente) reduziria a velocidade?

— Richard JP Le Guen

@ Richard - Eu acho que isso depende da implementação real em um navegador específico, mas eu tenho dificuldade em creditar a ideia de que ser explícito sobre onde você quer que um elemento termine seria pior para o desempenho do que dizer ao navegador para descobrir isso. vocês.

— Joel Mueller

@RichardJPLeGuen Acho que tudo depende da aparência exata das regras. Quando você fecha um </table>e sua pilha contém <table><tbody><tr><td>, você pode simplesmente fechar tudo até combinar com o <table>. Da mesma forma, para abrir <p>em um contexto que não seja do relógio. Mas pode haver casos muito mais difíceis, não sei.

— Maaartinus 27/05

-1

Faça o que achar melhor para tornar o código mais legível e sustentável.

Pessoalmente, eu sempre estaria inclinado a fechar <td>e <tr>, mas nunca me incomodaria <li>.

— Matthew Wilson
fonte

1

Eu esperava alguma orientação sobre a decisão de design original e que eles teriam feito x se pudessem.

— 11558 Ian

Qual é a diferença entre <td>e <li>isso faz você não se preocupar <li>? Para mim, há pouca diferença.

— ghoppe

Não há diferença técnica, é puramente subjetiva. Sinto que posso ler melhor o HTML se fechar td e tr. Mas nunca senti a necessidade de li.

— Matthew Wilson

-2

Para tipos de fechamento proibidos, use sintaxe como: <img /> Com o />para fechar a tag que é aceita em xml

— Dani
fonte

1

Ele não funciona no HTML4 (corresponde à sintaxe SGML obscura que faz algo ligeiramente diferente). No HTML5 é permitido, mas sem sentido.

— Kornel