135 votos

¿Por qué son guiones preferidos para selectores CSS / atributos HTML?

En el pasado he utilizado siempre pone de relieve para la definición de clase y de id de atributos en HTML. Durante los últimos años he cambiado a lo largo de guiones, la mayoría de 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 de código y Edición

La mayoría de los editores tratar los guiones como separadores de palabras, así que no puedo ficha por el símbolo que desea. Decir que la clase es "featured-product", tengo que auto-completar "featured", escribe un guión, y completa "product".

Con caracteres de subrayado "featured_product" es tratada como una sola palabra, por lo que se pueden llenar en un solo paso.

Lo mismo se aplica a navegar a través del documento. Saltando por palabras o haciendo doble clic en los nombres de clase se rompe por guiones.

(Más en general, creo que de clases y los identificadores como fichas, por lo que no tiene sentido para mí que un token debe ser tan fácilmente splittable en los guiones.)

La ambigüedad con operador aritmético

El uso de guiones rompe objeto de propiedad acceso a los elementos de formulario en JavaScript. Esto sólo es posible con caracteres de subrayado:

form.first_name.value='Stormageddon';

(Admito que no tengo acceso a los elementos de los formularios de esta manera a mí, pero a la hora de decidir sobre guiones vs subraya como una regla universal, considere la posibilidad de que alguien pueda.)

Idiomas como el Sass (especialmente a lo largo de la Brújula marco) se han asentado en guiones como estándar, incluso para los nombres de variable. Originalmente utilizado guiones bajos en el principio. El hecho de que el presente se analiza de manera diferente que me parece extraño:

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

Incompatibilidad con denominación de variables a través de los idiomas

De vuelta en el día, me utiliza para escribir underscored_names para las variables en PHP, ruby, HTML/CSS, y JavaScript. Esto era conveniente y coherente, pero de nuevo con el fin de "encajar" ahora yo uso:

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

Esto en realidad no me molesta demasiado, pero me pregunto por qué estos se volvieron tan mal alineados, aparentemente a propósito. Al menos con caracteres de subrayado fue posible mantener la coherencia:

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

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

Así que me pregunto: ¿por Qué la comunidad casi universalmente asentarse en los guiones, y existen razones que superan pone de relieve?

Hay una pregunta relacionada con la de la espalda todo el tiempo esto empezó, pero yo soy de la opinión de que no es (o no debería haber) sólo una cuestión de gusto. Me gustaría entender por qué todos se instalaron en este convenio, si realmente era sólo una cuestión de gusto.

83voto

asbjornu Puntos 5042

Finalización de código

Si el guión es interpretado como signos de puntuación o como un cuerpo opaco identificador depende del editor de elección, supongo. Sin embargo, como una preferencia personal, estoy a favor de poder de la ficha entre cada palabra en un archivo CSS y sería molesto si estaban separados con guión bajo y no se detiene.

Además, el uso de guiones que le permite tomar ventaja de el |= selector de atributo, el cual selecciona cualquier elemento que contiene el texto, seguido opcionalmente por un guión:

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

Esto haría que los siguientes elementos HTML tienen cursiva font-style:

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

La ambigüedad con operador aritmético

Yo diría que el acceso a elementos de HTML a través de la notación de punto en JavaScript es un error en vez de una característica. Es un terrible construir a partir de los primeros días de terrible implementaciones de JavaScript y no es realmente una gran práctica. Para la mayoría de las cosas que hacer con JavaScript en estos días, es conveniente utilizar los Selectores de CSS para la obtención de elementos del DOM de todos modos, lo que hace que el conjunto de la notación de punto bastante inútil. Que uno prefiere?

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

Me parece que las dos primeras opciones mucho más preferible, especialmente desde '#first-name' puede ser reemplazado con una variable de JavaScript y construido de forma dinámica. También me parece más agradable en los ojos.

El hecho de que Sass permite la aritmética en sus extensiones de CSS en realidad no se aplican a CSS sí, pero yo no entiendo (y la abrazo) el hecho de que Sass sigue el lenguaje de estilo de CSS (excepto para los $ prefijo de las variables, que por supuesto debería haberse @). Si Sass documentos se vea y se sienta como CSS documentos, que deben seguir el mismo estilo como CSS, que utiliza el guión como un delimitador. En CSS3, la aritmética se limita a la calc función, que va a demostrar que en CSS en sí mismo, esto no es un problema.

