Pourquoi les tirets sont-ils préférés pour les sélecteurs CSS / atsortingbuts HTML?

Dans le passé, j’ai toujours utilisé des caractères de soulignement pour définir les atsortingbuts de classe et d’ ID en HTML. Au cours des dernières années, je me suis tourné vers les élans, principalement pour me conformer à la tendance dans la communauté , pas nécessairement parce que cela avait un sens pour moi.

J’ai toujours pensé que les tirets ont plus d’inconvénients, et je ne vois pas les avantages:

Achèvement du code et édition

La plupart des éditeurs traitent les tirets comme des séparateurs de mots. Je ne peux donc pas accéder au symbole que je veux. Disons que la classe est ” featured-product “, je dois compléter automatiquement ” featured “, entrez un trait d’union et complétez ” product “.

Avec les featured_product soulignement, ” featured_product ” est traité comme un seul mot, il peut donc être rempli en une seule étape.

La même chose s’applique à la navigation dans le document. Sauter par mots ou double-cliquer sur les noms de classes est interrompu par des tirets.

(Plus généralement, je considère les classes et les identifiants comme des jetons , donc cela n’a pas de sens pour moi qu’un jeton soit si facilement séparable sur les tirets).

Ambiguïté avec opérateur arithmétique

L’utilisation de tirets interrompt l’ access à la propriété d’object pour former des éléments dans JavaScript. Ceci est uniquement possible avec les soulignés:

 form.first_name.value='Stormageddon'; 

(Certes, je n’ai pas access aux éléments de formulaire de cette manière, mais lorsque vous choisissez des tirets ou des traits de soulignement comme règle universelle, considérez que quelqu’un pourrait le faire.)

Les langages comme Sass (en particulier dans le cadre Compass ) ont défini les tirets comme standard, même pour les noms de variables. Au début, ils ont également utilisé des traits de soulignement. Le fait que cela soit analysé différemment me semble étrange:

 $list-item-10 $list-item - 10 

Incohérence avec la dénomination des variables dans les différentes langues

Dans le passé, j’écrivais underscored_names pour les variables PHP, Ruby, HTML / CSS et JavaScript. C’était pratique et cohérent, mais encore une fois, afin de “s’intégrer”, j’utilise maintenant:

  • dash-case en HTML / CSS
  • camelCase en JavaScript
  • underscore_case en PHP et ruby

Cela ne me dérange pas vraiment trop, mais je me demande pourquoi ceux-ci sont devenus si mal alignés, apparemment express. Au moins avec des traits de soulignement, il était possible de maintenir la cohérence:

 var featured_product = $('#featured_product'); // instead of var featuredProduct = $('#featured-product'); 

Les différences créent des situations où nous devons traduire des chaînes inutilement, avec le potentiel de bogues.

Alors, je demande: pourquoi la communauté s’est-elle presque universellement installée sur les élans, et y a-t-il des raisons qui l’emportent sur les soulignés?

