web-dev-qa-db-fra.com

Considérations pratiques pour les conventions de dénomination HTML / CSS (syntaxe)

Question: quelles sont les considérations pratiques pour la syntaxe dans les valeurs class et id?

Notez que je ne pose pas de questions sur la sémantique, c'est-à-dire les mots réels qui sont utilisés, comme par exemple décrit dans cet article de blog . Il y a déjà beaucoup de ressources de ce côté des conventions de nommage, obscurcissant en fait ma recherche d'informations pratiques sur les différents syntaxiques bits: casing, utilisation de l'interponction (en particulier le - tiret), des caractères spécifiques à utiliser ou à éviter, etc.

Pour résumer les raisons pour lesquelles je pose cette question:

  • La dénomination restrictions on id et class ne mène naturellement à aucune convention
  • L'abondance de ressources du côté sémantique des conventions de dénomination obscurcit les recherches sur les considérations syntaxiques
  • Je n'ai trouvé aucune source faisant autorité sur ce
  • Il n'y avait pas encore de question sur les programmeurs SE sur ce sujet :)

Certaines des conventions que j'ai envisagées d'utiliser:

  1. UpperCamelCase, principalement comme habitude croisée du codage côté serveur
  2. lowerCamelCase, pour cohérence avec conventions de dénomination JavaScript
  3. css-style-classes, ce qui est cohérent avec la dénomination des propriétés css (mais peut être ennuyeux lorsque Ctrl + Shift + ArrowKey sélection du texte)
  4. with_under_scores, que je n'ai personnellement pas vu beaucoup utilisé
  5. alllowercase, simple à retenir mais peut être difficile à lire pour les noms plus longs
  6. UPPERCASEFTW, comme un excellent moyen d'agacer vos collègues programmeurs (peut-être combiné avec l'option 4 pour la lisibilité)

Et j'ai probablement laissé de côté certaines options ou combinaisons importantes. Alors: quelles considérations y a-t-il pour nommer les conventions, et à quelle convention mènent-elles?

coding-stylenaminghtmlcoding-standardscss
28
Jeroen

Bounty ou non, dans une certaine mesure, le choix sera toujours une "question de préférence" - après tout, comment vous sentiriez-vous si le W3C recommandait (ou même imposait) une certaine convention que vous ne jugiez pas correcte?

Cela dit, cependant, je préfère personnellement la convention lowerCamelCase, et je donnerai les raisons et les considérations pratiques que j'ai utilisées pour me décider - je le ferai par un processus d'élimination, en utilisant la numérotation de votre question:

(5.) n'est pas facilement lisible car vous ne savez pas où commencer.

(6.) ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTTING.

(4.) historic_incompatibility_plus_see: Documentation Mozilla Dev .

(3.) un peu plus compliqué à expliquer ... comme vous le mentionnez, la sélectionnabilité dans les éditeurs de texte est un problème (comme avec les traits de soulignement, selon l'éditeur), mais pour moi, c'est aussi le fait que cela me rappelle la syntaxe réservée à mots clés spécifiques au fournisseur , même si ceux-ci commencent par un tiret ainsi que par des mots séparés par eux.

Donc, cela laisse votre (1.) et (2.), UpperCamelCase et lowerCamelCase, respectivement. Malgré le lien mental avec les classes Java (qui sont, par une convention plus clairement définie, UpperCamelCase), classe CSS les noms me semblent être mieux en commençant par une lettre minuscule. C'est peut-être à cause de élément XHTML et noms d'attribut , mais je suppose que vous pourriez également faire valoir que le fait d'avoir des classes CSS utilise UpperCamelCase Si vous avez besoin d'une autre raison, lowerCamelCase est ce que le W3C utilise dans exemples de bons noms de classe (bien que l'URL elle-même, ennuyeusement, soit en désaccord avec moi).

Je déconseille (4.), (5.) et (6.), pour les raisons indiquées ci-dessus, mais je suppose que des arguments pourraient être avancés pour l'un ou l'autre des trois autres.

Que vous (ou quelqu'un d'autre d'ailleurs) soyez d'accord avec moi sur cette question dépend de vous. Le fait que vous n'ayez pas de réponse définitive citant des sources faisant autorité peut être considéré comme un indice qu'il n'est pas une telle chose comme un standard précis sur ce problème (sinon nous l'utiliserions tous). Je ne suis pas sûr que ce soit nécessairement une mauvaise chose.

18
Amos M. Carpenter

Les mots dans les noms de classe CSS doivent être séparés par des tirets (class-name), car c'est ainsi que les mots dans les propriétés CSS et pseudo-classes sont séparés et leur syntaxe est définie par le spécifications CSS .

Les mots dans les noms d'ID doivent également être séparés par des tirets, pour correspondre au style syntaxique des noms de classe et parce que les noms d'ID sont souvent utilisés dans les URL et le tiret est le séparateur de mots original et le plus courant dans les URL.

7
Emanuil Rusev

C'est surtout une question de préférence; il n'existe aucune norme établie, et encore moins une source faisant autorité, en la matière. Utilisez ce qui vous convient le mieux; soyez juste cohérent.

Personnellement, j'utilise css-style-with-dashes, Mais j'essaie d'éviter les noms de classe multi-Word et d'utiliser plusieurs classes autant que possible (donc button important default Plutôt que button-important-default). D'après mon expérience, cela semble également être le choix le plus populaire parmi les sites Web et les cadres de haute qualité.

Les minuscules avec des tirets sont également plus faciles à taper que les autres options (à l'exception de la convention nowordseparatorswhatsoever difficile à lire), au moins sur les claviers américains, car cela ne nécessite pas l'utilisation de la touche Maj.

Pour les identifiants, il y a la considération pratique supplémentaire que si vous voulez référencer les éléments par leur ID directement en javascript (par exemple document.forms[0].btn_ok), Les tirets ne fonctionneront pas si bien - mais alors, si vous utilisez jQuery, vous allez probablement les utiliser via $() de toute façon, donc vous pouvez simplement avoir $('#btn-ok'), ce qui rend ce point principalement théorique.

Pour mémoire, une autre convention que je rencontre utilise régulièrement des verrues hongroises dans les identifiants pour indiquer le type d'élément, en particulier pour les contrôles de formulaire - vous auriez donc #lblUsername, #tbUsername, #valUsername pour le nom d'utilisateur, l'entrée et le validateur.

3
tdammers

Je crois fermement que ce qui importe le plus, c'est la cohérence.

Il y a deux façons de regarder ceci:

  1. Un bon argument peut être fait pour alllowercase ou css-style-clauses (probablement le meilleur choix) car ils seront les plus cohérents avec le code dans lequel ils se trouveront. Cela donnera un flux plus naturel au code dans son ensemble et rien ne sera discordant ou déplacé.

  2. Un argument tout aussi valable peut être avancé pour un style distinct des noms de balises HTML ou des clauses CSS, s'il différencie les ID et les classes de manière à faciliter la lisibilité. Par exemple, si vous avez utilisé UpperCamelCase pour les ID et les classes, et que vous ne l'avez utilisé pour aucune autre construction ou fin, vous sauriez que vous en avez rencontré une à chaque fois que vous avez vu un jeton dans ce format. Une restriction que cela pourrait imposer est qu'il serait plus efficace si chaque ID ou classe était un nom de mot 2+, mais c'est raisonnable dans de nombreux cas.

En écrivant cette réponse, je me suis rendu compte que je suis beaucoup plus enclin au deuxième choix, mais je vais laisser les deux parce que je pense que les deux cas ont du mérite.

2
asfallows