¿Cuál es la convención de nomenclatura estándar para identificadores y clases html / css?

¿Depende de la plataforma que esté utilizando o existe una convención común que la mayoría de los desarrolladores sugieren / siguen?

Hay varias opciones:

1. id="someIdentifier"' - se ve bastante consistente con el código javascript.
2. id="some-identifier" - se parece más a los atributos tipo html5 y otras cosas en html.
3. id="some_identifier" - se ve bastante consistente con el código ruby ​​y sigue siendo un identificador válido dentro de Javascript

Estaba pensando que el n. ° 1 y el n. ° 3 anteriores tienen más sentido porque juegan mejor con Javascript.

¿Hay una respuesta correcta a esto?

No hay uno

Uso guiones bajos todo el tiempo, debido a los guiones que estropean el resaltado de sintaxis de mi editor de texto (Gedit), pero esa es una preferencia personal.

He visto todas estas convenciones en todo el lugar. Use el que le parezca mejor: el que le parezca más agradable / fácil de leer, y el más fácil de escribir porque lo usará mucho. Por ejemplo, si tiene la tecla de subrayado en la parte inferior del teclado (poco probable, pero totalmente posible), entonces utilice guiones. Simplemente ve con lo que es mejor para ti. Además, las 3 convenciones son fácilmente legibles. Si está trabajando en un equipo, recuerde seguir la convención especificada por el equipo (si corresponde).

Actualización 2012

He cambiado la forma en que programo con el tiempo. Ahora uso camel case ( thisIsASelector) en lugar de guiones ahora; Este último me parece bastante feo. Use lo que prefiera, que puede cambiar fácilmente con el tiempo.

Actualización 2013

Parece que me gusta mezclar cosas anualmente ... Después de cambiar a Sublime Text y usar Bootstrap por un tiempo, volví a los guiones. Para mí, ahora se ven mucho más limpios que un_der_scores o camelCase. Sin embargo, mi punto original sigue en pie: no hay un estándar.

Actualización 2015

Un caso interesante de esquina con convenciones aquí es Rust . Realmente me gusta el lenguaje, pero el compilador te avisará si defines cosas usando algo más que underscore_case. Puede desactivar la advertencia, pero es interesante que el compilador sugiera una convención por defecto. Me imagino que en proyectos más grandes conduce a un código más limpio que no es malo.

Actualización 2016 ( lo solicitó)

He adoptado el estándar BEM para mis proyectos en el futuro. Los nombres de clase terminan siendo bastante detallados, pero creo que les da una buena estructura y reutilización a las clases y CSS que van con ellos. Supongo que BEM es en realidad un estándar (por lo que mi se noconvierte en un yestal vez), pero aún depende de usted lo que decida usar en un proyecto. Lo más importante: sea coherente con lo que elija.

Actualización 2019 ( lo solicitó)

Después de no escribir CSS durante bastante tiempo, comencé a trabajar en un lugar que usa OOCSS en uno de sus productos. Personalmente, me parece bastante desagradable dejar basura en todas partes, pero no tener que saltar entre HTML y CSS todo el tiempo se siente bastante productivo.

Sin embargo, todavía estoy decidido por BEM. Es detallado, pero el espacio de nombres hace que trabajar con él en los componentes React sea muy natural. También es ideal para seleccionar elementos específicos cuando se realizan pruebas en el navegador.

OOCSS y BEM son solo algunos de los estándares CSS disponibles. Elija uno que funcione para usted: todos están llenos de compromisos porque CSS simplemente no es tan bueno .

Actualización 2020

Una actualización aburrida este año. Todavía estoy usando BEM. Mi posición realmente no ha cambiado desde la actualización de 2019 por los motivos enumerados anteriormente. Use lo que funcione para usted que se adapte al tamaño de su equipo y oculte tanto o tan poco conjunto de características pobres de CSS como desee.

Hay una guía de estilo CSS y HTML de Google, que recomienda utilizar siempre un guión: https://google.github.io/styleguide/htmlcssguide.html#ID_and_Class_Name_Delimiters .