Il y a une question connexe à l’époque où cela a commencé, mais je pense que ce n’est pas (ou n’aurait pas dû être) une question de goût. J’aimerais comprendre pourquoi nous avons tous adopté cette convention si c’était vraiment une question de goût.

    Achèvement du code

    Que le tiret soit interprété comme une ponctuation ou comme un identifiant opaque dépend de l’éditeur de choix, je suppose. Cependant, en tant que préférence personnelle, je privilégie la possibilité d’intercaler chaque mot dans un fichier CSS et je trouverais cela ennuyeux s’ils étaient séparés par un trait de soulignement et qu’il n’y ait pas d’arrêt.

    De même, l’utilisation de tirets vous permet de tirer parti du sélecteur d’atsortingbut | = , qui sélectionne tout élément contenant le texte, éventuellement suivi d’un tiret:

     span[class|="em"] { font-style: italic; } 

    Cela rendrait les éléments HTML suivants en italique:

     I'm italic I'm italic too 

    Ambiguïté avec opérateur arithmétique

    Je dirais que l’access aux éléments HTML via la notation par points dans JavaScript est un bogue plutôt qu’une fonctionnalité. C’est une construction terrible depuis les débuts des terribles mises en œuvre de JavaScript et n’est pas vraiment une bonne pratique. Pour la plupart des choses que vous faites avec JavaScript de nos jours, vous voudrez de toute façon utiliser des sélecteurs CSS pour récupérer des éléments du DOM, ce qui rend la notation par points plutôt inutile. Lequel préfèrerais tu?

     var firstName = $('#first-name'); var firstName = document.querySelector('#first-name'); var firstName = document.forms[0].first_name; 

    Je trouve les deux premières options beaucoup plus préférables, d’autant plus que '#first-name' peut être remplacé par une variable JavaScript et construit dynamicment. Je les trouve aussi plus agréables sur les yeux.

    Le fait que Sass active l’arithmétique dans ses extensions pour CSS ne s’applique pas vraiment à CSS lui-même, mais je comprends (et emarmse) le fait que Sass suit le style de langage de CSS (à l’exception du préfixe $ des variables aurait dû être @ ). Si les documents Sass doivent ressembler à des documents CSS, ils doivent suivre le même style que CSS, qui utilise un tiret comme séparateur. En CSS3, l’arithmétique est limitée à la fonction calc , ce qui montre que dans CSS lui-même, ce n’est pas un problème.

    Incohérence avec la dénomination des variables dans les différentes langues

    Toutes les langues, à savoir les langages de balisage, les langages de programmation, les langages de style ou les langages de script, ont leur propre style. Vous trouverez cela dans des sous-langages de groupes de langues comme XML, où par exemple XSLT utilise des minuscules avec des délimiteurs de tirets et XML Schema utilise camel-casing.

    En général, vous constaterez qu’il est préférable d’adopter le style qui semble le plus “natif” à la langue dans laquelle vous écrivez, plutôt que d’essayer de personnaliser votre propre style dans toutes les langues. Comme vous ne pouvez pas éviter d’avoir à utiliser des bibliothèques natives et des constructions de langage, votre style sera “pollué” par le style natif, que cela vous plaise ou non. Il est donc inutile d’essayer.

    Mon conseil est de ne pas trouver un style préféré dans toutes les langues, mais plutôt de vous sentir chez vous dans chaque langue et d’apprendre à aimer tous ses caprices. L’une des particularités de CSS est que les mots-clés et les identificateurs sont écrits en minuscules et séparés par des tirets. Personnellement, je trouve cela très attrayant et je pense qu’il correspond bien au HTML en minuscules (même si aucun trait d’union).

    Une des principales raisons pour lesquelles la communauté HTML / CSS s’est alignée sur les tirets au lieu des traits de soulignement est peut-être due à des lacunes historiques dans les spécifications et les implémentations du navigateur.

    Extrait d’un document Mozilla publié en mars 2001 @ https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

    La spécification CSS1, publiée sous sa forme définitive en 1996, ne permettait pas d’utiliser des traits de soulignement dans les noms de classe et d’ID sauf s’ils étaient «échappés». Un soulignement évité ressemblerait à ceci:

      p.urgent\_note {color: maroon;} 

    Ce n’était pas bien pris en charge par les navigateurs à l’époque, cependant, et la pratique n’a jamais pris le dessus. CSS2, publié en 1998, interdit également l’utilisation de traits de soulignement dans les noms de classe et d’ID. Cependant, les errata à la spécification publiée au début de 2001 ont rendu les soulignés légaux pour la première fois. Cela compliquait malheureusement un paysage déjà complexe.

    J’apprécie généralement les soulignés, mais la contre-attaque ne fait que rendre la vie désespérée, sans parler de la rareté du soutien à l’époque. Je peux comprendre pourquoi les développeurs l’ont évité comme la peste. Bien sûr, nous n’avons pas besoin de la barre oblique de nos jours, mais l’étiquette de tableau de bord a déjà été fermement établie.

    Je ne pense pas que quiconque puisse y répondre définitivement, mais voici mes suppositions éduquées:

    1. Les traits de soulignement nécessitent un appui sur la touche Maj et sont donc plus difficiles à taper.

    2. Les sélecteurs CSS qui font partie des spécifications CSS officielles utilisent des tirets (tels que les pseudo-classes comme: premier-enfant et pseudo-éléments: première ligne), et non des traits de soulignement. Même chose pour les propriétés, par exemple la décoration de texte, la couleur de fond, etc. Les programmeurs sont des créatures d’habitude. Il est logique qu’ils suivent le style de la norme s’il n’y a pas de raison de ne pas le faire.

    3. Celui-ci est plus éloigné, mais … Que ce soit un mythe ou un fait, il y a une idée de longue date que Google traite les mots séparés par des traits de soulignement comme un seul mot et les mots séparés par des tirets. (Matt Cutts sur Underscores vs. Dashes.) Pour cette raison, je sais que ma préférence maintenant pour créer des URL de page est d’utiliser des mots-avec-tirets, et pour moi au moins, cela a saigné dans mes conventions de nommage pour d’autres choses , comme les sélecteurs CSS.

    Ces dernières années, il y a eu une nette augmentation du nombre de segments d’URL séparés par des traits d’union. Ceci est encouragé par les meilleures pratiques SEO. Google recommande explicitement “d’utiliser des traits d’union (-) au lieu de traits de soulignement (_) dans vos URL”: http://www.google.com/support/webmasters/bin/answer.py?answer=76329 .

    Comme indiqué précédemment, différentes conventions ont prévalu à différents moments dans différents contextes, mais elles ne font généralement pas partie intégrante d’un protocole ou d’un cadre.

    Mon hypothèse est donc que la position de Google ancre ce modèle dans un contexte clé (SEO), et la tendance à utiliser ce modèle dans les noms de classe, d’identifiant et d’atsortingbut est simplement le mouvement lent du troupeau dans cette direction générale.

    Il y a plusieurs raisons, mais l’une des plus importantes est de maintenir la cohérence .

    Je pense que cet article l’explique de manière exhaustive.

    CSS est une syntaxe délimitée par des traits d’union. Je veux dire par là que nous écrivons des choses comme font-size , la line-height , la border-bottom etc.

    Alors:

    Vous ne devriez pas mélanger les syntaxes: c’est incohérent .

    Je pense que c’est une chose qui dépend du programmeur. Certains aiment utiliser des tirets, d’autres utilisent des traits de soulignement.
    J’utilise personnellement des traits de soulignement ( _ ) parce que je l’utilise aussi ailleurs. Tel que:
    – les variables JavaScript ( var my_name );
    – Mes actions de contrôleur ( public function view_detail )
    Une autre raison pour laquelle j’utilise des caractères soulignés est la suivante: dans la plupart des EDI, deux mots séparés par des traits de soulignement sont considérés comme 1 mot. (et il est possible de sélectionner avec double_click).