Il existe de nombreuses différences qui sont parfois subtiles. Certaines tiennent à :
Les 2 langages sont de la même famille et les fondamentaux restent bien sûr les mêmes, mais certains détails peuvent cependant différer. En ce qui concerne les éléments ou attributs, il faudra s'en tenir au dictionnaire correspondant au langage utilisé. En ce qui concerne la syntaxe, nous conseillons de conserver les bonnes habitudes induites par le xHTML de manière a assurer la meilleure régularité, lisibilité du code ainsi que sa complémentarité avec des parsers externes comme ceux de PHP ou python.
Globalement le code écrit à la façon xHTML est :
Aussi, même si nous ne conseillons plus le développement de site en XHTML, il nous semble utile et profitable d'écrire un code HTML5 compatible XHTML pour les raisons mentionnées ci-dessus. Vous vous demanderez alors : pourquoi ne pas faire directement du xHTML ? parce que c'est une norme ancienne donc le vocabulaire correspond moins aux usages contemporains du web que celui du HTML5. xHTML est intéressant pour sa syntaxe. Aussi on combinant les avantages de chaque vous créerez des sites faciles à maintenir et prenant en compte les nouvelles recommandations.
Rappelons qu'il est souvent plus rapide et facile d'éviter les erreurs que de passer des dizaines de minutes à les rechercher. Rappelons enfin que le temps de débogage augmente avec l'accroissement en taille des projets.Le doctype HTML5 est largement simplifié :
<!DOCTYPE html>
xHTML en possédait 3 mais tous de ce type bien long :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
En HTML5, la casse des balises n'est plus stricte alors qu'elle l'était en xHTML. Ainsi,
<span id="ref">Mon fichier</SPAN>
ou
<spAn id="ref">Mon fichier</spAN>
sont normalement supportés en HTML5 alors qu'il aurait fallu écrire
<span id="ref">Mon fichier</span>
ou
<SPAN id="ref">Mon fichier</SPAN>
en xHTML soit exactement la même écriture en balise ouvrante et fermante.
Nous conseillons la rigueur et de tenter de conserver l'écriture stricte à la casse.
le HTML5 autorise l'omission de la balise fermante lorsqu'il n'y a pas de doutes sur sa position. Ainsi on pourra écrire :
<ul> <li>menu1 <li>menu2 </ul>
là où en xHTML il aurait fallu strictement écrire :
<ul> <li>menu1</li> <li>menu2</li> </ul>
Le développeur ou l'intégrateur web adoptant la démarche avec fermeture implicite laisse donc au navigateur le choix d'interpréter la position des fermetures de balises. Le W3C tente d'en préciser les règles mais on sait ce qu'il en est des implémentations douteuses. Nous conseillons une fois encore la préservation d'une écriture contrôlée par le développeur.
De plus, l'omission ne peut être universelle, par exemple ici :
<p>je commence un paragraphe <em>pour l'exemple mais quand l'emphase se termine-t-elle ?</p>
Il nous semble plus compliquer de se poser la question à chaque fois (dois-je fermer la balise ou pas ?) que de se forcer à systématiquement fermer, et surtout plus sûr au final.
En HTML5, il est permis de ne pas encadrer les attributs par des guillemets <strong>quand ceux-ci ne sont pas utiles</strong>. Une fois encore, il s'agit de laisser de la marge au navigateur. Ainsi au lieu d'écrire
<h1 id="titre">grand titre</h1>
en xHTML, on peut écrire
<h1 id=titre>grand titre</h1>
en HTML5. Cela posant parfois des soucis en cas de valeurs multiples par exemple :
<p class=note footer>1. une petite note</p>
au lieu de
<p class="note footer">1. une petite note</p>
plus fiable car on est alors certain que footer ne sera pas interprété comme un attribut, les guillemets indiquant clairement son statut de valeur.
Concernant, les attributs, HTML5 apporte la possibilité d'ignorer la valeur dans le cas des attributs booléens, c'est-à-dire ceux qui n'ont que 2 valeurs possibles. Ces attributs étaient assez peu fréquent en xHTML mais plusieurs ont été ajoutés dans le HTML5 en compléments des nouvelles définitions de formulaires ainsi que des nouveaux éléments multimédias.
Ainsi, en HTML5, il est possible d'écrire
<audio src="musique.mp3" controls />
ou
<audio src="music.mp3" controls="controls" />
Dans ce cas, l'apport de HTML5 nous semble intéressant : si l'attribut est mentionné c'est que le navigateur doit considérer sa propriété comme activée, sinon, elle doit être désactivée.
De tous les changements, ce sont ceux qui au début ont le plus attirer l'attention. Les nouvelles balises tentent de faciliter :
Il y a de nombreuses nouvelles balises listées en fin d'ouvrage. Certaines sont sûr de persister (audio, vidéo, section, articles...) d'autres manquent encore d'implémentation dans les navigateurs et pourraient être abandonnées.
Voici une petite liste des principaux nouveaux éléments :
audio, video, articles, section, main, nav, header, footer, aside ...
Plus poussé et sortant du cadre de l'intégration pour rentrer dans le développement web, la recommandation HTML5 fait l'effort d'améliorer l'intégration des différentes technologies du web : ainsi SVG ou mathml qui dormaient dans les placards depuis 10 ans se sont soudain réveillés dans l'esprit des intégrateurs.
Mais aussi, la recommandation définit comment Ecmascript (et javascript) doit pouvoir accéder aux éléments de manière à standardiser la façon dont les navigateurs vont les gérer, facilitant a priori le travail des développeurs et la fiabilité des sites. Cela apporte au passage quelques possibilités comme :
Les évolutions entre xHTML et HTML5 sont donc assez nombreuses, même si les bases changent peu. faire un site vraiment HTML5 et en exploitant les possibilités change largement la nature du travail qui exigera maintenant un effort encore plus important de structuration de contenu et d'intégration en prenant beaucoup plus en compte les problématiques d'ergonomie et d'efficacité.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.