Incompatibilidad con denominación de variables a través de los idiomas

Todos los idiomas, siendo lenguajes de marcado, lenguajes de programación, diseño de idiomas o lenguajes de secuencias de comandos, tienen su propio estilo. Usted encontrará dentro de este sub-lenguajes de grupos de lenguajes como XML, donde por ejemplo, XSLT utiliza minúsculas con guión delimitadores y de Esquemas XML utiliza camel.

En general, usted encontrará que la adopción del estilo de la que se siente y se ve más "nativo" para el idioma que estás escribiendo es mejor que intentar calzador su propio estilo en cada idioma diferente. Ya que no se puede evitar tener que utilizar bibliotecas nativas y construcciones del lenguaje, su estilo va a ser "contaminado" por el estilo nativo de si te gusta o no, así que es bastante inútil siquiera intentar.

Mi consejo es no encontrar un estilo favorito, a través de los idiomas, pero en lugar de hacer usted mismo en casa dentro de cada lengua y aprender a amar a todos sus caprichos. Uno de CSS peculiaridades es que las palabras clave y los identificadores están escritos en minúsculas y separadas por guiones. Personalmente, esto me parece muy atractivo a la vista y creo que encaja con el minúsculas (aunque sin guión) HTML.

27voto

Mason G. Zhwiti Puntos 1413

No creo que nadie puede responder a esta definitivamente, pero aquí están mis conjeturas:

  1. Subraya requieren de golpear la tecla Shift, y son por lo tanto más difícil de escribir.

  2. Los selectores de CSS, que son parte de la oficial de CSS especificaciones utilice guiones (como pseudo-clases :primero.-el niño y los pseudo-elementos :first-line), no pone de relieve. Lo mismo para las propiedades, por ejemplo, text-decoration, color de fondo, etc. Los programadores son criaturas de hábito. Tiene sentido que seguirían el estándar del estilo si no hay una buena razón para no hacerlo.

  3. Este es uno más en la repisa, pero... Si es un mito o realidad, no es una vieja idea que Google trata de 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 la creación de Url de la página es el uso de-palabras-con-guiones, y al menos para mí, este ha sangrado en mi convenciones de nomenclatura para otras cosas, como los selectores de CSS.

24voto

user193130 Puntos 873

Tal vez una razón clave de por qué el HTML/CSS de la comunidad se alineó con los guiones en lugar de guiones es debido a las insuficiencias históricas en las especificaciones y el navegador implementaciones.

Desde Mozilla doc publicado en Marzo de 2001 @ https://developer.mozilla.org/en-us/docs/underscores_in_class_and_id_names

La especificación CSS1, publicado en su forma final en 1996, no permitir el uso de guiones bajos en clase y los nombres de IDENTIFICACIÓN, a menos que se "escaparon." Un escapó subrayado sería algo como esto:

    p.urgent\_note {color: maroon;}

Esto no fue bien soportado por los navegadores en el tiempo, sin embargo, y la la práctica nunca se ha capturado. CSS2, publicado en 1998, también se prohibía el uso de guiones bajos en clase y los nombres de IDENTIFICACIÓN. Sin embargo, la fe de erratas a la especificación publicada a principios de 2001 pone de relieve legal para la primera vez. Por desgracia, este complicado ya de un complejo paisaje.

En general me gusta pero subraya la barra diagonal inversa sólo la hace fea más allá de la esperanza, por no mencionar el escaso apoyo en el momento. Puedo entender por qué los desarrolladores evitado como la peste. Por supuesto, no necesitamos la barra diagonal inversa en la actualidad, pero el guión-la etiqueta ya ha sido firmemente establecida.

6voto

Faust Puntos 7523

Ha habido un claro incremento en las separados por guiones, toda palabra segmentos de direcciones Url en los últimos años. Esto es alentado por las mejores prácticas de SEO. Google explícitamente "recomendamos que utilice guiones (-) en vez de subrayado (_) en su Url": http://www.google.com/support/webmasters/bin/answer.py?answer=76329.

Como se señaló, los diferentes convenios han prevalecido en diferentes tiempos y contextos, pero que normalmente no son parte formal de cualquier protocolo o marco.

Mi hipótesis es la de que Google la posición de los anclajes de este patrón dentro de una de las claves de contexto (SEO), y la tendencia hacia la utilización de este patrón en la clase, id, y nombres de atributo es simplemente el rebaño se mueve lentamente en esta dirección general.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by: