Trucsweb.com

Trucsweb.com

HTML

World Wide Web Consortium (W3C)

RDFFav

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

La reine est morte, vive le roi!Living StandardLiving Standard pour HTML de Apple, Google, Mozilla, Microsoft ...et la W3C

Logo W3C WHATWG

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!

La petite histoire récente du HTML

« En 2006, le W3C a indiqué un intérêt à participer au développement de HTML5 après tout, et en 2007 a formé un groupe de travail chargé de travailler avec le WHATWG sur le développement de la spécification HTML5. Apple, Mozilla et Opera ont autorisé le W3C à publier la spécification sous le copyright du W3C, tout en conservant une version avec la licence la moins restrictive sur le site WHATWG.

Pendant plusieurs années, les deux groupes ont ensuite travaillé ensemble. En 2011, cependant, les groupes sont arrivés à la conclusion qu’ils avaient des objectifs différents : le W3C voulait publier une version « finie » de « HTML5 », tandis que le WHATWG voulait continuer à travailler sur un Living Standard pour HTML, en maintenant continuellement la spécification plutôt que de le geler dans un état avec des problèmes connus et d’ajouter de nouvelles fonctionnalités au besoin pour faire évoluer la plate-forme.

En 2019, le WHATWG et le W3C ont signé un accord pour collaborer sur une version unique de HTML à l’avenir... »

Le nouveau HTML Living Standard

Avertissement, les coeurs sensibles, les puristes, les amateurs de XML ou de XHTML stricte comme moi, les prochaines lignes risquent de vous choquer, tenez-vous le pour dit ;- ) La plupart de ses recommandations ne retournent pas encore d’erreur ni même d’avertissement. Il est fort possible que vous n’ayez rien à faire pour conformer votre site Web. Par contre, si comme moi vous êtes amateur de XML et par le fait même de code « bien formé », votre travail consistera à piler sur votre orgueil et modifier votre code pour qu’il soit dorénavant « mal formé »!

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 :

SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers.

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 » ;- )

Utilisez toujours HTTPS (https:) pour les images et autres fichiers multimédias, feuilles de style et scripts, à moins que les fichiers respectifs ne soient pas disponibles via HTTPS.


<!-- 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 :

(This item is optional as it is not deemed a realistic expectation to always demand fully documented code. Mileage may vary heavily for HTML and CSS code and depends on the project’s complexity.)

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.

L’utilisation d’un HTML valide est un attribut de qualité de base mesurable qui contribue à l’apprentissage des exigences et des contraintes techniques, et qui garantit une utilisation correcte du HTML.


<!-- 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

Utilisez des éléments (parfois appelés à tort "balise") pour ce pour quoi ils ont été créés. Par exemple, utilisez des éléments de titre pour les titres, des éléments p pour les paragraphes, des éléments a pour les ancres, etc. L’utilisation du HTML en fonction de son objectif est importante pour des raisons d’accessibilité, de réutilisation et d’efficacité du code.

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

Gardez strictement à l’écart la structure (balisage), la présentation (style) et le comportement (script) et essayez de maintenir l’interaction entre les trois à un minimum absolu. Autrement dit, assurez-vous que les documents et les modèles contiennent uniquement du HTML et du HTML qui sert uniquement à des fins structurelles. Déplacez tout ce qui est de présentation dans des feuilles de style et tout ce qui est comportemental dans des scripts. De plus, lier le moins possible de feuilles de style et de scripts à partir de documents et de modèles. Séparer la structure de la présentation du comportement est important pour des raisons de maintenance. Il est toujours plus coûteux de modifier des documents et des modèles HTML que de mettre à jour des feuilles de style et des scripts.

<!-- 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!

Il n’est pas nécessaire d’utiliser des références d’entité telles que -, ” ou ☺, en supposant que le même encodage (UTF-8) est utilisé pour les fichiers et les éditeurs ainsi qu’entre les équipes. Les seules exceptions s’appliquent aux caractères ayant une signification spéciale en HTML (comme < et &) ainsi qu’aux caractères de contrôle ou "invisibles" (comme les espaces insécables).

<!-- 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...

À des fins d’optimisation de la taille des fichiers et de capacité d’analyse, envisagez d’omettre les balises facultatives. La spécification HTML5 définit les balises qui peuvent être omises. (Cette approche peut nécessiter l’établissement d’un délai de grâce en tant que directive plus large, car elle est très différente de ce que les développeurs Web apprennent généralement. Pour des raisons de cohérence et de simplicité, il est préférable d’omettre toutes les balises facultatives, pas seulement une sélection.)

<!-- 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.

Exceptions ;- )

  • La balise de fin d’un élément html peut être omise si l’élément html n’est pas immédiatement suivi d’un commentaire.

  • La balise de début d’un élément head peut être omise si l’élément est vide ou si la première chose à l’intérieur de l’élément head est un élément.

  • La balise de fin d’un élément head peut être omise si l’élément head n’est pas immédiatement suivi d’un espace ASCII ou d’un commentaire.

  • La balise de début d’un élément body peut être omise si l’élément est vide, ou si la première chose à l’intérieur de l’élément body n’est pas un espace ASCII ou un commentaire, sauf si la première chose à l’intérieur de l’élément body est un meta, noscript, link, script, style ou élément template.

  • La balise de fin d’un élément body peut être omise si l’élément body n’est pas immédiatement suivi d’un commentaire.

  • La balise de fin d’un élément li peut être omise si l’élément li est immédiatement suivi d’un autre élément li ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément dt peut être omise si l’élément dt est immédiatement suivi d’un autre élément dt ou d’un élément dd.

  • La balise de fin d’un élément dd peut être omise si l’élément dd est immédiatement suivi d’un autre élément dd ou d’un élément dt, ou s’il

  • n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément p peut être omise si l’élément p est immédiatement suivi de address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, ou ul ou s’il n’y a plus de contenu dans l’élément parent et que l’élément parent est un élément HTML qui est pas un élément a, audio, del, ins, map, noscript ou video, ni un élément personnalisé autonome.

  • La balise de fin d’un élément rt peut être omise si l’élément rt est immédiatement suivi d’un élément rt ou rp, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément rp peut être omise si l’élément rp est immédiatement suivi d’un élément rt ou rp, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément optgroup peut être omise si l’élément optgroup est immédiatement suivi d’un autre élément optgroup, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément option peut être omise si l’élément option est immédiatement suivi d’un autre élément option, ou s’il est immédiatement suivi d’un élément optgroup, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de début d’un élément colgroup peut être omise si la première chose à l’intérieur de l’élément colgroup est un élément col, et si l’élément n’est pas immédiatement précédé d’un autre élément colgroup dont la balise de fin a été omise. (Il ne peut pas être omis si l’élément est vide.)

  • La balise de fin d’un élément colgroup peut être omise si l’élément colgroup n’est pas immédiatement suivi d’un espace ASCII ou d’un commentaire.

  • La balise de fin d’un élément caption peut être omise si l’élément caption n’est pas immédiatement suivi d’un espace ASCII ou d’un commentaire.

  • La balise de fin d’un élément thead peut être omise si l’élément thead est immédiatement suivi d’un élément tbody ou tfoot.

  • La balise de début d’un élément tbody peut être omise si la première chose à l’intérieur de l’élément tbody est un élément tr et si l’élément n’est pas immédiatement précédé d’un élément tbody, thead ou tfoot dont la balise de fin a été omise. (Il ne peut pas être omis si l’élément est vide.)

  • La balise de fin d’un élément tbody peut être omise si l’élément tbody est immédiatement suivi d’un élément tbody ou tfoot, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément tfoot peut être omise s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément tr peut être omise si l’élément tr est immédiatement suivi d’un autre élément tr, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément td peut être omise si l’élément td est immédiatement suivi d’un élément td ou th, ou s’il n’y a plus de contenu dans l’élément parent.

  • La balise de fin d’un élément th peut être omise si l’élément th est immédiatement suivi d’un élément td ou th, ou s’il n’y a plus de contenu dans l’élément parent.

Tous les détails sont expliqués dans la section « 13.1.2.4 Optional tags » du site officiel du HTML Living Standard (WHATWG)


<!-- 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>

Mais attention ;- )

Cependant, une balise de début ne doit jamais être omise si elle possède des attributs.


<!-- 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.

Si l’élément body dans cet exemple devait avoir un attribut class et que l’élément html devait avoir un attribut lang, le balisage devrait devenir :


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

Autant dire qu’en français, c’est obligatoire!

NOTE du WHATWG : Cette section suppose que le document est conforme, en particulier qu’il n’y a pas de violation du modèle de contenu. L’omission de balises de la manière décrite dans cette section dans un document qui n’est pas conforme aux modèles de contenu décrits dans cette spécification est susceptible d’entraîner des différences DOM inattendues (c’est en partie ce que les modèles de contenu sont conçus pour éviter).


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.

La spécification d’attributs de type dans ces contextes n’est pas nécessaire car HTML5 implique text/css et text/javascript par défaut. Cela peut être fait en toute sécurité même pour les navigateurs plus anciens.

<!-- 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 »

Préférez les attributs de class pour le style et les attributs data pour les scripts. Lorsque les attributs id sont strictement requis, incluez toujours un trait d’union dans la valeur pour vous assurer qu’il ne correspond pas à la syntaxe de l’identifiant JavaScript, par ex. utilisez user-profile plutôt que profile ou userProfile.

Lorsqu’un élément a un attribut id, les navigateurs le rendent disponible en tant que propriété nommée sur le prototype de la window globale, ce qui peut provoquer un comportement inattendu. Bien que les valeurs d’attribut id contenant un trait d’union soient toujours disponibles en tant que noms de propriété, elles ne peuvent pas être référencées en tant que variables JavaScript globales.


<!-- 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

Utilisez une nouvelle ligne pour chaque élément de bloc, de liste ou de tableau, et indentez chacun de ces éléments enfants. Indépendamment du style d’un élément (comme CSS permet aux éléments d’assumer un rôle d’affichage différent par display), placez chaque bloc, liste ou élément de tableau sur une nouvelle ligne. Indentez-les également s’il s’agit d’éléments enfants d’un élément de bloc, de liste ou de tableau. (Si vous rencontrez des problèmes d’espace entre les éléments de la liste, il est acceptable de mettre tous les éléments li sur une seule ligne. Une "demande" est encouragé à lancer un avertissement au lieu d’une erreur.)

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

Bien qu’il n’y ait pas de recommandation de limite de colonne pour HTML, vous pouvez envisager d’envelopper de longues lignes si cela améliore considérablement la lisibilité. Lors du retour à la ligne, chaque ligne de continuation doit être indentée d’au moins 4 espaces supplémentaires par rapport à la ligne d’origine pour distinguer les attributs enveloppés des éléments enfants.


<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

Utilisez des doubles ("") plutôt que des guillemets simples ('') autour des valeurs d’attribut.

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

Au lieu de noms de présentation ou cryptiques, utilisez toujours des noms de classe qui reflètent le but de l’élément en question, ou qui sont autrement génériques. Les noms qui sont spécifiques et reflètent le but de l’élément doivent être préférés car ils sont les plus compréhensibles et les moins susceptibles de changer. Les noms génériques sont simplement une solution de repli pour les éléments qui n’ont aucune signification particulière ou différente de leurs frères et sœurs. Ils sont généralement nécessaires en tant qu’"aides". L’utilisation de noms fonctionnels ou génériques réduit la probabilité de modifications inutiles de documents ou de modèles.


/* 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

Utilisez des noms de classe aussi courts que possible mais aussi longs que nécessaire. Essayez de transmettre le sujet d’un cours tout en étant aussi bref que possible. L’utilisation des noms de classe de cette manière contribue à des niveaux acceptables de compréhensibilité et d’efficacité du code.


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

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

Délimiteurs de nom de classe

Séparez les mots dans les noms de classe par un trait d’union. Ne concaténez pas les mots et les abréviations dans les sélecteurs par des caractères (y compris aucun) autres que des traits d’union, afin d’améliorer la compréhension et la lisibilité.


/* 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

Dans les grands projets ainsi que pour le code intégré dans d’autres projets ou sur des sites externes, utilisez des préfixes (comme espaces de noms) pour les noms de classe. Utilisez des identifiants courts et uniques suivis d’un tiret. L’utilisation d’espaces de noms permet d’éviter les conflits de noms et peut faciliter la maintenance, par exemple dans les opérations de recherche et de remplacement.


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

Sélecteurs de types

Sauf si nécessaire (par exemple avec des classes d’assistance), n’utilisez pas de noms d’éléments en conjonction avec des classes. Éviter les sélecteurs d’ancêtre inutiles est utile pour des raisons de performances.


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

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

Sélecteurs d’ID

Les attributs d’ID doivent être uniques sur une page entière, ce qui est difficile à garantir lorsqu’une page contient de nombreux composants travaillés par de nombreux ingénieurs différents. Les sélecteurs de classe doivent être préférés dans toutes les situations.


/* 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

Le CSS offre une variété de propriétés abrégées (comme la police) qui doivent être utilisées chaque fois que possible, même dans les cas où une seule valeur est explicitement définie. L’utilisation de propriétés abrégées est utile pour l’efficacité et la compréhensibilité du code.


/* 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

N’utilisez pas d’unités après les valeurs 0 sauf si elles sont obligatoires.


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

Mettez des 0 devant les valeurs ou les longueurs comprises entre -1 et 1.


font-size: 0.8em;

Notation hexadécimale

Pour les valeurs de couleur qui le permettent, la notation hexadécimale à 3 caractères est plus courte et plus succincte.


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

/* Recommandé */
color: #ebc;

Déclarations importantes (!important)

Ces déclarations cassent la cascade naturelle de CSS et rendent difficile le raisonnement et la composition des styles. Utilisez plutôt la spécificité du sélecteur pour remplacer les propriétés.


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

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

Hacks

Il est tentant d’aborder les différences de style sur la détection de l’agent utilisateur ou les filtres CSS spéciaux, les solutions de contournement et les hacks. Les deux approches doivent être considérées comme un dernier recours afin d’obtenir et de maintenir une base de code efficace et gérable. En d’autres termes, donner un laissez-passer à la détection et aux hacks nuira aux projets à long terme, car les projets ont tendance à emprunter la voie de la moindre résistance. Autrement dit, permettre et faciliter l’utilisation de la détection et des hacks signifie utiliser la détection et les hacks plus fréquemment - et plus fréquemment, c’est trop souvent.


