HTML: includere o escludere tag di chiusura opzionali?

149

Alcuni tag di chiusura HTML ¹ sono opzionali , ovvero:

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

Nota: da non confondere con i tag di chiusura che è vietato includere, ovvero:

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

Nota: xhtml è diverso dall'HTML. xhtml è una forma di xml, che richiede che ogni elemento abbia un tag di chiusura. Un tag di chiusura può essere proibito in html, ma obbligatorio in xhtml.

Sono i tag di chiusura opzionali

idealmente incluso , ma li accetteremo se li hai dimenticati, o
idealmente non incluso, ma li accetteremo se li inserirai

In altre parole, dovrei includerli o non dovrei includerli?

La specifica HTML 4.01 parla del fatto che i tag degli elementi di chiusura siano facoltativi , ma non dice se è preferibile includerli o preferire non includerli.

D'altra parte, un articolo casuale su DevGuru dice :

Il tag finale è facoltativo. Tuttavia, si consiglia di includerlo.

Il motivo che mi chiedo è perché basta sapere che è facoltativa per motivi di compatibilità; e li avrebbero resi ( obbligatori | vietati ) se avessero potuto.

Detto in altro modo: cosa hanno fatto HTML 1, 2, 3 riguardo a questi tag di chiusura, ora facoltativi. Cosa fa HTML 5? E che cosa dovrebbe io fare?

Nota

Ad alcuni elementi in HTML è vietato avere tag di chiusura. Potresti non essere d'accordo con quello, ma questa è la specifica, e non è in discussione. Sto chiedendo dei tag di chiusura opzionali e quale fosse l'intenzione.

Le note

¹ HTML 4.01

html html4

— Ian Boyd
fonte

4

Domanda difficile ... alcune delle raccomandazioni di w3c includono anche esempi che fanno entrambe le cose: w3.org/TR/html401/struct/global.html#id-and-class Il primo esempio ha </p>tag di chiusura e il secondo li omette!

— Richard JP Le Guen,

Giusto per chiarire: nel caso di tag proibiti in HTML5, la soluzione valida "esplicita" / XML è quella di chiuderli con un />, come <meta charset="utf-8" />se anche se <meta charset="utf-8">è HTML5 valido?

— cboettig,

@cboettig Sì. non<meta charset="utf-8" /> è html non valido , deve essere <meta charset="utf-8">. D'altra parte non<meta charset="tuf-8"> è xhtml non valido , deve essere<meta charset="utf-8" />

— Ian Boyd il

@IanBoyd davvero? in HTML5? La bozza del manuale W3C per polyglot html / xhtml dice di usare <meta charset="UTF-8"/>con il tag di chiusura. Altrimenti come potrebbero mai validare polyglot o xhtml come html5 e xml?

— cboettig,

@cboettig Hai ragione. Il markup Polyglot (ovvero documenti XHTML compatibili con HTML ) non può essere HTML 4.01 valido. HTML5 (ancora un work in progress) ha la nozione di elementi Void - elementi che non possono avere un tag end . Presumibilmente la maggior parte dei browser è delicata e perdonerà i tuoi errori di markup.

— Ian Boyd,

49

Quelli facoltativi sono tutti quelli che dovrebbero essere semanticamente chiari su dove finiscono, senza bisogno del tag end. EG <li>implica ciascuno un </li>se non ce n'è uno prima di esso.

Tutti i tag di fine proibiti sarebbero immediatamente seguiti dal loro tag di fine, quindi sarebbe un po 'ridondante dover digitare <img src="blah" alt="blah"></img>ogni volta.

Uso quasi sempre i tag opzionali (a meno che non abbia un ottimo motivo per non farlo) perché si presta a codice più leggibile e aggiornabile.

— aslum
fonte

18

ora lo vedo. <LI>è come un proiettile. Nessuno vorrebbe dover racchiudere un intero punto <LI>...</LI>. Quindi in questo modo LIcorrisponde a ciò che la gente scriverà naturalmente durante il markup. Sames indica un segno di paragrafo ( <P>), nell'elaborazione di testi aggiungi un segno di paragrafo all'inizio di un paragrafo; e non alla fine anche di tutti. Quindi in questa interpretazione i tag di chiusura sono opzionali perché nessuna persona normale potrebbe pensare di averli. Inoltre, l'elemento stesso non ha contenuto: l'elemento è il contenuto.

