web-dev-qa-db-fra.com

Conventions de dénomination HTML pour l'ID, la classe et pour inclure le préfixe du type d'élément?

Quelqu'un connaît-il une bonne ressource pour expliquer les bonnes conventions de dénomination pour les ID HTML et les classes et s'il faut préfixer les ID avec un type d'élément, c'est-à-dire btn ou bouton ou similaire?

Les classes doivent-elles être plurielles ou singulières? J'obtiens que les identifiants doivent être singuliers car ils sont uniques, mais qu'en est-il des classes?

Les identifiants et les classes doivent utiliser des noms, non?

J'utilise des pages qui injectent d'autres pages dans les pages existantes, un peu comme des pages partielles ... donc ... Je me demandais si quelqu'un préfixait un nom devant les identifiants et/ou les classes .. un peu comme un espace de noms ou similaire?

Tous les commentaires ou idées ont vraiment été appréciés.

htmlcssxhtmlnaming-conventions
61
mark smith

Je ne préfixerais pas le type, comme vous pouvez le déduire dans le sélecteur si vous devez

form#contact {
    property: value;

}

La méthode que vous avez décrite est connue sous le nom de notation hongroise et n'est pas très populaire.

Pour ce que vous mentionnez, vous pouvez placer votre code HTML injecté dans une div avec une classe/id unique, qui a une sorte de réinitialisation localisée. Recherchez le sélecteur CSS de manière spécifique pour vous assurer que vos règles prendront effet et non les autres règles dans le CSS de la page hôte. Voir cette réponse à une question similaire concernant le style d'un élément dans une page parent.

11
alex

2015: une nouvelle réponse axée sur les systèmes de nommage CSS et HTML existants

Pour toute convention que vous choisissez, je vous suggère de choisir des exigences qui ciblent les besoins de votre projet.

A savoir: votre projet est-il petit ou énorme? votre projet va-t-il être réutilisé ou doit-il gérer une sorte de thème? Les développeurs travaillant sur le CSS/HTML sont-ils désireux ou suffisamment expérimentés pour respecter les conventions? & bientôt..

Tout d'abord, si vous n'êtes pas au courant de cette pratique courante (bonne?): évitez les ID comme crochets de style, essayez de n'utiliser que des classes

