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


213

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

Siempre he pensado que los guiones tienen más inconvenientes, y no veo los beneficios:

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 pasar al símbolo que quiero. Digamos que la clase es " featured-product", tengo que completar automáticamente " featured", ingresar un guión y completar " product".

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

Lo mismo se aplica a la navegación por el documento. Saltar por palabras o hacer doble clic en los nombres de las clases está dividido por guiones.

(En términos más generales, pienso en las clases y los identificadores como tokens , por lo que no tiene sentido para mí que un token se pueda dividir tan fácilmente en guiones).

Ambigüedad con operador aritmético

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

form.first_name.value='Stormageddon';

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

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

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

Inconsistencia con nombres variables entre idiomas

En el pasado, solía escribir underscored_namespara variables en PHP, ruby, HTML / CSS y JavaScript. Esto fue conveniente y consistente, pero nuevamente 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 desalinearon, aparentemente a propósito. Al menos con guiones bajos fue 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 la posibilidad de errores.

Entonces, pregunto: ¿por qué la comunidad se decidió casi universalmente en guiones, y hay alguna razón que supere los subrayados?

Hay una pregunta relacionada desde el momento 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 gustos. Me gustaría entender por qué todos nos decidimos por esta convención si realmente era solo cuestión de gustos.


50
Uso guiones porque no tengo que presionar la tecla Mayús.
Jrod

12
Curioso por qué esto se cerró ... ¿hubo votos para cerrarlo? No estoy solicitando opiniones en esta pregunta. Di razones específicas contra el uso de guiones, pero debe haber buenas razones para ellos si todos parecen estar de acuerdo con esta tendencia. Hay algunas buenas respuestas y buena información aquí. ¿Puedo mejorar la pregunta?
Andrew Vit

9
Estoy nominando mi pregunta para reabrirla: todas las respuestas a continuación incluyen "hechos, referencias o experiencia específica" ... así que no veo cómo fue "no constructivo".
Andrew Vit

12
Creo que cerrar este hilo como no constructivo fue una decisión estúpida. Si hay un estilo de codificación que se prefiere por algo diferente a la preferencia (más fácil para los IDE, completar el código más fácilmente, una mejor integración con las herramientas), creo que sería una pregunta / respuesta / discusión bastante constructiva.
Jake Wilson

8
@ AndrewVit: esta es una muy buena pregunta, bien formateada, informativa y destaca múltiples aspectos. +1 por eso. Por cierto, estoy de acuerdo en que no tenía sentido cerrar este tema como "no constructivo" . En realidad es constructivo.
Sk8erPeter

Respuestas:


130

Completar código

Supongo que si el guión se interpreta como puntuación o como un identificador opaco depende del editor de elección. Sin embargo, como preferencia personal, estoy a favor de poder tabular entre cada palabra en un archivo CSS y me resultaría molesto si se separaran con un guión bajo 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 un estilo de letra cursiva:

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

Ambigüedad con operador aritmético

Yo diría que el acceso a 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 implementaciones terribles 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, de todos modos, querrás usar los selectores CSS para obtener elementos del DOM, lo que hace que la notación de puntos completa sea bastante inútil. ¿Cuál preferirías?

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'pueden reemplazarse con una variable de JavaScript y construirse dinámicamente. También los encuentro más agradables a la vista.

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

Inconsistencia con nombres variables entre idiomas

Todos los idiomas, que son lenguajes de marcado, lenguajes de programación, lenguajes de estilo o lenguajes de secuencias de comandos, tienen su propio estilo. Encontrará esto dentro de los sub-idiomas de los grupos de idiomas como XML, donde, por ejemplo, XSLT usa minúsculas con delimitadores de guiones y el Esquema XML usa mayúsculas y minúsculas .

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

Mi consejo es que no encuentres un estilo favorito en todos los idiomas, sino que te sientas como en casa dentro de cada idioma y aprendas 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, encuentro esto visualmente atractivo y creo que encaja con el HTML en minúsculas (aunque sin guiones) .


44
"Si el guión se interpreta como puntuación o como un identificador opaco depende del editor de elección" No creo que esto sea cierto en general, aunque puede haber algunos editores excepcionales. Al hacer doble clic en una palabra con guión solo se seleccionará parte de ella, no el token completo: esto parece ser de todo el sistema operativo.
Andrew Vit

13
Buen punto sobre el |=selector, lo vi en la otra respuesta, y es un punto justo. ¿La convención de idiomas fue diseñada en torno a esto o al revés? (Los guiones como tendencia universal parecen ser relativamente recientes, podrían haber surgido más o menos al mismo tiempo)
Andrew Vit,