— Ian Boyd,

8

Che cosa intendi per uso quasi sempre dei tag opzionali : vuoi dire che includi il tag end o che lo lasci fuori ? (Ho avuto l'impressione che la includessi , quando ho letto la tua risposta - ma il commento sopra di Ian Boyd mi dà l'impressione che tu la escluda .)

— KajMagnus,

3

@IanBoyd E per l'ultimo paragrafo?

— Pacerier,

22

@Pacerier People ha scritto paragrafi di testo per centinaia di anni. Nessuno è mai stato confuso quando un paragrafo finisce.

— Ian Boyd,

4

Link pertinente per HTML5, per coloro che hanno trovato questa risposta durante il tentativo di trovare la documentazione di riferimento effettiva: w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

Ci sono casi in cui i tag espliciti aiutano, ma a volte è inutile pedanteria.

Nota che le specifiche HTML specificano chiaramente quando è valido omettere i tag, quindi non è sempre un errore.

Ad esempio non hai mai bisogno </body></html>. Nessuno si ricorda mai di mettere <tbody>esplicitamente (al punto che XHTML ha fatto eccezioni per questo).

Non è necessario a </head><body>meno che non si disponga di script di manipolazione DOM che effettivamente effettuano ricerche <head>(quindi è meglio chiuderlo esplicitamente, perché le regole per la fine implicita di <head>potrebbero sorprenderti).

Gli elenchi nidificati in realtà stanno meglio senza </li>, perché è più difficile creare un ul > ulalbero errato .

Valido:

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

Non valido:

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

E tieni presente che i tag di fine sono impliciti se provi a chiudere tutti gli elementi o meno. Mettere i tag di fine non renderà automaticamente l'analisi più solida:

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

analizzerà come:

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

Può aiutare solo quando si convalidano i documenti.

— Kornel
fonte

4

Aspetta, perché <p>foo <p>bar</p> baz</p>non viene analizzato come due ptag nidificati ?

— Eric

19

Perché un <P>elemento non può contenere elementi a livello di blocco ed <P>è un elemento a livello di blocco. Da ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "L'elemento P rappresenta un paragrafo. Non può contenere elementi a livello di blocco (incluso lo stesso P)."

— Ian Boyd,

1

@IanBoyd Vuoi dire che non può contenere elementi a livello di blocco indipendentemente dalle regole CSS?

— Pacerier,

6

@Pacerier CSS non può influenzare DOM in alcun modo. Viene prima analizzato DOM e quindi CSS lo visualizza. La blockvisualizzazione CSS è completamente diversa dal contenuto a livello di blocco HTML (accade semplicemente che la maggior parte degli elementi a livello di blocco HTML siano visualizzati come blocchi CSS per impostazione predefinita).

— Kornel,

2

@ anton1980 No, questo non è lo stesso. La gestione dei tag di chiusura opzionali omessi è chiaramente specificata e funziona in modo affidabile in tutti i browser conformi. OTOH un trucco <t>non funzionerà come <title>.

— Kornel,

18

Sto aggiungendo alcuni link qui per aiutarti con la storia dell'HTML, affinché tu possa capire le varie contraddizioni. Questa non è la risposta alla tua domanda, ma ne saprai di più dopo aver letto questi vari digest.

Alcuni estratti da Dive Into HTML5 :

Il fatto che il markup HTML "non funzionante" continuasse a funzionare nei browser Web ha portato gli autori a creare pagine HTML non funzionanti. Molte pagine spezzate. Secondo alcune stime, oltre il 99% delle pagine HTML sul Web oggi presenta almeno un errore. Ma poiché questi errori non fanno sì che i browser visualizzino messaggi di errore visibili, nessuno li corregge mai.

