Pourquoi sont des tirets préféré pour les sélecteurs CSS / attributs HTML?

Question

Dans le passé, j'ai toujours utilisé le caractère de soulignement pour la définition de la classe et id attributs HTML. Au cours de la dernière quelques années, j'ai changé de tirets, surtout pour aligner moi-même avec la tendance dans la communauté, pas nécessairement parce qu'il fait sens pour moi.

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

La complétion de Code et d'Édition

La plupart des éditeurs de traiter des tirets comme des séparateurs de mots, donc je ne peux pas l'onglet à travers le symbole de la je veux. Dire que la classe est "featured-product", j'ai pour l'auto-complétion "featured", entrer un trait d'union, et complète "product".

Avec des traits de soulignement "featured_product" est traité comme un seul mot, donc il peut être rempli en une seule étape.

La même chose s'applique à la navigation dans le document. Saut en mots ou en double-cliquant sur les noms de classe est cassé par des traits d'union.

(Plus généralement, je pense que de classes et les id comme des jetons, donc ça n'a pas de sens pour moi qu'un jeton doit être si facilement splittable sur des traits d'union.)

L'ambiguïté avec les opérateurs arithmétiques

En utilisant des tirets pauses objet de la propriété de l'accès à des éléments de formulaire en JavaScript. Cela n'est possible que par des caractères de soulignement:

form.first_name.value='Stormageddon';

(Il est vrai que je n'ai pas accès à des éléments de formulaire, de cette façon, moi-même, mais au moment de décider sur des tirets vs traits de soulignement comme une règle universelle, considère que quelqu'un pourrait.)

Les langues, comme le Sass (en particulier tout au long de la Boussole cadre) se sont installés sur des tirets comme une norme, même pour les noms de variables. Ils ont utilisé le caractère de soulignement au début aussi. Le fait que ceci est analysé différemment, me paraît bizarre:

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

Incompatibilité avec l'appellation variable à travers les langues

Retour dans la journée, j'ai utilisé pour écrire underscored_names pour les variables en PHP, ruby, HTML/CSS, et JavaScript. Cela a été facile et uniforme, mais encore une fois, afin de "tenir dans" je vais maintenant utiliser:

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

Ce ne sont pas vraiment me dérange pas trop, mais je me demande pourquoi c'est devenu tellement mal alignées, apparemment sur la fin. Au moins avec des traits de soulignement, il a été possible de maintenir la cohérence:

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

Les différences de créer des situations où nous devons traduire les chaînes inutilement, ainsi que le potentiel pour les bugs.

Alors je vous le demande: Pourquoi la communauté presque universellement s'installer sur des tirets, et il y a toutes les raisons qui l'emportent sur les traits de soulignement?

Il y a une question connexe de l'arrière à travers le temps, cela a commencé, mais je suis de l'avis qu'il n'est pas (ou ne devrait pas l' avoir été) juste une question de goût. J'aimerais comprendre pourquoi nous sommes tous installés sur la présente convention si elle était vraiment juste une question de goût.

Answer 1

La complétion de Code

Si le tableau de bord est interprété comme un signe de ponctuation ou un identifiant opaque dépend de l'éditeur de choix, je suppose. Cependant, comme une question de préférence personnelle, je préfère être en mesure de tabulation entre chaque mot dans un fichier CSS et qu'ils trouvent que c'est gênant si elles étaient séparées par un trait de soulignement et il n'y avait pas de cesse.

Aussi, l'utilisation des traits d'union vous permet de profiter de la |= sélecteur d'attributs, qui permet de sélectionner n'importe quel élément contenant le texte, éventuellement suivie par un tiret:

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

Cela rendrait le code HTML suivant les éléments ont italique font-style:

<span class="em">I'm italic</span>
<span class="em-strong">I'm italic too</span>

L'ambiguïté avec les opérateurs arithmétiques

Je dirais que l'accès à des éléments HTML via la notation de point en JavaScript est un bug plutôt que d'une fonction. C'est un terrible construire dès les premiers jours de la terrible implémentations de JavaScript et n'est pas vraiment une grande pratique. Pour la plupart des choses que vous faites avec JavaScript ces jours, vous souhaitez utiliser les Sélecteurs CSS pour aller chercher des éléments du DOM toute façon, ce qui rend l'ensemble de la notation point plutôt inutile. Lequel préférez-vous?

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

Je trouve les deux premières options sont beaucoup plus préférable, surtout depuis '#first-name' peut être remplacée par une variable JavaScript et construit de manière dynamique. Je trouve aussi plus agréable pour les yeux.

Le fait que Sass permet de compter dans ses extensions CSS ne s'applique pas à la CSS de lui-même, mais je ne comprends (et étreinte) le fait que Sass suit le langage de style CSS (sauf pour l' $ préfixe de variables, ce qui bien sûr doit avoir été @). Si Sass documents sont à regarder et se sentir comme les documents CSS, ils doivent suivre le même style que le CSS, qui utilise un tiret comme séparateur. En CSS3, l'arithmétique est limitée à l' calc de la fonction, ce qui tend à montrer que dans le CSS lui-même, ce n'est pas un problème.

Incompatibilité avec l'appellation variable à travers les langues

Toutes les langues, en cours de balisage en langues, langages de programmation, le style de langues ou langages de script, ont leur propre style. Vous trouverez cela dans les sous-langues des groupes linguistiques comme XML, où par exemple XSLT utilise des bas-de-casse avec trait d'union séparateurs et les schémas XML utilise des chameaux boîtier.

En général, vous constaterez que d'adopter le style qui sent et ressemble le plus "natif" de la langue que vous écrivez est mieux que d'essayer de chausse-pied votre propre style dans chaque langue différente. Puisque vous ne pouvez pas éviter d'avoir à utiliser des bibliothèques natives et les constructions de langage, votre style va être "pollué" par le natif de style si vous l'aimez ou pas, donc il est assez vain de même essayer.

Mon conseil est de ne pas trouver un favori de style à travers les langues, mais au lieu de vous rendre à la maison à l'intérieur de chaque langue et d'apprendre à les aimer tous ses caprices. L'un des CSS quirks est que les mots clés et les identifiants sont écrits en minuscules et séparés par des traits d'union. Personnellement, je trouve cela très agréable visuellement et pense qu'il s'inscrit dans les minuscules (bien que sans trait d'union) HTML.

Answer 2

Peut-être l'une des principales raisons pourquoi le HTML/CSS de la communauté est associée avec des tirets au lieu de soulignement est le fruit de l'histoire des lacunes dans les specs et le navigateur implémentations.

À partir d'un Mozilla doc, publié en Mars 2001 @ https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

La spécification CSS1, publié sous sa forme définitive en 1996, n'a pas permettre l'utilisation de caractères de soulignement dans les class et ID noms, à moins qu'ils ont été "s'est échappé." Un échappé de soulignement ressemblerait à quelque chose comme ceci:

    p.urgent\_note {color: maroon;}

Cela n'a pas été bien pris en charge par les navigateurs, à l'époque, cependant, et la la pratique n'a jamais pris. CSS2, publié en 1998, a aussi interdit l'utilisation des caractères de soulignement dans les class et ID noms. Cependant, errata à la spécification publiée au début de 2001, souligne l' première fois. Cela s'est malheureusement compliqué, déjà complexe paysage.

De manière générale, j'aime souligne mais la barre oblique inverse, il fait juste laid au-delà de l'espoir, pour ne pas mentionner le peu d'appui à l'époque. Je peux comprendre pourquoi les développeurs s'en méfie comme de la peste. Bien sûr, nous n'avons pas besoin de la barre oblique de nos jours, mais le tableau de bord de l'étiquette a déjà été fermement établie.

Answer 3

Je ne pense pas que n'importe qui peut répondre à cette façon définitive, mais voici mes hypothèses:

1. Souligne besoin de frapper la touche Maj enfoncée, et sont donc plus difficiles à saisir.

2. Les sélecteurs CSS qui sont officiellement partie des spécifications CSS utiliser des tirets (tels que les pseudo-classes comme :d'abord l'enfant et les pseudo-éléments :first-line), pas de traits de soulignement. Même chose pour les propriétés, par exemple text-decoration, couleur de fond, etc. Les programmeurs sont des créatures d'habitude. Il est logique qu'ils suivent les normes du style si il n'y a aucune bonne raison de ne pas.

3. Celui-ci est plus loin sur la corniche, mais... Si c'est un mythe ou une réalité, il est de longue date l'idée 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 comme des mots séparés. (Matt Cutts sur Souligne vs Tirets.) Pour cette raison, je sais que ma préférence, maintenant, pour la création d'une page Url est l'utilisation de mots-avec-des tirets, et pour moi au moins, cela a saigné dans mon conventions de nommage pour les autres choses, comme les sélecteurs CSS.

Answer 4

Il y a eu une nette reprise du trait d'union-séparé, l'ensemble des segments de parole de l'Url au cours des dernières années. Cela est encouragé par les bonnes pratiques SEO. Google explicitement "vous recommandons d'utiliser des traits d'union (-) au lieu de soulignement (_) dans votre Url": http://www.google.com/support/webmasters/bin/answer.py?answer=76329.

Comme indiqué, les différentes conventions ont prévalu à des moments différents dans des contextes différents, mais ils ne sont généralement pas une partie officielle de tout protocole ou d'un cadre.

Mon hypothèse est donc que la position de Google ancres de ce motif dans un délai d'une clé de contexte (SEO), et la tendance à utiliser ce modèle dans la classe, id et les noms d'attribut est tout simplement le troupeau se déplaçant lentement dans cette direction.