¿Por qué se prefieren los guiones para los selectores CSS / atributos HTML?

En el pasado siempre he usado guiones bajos para definir los atributos class y id en HTML. En los últimos años cambié a guiones, principalmente para alinearme con la tendencia en la comunidad, no necesariamente porque tuviera sentido para mí.

Siempre he pensado que los guiones tienen más inconvenientes, y no veo los beneficios:{[18]]}

Finalización y edición de código

La mayoría de los editores tratan los guiones como separadores de palabras, por lo que no puedo tabular hasta el símbolo que quiero. Digamos que la clase es " featured-product", tengo que autocompletar "featured", introducir un guion y completar "product".

Con guiones bajos "featured_product" se trata como una sola palabra, por lo que se puede rellenar en un solo paso.

Lo mismo se aplica a la navegación a través del documento. Saltar por palabras o hacer doble clic en los nombres de las clases se rompe por guiones.

(Más generalmente, pienso en clases e ids como tokens , por lo que no tiene sentido para mí que un token deba ser tan fácilmente divisible en guiones.)

Ambigüedad con el operador aritmético

El uso de guiones rompe la propiedad-objeto el acceso a los elementos del formulario en JavaScript. Esto solo es posible con guiones bajos:

form.first_name.value='Stormageddon';

(Es cierto que yo no acceso a los elementos de formulario de esta manera, pero al decidir sobre guiones vs guiones bajos como una regla universal, considere que alguien podría.)

Idiomas como Sass (especialmente en todo el marco Compass ) tienen se estableció en guiones como estándar, incluso para nombres de variables. Originalmente usaban guiones bajos al principio también. El hecho de que esto se analiza de manera diferente me parece extraño:

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

Inconsistencia con la nomenclatura de variables entre idiomas

En el pasado, solía escribir underscored_names para variables en PHP, ruby, HTML/CSS y JavaScript. Esto era conveniente y consistente, pero de nuevo para "encajar" ahora uso:

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

Esto realmente no me molesta demasiado, pero me pregunto por qué estos se volvieron tan desalineados, aparentemente a propósito. Al menos con guiones bajos era posible mantener la consistencia:

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

Las diferencias crean situaciones en las que tenemos que traducir cadenas innecesariamente, junto con el potencial de errores.

Así que pregunto: ¿Por qué la comunidad casi universalmente se conformó con guiones, y hay alguna razón ¿eso supera a los subrayados?

Hay una pregunta relacionada de la época en que esto comenzó, pero soy de la opinión de que no es (o no debería haber sido) solo una cuestión de gusto. Me gustaría entender por qué todos decidimos esta convención si realmente era solo una cuestión de gustos.

Author: Community, 2011-09-27
Source

6 answers

Finalización del código

Si el guion se interpreta como puntuación o como un identificador opaco depende del editor de elección, supongo. Sin embargo, como preferencia personal, estoy a favor de poder tabular entre cada palabra en un archivo CSS y me parecería molesto si se separaran con subrayado y no hubiera paradas.

Además, el uso de guiones le permite aprovechar el selector de atributos |= , que selecciona cualquier elemento que contenga el texto, opcionalmente seguido de un guión:

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

Esto haría que los siguientes elementos HTML tengan estilo de fuente en cursiva: 

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

Ambigüedad con el operador aritmético

Yo diría que el acceso a los elementos HTML a través de la notación de puntos en JavaScript es un error en lugar de una característica. Es una construcción terrible desde los primeros días de terribles implementaciones de JavaScript y no es realmente una gran práctica. Para la mayoría de las cosas que haces con JavaScript en estos días, te gustaría usar Selectores CSS para recuperar elementos del DOM de todos modos, lo que hace que toda la notación de puntos sea bastante inútil. ¿Cuál prefieres?

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

Encuentro las dos primeras opciones mucho más preferibles, especialmente porque '#first-name' se puede reemplazar con una variable JavaScript y construirse dinámicamente. También los encuentro más agradables en los ojos.

El hecho de que Sass habilite la aritmética en sus extensiones a CSS realmente no se aplica a CSS en sí, pero entiendo (y abrazo) el hecho de que Sass sigue la estilo de lenguaje de CSS (excepto el prefijo $ de las variables, que por supuesto debería haber sido @). Si los documentos Sass deben verse y sentirse como documentos CSS, deben seguir el mismo estilo que CSS, que usa dash como delimitador. En CSS3, la aritmética se limita a la calc función, que va a mostrar que en CSS en sí, esto no es un problema.

Inconsistencia con la nomenclatura de variables entre idiomas

Todos los idiomas, siendo lenguajes de marcado, programación los idiomas, lenguajes de estilo o lenguajes de scripting, tienen su propio estilo. Encontrará esto dentro de sub-idiomas de grupos de idiomas como XML, donde por ejemplo XSLT utiliza minúsculas con delimitadores de guion y XML Schema utiliza camel-casing.