Il W3C ha visto questo come un problema fondamentale con il web e ha deciso di correggerlo. XML, pubblicato nel 1997, si spezzò dalla tradizione di perdonare i clienti e imponeva che tutti i programmi che consumavano XML dovessero considerare fatali i cosiddetti errori di "buona forma". Questo concetto di fallimento del primo errore divenne noto come "gestione degli errori draconiani", dopo che il leader greco Draco che istituì la pena di morte per infrazioni relativamente minori delle sue leggi. Quando il W3C ha riformulato l'HTML come vocabolario XML, ha imposto che tutti i documenti serviti con il nuovo application/xhtml+xmltipo MIME sarebbero soggetti alla draconiana gestione degli errori. Se nella vostra pagina XHTML fosse presente anche un singolo errore di buon formato […] i browser Web non avrebbero altra scelta che interrompere l'elaborazione e visualizzare un messaggio di errore all'utente finale.

Questa idea non era universalmente popolare. Con un tasso di errore stimato del 99% sulle pagine esistenti, la possibilità sempre presente di visualizzare gli errori per l'utente finale e la scarsità di nuove funzionalità in XHTML 1.0 e 1.1 per giustificare il costo, gli autori del Web hanno sostanzialmente ignorato application/xhtml+xml. Ma ciò non significa che abbiano ignorato del tutto XHTML. Oh, sicuramente no. L'Appendice C della specifica XHTML 1.0 ha dato una scappatoia agli autori web del mondo: "Usa qualcosa che assomigli alla sintassi XHTML, ma continua a servirla con il text/htmltipo MIME". Ed è esattamente quello che hanno fatto migliaia di sviluppatori web: hanno "aggiornato" la sintassi XHTML ma hanno continuato a servirlo con un tipo MIME text / html.

Ancora oggi, milioni di pagine Web dichiarano di essere XHTML. Iniziano con il doctype XHTML sulla prima riga, usano nomi di tag minuscoli, usano virgolette attorno ai valori degli attributi e aggiungono una barra finale dopo elementi vuoti come <br />e <hr />. Ma solo una piccola parte di queste pagine viene fornita con il application/xhtml+xmltipo MIME che innescherebbe la draconiana gestione degli errori di XML. Qualsiasi pagina pubblicata con un tipo MIME di text/html- indipendentemente da doctype, sintassi o stile di codifica - verrà analizzata utilizzando un parser HTML "perdonatore", ignorando silenziosamente eventuali errori di markup e non avvisando mai gli utenti finali (o chiunque altro) anche se le pagine sono tecnicamente rotti.

XHTML 1.0 includeva questa scappatoia, ma XHTML 1.1 lo ha chiuso e l'XHTML 2.0 mai finalizzato ha continuato la tradizione di richiedere la gestione degli errori draconiani. Ed è per questo che ci sono miliardi di pagine che affermano di essere XHTML 1.0 e solo una manciata che afferma di essere XHTML 1.1 (o XHTML 2.0). Quindi stai davvero usando XHTML? Controlla il tuo tipo MIME. (In realtà, se non sai quale tipo MIME stai usando, posso praticamente garantire che stai ancora usando text/html.) A meno che tu non stia offrendo le tue pagine con un tipo MIME di application/xhtml+xml, il tuo cosiddetto "XHTML" XML è solo nel nome.

[T] le persone che avevano proposto l'evoluzione dei moduli HTML e HTML hanno dovuto affrontare due scelte: rinunciare o continuare il loro lavoro al di fuori del W3C. Hanno scelto quest'ultimo, hanno registrato il whatwg.orgdominio e nel giugno 2004 è nato il WHAT Working Group .

Quello che il gruppo di lavoro stava lavorando tranquillamente anche su alcune altre cose. Uno di questi era una specifica, inizialmente soprannominata Web Forms 2.0 , che aggiungeva nuovi tipi di controlli ai moduli HTML. (Imparerai di più sui moduli web in A Form of Madness .) Un'altra era una specifica di bozza chiamata "Web Applications 1.0", che includeva nuove importanti funzionalità come una tela di disegno in modalità diretta e il supporto nativo per audio e video senza plugin .

Nell'ottobre 2009, il W3C ha chiuso il gruppo di lavoro XHTML 2 e rilasciato questa dichiarazione per spiegare la loro decisione :

Quando il W3C ha annunciato i gruppi di lavoro HTML e XHTML 2 nel marzo 2007, abbiamo indicato che avremmo continuato a monitorare il mercato di XHTML 2. Il W3C riconosce l'importanza di un chiaro segnale per la comunità sul futuro dell'HTML.