/* 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

Triez les déclarations de manière cohérente au sein d’un projet. En l’absence d’outils pour automatiser et appliquer un ordre de tri cohérent, envisagez de classer les déclarations par ordre alphabétique afin d’obtenir un code cohérent d’une manière facile à apprendre, à mémoriser et à gérer manuellement. Ignorez les préfixes spécifiques au fournisseur à des fins de tri. Cependant, plusieurs préfixes spécifiques au fournisseur pour une certaine propriété CSS doivent rester triés (par exemple, le préfixe -moz vient avant -webkit).


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

Indentez tout le contenu du bloc, c’est-à-dire les règles dans les règles ainsi que les déclarations, afin de refléter la hiérarchie et d’améliorer la compréhension.

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

Terminez chaque déclaration par un point-virgule pour des raisons de cohérence et d’extensibilité.


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

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

Deux points de la déclaration

Utilisez toujours un seul espace entre la propriété et la valeur (mais pas d’espace entre la propriété et les deux-points) pour des raisons de cohérence.

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

Utilisez toujours un seul espace entre le dernier sélecteur et l’accolade ouvrante qui commence le bloc de déclaration.

L’accolade ouvrante doit être sur la même ligne que le dernier sélecteur d’une règle donnée.

/* 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

Commencez toujours une nouvelle ligne pour chaque sélecteur et déclaration.

À 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

Mettez toujours une ligne vide (deux sauts de ligne) entre les règles.


html {
  background: #fff;
}

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

Guillemets CSS

Utilisez des guillemets simples ('') plutôt que des guillemets doubles ("") pour les sélecteurs d’attributs et les valeurs de propriété. N’utilisez pas de guillemets dans les valeurs URI (url()). Exception : si vous devez utiliser la règle @charset, utilisez des guillemets doubles ; les guillemets simples ne sont pas autorisés.


/* 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

Si possible, regroupez les sections de feuille de style en utilisant des commentaires. Sections séparées avec de nouvelles lignes.

À 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

Si vous éditez du code, prenez quelques minutes pour regarder le code autour de vous et déterminer son style. S’ils utilisent des espaces autour de tous leurs opérateurs arithmétiques, vous devriez également le faire. Si leurs commentaires sont entourés de petites boîtes de marques de hachage, faites en sorte que vos commentaires soient également entourés de petites boîtes de marques de hachage.

L’intérêt d’avoir des directives de style est d’avoir un vocabulaire commun de codage afin que les gens puissent se concentrer sur ce que vous dites plutôt que sur la façon dont vous le dites. Nous présentons ici les règles de style globales afin que les gens connaissent le vocabulaire, mais le style local est également important. Si le code que vous ajoutez à un fichier semble radicalement différent du code existant qui l’entoure, il perturbe le rythme des lecteurs lorsqu’ils vont le lire. Évitez cela.

Source : Google HTML/CSS Style Guide

Références

Oznog
Dernière mise à jour :

Commentaires

    Ajouter un commentaire
    Votre adresse de courriel ne sera pas publiée. * L'astérisque indique les champs obligatoires.
    Votre évaluation du tutoriel

    10/10 sur 1 revues.
           Visites : 5543 - Pages vues : 5673
    X

    Trucsweb.com Connexion

    Connexion

    X

    Trucsweb.com Mot de passe perdu

    Connexion

    X

    Trucsweb.com Conditions générales

    Conditions

    Responsabilité

    La responsabilité des Trucsweb.com ne pourra être engagée en cas de faits indépendants de sa volonté. Les informations mises à disposition sur ce site le sont uniquement à titre purement informatif et ne sauraient constituer en aucun cas un conseil ou une recommandation de quelque nature que ce soit.

    Aucun contrôle n'est exercé sur les références et ressources externes, l'utilisateur reconnaît que les Trucsweb.com n'assume aucune responsabilité relative à la mise à disposition de ces ressources, et ne peut être tenue responsable quant à leur contenu.

    Droit applicable et juridiction compétente

    Les règles en matière de droit, applicables aux contenus et aux transmissions de données sur et autour du site, sont déterminées par la loi canadienne. En cas de litige, n'ayant pu faire l'objet d'un accord à l'amiable, seuls les tribunaux canadien sont compétents.

    X

    Trucsweb.com Trucsweb

    X

    Trucsweb.com Glossaire

    X

    Trucsweb.com Trucsweb

    X

    Trucsweb.com Trucsweb

    Conditions

    Aucun message!

    Merci.

    X
    Aucun message!
    X

    Trucsweb.com Créer un compte

    Créer un compte

    .
    @