1
@ AndrewVit, hay editores basados ​​en CLI donde hacer doble clic no es relevante (ya que generalmente no hay mouse) y que se pueden configurar para tener este tipo de comportamiento. Pero en general, tienes razón. El |=selector de atributos está hecho específicamente para el langatributo, pero su uso puede ampliarse. Siempre he usado guiones en mi CSS, por lo que no puedo hablar por el público en general, pero definitivamente ha habido una convergencia hacia los guiones del caso pascal, el caso camel y los guiones bajos. Sin |=embargo, el selector y el guión como delimitador no están relacionados.
Asbjørn Ulsberg

3
No veo la notación de puntos como un error, es CSS que no debería haber usado guiones. Además, lo que agrada a los ojos es variable.
vivek

2
@ KamilKiełczewski Eso es útil, pero funciona de manera ligeramente diferente.
gcampbell

68

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

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

La especificación CSS1, publicada en su forma final en 1996, no permitía el uso de guiones bajos en los nombres de clase e ID a menos que se "escaparan". Un guión bajo se vería así:

    p.urgent\_note {color: maroon;}

Sin embargo, los navegadores no admitían esto en ese momento, y la práctica nunca se ha puesto de moda. CSS2, publicado en 1998, también prohibió el uso de guiones bajos en los nombres de clase e ID. Sin embargo, las erratas a la especificación publicada a principios de 2001 hicieron que los subrayados fueran legales por primera vez. Desafortunadamente, esto complicó un paisaje ya complejo.

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


66
¡Gracias! Me encanta descubrir la 'etimología' de una convención como esta. Me ayuda a recordar usar la convención ya que puedo asociar el lenguaje con ella. Tener la asociación me ayuda a preparar mi subconsciente para usar la convención como resultado.
Ape-inago

39

No creo que nadie pueda responder esto definitivamente, pero aquí están mis conjeturas 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 de 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 para las propiedades, por ejemplo, decoración de texto, color de fondo, etc. Los programadores son criaturas de hábitos. Tiene sentido que sigan el estilo del estándar si no hay una buena razón para no hacerlo.

  3. Este está más allá en el borde, pero ... Ya sea un mito o un hecho, existe la idea 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 en guiones bajos vs. guiones). Por esta razón, sé que mi preferencia ahora para crear URL de páginas es usar palabras con guiones, y para mí al menos, esto se ha desangrado en mis convenciones de nombres para otras cosas. , como los selectores CSS.


2
Buen punto sobre el SEO con respecto a los guiones en las URL y para el marcado semántico (si esto es realmente cierto o no) ... ¿Puede aclarar qué "selectores CSS que forman parte de las especificaciones oficiales de CSS usan guiones"?
Andrew Vit

Extendí el punto 2 en mi respuesta para dar algunos ejemplos, aunque estaba pensando más en las propiedades CSS como la decoración de texto en lugar de "selectores", por lo que fue algo así como un error tipográfico, aunque hay algunos selectores que lo hacen, como mencionado anteriormente
Mason G. Zhwiti

1
Gracias @albert, eso sería una buena respuesta por derecho propio ... al menos para el contexto histórico. ¡No sabía que la especificación original no permitía guiones bajos! (Pero no tiene sentido por qué deberían ser rechazados.)
Andrew Vit

44
Punto # 2 me convenció, especialmente teniendo en cuenta propiedades como color de fondo, texto-decoración, etc.
Gran McLargeHuge

2
Para su información, la url devedge-temp a la que se hace referencia en el comentario de @ albert anterior ( devedge-temp.mozilla.org/viewsource/2001/css-underscores ) ahora está en developer.mozilla.org/en-US/docs/…
aponzani

14

Hay muchas razones, pero una de las más importantes es mantener la 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-bottometc.

Entonces:

Simplemente no deberías mezclar sintaxis: es inconsistente .


11

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

Como se señaló, diferentes convenciones han prevalecido en diferentes momentos en diferentes contextos, pero generalmente 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 a usar este patrón en los nombres de clase, id y atributo es simplemente la manada moviéndose lentamente en esta dirección general.


5

Creo que es una cosa dependiente del programador. A algunos les gusta usar guiones, otros usan guiones bajos.
Yo personalmente uso guiones bajos ( _) porque también lo uso en otros lugares. Tales como:
- Variables de 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 1 palabra. (y son posibles de seleccionar con doble clic).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.