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

selector padre css

Question

En el pasado siempre he usado guiones bajos para definir los 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 ver el 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 los 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 con palabras o hacer doble clic en los nombres de las clases se rompe con guiones.

(Más generalmente, 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 yo no accedo a los elementos de formulario de esta manera, pero cuando decido guiones frente a guiones bajos como una regla universal, considere que alguien podría hacerlo).

Los lenguajes como Sass (especialmente en todo el marco de Compass ) se han basado en guiones como estándar, incluso para nombres de variables. Originalmente utilizaron 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 la denominación de variables a través de idiomas

En el pasado, solía escribir los underscored_names para las 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é 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 el potencial de errores.

Entonces pregunto: ¿Por qué la comunidad se conformó casi universalmente con guiones, y hay alguna razón que supere los guiones bajos?

Hay una pregunta relacionada desde el momento en que esto comenzó, pero opino que no es (o no debería ) ser solo una cuestión de gustos. Me gustaría entender por qué nos decidimos por esta convención si realmente fue solo una cuestión de gustos.

Answer 1

Código completado

Si el guión se interpreta como puntuación o como un identificador opaco depende del editor que elija, supongo. Sin embargo, como preferencia personal, prefiero 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 atributo | = , que selecciona cualquier elemento que contenga el texto, seguido opcionalmente por 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 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 las 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, querrías usar los selectores de CSS para obtener elementos del DOM de todos modos, lo que hace que la notación de puntos 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;

Considero que las dos primeras opciones son mucho más preferibles, especialmente porque ''#first-name'' puede reemplazarse con una variable de JavaScript y construirse dinámicamente. También los encuentro más agradables a los ojos.

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

Inconsistencia con la denominación de variables a través de idiomas

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

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

Mi consejo es que no encuentres un estilo favorito en todos los idiomas, sino que te sientas cómodo en 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, esto me parece muy atractivo a la vista y creo que encaja con el HTML minúsculas (aunque no con guiones).

Answer 2

Creo que es una cosa que depende del programador. A algunos les gusta usar guiones, otros usan guiones bajos.
Personalmente uso guiones bajos ( _ ) porque también lo uso en otros lugares. 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 como 1 palabra. (y se puede seleccionar con doble clic).

Answer 3

En los últimos años ha habido un claro aumento en los segmentos de URL de palabras completas separados por guiones. 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 atributos es simplemente la manada que avanza lentamente en esta dirección general.

Answer 4

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

Creo que this 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.

Asi que:

Simplemente no debes mezclar las sintaxis: es inconsistente .

Answer 5

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

1. Los guiones bajos requieren pulsar 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ábito. Tiene sentido que sigan 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, hay una 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 los guiones bajos contra los guiones). Por este motivo, sé que ahora prefiero crear las URL de las páginas es usar palabras con guiones, y al menos para mí, esto ha sangrado en mis convenciones de nombres para otras cosas. , como los selectores de CSS.

Answer 6

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 y las 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 final en 1996, no permitía el uso de guiones bajos en los nombres de clase e identificación a menos que fueran "escapados". Un guión bajo escapado se vería así:

    p.urgent/_note {color: maroon;}

Sin embargo, esto no fue bien soportado por los navegadores en ese momento, y la práctica nunca ha tenido éxito. CSS2, publicado en 1998, también prohibió el uso de guiones bajos en los nombres de clase e identificación. Sin embargo, la errata de la especificación publicada a principios de 2001 hace que los subrayados sean legales por primera vez. Esto desafortunadamente complicó un paisaje ya complejo.

Por lo general, me gustan los guiones bajos, pero la barra invertida solo los hace feos más allá de la 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 en estos días, pero la etiqueta del tablero ya se ha establecido firmemente.