Usar clases CSS como decoradores, ¿un buen patrón?

He estado construyendo una aplicación web con una GUI bastante compleja: muchos elementos pequeños uno junto al otro y dentro de otros elementos que necesitan varios comportamientos (arrastrar, hacer clic, pero sensibles al contexto).

Mi código tiende a funcionar así:

los controles comienzan como etiquetas html

<li>

luego agrego clases a la etiqueta

<li class = 'static passive included'>

algunas clases pueden ser para que el estilo CSS afecte la apariencia

.static {background: blue; float: left;}

mientras que jQuery actúa sobre otros para dar comportamiento a los eventos DOM asociados

$("#container").delegate(".passive", function {onclick : //do-stuff})

y otros pueden ser recogidos por JavaScript normal al escanear el documento, por ejemplo. recopile los valores de texto de todos los nodos con la clase 'incluida'. Entonces, ciertos elementos DOM son objetos GUI que implementan clases definidas a través de una combinación de css y jQuery.

Mi pregunta es, ¿es esta una buena forma de trabajar? Y también son estos realmente "decoradores": ciertamente "agregan responsabilidades adicionales a un objeto dinámicamente", pero no estoy seguro de ese término. Finalmente, ¿utiliza este patrón en sus propios sitios?

Creo que lo que estás haciendo está muerto. Los beneficios de usar clases, en lugar de inventar nombres de atributos, es que aún puede validar la página. Ningún navegador moderno se molestará por las clases CSS indefinidas, y son triviales de usar con jQuery, et al.

Las clases están bien, pero también consideraría los atributos de datos HTML . A menudo, un nombre de clase simplemente no transmite suficiente información para habilitar el enganche de JavaScript adecuado (sin nombres de identificación de elementos de codificación rígida). Los atributos de datos HTML proporcionan otra forma de clasificar y seleccionar elementos y adjuntarles datos con fines auxiliares, como las mejoras basadas en JavaScript.

Con jQuery, los atributos de datos HTML son igualmente fáciles de usar que las clases CSS.

Hmmm ... si y no. Está bien hacer cosas así, pero las clases realmente deberían nombrarse para mostrar lo que es común acerca de los datos dentro de ellas. Si no hay nada común entre dos etiquetas, existe la posibilidad de que los requisitos de las clases diverjan más tarde.

Requisito de ejemplo:

• todos los elementos de navegación serán blancos sobre azules, helvéticos con un margen de 1px
• todas las descripciones de comentarios serán blancas sobre azul, ariales con un margen de 4px y un relleno de 2px

¿Es mejor darles a ambos una clase de blanco sobre azul donde

.whiteonblue {
  font-color: white;
  background-color: blue;
}

o tener código repetido

.navitems {
  font-color: white;
  background-color: blue;
// more css
}

.commentdesc {
  font-color: white;
  background-color: blue;
// more css
}

Yo argumento lo último. No hay conexión entre navitems y commentdescs y, por lo tanto, lo más probable es que cuando uno cambie, el otro no. ¿Realmente desea tener que buscar en el html la clase correcta, eliminar la clase, agregar una nueva (en blanco) antes de ir al CSS en ese punto? Yo no.

Del mismo modo Javascript. Tal vez desee hacer lo mismo en el diseño inicial, pero lo más probable es que si uno cambia, el otro no. Es bastante fácil decir

$(".navitems, .commentdesc")

Si te apegas a esta política, sospecho que encontrarás que tu pregunta desaparece bastante rápido, pero donde no lo hace, entonces lo que estás haciendo está bien.