Le sugiero que use un guión bajo en lugar de un guión (-), ya que ...

<form name="myForm">
  <input name="myInput" id="my-Id" value="myValue"/>
</form>

<script>
  var x = document.myForm.my-Id.value;
  alert(x);
</script>

puede acceder al valor por id fácilmente de esa manera. Pero si usa un guión, causará un error de sintaxis.

Esta es una muestra antigua, pero puede funcionar sin jquery - :)

Gracias a @jean_ralphio, hay una manera de evitar

var x = document.myForm['my-Id'].value;

Dash-style sería un estilo de código de google, pero realmente no me gusta. Preferiría TitleCase para id y camelCase para clase.

tl; dr;

No hay una respuesta verdadera. Puede elegir uno de los muchos que existen, o crear sus propios estándares según lo que tenga sentido, dependiendo de con quién esté trabajando. Y es 100% dependiente de la plataforma.

Publicación original

Solo un estándar alternativo más a considerar:

<div id="id_name" class="class-name"></div>

Y en tu guión:

var variableName = $("#id_name .class-name");

Esto solo usa camelCase, under_score y guión respectivamente para variables, identificadores y clases. He leído sobre este estándar en un par de sitios web diferentes. Aunque es un poco redundante en los selectores css / jquery, las redundancias hacen que sea más fácil detectar errores. por ejemplo: si ve .unknown_nameo #unknownNameen su archivo CSS, sabe que necesita averiguar a qué se refiere realmente.

ACTUALIZACIÓN 2019

(Los guiones se llaman 'kebab-case', los guiones bajos se llaman 'snake_case', y luego tiene 'TitleCase', 'pascalCase')

