HTML

World Wide Web Consortium (W3C)

Living Standard pour HTML de Apple, Google, Mozilla, Microsoft ...et la W3C

Comme j’ai écrit dans le tutoriel « Le nouveau HTML « Living Standard » et le XML », la nouvelle mouture du HTML n’a rien à voir avec la révolution du HTML5. À part la simplification des balises de structure, tout est dans l’esthétique du code qui au demeurant perdra tout ces nouveaux attributs lors de la compression des codes!

WHATWG⑴

Bon, ça n’est pas une mauvaise nouvelle en soi, il y a beaucoup de bons côtés! Et surtout, le HTML reste un format ouvert et les brevets, libre de droits! Le 28 mai 2019, la W3C signait un accord historique avec le groupe WHATWG⑵ pour collaborer au développement d’une version unique des spécifications HTML et DOM. Avec des promesses, dont celle de créer une nouvelle équipe(!) Même si nulle part on ne fait mention d’argent dans cette entente, on peut se demander si le WHATWG a acheté la W3C? Toujours est-il qu’aujourd’hui, on récolte les fruits de ce "coup d’État" ; -) La création de la nouvelle version du HTML5, le « Living Standard ».

« Living Standard » exprime deux vœux pieux. Premièrement, tenir des normes à jour et bien détaillée pour permettre aux Navigateurs de les suivre. Avant c’était l’inverse, c’était les navigateurs qui dictaient l’évolution des normes. Ensuite, les normes seront continuellement mises à jour au fur et à mesure que le WHATWG reçoit des commentaires, que ce soit des développeurs Web, des fournisseurs de navigateurs, des fournisseurs d’outils ou de toute autre partie intéressée. C’est la définition officielle et visiblement les développeurs en question ne sont pas amateurs de XML ;-) Et noter une incongruité dans cette définition, c’est Apple, Google, Mozilla et Microsoft qui sont derrière le « Living Standard ».

Chromium et Webkit

Ha, mais c’est contredire la première affirmation, tous ces acteurs sont ...des créateurs de navigateurs! Fait très intéressant à noter, à part Firefox et Safari, la plupart des navigateurs son bâtie depuis quelques années sur le navigateur Chromium ⑵, Chrome bien sûr mais aussi Microsoft Edge, Samsung Internet, Opera... Vous aller me dire que Apple n’est pas sous Chronium, faux! en fait c’est Chromium qui est bâti sur un noyau WebKit. Qui est derrière WebKit, Apple ;- ) https://developer.apple.com/documentation/webkit

...Ni de version, je ne sais pas qu’elle numéro de version ou nom de ce nouveau HTML. Est-il encore HTML5? Non, c’est le « Living Standard ». Mais nous ne sommes que la plèbe en fin de compte, au diable la philosophie et au travail!

Une autre bonne différence, c’est les gens derrière les nouveautés du HTML. La W3C n’est plus seul, le Web Hypertext Application Technology Working Group (WHATWG) géré par Apple, Google, Mozilla et Microsoft! À ce demander s’il (à part peut-être Mozilla) n’ont pas seulement deux buts dans la vie, faire de l’argent et faire de l’argent!

Le nouveau HTML Living Standard

Pas si nouveau, le HTML4 avait déjà introduit la plupart des "nouvelles" recommandations.

Protocole

La première, l’obligation d’utiliser un certificat SSL. Google l’exige déjà depuis 2014 en dénaturant complètement sa nature. Un certificat SSL permet l’authentification et le cryptage des données lorsqu’elles transigent de serveur en serveur. Pourquoi dénaturer, parce que Google s’en sert essentiellement pour augmenter la confiance. Comme s’il n’y avait que les anges capables de se payer un certificat SSL! Je parle beaucoup de ce détail, mais si vous avez un site non transactionnel, qui ne requiert aucune sécurité, vous avez un site entièrement public, vous n’avez rien à cacher et donc aucune raison de payer un certificat SSL. Google vous promet de négliger votre positionnement! Vous avez un formulaire de recherche qui n’a toujours rien de confidentiel, vous risquez un beau gros message alarmant! C’est drôle, quand j’investigue sur une tentative d’attaque ou du simple pourriel, c’est toujours des sites ...avec certificat SSL! Un site qui vous hameçonne avec un certificat SSL est jugé plus fiable par Google que le site inoffensif d’un poète qui ne possède pas (ou n’a pas le moyen) un certificat SSL!