Mentre riconosciamo il valore dei contributi del gruppo di lavoro XHTML 2 nel corso degli anni, dopo aver discusso con i partecipanti, il management del W3C ha deciso di consentire alla carta del gruppo di lavoro di scadere alla fine del 2009 e di non rinnovarla.

Quelli che vincono sono quelli che spediscono.

— Srikar Doddi
fonte

12

Il motivo per cui ti chiedo è perché sai solo che è facoltativo per motivi di compatibilità; e li avrebbero resi (obbligatori | vietati) se avessero potuto.

Questa è un'inferenza interessante. La mia lettura è che quasi ogni volta che un tag può essere dedotto in modo affidabile, il tag è facoltativo. Il design suggerisce che l'intenzione era di renderlo semplice e veloce da scrivere.

Cosa hanno fatto HTML 1, 2, 3 rispetto a questi, ora facoltativi, tag di chiusura.

Il DTD per HTML 2 è incorporato nell'RFC che, insieme al DTD HTML originale , ha tag di inizio e fine opzionali ovunque .

HTML 3 è stato abbandonato (grazie alle guerre del browser) e sostituito con HTML 3.2 (che è stato progettato per descrivere lo stato attuale del web).

Cosa fa HTML 5?

HTML 5 è stato orientato verso "spianare i sentieri" fin dall'inizio.

E cosa dovrei fare?

Ah, ora è soggettivo e polemico :)

Alcune persone pensano che i tag espliciti siano migliori per la leggibilità e la manutenibilità in virtù dell'essere davanti agli occhi dei lettori.

Alcune persone pensano che i tag dedotti siano migliori per la leggibilità e la manutenibilità in quanto non ingombrano l'editor.

— Quentin
fonte

1

+1 non avevo pensato al concetto di "inferimento affidabile". Quindi ciò sostiene l'idea che in un modo o nell'altro non ci fosse davvero alcuna intenzione. supponevo che la specifica stesse tentando di essere il più compatibile possibile con il contenuto HTML e le specifiche HTML esistenti.

— Ian Boyd,

Mi dispiace, Dave, l'ho dato ad Aslum; ha bisogno del rappresentante :) Ma tu hai la stessa idea, con più contenuti collegati e citati. Ma bella risposta.

— Ian Boyd,

8

Cosa fa HTML 5?

La risposta a questa domanda è nel Draft di lavoro del W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission

E cosa dovrei fare?

È una questione di stile. Cerco di non omettere mai i tag di fine perché mi aiuta a essere rigoroso e non a omettere i tag necessari.

— ghoppe
fonte

+1 per il collegamento alla bozza delle specifiche HTML 5 e la sezione appropriata. Ma HTML 5 non dice in un modo o nell'altro.

— Ian Boyd,

6

Se è superfluo, lascialo fuori.

Se serve a uno scopo (anche uno scopo apparentemente banale, come placare il tuo IDE o placare i tuoi occhi), lascialo entrare.

È raro in una specifica ben definita vedere elementi opzionali che non influiscono sul comportamento. Ad eccezione dei "commenti", ovviamente. Ma le specifiche HTML sono meno di una specifica di progettazione e più di un documento sullo stato delle attuali importanti implementazioni. Pertanto, quando un elemento è facoltativo in HTML e sembra non avere alcuno scopo, possiamo supporre che la natura facoltativa sia semplicemente la documentazione di una stranezza in un browser specifico.

Guardando la sezione RFC delle specifiche HTML-5 collegata sopra, vedi che i tag opzionali sono stranamente collegati alla presenza di commenti! Ciò dovrebbe dirti che gli autori non indossano cappelli di design. Stanno invece giocando a "documentare le stranezze" nelle principali implementazioni. Quindi non possiamo prendere le specifiche troppo sul serio in questo senso.

Quindi, la soluzione è: non sudare. Passa a qualcosa che conta davvero. :)

— John
fonte

5

Penso che la risposta migliore sia quella di includere tag di chiusura per la leggibilità o il rilevamento degli errori. Tuttavia, se hai molti HTML generati (ad esempio tabelle di dati), puoi risparmiare una larghezza di banda significativa omettendo i tag opzionali.

— Gabe
fonte

2