Personalmente no me gustan los guiones. Originalmente publiqué esto como una alternativa (porque las reglas son simples). Sin embargo, los guiones hacen que los atajos de selección sean muy difíciles (doble clic, ctrl/ option+ left/ righty ctrl/ cmd+ Den vsCode. Además, los nombres de clase y de archivo son el único lugar donde funcionan los guiones, porque casi siempre están entre comillas o css, etc. Pero el atajo aún se aplica.

Además de las variables, los nombres de clase y los identificadores, también desea consultar las convenciones de nombres de archivo. Y Git Branches.

El grupo de codificación de mi oficina en realidad tuvo una reunión hace un mes o dos para discutir cómo íbamos a nombrar las cosas. Para las ramas de git, no pudimos decidir entre 321-the_issue_description o 321_the-issue-description. (Quería 321_theIssueDescription, pero a mis compañeros de trabajo no les gustó eso).

Un ejemplo, para demostrar el trabajo con los estándares de otras personas ...

Vue.js tiene un estándar. En realidad, tienen dos estándares alternativos para varios de sus artículos. No me gustan sus dos versiones para los nombres de archivo. Recomiendan cualquiera "/path/kebab-case.vue"o "/path/TitleCase.Vue". El primero es más difícil de cambiar de nombre, a menos que esté tratando específicamente de cambiar el nombre de una parte. Este último no es bueno para la compatibilidad multiplataforma. Yo preferiría "/path/snake_case.vue". Sin embargo, cuando se trabaja con otras personas o proyectos existentes, es importante seguir cualquier estándar que ya se haya establecido. Por lo tanto, voy con kebab-case para los nombres de archivo en Vue, aunque me quejaré por completo. Porque no seguir eso significa cambiar muchos archivos que configura vue-cli.

No existe una convención de nomenclatura acordada para HTML y CSS. Pero podría estructurar su nomenclatura en torno al diseño de objetos. Más específicamente, lo que yo llamo propiedad y relación.

Propiedad

Las palabras clave que describen el objeto, podrían estar separadas por guiones.

auto nuevo giró a la derecha

Las palabras clave que describen el objeto también pueden clasificarse en cuatro categorías (que deben ordenarse de izquierda a derecha): Objeto, Descriptor de objeto, Acción y Descriptor de acción.

car - un sustantivo y un objeto
nuevo - un adjetivo y un descriptor de objeto que describe el objeto con más detalle
convertido - un verbo y una acción que pertenece al objeto
derecho - un adjetivo y un descriptor de acción que describe la acción con más detalle

Nota: los verbos (acciones) deben estar en pasado (convertido, did, run, etc.).

Relación

Los objetos también pueden tener relaciones como padre e hijo. La acción y el descriptor de acción pertenecen al objeto padre, no pertenecen al objeto hijo. Para las relaciones entre objetos, puede usar un guión bajo.

auto-nuevo-giró-derecha_wheel-izquierda-giró-izquierda

• auto-nuevo-giró a la derecha (sigue la regla de propiedad)
• rueda-izquierda-vuelta-izquierda (sigue la regla de propiedad)
• auto-nuevo-giró-derecha_wheel-izquierda-giró-izquierda (sigue la regla de relación)

Notas finales

• Como CSS no distingue entre mayúsculas y minúsculas, es mejor escribir todos los nombres en minúsculas (o mayúsculas); evite el caso de camello o pascal, ya que pueden dar lugar a nombres ambiguos.
• Sepa cuándo usar una clase y cuándo usar una identificación. No se trata solo de una identificación que se usa una vez en la página web. La mayoría de las veces, desea utilizar una clase y no una identificación. Los componentes web como (botones, formularios, paneles, ... etc.) siempre deben usar una clase. Las identificaciones pueden conducir fácilmente a conflictos de nombres y deben usarse con moderación para el espacio de nombres de su marcado. Los conceptos anteriores de propiedad y relación se aplican a los nombres de las clases y los identificadores, y lo ayudarán a evitar conflictos de nombres.
• Si no le gusta mi convención de nomenclatura CSS, también hay varias otras: convención de nomenclatura estructural, convención de nomenclatura de presentación, convención de nomenclatura semántica, convención de nomenclatura BEM, convención de nomenclatura OCSS, etc.

Otra razón por la que muchos prefieren guiones en la identificación de CSS y los nombres de clase es la funcionalidad.

El uso de métodos abreviados de teclado como option+ left/ right(o ctrl+ left/ righten Windows) para recorrer el código palabra por palabra detiene el cursor en cada guión, lo que le permite recorrer con precisión la identificación o el nombre de la clase utilizando métodos abreviados de teclado. Los guiones bajos y camelCase no se detectan y el cursor se desplazará sobre ellos como si fuera una sola palabra.

Hace poco comencé a aprender XML. La versión de subrayado me ayuda a separar todo lo relacionado con XML (DOM, XSD, etc.) de los lenguajes de programación como Java, JavaScript (caso de camello). Y estoy de acuerdo con usted en que usar identificadores que están permitidos en los lenguajes de programación se ve mejor.

Editar: puede no estar relacionado, pero aquí hay un enlace para reglas y recomendaciones sobre cómo nombrar elementos XML que sigo al nombrar identificadores (secciones "Reglas de nombres XML" y "Mejores prácticas de nombres").

http://www.w3schools.com/xml/xml_elements.asp

Creo que depende de la plataforma. Cuando desarrollo en .Net MVC, uso minúsculas y guiones de estilo bootstrap para los nombres de clase, pero para identificadores uso PascalCase.

El razonamiento para esto es que mis vistas están respaldadas por modelos de vista fuertemente tipados. Las propiedades de los modelos C # son mayúsculas y minúsculas. En aras de la vinculación del modelo con MVC, tiene sentido que los nombres de los elementos HTML que se unen al modelo sean coherentes con las propiedades del modelo de vista, que son mayúsculas y minúsculas. Para simplificar, mis identificadores usan la misma convención de nomenclatura que los nombres de elementos, excepto los botones de opción y las casillas de verificación que requieren identificadores únicos para cada elemento en el grupo de entrada con nombre.