Et pourtant, la définition officielle est :

Le pire c’est qu’un certificat SSL ne protège que la transmission lors de la requête HTTP, essentiellement pour éviter de vous faire voler votre numéro de carte de crédit (il ne protège pas non plus Google de compiler toujours plus de données sur vous et vois habitudes, avec ou sans SSL!! La plupart des attaques en 2022 ne se font même pas à ce niveau. La plupart des sites Web ne sont pas sécuritaires même avec un certificat SSL! Amusé vous à tester la vulnérabilité des sites Web https://securityheaders.com/ en regard des véritables dangers qui pullulent sur le Web!

M’enfin, encore de la philo inutile étant donné que c’est maintenant exigé par ledit consortium, "présidé" par ...Google. Alors, attendez-vous à un beau message inquiétant des navigateurs si votre site n’a pas de certificat SSL.

En passant, Google se fait le porte-étendard de l’efficacité et de l’optimisation des sites Web pour augmenter la vitesse de chargement d’un site Web. C’est d’ailleurs un peu l’idée derrière cette nouvelle mouture du HTML plus « simple »! Mais un certificat SSL multiplie considérablement le poids total du Web. Un peu comme l’écran blanc du fameux moteur de recherche. On pourrait sauver des millions au niveau de l’efficacité énergétique seulement avec un écran noir. Et d’ailleurs, Google offre maintenant de configurer le résultat pour l’obtenir dans une page noire. Imaginer maintenant l’empreinte environnementale des certificats SSL! On a beau être au bord du gouffre côté environnement, le Web n’est pas responsable. Juste l’idée du minage de bitcoins est 1000 fois plus polluante!

Alors voilà cette "recommandation" qui cache en fait de plus en plus une obligation.

Utilisez HTTPS pour les ressources intégrées (embedded resources) dans la mesure du possible. Héhé, dans la phrase suivante on précise cette fois « toujours » mais on termine par « à moins que » ;- )

<!-- Non recommandé : omet le protocole -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/3.4.0/jquery.min.js"></script>

<!-- Non recommandé : utilise le protocole HTTP -->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/3.4.0/jquery.min.js"></script>

<!-- Recommandé : utilise le protocole HTTPS -->
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.4.0/jquery.min.js"></script>

/* Non recommandé : omet le protocole */
@import '//fonts.googleapis.com/css?family=Open+Sans';

/* Non recommandé : utilise le protocole HTTP */
@import 'http://fonts.googleapis.com/css?family=Open+Sans';

/* Recommandé : utilise le protocole HTTPS */
@import 'https://fonts.googleapis.com/css?family=Open+Sans';

Règles générales de formatage

Wow, tu parles d’un détail!?! Bien sûr que c’est important, c’est la première chose qu’on apprend en informatique. Des codes aéré, clair et indenté. Il n’y a rien de pire que de déboguer un code tout croche, particulièrement avec une arborescence HTML. Mais boyenne, Google lui-même exige de tout compresser, des images aux fichiers JavaScript et aux feuilles de styles CSS et même du HTML. En faire une recommandation set à quoi? Aider le programmeur ? D’où proviens c’est soudaine empathie?!? Give me a break!

Pour ceux qui ne savent pas de quoi on parle, essentiellement deux espace pour indenter le code ET sans utiliser la tabulation :

<ul>
  <li>Fantastic
  <li>Great
</ul>

.example {
  color: blue;
}

Lettres minuscules

Ça c’est très bien, ce qui est ironique toutefois c’est que plusieurs recommandations de cette nouvelle version nous retournent aux premières versions du HTML qui était toujours en majuscule... Cela s’applique aux éléments HTML, aux attributs, aux valeurs d’attribut (sauf texte/CDATA), aux sélecteurs CSS, aux propriétés et aux valeurs de propriété (à l’exception des chaînes).