En general, encontrará que adoptar el estilo que se siente y se ve más "nativo" del idioma en el que está escribiendo es mejor que tratar de calzar su propio estilo en cada idioma diferente. Ya que no puedes evitar tener para usar bibliotecas nativas y construcciones de lenguaje, tu estilo estará "contaminado" por el estilo nativo, te guste o no, por lo que es bastante inútil intentarlo.

Mi consejo es no encontrar un estilo favorito en todos los idiomas, sino sentirse como en casa dentro de cada idioma y aprender a amar todas sus peculiaridades. Una de las peculiaridades de CSS es que las palabras clave y los identificadores están escritos en minúsculas y separados por guiones. Personalmente, me parece muy atractivo visualmente y creo que encaja con el HTML todo en minúsculas (aunque sin guion) .

 121
Author: Asbjørn Ulsberg,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-09-26 21:14:52

Quizás una razón clave por la que la comunidad HTML/CSS se alineó con guiones en lugar de guiones bajos se debe a deficiencias históricas en las especificaciones e implementaciones del navegador.

De un documento de Mozilla publicado en marzo de 2001 @ https://developer.mozilla.org/en-US/docs/Underscores_in_class_and_ID_Names

La especificación CSS1, publicada en su forma definitiva en 1996, no permitir el uso de guiones bajos en los nombres de clase e ID a menos que se escaparon." Un el guion bajo escapado se vería algo como esto: 

    p.urgent\_note {color: maroon;}

Esto no estaba bien soportado por los navegadores en el momento, sin embargo, y el la práctica nunca se ha hecho popular. CSS2, publicado en 1998, también prohibió el uso de guiones bajos en los nombres de clase e ID. Sin embargo, errata a la especificación publicada a principios de 2001 hecho subraya legal para el primera vez. Esto por desgracia complicado un ya complejo paisaje.

Generalmente me gustan los guiones bajos, pero la barra invertida simplemente lo hace feo más allá de toda esperanza, por no mencionar el escaso apoyo en ese momento. Puedo entender por qué los desarrolladores lo evitaron como la plaga. Por supuesto, no necesitamos la barra invertida hoy en día, pero la etiqueta del guión ya se ha establecido firmemente.

 51
Author: user193130,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-11-27 21:08:02

No creo que nadie pueda responder esto definitivamente, pero aquí están mis suposiciones educadas:

  1. Los guiones bajos requieren presionar la tecla Mayús y, por lo tanto, son más difíciles de escribir.

  2. Los selectores CSS que forman parte de las especificaciones oficiales de CSS usan guiones (como pseudo-clases como: first-child y pseudo-elements: first-line), no guiones bajos. Lo mismo ocurre con las propiedades, por ejemplo, decoración de texto, color de fondo, etc. Los programadores son criaturas de hábito. Hace sentir que seguirían el estilo del estándar si no hay una buena razón para no hacerlo.

  3. Este está más lejos en la cornisa, pero... Ya sea un mito o un hecho, existe una idea de larga data de que Google trata las palabras separadas por guiones bajos como una sola palabra, y las palabras separadas por guiones como palabras separadas. (Matt Cutts sobre Subraya vs Guiones.) Por esta razón, sé que mi preferencia ahora para crear URLs de página es usar-palabras-con-guiones, y para mí al menos, esto ha sangrado en mis convenciones de nombres para otras cosas, como selectores CSS.

 37
Author: Mason G. Zhwiti,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-09-27 03:32:09

Ha habido un claro repunte en los segmentos de palabras enteras de URL separados por guiones en los últimos años. Esto es alentado por las mejores prácticas de SEO. Google explícitamente "recomienda que uses guiones ( - ) en lugar de guiones bajos ( _ ) en tus URLs": http://www.google.com/support/webmasters/bin/answer.py?answer=76329 .

Como se ha señalado, diferentes convenciones han prevalecido en diferentes momentos en diferentes contextos, pero por lo general no son una parte formal de ningún protocolo o marco.

Mi hipótesis, entonces, es que la posición de Google ancla este patrón dentro de un contexto clave (SEO), y la tendencia de usar este patrón en nombres de clase, id y atributos es simplemente el rebaño que se mueve lentamente en esta dirección general.

 11
Author: Faust,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-09-26 22:16:24

Hay muchas razones, pero una de las más importantes es mantener consistencia.

Creo que este artículo lo explica exhaustivamente.

CSS es una sintaxis delimitada por guiones. Con esto quiero decir que escribimos cosas como font-size, line-height, border-bottom etc.

Así que:

Simplemente no debes mezclar sintaxis: es inconsistente.

 4
Author: simhumileco,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-22 09:39:25

Creo que es una cosa dependiente del programador. A algunos les gusta usar guiones, otros usan guiones bajos.
Yo personalmente uso guiones bajos (_) porque lo uso en otros lugares también. Tales como:
- Variables JavaScript(var my_name);
- Mis acciones de controlador(public function view_detail)
Otra razón por la que uso guiones bajos, es que en la mayoría de los IDE dos palabras separadas por guiones bajos se consideran como 1 palabra. (y se puede seleccionar con un clic doble).

 2
Author: Ali Farhoudi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-29 07:43:32