Richard: Quando hai strutture profondamente annidate, è molto più facile trovare errori perché i tag di chiusura forniscono maggiori informazioni sull'intento.

— Gabe,

1

Penso che "la chiusura dei tag fornisca ulteriori informazioni sull'intento" è la migliore risposta concisa a questa domanda. Sostiene una buona ragione chiara in un modo o nell'altro.

— squarecandy

4

La mia raccomandazione è di omettere la maggior parte dei tag di chiusura opzionali e tutti gli attributi opzionali con cui è possibile cavarsela. Molti IDE si lamenteranno, quindi potresti non essere in grado di cavartela con alcuni di questi, ma è generalmente meglio per file di dimensioni inferiori e meno ingombro. Se hai generatori di codice sicuramente ometti i tag di fine lì perché puoi ottenere una buona riduzione delle dimensioni da esso. Di solito non importa in un modo o nell'altro.

Ma quando è importante, agire su di esso. In alcuni miei recenti lavori sono stato in grado di ridurre la dimensione del mio HTML renderizzato da 1,5 MB a 800 KB eliminando la maggior parte degli attributi generati di fine e ridondanza generati per il tag aperto, in cui il testo dell'elemento era uguale al valore. Ho circa 200 tag. Potrei implementarlo completamente in altro modo, ma sarebbe più lavoro ($$$), quindi questo mi permette di rendere facilmente la pagina più reattiva.

Solo per curiosità ho scoperto che se avessi rimosso le virgolette sugli attributi che non ne avevano bisogno avrei potuto risparmiare 20 KB, ma al mio IDE (Visual Studio) non sarebbe piaciuto. Sono stato anche sorpreso di scoprire che l'ID davvero lungo che ASP.NET genera rappresenta il 20% del mio file.

L'idea che avremmo mai potuto ottenere una parte rilevante dell'HTML strettamente valida era inizialmente sbagliata, quindi fai tutto ciò che funziona meglio per te e i tuoi clienti. La maggior parte degli strumenti che io abbia mai visto o usato diranno che generano xhtml, ma in realtà non funzionano al 100%, e comunque non c'è alcun vantaggio nell'aderenza rigorosa.

— user1777246
fonte

Riesco a malapena ad accettare l'omissione di tag finali opzionali, ma trovo un'idea piuttosto negativa omettere le citazioni sugli attributi. Stai rischiando che il tuo sito rompa alcuni browser in quel modo. Se hai file html da 800kb stai facendo qualcosa di gravemente sbagliato.

— Christoph,

2

@Christoph: omettere i tag di fine opzionali (come </p>o </li>) va perfettamente bene secondo le specifiche HTML. Se il browser non lo capisce, allora è un problema con il browser.

— Konrad Borowski il

2

Personalmente, sono un fan di XHTML e, come ghoppe, "Cerco di non omettere mai i tag di fine perché mi aiuta a essere rigoroso e non a omettere i tag necessari".

ma

Se stai usando deliberatamente HTML 4.n, non si può sostenere che includerli rende più semplice il consumo del documento, poiché la nozione di buona formazione in contrapposizione alla validità è un concetto XML e perdi quel vantaggio quando vietare alcuni tag di chiusura. Quindi l'unico problema diventa la validità ... e se è ancora valido senza di loro ... potresti anche salvare la larghezza di banda, no?

— Richard JP Le Guen
fonte

2

L'uso dei tag di fine semplifica la gestione dei frammenti perché il loro comportamento non dipende da elementi di pari livello. Questo motivo da solo dovrebbe essere abbastanza convincente. Qualcuno si occupa più di documenti html monolitici?

— CurtainDog
fonte

1

In alcuni linguaggi di parentesi graffe come C #, puoi omettere le parentesi graffe attorno a un'istruzione if se sono lunghe solo due righe. per esempio...

if ([condizione])
[codice]

ma non puoi farlo ...

if ([condizione])
[codice]
[codice]

la terza riga non farà parte dell'istruzione if. danneggia la leggibilità e i bug possono essere facilmente introdotti ed essere difficili da trovare.

per gli stessi motivi, chiudo tutti i tag. i tag come il tag img devono ancora essere chiusi, ma non con un tag di chiusura separato.

— MiguelR
fonte