<!-- Non recommandé -->
<A HREF="/">Home</A>

<!-- Recommandé -->
<img src="google.png" alt="Google">

/* Non recommandé */
color: #E5E5E5;

/* Recommandé */
color: #e5e5e5;

Espace blanc de fin

Supprimez les espaces blancs à la fin! Les espaces blancs à la fin ne sont pas nécessaires et peuvent compliquer la comparaison de texte(!). Ce n’est pas une mauvaise idée. Mais on s’entend ici pour dire que c’est une recommandation essentiellement au service des intérêts de Google. Ce qui confirme le constat que cette nouvelle mouture profite surtout aux navigateurs et robots d’indexation...

<!-- Non recommandé -->
What?_

<!-- Recommandé -->
Yes please.

Encodage UTF-8 sans BOM (indicateur d’ordre des octets ou « byte-order mark »)

Utilisez UTF-8 (sans BOM) pour encoder vos pages HTML. Normallement ça va de soit pour un francophone. Assurez-vous que votre éditeur utilise UTF-8 comme encodage de caractères, sans marque d’ordre d’octet (BOM).

Spécifiez l’encodage dans les modèles et documents HTML via <meta charset="utf-8">. Ne spécifiez pas l’encodage des feuilles de style car celles-ci supposent UTF-8.

Commentaires

Expliquez le code si nécessaire, si possible. Utilisez des commentaires pour expliquer le code : que couvre-t-il, à quoi sert-il, pourquoi la solution respective est-elle utilisée ou préférée ?

Héhé, merci du conseil, d’ailleurs on s’empresse de préciser :

Mieux encore, mettez en surbrillance les tâches en utilisant uniquement le mot-clé TODO, pas d’autres formats courants tels que @@. Un peu plus et on va nous recommander d’écrire différaient notre propre nom! On parle ici de spécification propre à une application qui n’a rien avoir avec le HTML en tant que tel. Mais bon, le voilà quand même!

Ajoutez un contact (nom d’utilisateur ou liste de diffusion) entre parenthèses comme avec le format TODO(contact).

