Balises fermantes et encadrantes

bonjour

certains prétendent que les balises <p>, <dd>, <dt>, <li>, <optgroup>, <option>, <rt>, <rp>, <td>, <th>, <tr>, <thead>, <tfoot> n'ont pas besoin de balise fermante pour être valides ! - comment es-ce possible ? pourquoi accepter cela car en quoi l’absence de balise non fermante rendrait les ligne de code plus claire ?

par contre il existe des balises qui sont non encadrantes tel que <br> que je note </br> - quelle est la meilleur syntaxe ? où peut-on avoir la liste de ces balises non encadrantes ?

merci d'avance de vos réponses

Hello,

Tu peux éviter de fermer certaines balise si tu es en HTML5, il permet dans certains cas, d'être permissif et de les interpréter. Par contre, tu ne peux pas le faire en XHTML.
Voici la liste et les conditions sur le site du W3C : http://www.w3.org/TR/html5/syntax.html#optional-tags

Personnellement, je préfère toujours fermer ces balises.

Par contre pour le br, la bonne syntaxe est

<br />

ou

<br>

(fonctionne que si tu es en HTML et non en XHTML), c'est une balise autofermante .

+1

Je suis tout à fait contre cette permissivité d'HTML5, qui ne fait qu'encourager les mauvaises pratiques d'écriture et le manque de rigueur, de lisibilité, de maintenabilité… donc oui à HTML5, mais vive la syntaxe XHTML

RR7008 a écrit :
pourquoi accepter cela car en quoi l’absence de balise non fermante rendrait les ligne de code plus claire ?

C'est une possibilité : on peut faire les 2 et ce n'est pas par clarté, juste par commodité dans certains cas. Si c'est du code côté serveur (PHP, etc) qui génére ton code HTML, ça peut éviter d'avoir à se coltiner la gestion de la balise fermante.

Dans quelles conditions est-ce possible ? Uniquement avec des doctype l'autorisant. HTML5 oui, XHTML5 non (mais à peu près personne n'utilise ça), XHTML 1.0 Strict certainement pas non plus.

Quand est-ce possible ? Uniquement avec les éléments que tu cites, où on (les navigateurs) est absolument certain du comportement à adopter en rencontrant dans le code HTML la balise suivante.
Après un <option> et du texte, il ne peut y avoir qu'un <optgroup>, un autre <option> ou un </select> ; le reste c'est invalide et le navigateur va probablement corriger en rajoutant un </select> et le validateur te hurler dessus si tu lui demandes son avis
Après un <td>, soit c'est un autre <td> ou <th>, soit la fin de ligne </tr> ou thead/tfoot/tbody ou enfin </table>.

Tu peux écrire vite fait

<ul>
  <li>un
  <li>deux
  <li>trois
  <li>quatre
</ul>

y a peu de chances de se tromper, que ce soit toi dans 1 an ou un collègue/confrère/client dans 2 jours. 0 ambiguïté. Mais si c'est plus complexe avec des éléments dedans, des liens, etc tu rends service à tout le monde en rajoutant les balises fermantes : tu te remercieras dans 1 an de ne pas avoir laissé d'ambiguïté dans ton code et tes collègues/confrères/clients n'ont pas le temps ni l'envie d'essayer de comprendre ce que tu voulais faire.

Paix à XHTML2 qui est mort avant même d'être né.... il nous aurait épargné certaines de ces possibles ambiguïtés, qui sont, avouons-le, permises simplement parce que certains sont paresseux et de mauvaise volonté.

Il me semble que la quasi-totalité des langages de programmation proposent des bibliothèques DOM (en tout cas de sûr php, java, javascript, C#, python, ...) qui sont faites pour ne pas avoir sans cesse à ce soucier de la fermeture correcte des balises dans le bon ordre... utilisons-les !