Potresti dare un esempio di HTML così complicato? Nella mia esperienza i tag di fine opzionali non sono così ingannevoli.

— Kornel,

Ricordo di aver avuto un problema con IE7 qualche anno fa, in cui ho trovato un tag li di apertura su una riga separata dal testo in esso contenuto, senza li di chiusura, IE7 ha trattato tutti i proiettili come un grosso proiettile. inserendo il tag e il testo su una riga o chiudendo il tag, si risolverebbe il problema. Tuttavia, non riesco a riproporlo ora, quindi probabilmente ha anche qualcosa a che fare con i CSS in gioco. ma non ti biasimerei per aver preso questo come "ho totalmente una ragazza ... in Canada!" storia.

— MiguelR,

0

Se stavi scrivendo un parser HTML, sarebbe più semplice analizzare HTML che includeva tag di chiusura opzionali o HTML che no? Penso che i tag di chiusura opzionali presenti renderebbero più semplice, in quanto non dovrei dedurre dove dovrebbe essere il tag di chiusura.

Per questo motivo, includo sempre i tag di chiusura opzionali - in teoria che la mia pagina potrebbe essere visualizzata più velocemente, poiché sto creando meno lavoro per il parser HTML del browser.

— Joel Mueller
fonte

1

Non sono d'accordo; la nozione di ben formata in contrapposizione alla validità è un concetto solo XML e diventa irrilevante quando si hanno elementi i cui tag vicini sono vietati .

— Richard JP Le Guen,

1

Lo capisco, ma l'elemento DOM renderizzato ha sia un inizio che una fine, anche se il tag HTML non lo è. Se includi un <li>tag senza tag di chiusura, ad un certo punto il browser dovrà decidere dove finisce l'elemento e agire come se avessi messo un tag di fine in quel punto. Questa potrebbe essere una quantità relativamente logica di logica, ma "alcuni" sono ancora più di "nessuno" e non credo sia irragionevole supporre che tralasciare i tag di fine opzionali faccia più lavoro per il browser che includerli.

— Joel Mueller,

È un punto interessante ma non sono ancora d'accordo; i tag di chiusura sono opzionali in quanto sarebbero richiesti e quindi impliciti in base alle regole di convalida ... quindi quando il parser raggiunge un punto in cui deve esserci un tag di chiusura in base alla convalida, non si potrebbe sostenere che il compito di consumare un tag di chiusura (quando presente) lo rallenterebbe?

— Richard JP Le Guen,

@Richard - Immagino che dipenda dall'implementazione effettiva in un particolare browser, ma ho difficoltà a accreditare l'idea che essere espliciti su dove vuoi che un elemento finisca sarebbe peggio per le prestazioni rispetto a dire al browser di capirlo tu.

— Joel Mueller,

@RichardJPLeGuen Immagino, tutto dipende da come appaiono esattamente le regole. Quando chiudi </table>ae il tuo stack contiene <table><tbody><tr><td>, puoi semplicemente chiudere tutto fino a quando non combaci con <table>. Allo stesso modo per l'apertura <p>in un contesto non di clock. Ma potrebbero esserci casi molto più difficili, non lo so.

— maaartinus,

-1

Fai tutto ciò che ritieni rende il codice più leggibile e gestibile.

Personalmente sarei sempre propenso a chiudere <td>e <tr>, ma non mi preoccuperei mai <li>.

— Matthew Wilson
fonte

1

speravo in una guida sulla decisione di progettazione originale e che avrebbero fatto x se avessero potuto.

— Ian Boyd,

Qual è la differenza tra <td>e <li>che non ti dà fastidio <li>? Per me c'è poca differenza.

— ghoppe,

Non c'è differenza tecnica, è puramente soggettiva. Mi sembra di poter leggere meglio l'HTML se chiudo td e tr. Ma non ho mai sentito il bisogno di Li.

— Matthew Wilson,

-2

Per i tipi di chiusura vietati utilizzare la sintassi come: <img />Con il />per chiudere il tag che è accettato in XML

— Dani
fonte

1

Non funziona in HTML4 (corrisponde a una sintassi SGML oscura che fa qualcosa di leggermente diverso). In HTML5 è consentito, ma insignificante.

— Kornel,