{# TODO(john.doe): revisit centering #}
<center>Test</center>

Ajoutez les éléments d’action après deux-points comme dans TODO : élément d’action.

<!-- TODO: remove optional tags -->
<ul>
  <li>Apples</li>
  <li>Oranges</li>
</ul>

HTML

Type de document (Document Type)

On demande d’utiliser le HTML5! Et donc :

<!DOCTYPE html>

Et la phrase assassine, c’est à dire du text/html et non pas du application/xhtml+xml :

It’s recommended to use HTML, as text/html. Do not use XHTML. XHTML, as application/xhtml+xml, lacks both browser and infrastructure support and offers less room for optimization than HTML.

C’est un peu plus clair, l’optimisation... Et la recommandation s’empresse de dire « Bien que cela fonctionne avec HTML, ne fermez pas les éléments vides ».

Bon, c’est faux, le 5 octobre dernier, la W3C retournait un « avertissement » (warning), et le lendemain, une « info ». Peut importe, si vous ne respecter pas cette recommandation, vous n’aurez pas le message tant recherché « Aucune erreur »!

À savoir, ne pas fermer les éléments vide, par exemple le saut de ligne (line break) :

<!-- Non recommandé -->
<br />

<!-- Recommandé -->
<br>

Ou encore :

<!-- Non recommandé -->
<meta charset="utf-8" />

<!-- Recommandé -->
<meta charset="utf-8">

Validité HTML

Utilisez un code HTML valide, sauf si cela n’est pas possible en raison d’objectifs de performances autrement inaccessibles concernant la taille du fichier. Utilisez des outils tels que le validateur HTML du W3C pour tester.

<!-- Non recommandé -->
<!-- manque le type de document et le charset -->
<title>Tester</title>
<article>Ce n’est qu’un test.

<!-- Recommandé -->
<!DOCTYPE html>
<meta charset="utf-8">
<title>Tester</title>
<article>Ce n’est qu’un test.</article>

Rien de nouveau dans cet exemple, ce qu’il faut observer c’est qu’il ne faut plus fermer les éléments vides, dans ce cas-ci, le jeu de caractères <meta charset="utf-8">

Sémantique

Bien sûr, ce n’est plus des balises si on n’a pas besoin de les fermer. I ne balise pas, ils séparent! Pouir rester sémantique, il faudrait dire des « séparateurs » (c’est une blague ;- )

<!-- Non recommandé -->
<!-- Utiliser plutôt A -->
<div onclick="goToRecommendations();">Toutes les recommandations</div>

<!-- Recommandé -->
<a href="recommendations/">Toutes les recommandations</a>

Textes alternatifs

Encore une fois, rien de nouveau, il faut fournir des contenus alternatifs pour le multimédia, comme les images, les vidéos, les objets animés via canvas. Pour les images, cela signifie l’utilisation d’un texte alternatif significatif (alt) et pour les transcriptions et les légendes vidéo et audio, si disponibles.

Fournir des contenus alternatifs est important pour des raisons d’accessibilité : un utilisateur aveugle a peu d’indices pour dire de quoi parle une image sans @alt, et les autres utilisateurs peuvent n’avoir aucun moyen de comprendre de quoi parle le contenu vidéo ou audio non plus.

On conseil : « Pour les images dont les attributs alt introduiraient une redondance, et pour les images dont le but est purement décoratif pour lequel vous ne pouvez pas immédiatement utiliser CSS, n’utilisez pas de texte alternatif, comme dans alt="". » Mais vous aurez un avertissement. Essayer d’être imaginatif...

<!-- Non recommandé -->
<img src="image.png">

<!-- Recommandé -->
<img src="image.png" alt="Capture d'écran de la feuille de calcul.">

Séparation des préoccupations

<!-- Non recommandé -->
<!DOCTYPE html>
<title>HTML craint</title>
<link rel="stylesheet" href="base.css" media="screen">
<link rel="stylesheet" href="grid.css" media="screen">
<link rel="stylesheet" href="print.css" media="print">
<h1 style="font-size : 1em ;">HTML, c'est nul</h1>
<p>J'ai lu à ce sujet sur quelques sites, mais maintenant je suis sûr :
  <u>Le HTML est stupide ! 1</u>
<center>Je n'arrive pas à croire qu'il n'y ait aucun moyen de contrôler le style de
  mon site Web sans tout refaire !</center>

<!-- Recommandé -->
<!DOCTYPE html>
<title>Ma première refonte CSS uniquement</title`
<link rel="stylesheet" href="default.css">
<h1>Ma première refonte CSS uniquement</h1>
<p>J'ai lu à ce sujet sur quelques sites, mais aujourd'hui, je suis en fait
  le faire : séparer les préoccupations et éviter quoi que ce soit dans le code HTML de
  mon site Web qui est de présentation.
<p>C'est génial !

Pourquoi le bon exemple a retiré le souligné <u>HTML is stupid!!1</u> et le <center> En principe, ça respecte les 3 recommandations de ce point. Par contre, est-ce qu’on exige d’ajouter une classe centrer au lieu de la balise <center>, c’est une bonne idée, mais qui va à l’encontre de la recommandation d’utilise le HTML pour la structure. Quant au souligné, ajouter une classe avec un span, hum pas sure, ça ne respecte pas plus la recommandation d’utilise le HTML pour la structure. Par contre, la convention veut que le souligné identifie un hyperlien. Alors, vaux mieux d’éviter le soulignage dans le texte d’une page Web pour éviter la confusion. Vous pouvez certes utiliser le souligné dans votre visuel, mais essayer de le distinguer d’un hyperlien en jouant sur l’épaisseur, la couleur et la position...

Entités HTML

Une nouvelle intéressante, demande d’arrêter d’utiliser les entités HTML au profit d’un document encodé UTF-8 sans indicateur d’ordre des octets dit « BOM » (byte-order mark)⑿! Wow. Personnellement, ça fait 20 ans que j’y suis déjà comme la plupart des professionnelles non anglophones. Imaginer utiliser les entités HTML en mandarin? C’est bien sûr impossible! Tous langages non latins sont d’ores et déjà encodés en UTF-8! Les Latins ont davantage de problèmes, car ils partagent la grande majorité des caractères avec les gens de la langue de Shakespeare. Et ils utilisent les outils (comme WordPress) anglophones. Les entités HTML pour les caractères accentués, par exemple, sont légion en 2022! Encore aujourd’hui un tas de sites généralement WordPress qui persiste à utiliser les entités HTML. Pire, parfois mêmes si le document est encodé UTF-8. Mais les chanceux n’ont pas de message dans le valideur pour les décourager alors que ça fait 20 ans qu’ils ne comprennent pas la technologie ;- ) À mon avis, même si c’est une recommandation plus importante (pour les francophones!?!) ou au même titre que la balise de fermeture, le valideur de la W3C va ignorer cette directive encore longtemps!

<!-- Non recommandé -->
Le symbole monétaire de l’euro est « &eur; ».

<!-- Recommandé -->
Le symbole monétaire de l’euro est « € ».

Balises facultatives

C’est ici que ça se gâte, ça reste facultatif, mais un avertissement risque de survenir un jour ou l’autre comme c’est préciser dans le texte officiel, un « délai de grâce » ;- ). Avant, la règle était simple, fermer toutes les balises, même les balises sans contenu comme le saut de ligne <br />. Donc, depuis le HTML5, il y a un tas d’exception et visiblement susceptible de mériter un jour un avertissement... D’autre part, c’est bien beau la vertu (il suffit d’enlever ou de compresser une image pour opprimer davantage la page...), mais il faut savoir que le navigateur l’exigera toujours! En fait, les « Balises facultatives » que vous ne spécifierez pas seront ajoutées au code HTML par le navigateur, de toute façon...

<!-- Non recommandé -->
<!DOCTYPE html>
<html>
   <head>
     <title>Dépenser de l'argent, dépenser des octets</title>
    </head>
   <body>
     <p>Sic.</p>
   </body>
</html>

<!-- Recommandé -->
<!DOCTYPE html>
<title>Économiser de l'argent, économiser des octets</title>
<p>Cf.

Hum, j’aime bien séparer mes sections, surtout l’entête (head), le corps (body). Et on ne peut pas dire que le poids est important!?! Compressez une seule image et vous gagnerez davantage! Cette fois c’est clairement dans le but d’aider les robots! C’est correct, ce n’est pas moi le boss, mais ayez donc l’honnêteté de dire la vérité. Le poids de la balise head ;- )) Quant à la fermeture du paragraphe </p> Bon, comme je disais, ça date du HTML4, de 20 ans! On s’y fait. Mais attention aux exceptions.

<!-- Non recommandé -->
<table>
  <caption>37547 Fonctions du train automoteur électrique TEE (en abrégé)</caption>
  <colgroup><col><col><col></colgroup>
  <thead>
   <tr>
    <th>Fonction</th>
    <th>Unité de contrôle</th>
    <th>Gare centrale</th>
   </tr>
  </thead>
  <tbody>
   <tr>
    <td>Phares</td>
    <td>✔</td>
    <td>✔</td>
   </tr>
   <tr>
    <td>Lumières intérieures</td>
    <td>✔</td>
    <td>✔</td>
   </tr>
   <tr>
    <td>Sons de fonctionnement de la locomotive électrique</td>
    <td>✔</td>
    <td>✔</td>
   </tr>
   <tr>
    <td>Éclairage cabine conducteur</td>
    <td></td>
    <td>✔</td>
   </tr>
   <tr>
    <td>Annonces des stations - Suisse</td>
    <td></td>
    <td>✔</td>
   </tr>
  </tbody>
</table>

<!-- Recommandé -->
<table>
 <caption>37547 Fonctions du train automoteur électrique TEE (en abrégé)
 <colgroup><col><col><col>
 <thead>
  <tr> <th>Fonction                                            <th>Unité de contrôle <th>Station centrale
 <tbody>
  <tr> <td>Phares                                              <td>✔                 <td>✔
  <tr> <td>Éclairage intérieur                                 <td>✔                 <td>✔
  <tr> <td>Sons de fonctionnement de la locomotive électrique  <td>✔                 <td>✔
  <tr> <td>Éclairage cabine conducteur                         <td>                  <td>✔
  <tr> <td>Annonces des stations - Suisse                      <td>                  <td>✔
</table>

<!-- Non recommandé -->
<!-- Parceque c’est en français -->
<!-- En français il faut spécifier l’attribut lang="fr-FR" -->
<!DOCTYPE HTML>
<title>Bonjour</title>
<p>Bienvenue dans cet exemple.

<!-- Recommandé -->
<!DOCTYPE HTML>
<html lang="fr-FR">
  <title>Bonjour</title>
  <body class="demo">
    <p>Bienvenue dans cet exemple.
  </body>
</html>

Attribut « type »

Ça aussi c’est exgigé depuis le HTML5, ne pas indiquer le type de contenu pour les feuilles de style et les scripts retourne une erreur dans le valideur depuis longtemps.

<!-- Non recommandé -->
<link rel="stylesheet" href="https://www.google.com/css/maia.css" type="texte/css">

<!-- Recommandé -->
<link rel="stylesheet" href="https://www.google.com/css/maia.css">

<!-- Non recommandé -->
<script src="https://www.google.com/js/gweb/analytics/autotrack.js" type="text/javascript"></script>

<!-- Recommandé -->
<script src="https://www.google.com/js/gweb/analytics/autotrack.js"></script>

Noter ici les deux fichiers JavaScript qui ont une balise de fermeture </script> qui va en principe à l’encontre de leurs recommandations de ne pas fermer les balises vides ;- ) À croire qu’il n’y a que les webmestres qui lisent les petits caractères!

Attribut « id »

<!-- Non recommandé : `window.userProfile` résoudra pour référencer le nœud <div> -->
<div id="userProfile"></div>

<!-- Recommandé : l'attribut `id` est obligatoire et sa valeur inclut un trait d'union -->
<div aria-depressedby="user-profile">
   …
   <div id="user-profile"></div>
   …
</div>

En gros, l’attribut id sert d’identifiant unique à un élément HTML. Mais on l’utiliser pour donner du style #identifiant {[mon CSS]}, pour récupérer l’élément en JavaScript var element = document.getElementById("identifiant"); et aussi par le navigateur pour faire un lien avec ancre <a href="#identifiant">Mon ancre</a>. Bien sûr, comme le précise le WHATWG, ça peut porter à confusion et provoquer des erreurs JavaScript. Par expérience, l’utilisation du ID comme identifiant unique à des fins de programmation JavaScript est de moins en moins utiliser au profit des des attributs data-* justement pour ce genre de problème. Ou encore, j’ai deux champs de saisie pour une recherche dans la même page, il faut donc donner deux « id » différents. En résumé, personnellement j’utilise l’attribut id spécifiquement pour faire des ancres! Ce qui règle le problème une fois pour tout. En fait, la W3C, oups le WHATWG, devrait ajouter un identifiant spécifique au JavaScript ou plutôt l’inverse, ajouter un attribut dédié à l’ancre : ancer="identifiant" par exemple et l’interdire en CSS (ou en créer un autre sélecteur pour le CSS!

Formatage

Indentation

Héhé, contrairement à cette recommandation, il n’y a pas d’avertissement et encore moins d’erreurs lors de la validation. Et j’espère bien, il y a des limites. On recommande aussi de compresser les HTML, et donc perdre tout ce travail! Mais bon, c’est une bonne pratique bien entendu, mais ça reste personnel, ça n’a absolument rien avoir avec le navigateur...

<blockquote>
  <p><em>Espace</em>, l'ultime frontière.</p>
</blockquote>

<ul>
  <li>Moe
  <li>Larry
  <li>Curly
</ul>

<table>
  <thead>
    <tr>
      <th scope="col">Income
      <th scope="col">Taxes
  <tbody>
    <tr>
      <td>$ 5.00
      <td>$ 4.50
</table>

Retour à la ligne

<button mat-icon-button color="primary" class="menu-button"
    (click)="openMenu()">
  <mat-icon>menu</mat-icon>
</button>

<button
    mat-icon-button
    color="primary"
    class="menu-button"
    (click)="openMenu()">
  <mat-icon>menu</mat-icon>
</button>

<button mat-icon-button
        color="primary"
        class="menu-button"
        (click)="openMenu()">
  <mat-icon>menu</mat-icon>
</button>

Guillemets et apostrophes

L’utilisation des doubles guillemets au lieu des simples guillemets dans les attributs HTML. Oui oui, du HTML strict ;- ) Quoique certains programmeurs soient habitués d’utiliser le simple guillemet dans certains cas. Non pas parce que c’est impossible en HTML mais parce que des composantes souvent JavaScript exige des doubles guillemets alors que le HTML permettait (avant) les deux types de guillemets :

<!-- Non recommandé -->
<a class='maia-button maia-button-secondaire'>Connexion</a>

<!-- Recommandé -->
<a class="maia-button maia-button-secondaire">Connexion</a>

<!-- Recommandation (avec raison) -->
<balise attribut="composante('valeur')">[...]</balise>

<!-- (mais) certaines composantes exigent le double guillemet, maintenant incompatible : -->
<!-- Non recommandé -->
<balise attribut='composante("valeur")'>[...]</balise>

Incompatible avec les nouvelles réglementations. Impossible aux Webmestres de réglé ce petit problème à la merci de la composante externe! Personnellement, mon gestionnaire de contenu Neural remplace tout les apostrophes « ' » au profit du « ’ » français depuis 20 ans, alors je n’ai aucun problème avec cette recommandation. Quelle chance d’être francophone ; -)

CSS

Règles de style CSS

Ici, on sort complètement du HTML, c’est du CSS et vous n’aurez probablement pas de message d’erreur ni d’avertissements par le valideur CSS de la W3C pour la plupart de ces exemples. C’est essentiellement à titre de bonnes pratiques...

Dénomination des classes

/* Non recommandé : sans signification */
.yee-1901 {}

/* Non recommandé : présentationnel */
.bouton-vert {}
.dégager {}

/* Recommandé : spécifique */
.Galerie {}
.connexion {}
.vidéo {}

/* Recommandé : générique */
.aux {}
.alt {}

Style de nom de classe

/* Non recommandé */
.la navigation {}
.atr {}

/* Recommandé */
.nav {}
.auteur {}

Délimiteurs de nom de classe

/* Déconseillé : ne sépare pas les mots « démo » et « image » */
.demoimage {}

/* Non recommandé : utilise un trait de soulignement au lieu d'un trait d'union */
.error_status {}

/* Recommandé */
.video-id {}
.ads-sample {}

Préfixes

/* Recommandé */
.tw-help {} /* Trucsweb */
.bs-note {} /* Bootstrap */

Sélecteurs de types

/* Non recommandé */
ul.exemple {}
div.error {}

/* Recommandé */
.Exemple {}
.Erreur {}

Sélecteurs d’ID

/* Non recommandé */
#Exemple {}

/* Recommandé */
.Exemple {}

Noter l’erreur avec cet exemple de la W3C, une majuscule qui ne respecte pas la recommandation...

Propriétés abrégées

/* Non recommandé */
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;

/* Recommandé */
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;

0 et Unités

flex: 0px; /* Ce composant basé flex nécessite une unité. */
flex: 1 1 0px; /* Non ambigu sans l’unité, mais nécessaire dans IE11. */
margin: 0;
padding: 0;

0 et le nombre entier

font-size: 0.8em;

Notation hexadécimale

/* Non recommandé */
color: #eebbcc;

/* Recommandé */
color: #ebc;

Déclarations importantes (!important)

/* Non recommandé */
.example {
  font-weight: bold !important;
}

/* Recommandé */
.example {
  font-weight: bold;
}

Hacks

/* Non recommandé */
<!--[if IE]> <link href="seulement_ie.css" rel="stylesheet"> <![endif]-->
<!--[if lt IE 7]> <link href="ie_6_et_moins.css" rel="stylesheet"> <![endif]-->
<!--[if !lt IE 7]> <![IGNORE[--><![IGNORE[]]> <link href="recent.css" rel="stylesheet"> <!--<![endif]-->
<!--[if !IE]--> <link href="non_ie.css" rel="stylesheet"> <!--<![endif]-->

Ordre de déclaration

background: fuchsia;
border: 1px solid;
-moz-border-radius: 4px;
-webkit-border-radius: 4px;
border-radius: 4px;
color: black;
text-align: center;
text-indent: 2em;

Dans le même ordre d’idée, sachez que le navigateur interprète les côtés (haut, droite, bas, gauche) dans le sens des aiguilles d’une montre en partant par le haut (midi). Habituez-vous à les déclarer dans le même ordre pour optimiser leur l’interprétation. C’est d’ailleurs par défaut avec les propriétés abrégées :

border: 10px 0 30px 0 // Haut, droite, bas, gauche

/* Non recommandé */
border-bottom: 10px;
border-top: 10px;

/* Recommandé */
border-top: 10px;
border-bottom: 10px;

Indentation des blocs de contenu

Encore une fois, à titre personnel c’est une bonne pratique pour vous aider à mettre à jour votre code. Car en principe une feuille de style CSS se doit d’être compressée, c’est-à-dire entre autres sans aucun formatage...

@media screen, projection {

  html {
    background: #fff;
    color: #444;
  }

}

Arrêts de déclaration

/* Non recommandé */
.test {
   display: block;
   height: 100px
}

/* Recommandé */
.test {
   display: block;
   height: 100px;
}

Deux points de la déclaration

Et parce que contrairement au français, en anglais il n’y a pas d’espace devant les deux points...

/* Non recommandé */
h3 {
   font-weight:bold;
}

/* Recommandé */
h3 {
   font-weight: bold;
}

Séparation des blocs de déclaration

/* Non recommandé : espace manquant */
.video{
  margin-top: 1em;
}

/* Non recommandé : saut de ligne inutile */
.video
{
  margin-top: 1em;
}

/* Recommandé */
.video {
  margin-top: 1em;
}

Sélecteur et séparation des déclarations

À titre personnel c’est une bonne pratique pour vous aider à mettre à jour votre code. Car en principe une feuille de style CSS se doit d’être compressée, c’est-à-dire entre autres sans aucun formatage...

/* Non recommandé */
a:focus, a:active {
  position: relative; top: 1px;
}

/* Recommandé */
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}

Séparation des règles

html {
  background: #fff;
}

body {
  margin: auto;
  width: 50%;
}

Guillemets CSS

/* Non recommandé */
@import url("https://www.google.com/css/maia.css");

html {
  font-family: "open sans", arial, sans-serif;
}

/* Recommandé */
@import url(https://www.google.com/css/maia.css);

html {
  font-family: 'open sans', arial, sans-serif;
}

Commentaires de rubrique

À titre personnel c’est une bonne pratique pour vous aider à mettre à jour votre code. Et vous pouvez le faire en français ; -) Mais les commentaires sont retirés lors de la compression des feuilles de styles CSS...

/* Entête */

.tw-entete {}

/* Pied de page */

.tw-pied {}

/* Galerie */

.tw-galerie {}

Conclusion

Références

• WHATWG
• Google HTML/CSS Style Guide
• W3C and WHATWG to work together to advance the open Web platform - W3C CEO Jeff Jaffe’s
• Today W3C and the WHATWG signed an agreement to collaborate on the development of a single version of the HTML and DOM specifications - Coralie Mercier, W3C Marketing and Communications
• The Chromium Projects - Google
• Web browser engine Webkit - Apple
• The Chromium Projects - Google
• Living Standard - Last Updated 5 October 2022 - WHATWG
• Le protocole HTTPS en tant qu’indicateur de classement - Google
• Well-Formed HTML - Developer.com
• validateur HTML - W3C
• Hypertext Markup Language - Wikipedia
• Gestion de l’encodage des caractères en HTML et CSS (tutoriel) - W3C
• Le nouveau HTML « Living Standard » et le XML - Oznog, Trucsweb.com