-
Notifications
You must be signed in to change notification settings - Fork 1
/
guide-html-010-validite.twig
196 lines (196 loc) · 9.32 KB
/
guide-html-010-validite.twig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
{% embed './views/partials/_recommandation.twig' %}
{% set recVersion = '1.1.1' %}
{% block recTitle %}
Validité du code
{% endblock %}
{% block recContent %}
<ol>
<li>
<p>
L’encodage <abbr title="" class="rfc2119">doit</abbr> être précisé
[<a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-code-source-de-chaque-page-contient-une-metadonnee-qui-definit-le-jeu-de-caracteres">Opquast <cite>Règle 225</cite></a>].
<abbr title="" class="rfc2119">Recommandé</abbr> : <em>UTF-8</em>,
sans BOM
[<a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-codage-de-caracteres-utilise-est-utf-8">Opquast <cite>Règle 226</cite></a>].
</p>
<aside class="bonus">
<p>
À défaut de l’encodage UTF-8,
le document <abbr title="" class="rfc2119">devrait</abbr> utiliser
un des autres encodage d’Unicode : UTF-16 ou éventuellement UTF-32.
</p>
<p>
Outil de vérification :
<a href="https://validator.w3.org/i18n-checker/">W3C Internationalization Checker</a>.
</p>
</aside>
</li>
<li>
<p>
Le balisage <abbr title="" class="rfc2119">doit</abbr> être <em>valide</em>.
En particulier, les éléments <abbr title="" class="rfc2119">doivent</abbr> être correctement imbriqués
et les caractères spéciaux <abbr title="" class="rfc2119">doivent</abbr> toujours être correctement échappés par des entités, en particulier les <code class="language-html token attr-value">&</code> dans les adresses.
</p>
<aside class="bonus">
<p>
Les caractères invisibles (p. ex. <code class="language-html">&nbsp;</code>) <abbr title="" class="rfc2119">devraient</abbr> également l’être, mais pas les autres caractères (p. ex. € ou ⓒ).
</p>
<p>
Outils de vérification :
affichage de code des principaux navigateurs,
vérificateur syntaxique de l’éditeur de code,
<a href="https://validator.w3.org/">W3C Markup Validation Service</a>.
</p>
</aside>
</li>
<li>
<p>
Le document <abbr title="" class="rfc2119">devrait</abbr> être
<em>conforme</em> à une version donnée du format choisi.
Format <abbr title="" class="rfc2119">recommandé</abbr> :
HTML5 en syntaxe HTML.
</p>
<aside class="bonus">
<p>
En particulier, un identifant HTML
(<code class="language-html token attr-name">id</code>)
n’est utilisé qu’une fois au plus par page
[<a href="https://checklists.opquast.com/fr/assurance-qualite-web/chaque-identifiant-html-nest-utilise-quune-seule-fois-par-page">Opquast <cite>Règle 229</cite></a>].
</p>
<p>
Outil de vérification :
<a href="https://validator.w3.org/">W3C Markup Validation Service</a>.
</p>
<p>
En général, il convient de privilégier la version officielle la plus récente
du format choisi.
</p>
</aside>
</li>
<li>
<p>
Les éléments <abbr title="" class="rfc2119">devraient</abbr>
toujours avoir une balise de fermeture,
sauf éventuellement pour les éléments toujours vides
(<code class="language-html token tag">link</code>,
<code class="language-html token tag">img</code>,
<code class="language-html token tag">br</code>).
</p>
<p>
De même, les valeurs d’attribut <abbr title="" class="rfc2119">devraient</abbr> toujours être entre guillemets
(simples <code class="language-html token attr-value">'</code>
ou doubles <code class="language-html token attr-value">"</code>),
sauf peut-être pour les attributs booléens (p. ex.
<code class="language-html token attr-name">required</code>,
<code class="language-html token attr-name">disabled</code> ou
<code class="language-html token attr-name">open</code>).
</p>
<aside class="bonus">
<p>
Si le code doit pouvoir être intégré à des pages utilisant la syntaxe XHTML
(p.ex. un composant réutilisable),
il est <abbr title="" class="rfc2119">obligatoire</abbr>
d’utiliser une écriture compatible avec le XML, notamment :
</p>
<ul>
<li>Noms de balises et d’attributs en minuscules (le XML est sensibles à la casse).</li>
<li>Les attributs, même booléens, ont toujours une valeur entre guillemets, vide si besoin.</li>
<li>Les commentaires ne contiennent pas la séquence
<code class="language-html token comment">--</code>.</li>
</ul>
<p>
La syntaxe XHTML est déconseillée aux concepteurs débutants.
</p>
</aside>
</li>
</ol>
{% endblock recContent %}
{% block recRationale %}
<ol>
<li>
<p>
<a class="principle" href="principes.html#ppe-service">Service</a>,
<a class="principle" href="principes.html#ppe-securite">sécurité</a> :
Les éditeurs de code devinent souvent l’encodage d’une page.
En revanche, les navigateurs utilisent un encodage par défaut,
quand celui-ci n’est pas spécifié.
Pour obtenir un affichage correct, en particulier quand des données
doivent être échangées, il est donc nécessaire d’expliciter
l’encodage
[<a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-code-source-de-chaque-page-contient-une-metadonnee-qui-definit-le-jeu-de-caracteres">Opquast <cite>Règle 225</cite></a>].
</p>
<p>
<a class="principle" href="principes.html#ppe-standard">Respect des standards</a>,
<a class="principle" href="principes.html#ppe-coherence">cohérence</a> :
les processeurs XML doivent accepter les encodages UTF-8 et UTF-16
[<a href="https://www.w3.org/TR/2006/REC-xml11-20060816/">XML 1.0</a>].
À un autre niveau, d’ailleurs, la politique de l’IETF impose à tous les
prococoles d’Internet de reconnaître au minimum UTF-8.
Ceci permet une communication dans toutes les langues et sur toutes
les plateformes, Unicode décrivant de façon universelle tous les
glyphes en usage.
</p>
<p>
<a class="principle" href="principes.html#ppe-performance">Performance</a> :
L’encodage le plus souvent le plus économe en quantité d’information
est UTF-8.
<a class="principle" href="principes.html#ppe-securite">Sécurité</a> :
De plus, UTF-8 permet de ne pas utiliser de BOM, lequel est parfois
mal pris en charge ou mal signalé par certains logiciels auteur.
</p>
</li>
<li>
<p>
La validité est un simple <a class="principle" href="principes.html#ppe-standard">respect des standards</a>.
De plus, il s’agit de la dimension la plus immédiatement visible de
la qualité d’un code et cela est également utile pédagogiquement.
</p>
<p>
Pour des raisons de <a class="principle" href="principes.html#ppe-maintenance">maintenabilité</a> et de
<a class="principle" href="principes.html#ppe-lisible">lisibilité</a>,
il est important de coder par des entités les caractères
invisibles (mais pas les caractères affichables).
</p>
</li>
<li>
<p>
Ne pas confondre validité du balisage et conformité du document :
les différentes version du format HTML imposent un certain nombre de
contraintes supplémentaires,
en particulier l’unicité de l’<code class="language-html token attr-name">id</code>.
</p>
<p>
La conformité des documents HTML est, là aussi,
un simple <a class="principle" href="principes.html#ppe-standard">respect des standards</a>.
</p>
</li>
<li>
<p>
<a class="principle" href="principes.html#ppe-standard">Respect des standards</a>,
<a class="principle" href="principes.html#ppe-securite">sécurité</a> :
Si ce code doit être utilisé dans du XML,
par exemple dans un document HTML utilisant la syntaxe XHTML,
il est impératif de scrupuleusement respecter celle-ci.
En effet, la moindre erreur fait basculer les lecteurs en syntaxe
HTML, dont la sémantique est différentes pour certains éléments.
</p>
<p>
En syntaxe XHTML (XML), tout élément, même vide doit être fermé.
En syntaxe HTML, cela n’est pas imposé, mais il est utile pour
la <a class="principle" href="principes.html#ppe-lisible">lisibilité</a> et
la compréhension de certains codes, donc pour leur
<a class="principle" href="principes.html#ppe-maintenance">maintenabilité</a>,
de toujours indiquer les balises de fin facultatives (p. ex.
<code class="language-html token attr-value"></p></code>),
sauf peut-être pour les balises toujours vides,
pour lesquelles il n’y a aucune ambiguïté.
</p>
<p>
Le même raisonnement s’applique aux attributs.
Cela réduit également les risques d’erreur de lecture ou d’oubli
d’une fermeture.
</p>
</li>
</ol>
{% endblock recRationale %}
{% endembed %}