Car:

  • seuls très peu de blocs (ex. en-tête de page, pied de page) peuvent garantir à 100% le fait qu'ils ne seront pas réutilisés ailleurs

  • vous voulez garder une spécificité faible, il y aura toujours des moments où vous devrez la remplacer (sans utiliser un sélecteur d'ID supplémentaire ou! important)

Exigences/conventions communes:

  • Les noms doivent être intuitifs/pleins de sens
  • NE PAS abréger les noms à moins que ce ne soit une abréviation vraiment bien connue (c'est-à-dire msg pour Message, accnt pour compte)
  • Utilisez des noms connus/communs: .site-nav, .aside-nav, .global-head, .btn-primary, .btn-secondary
  • Autoriser la hiérarchie structurelle (c'est-à-dire la convention BEM)
  • Utilisation - ou _ dans les noms: probablement subjectif (avis des développeurs) & en fonction des langues du clavier utilisées. Notez que camelCase a été laissé de côté pour les problèmes de compatibilité du navigateur, je crois, bien que je n'en ai jamais trouvé de preuve.
  • Ne jamais utiliser d'éléments dans les sélecteurs sauf cas exceptionnel: cela permet plus de flexibilité, c'est-à-dire. vous avez créé des boutons à l'aide de <input type="button"></input> et vous souhaitez passer à l'utilisation de <button></button>, si vous avez utilisé des types d'élément dans certains sélecteurs, vous pouvez planifier une refactorisation/un test/une correction de bogue ennuyeux/chronophage, tandis que si vous utilisez des sélecteurs sans élément, le changement sera infiniment plus facile. SMACCS l'a également dans ses conventions
  • Pour les états, essayez de faire correspondre les conventions connues d'autres langages (php, Java, c #): c'est-à-dire, utilisez "is-active", "is-badass", etc.
  • Nom de gauche à droite: du plus générique au plus précis, ie. btn-bluetheme-create-accnt ou accordion-modrnlook-userlist
  • un nom de classe ou d'id doit toujours être suffisamment spécifique pour être recherché dans l'ensemble d'un projet et renvoyer uniquement les résultats pertinents
  • Préférez le descendant direct si vous utilisez des sélecteurs descendants - utilisez .module-name > .sub-module-name contre .module-name .sub-module-name - vous vous éviterez des maux de tête à l'avenir (CSS plus simple mais aussi plus performant, bien que le terme "performances CSS puisse être risible")

Conventions connues:

Convention d'appellation structurelle: nommez la classe de l'élément en décrivant ce qu'il est, plutôt que son emplacement ou son aspect. Voir les exemples ci-dessous.

.page-container
     .page-wrap-header-n-content
     .page-header
          .branding-logo
          .branding-tagline
          .wrapper-search
          .page-nav-main
     .page-main-content
     .page-secondary-content
          .nav-supplementary
     .page-footer
          .site-info

Convention de dénomination de présentation: nomme la classe de l'élément en décrivant son emplacement et/ou son apparence. Voir les exemples ci-dessous.

.theme-ocean-blue
.theme-apricot-orange
.skin-red-tango
.skin-darkness

Convention de dénomination sémantique: nom en décrivant le contenu qu'il contient. Voir dans les exemples ci-dessous.

.product-review
.notification
.language-switch
.currency-switch
.list-of-friends
.latest-status

Convention de dénomination BEM: signifie "Block, Element, Modifier". La syntaxe est telle que <module-name>__<sub-module-name>--<modifier-or-state>. Le bloc est un conteneur "principal", une sorte de module/composant, peu importe comment vous l'appelez. L'élément n'est qu'un composant enfant du composant principal (le bloc). Le modificateur est une sorte d'état. Particularités: la syntaxe (utilisation du trait de soulignement dbl et du tiret dbl), et les éléments enfants doivent contenir le nom de leur composant le plus proche. Voir les exemples ci-dessous.

.nav-primary
.nav-primary__list
.nav-primary__item
.nav-primary__link
.nav-primary__link--is-active

.grid
.grid__item
.grid__description
.grid__img-wrap
.grid__img

.global-footer
.global-footer__col
.global-footer__header
.global-footer__link

Convention de dénomination OCSS: signifie CSS orienté objet. Utilise des skins à des fins de branding ou de cohérence du design (ex. Bg color, border color, ...). Résume les styles structurels. Exemple de style structurel abstrait ci-dessous. Deux principes principaux de l'OOCSS: structure et habillage séparés, deuxième contenant et contenu séparés.

 .global-width {
      min-width: 780px;    /* minimum width */
      max-width: 1400px;   /* maximum width */
      margin: 0 auto;      /* Centering using margin: auto */
      position: relative;  /* Relative positioning to create a positioning context for child elements */
      padding-left: 20px;
      padding-right: 20px;
      overflow: hidden;    /* Overflow set to "hidden" for clearfixing */
 }

Quelques directives CSS:

Il y a eu une "tendance" à partager votre guide de style CSS, en voici quelques-unes que vous pouvez lire pour choisir ce qui semble correspondre à vos besoins (convention de dénomination mais aussi bien plus, cela peut être hors de portée de votre question):

Mon opinion biaisée:

J'utilise actuellement un mélange de [~ # ~] bem [~ # ~] , sémantique & conventions de dénomination structurelles et ça a très bien fonctionné.

[~ # ~] bem [~ # ~] & sémantique fonctionne assez bien ensemble (oui, je nomme mes classes comme .list-of-friends__single-friend). BEM rend les choses particulièrement simples: pas de folie imbriquée dans le CSS et du code très verbeux.

La convention de dénomination structurelle est également la bienvenue pour la structure nue du site Web, ou pour chaque "modèle" si le site Web a plusieurs structures. À mon avis, cela ne devrait être utilisé que pour des éléments très génériques, alors utilisez-le soigneusement.

Convention de dénomination de présentation : vraiment ?? Merci mais, non merci. Vous pouvez le considérer dans des cas particuliers (par exemple, habiller une page entière dans différents thèmes).

[~ # ~] ocss [~ # ~] convention de dénomination: je dois admettre, je dois quand même approfondir la question. J'ai fourni des liens dans les ressources ci-dessous pour que vous puissiez approfondir votre recherche.

Ressources:

67
Adrien Be

Beaucoup de gens ne réalisent pas que vous pouvez faire ce genre de choses:

.awesome {
 /* rules for anything awesome */
}

div.awesome {
 /* rules for only awesome divs */
}

button.awesome {
 /* rules for any awesome buttons, but not awesome divs */
}

div.awesome h1 {
 /* rules for H1s inside of any div.awesome */
}

div.awesome>button {
 /* rules for immediate children buttons (not grandchildren+) of div.awesomes */
}
19
Ryan Florence