html - selectores - ¿Deben evitarse los nombres de clases css como ''floatleft'' que describen directamente el estilo adjunto?
selector padre css (20)
Andrés; es bueno dar un nombre sensato a una clase e identificación que sea fácil de entender para usted y los demás miembros que están trabajando en ese proyecto. Para mí, las clases small , center , floatleft , etc. no me definen nada porque cuando das el centro de la clase indica que el elemento está en el centro, pero también hay otras propiedades en esa clase like color, background etc
Por ejemplo
<div class="wrap">
<div class="center">lorem</div>
</div>
css:
.center{margin:0 auto;}
en este ejemplo, el center clase no me lo aclara. pero podemos usarlos como una clase de ayuda.
Por ejemplo
<div class="wrap">
<div class="panel center narrow">lorem</div>
</div>
css:
.center{margin:0 auto;}
del ejemplo anterior, ahora me queda claro cuál es el papel del center de clase en ese panel div
PARA MÁS VERIFICAR ESTOS ENLACES:
¿Cuál es la mejor manera de nombrar IDs y clases en CSS y HTML?
http://www.ronniesan.com/blog/entry.php?title=organizing-your-dom-elements-with-the-proper-ids
http://cssglobe.com/post/3745/my-top-10-most-used-css-class-names
Muchos sitios web usan nombres de clase como floatleft , clearfloat , alignright , small , center , etc. que describen el estilo que se adjunta a la clase. Esto parece tener sentido, así que cuando escribes contenido nuevo puedes ajustar fácilmente (por ejemplo) <div class="clearfloat">...</div> alrededor de tu elemento para que se comporte de la manera que quieras.
Mi pregunta es, ¿este estilo de nombrar clases no va en contra de la idea de separar el contenido de la presentación? Poner class="floatleft" en un elemento está poniendo claramente la información de la presentación en el documento HTML.
¿Deben evitarse los nombres de clase como este que describen directamente el estilo adjunto, y si es así, qué alternativa hay?
Para aclarar, esto no es solo una cuestión de qué nombrar las clases. Por ejemplo, un documento semánticamente preciso podría ser algo así como:
<div class="foo">Some info about foo</div>
...
<div class="bar">Info about unrelated topic bar</div>
...
<div class="foobar">Another unrelated topic</div>
Digamos que todos estos divs necesitan despejar carrozas, el CSS se vería algo así como:
div.foo, div.bar, div.foobar {
clear:both;
}
Esto comienza a ponerse feo a medida que aumenta el número de estos elementos de limpieza, mientras que una sola class="clearfloat" tendría el mismo propósito. ¿Se recomienda agrupar elementos basados en los estilos adjuntos para evitar la repetición en el CSS, incluso si esto significa que la información de presentación se introduce en el HTML?
Actualización : gracias por todas las respuestas. El consenso general parece ser evitar estos nombres de clase a favor de nombres semánticos, o al menos usarlos con moderación siempre que no impidan el mantenimiento. Creo que lo importante es que los cambios en el diseño no deberían requerir cambios excesivos en el marcado (aunque algunas personas dijeron que los cambios menores están bien si facilita el mantenimiento general). Gracias a aquellos que sugirieron otros métodos para mantener el código CSS más pequeño también.
Creo que aquí es donde lo viejo se encuentra con las nuevas tecnologías web. Desde tiempos pasados, ha sido difícil renderizar discretamente una experiencia web sobresaliente. Estos nombres de clase en su mayoría fueron útiles cuando los sitios web cambiaban los webmasters para ayudarlos a comprender el código. Sirvió bien a su causa, pero con las nuevas tecnologías de hoy en día, creo que esto se está muriendo poco a poco, de hecho, debería estar muerto.
La pregunta que debemos hacernos es: "¿Necesitamos crear una nueva clase para cada nuevo diseño innovador que pueda pasar como plantilla?". No lo creo. El marcado en un sitio debe hacer para lo que está destinado: marcado. Los nombres de clase utilizados en el marcado deben ser descriptivos del contenido y no de su apariencia. Las hojas de estilo, por otro lado, deberían poder seleccionar elementos en un documento en función de la información del marcado y darles un estilo.
Quiero relacionar esto con la convención de nombres de la asociación Rails. Considera esto...
class Post < ActiveRecord::Base
has_one :personifyable
has_many :personifications, :through => :personifyable
has_many :taggables
has_many :tags, :through => taggables
belongs_to :destroyers
end
Obviamente, este no es un modelo real; es algo que estoy usando para impulsar un punto. Considere el caso de una dependencia profundamente anidada. Estos nombres se volverán ridículos, si no lo son ya (es decir, en CSS, <div class=''mediumwidth floatright centeredtext graytheme master''></div> o algo así)
Ahora considera el caso en el que tienes diferentes principios. Distintos desarrolladores y diseñadores pueden, si no ''definitivamente lo harán'', tener diferentes razones para usar una convención de nomenclatura específica. ¿Cómo afectaría esto el tiempo de refactorización? Dejaré eso a tu imaginación. Además, si su socio comercial nota una nueva tendencia con temas de sitios que atrae el tráfico (más técnicamente, suponga que este socio comercial ha realizado algunas pruebas A / B experimentales y presenta algunas especificaciones), no desea cambiar los contenidos del pila completa (es decir, HTML y CSS y posiblemente páginas JS) para implementar este nuevo estilo .
En conclusión, siga dando consejos sobre el estilo de su marcado. Interactúa discretamente con el documento para estilizarlo y manipularlo. SASS te brinda una excelente forma de diseñar un sitio mientras que tu CSS se burla de tu marcado. jQuery es otra impresionante biblioteca de UJS. HTML5 le proporciona métodos que hacen que el marcado sea más flexible y proporciona más información a CSS y JS.
Creo que depende de cómo uses los estilos.
El contenido debe nombrarse en consecuencia, ya que el estilo puede cambiar, pero el contenido probablemente seguirá siendo el mismo.
Por ejemplo, si tiene un div que contiene información de inventario, debe nombrar el div como div class="stockInfo" , de modo que no importa cuál sea la presentación, puede cambiar los estilos y el nombre no contradirá esos estilos (como se opone a nombrar div div class="yellow" y luego cambiar el background-color a rojo).
Sin embargo , tendrá "estilos de ayuda" y estos deberían ser nombrados por lo que hacen.
Por ejemplo, es probable que desee utilizar un <br /> para borrar algunas carrozas. En este caso, es perfectamente razonable nombrarlo <br class="clear" /> y darle un estilo de br {clear:both;} .
De nuevo, la mayoría de los sitios web float sus imágenes a la derecha o a la izquierda. Para ayudar con esto, puede establecer <img class="right" src="" /> y <img class="left" src="" /> y luego tener los estilos para que coincidan, img.right {float:right;} etc.
Entonces depende del uso.
Creo que, al final del día, se trata de lo que funciona para usted. Si su nombre de clase es descriptivo de lo que hace, eso realmente no va contra la regla de separar el marcado de los estilos. Otro factor a considerar es si eres el único desarrollador o parte de un equipo. Si usted es parte de un equipo o sabe que su código será trabajado posteriormente por otros desarrolladores, debe establecer y documentar las convenciones de denominación utilizadas.
Actualmente estoy contratando a Down Jones en algunos proyectos muy grandes, y tenemos un documento bastante extenso sobre convenciones de nombres para nuestras clases, que incluye cuándo usar camel-case, guiones o guiones bajos, así como prefijos específicos basados en el nombre de clase. en el proyecto en el que trabajamos Parece una locura, pero cuando tienes una docena de desarrolladores de front-end trabajando en cosas al mismo tiempo, ¡es un salvavidas!
Depende, a veces tiene sentido simplemente agregar una clase para dejar flotar un elemento. El problema con el enfoque semántico es que terminarás bola de barro de clases de CSS. Claro, los nombres como redLink o blackHeader tienen que ser prohibidos, pero a veces necesitarás pequeños ayudantes como "clear" o "floatLeft".
Lee este artículo de Nicole Sullivan que explica esto en profundidad.
El principal problema con tener clases llamadas floatleft , clear o similares es el hecho de que los cambios en el diseño implican cambios en el marcado HTML. Esto no debería ocurrir, la verdadera separación entre contenido y presentación se logra solo cuando puede reutilizar el mismo marcado en múltiples diseños o incluso medios (piense en compartir el mismo HTML entre las versiones de escritorio y móvil de su sitio y solo cambiando las hojas de estilo).
Ahora, para un ejemplo práctico :). Para agregar la respuesta de Fredrik, LESSCSS le permite ocultar declaraciones de estilos / mixins de los desarrolladores. De esta manera, puede proteger los componentes reutilizables en sus hojas de estilo sin el peligro de que aparezcan en su HTML.
Marcado de muestra:
<div class="branding">Company Name</div>
Muestra less código:
// example of reusable functions
.noText() {
color: transparent;
text-indent: -9999px;
}
.clear-after() {
&:after {
content: ".";
display: block;
visibility: hidden;
height: 0;
clear: both;
}
}
.branding {
.clear-after();
.noText();
background-image: ...;
}
Por supuesto, para dispositivos móviles, es posible que desee tener el nombre de la empresa en negrita, sin ningún otro estilo:
.branding {
color: pink;
font-weight: bold;
}
Es excelente hasta que vuelva a diseñar, y el narrow se resaltará en amarillo, el center convertirá mejor en justificación a la izquierda, y la imagen que llamó floatleft ahora pertenece a la derecha.
floatleft el pecado de usar floatleft y clear como nombres de clases de CSS, pero es mucho más fácil mantener tu CSS si eliges nombres que se relacionan con el significado semántico del contenido, como los feedback y la heroimage .
Hay dos cosas que siento que quedan por completo fuera de estas discusiones con demasiada frecuencia. El primero es ¿POR QUÉ quieres ser semántico o no? Las palabras clave son Branding y Skinning. Los nombres de las clases de presentación pueden ser justificables si trabaja en algunos sitios web internos y departamentales, donde la creación de marca y el desván nunca recibirán fondos en un millón de años. Por otro lado, los sitios orientados al cliente, como los fabricantes de automóviles y los grandes almacenes, viven en un mundo en el que cada producto nuevo que se lanza tiene como resultado un aspecto completamente nuevo para el sitio web. Nuevos colores, nuevo diseño, nuevas imágenes de fondo y todo esto liderado por diseñadores que deberían poder realizar el cambio solo en CSS, por lo que no hay posibilidad de que puedan romper ningún php activo (o lo que sea que tengas). También hay sitios de marca, donde tiene varias máscaras, que se ejecutan potencialmente en el mismo sitio al mismo tiempo . En sitios con ese requisito, no puede tener cambios visuales que afecten html o termina rompiendo cualquier otra marca solo para actualizar una de ellas. En estas situaciones, los nombres de las clases semánticas son una necesidad.
La segunda cosa que a menudo se deja de lado es cómo combatir el problema de repetir grupos de propiedades creados por nombres de clases semánticas, como en:
.content-nav {
float: left;
margin-right: 10px;
background-color: #ccc;
}
.content-nav .user-photo {
float: left;
margin-right: 10px;
border: solid 1px #000;
}
.content-nav .user-display-name {
float: left;
margin-right: 10px;
text-decoration: underline;
}
La gente a menudo señala esto como un inconveniente de los nombres semánticos, y creo que ese es un punto válido. Por otro lado, me gustaría señalar que existen herramientas que pueden ayudarlo a mantener el CSS semántico SECO, como LESS y SASS. Vi a otro comentador mencionar esto arriba, pero pensé que este punto valía la pena destacarlo.
He hecho las dos cosas y debo decir que hoy en día me inclino por utilizar nombres de clase no presentacionales. Encontré este ingenioso marco llamado OOCSS https://github.com/stubbornella/oocss/wiki que me ayudó mucho cuando estaba creando un nuevo diseño para mi aplicación web y se ajustaba a mis requisitos tan bien.
Esto se debe principalmente a que la definición de las clases básicas de espaciado, encabezados y texto funciona tan bien cuando tiene que lidiar con gran cantidad de contenido. Debido a que usa las mismas clases en todas partes, ayuda a mejorar el diseño y mantenerlo.
Por supuesto, esto significa que un elemento en su html puede verse así: <div class="unit size1of3 lastUnit"> Pero de eso se trata el HTML? Asegurándose de que su información se presente correctamente.
No estoy de acuerdo en todo el punto de rediseño, se honesto, cuando tienes que rediseñar tu sitio web, la mayoría de los CSS salen por la puerta de todos modos. Y, al dividir el CSS en clases apropiadas para espaciado / encabezado / texto, es menos probable que haya reglas de CSS en conflicto que arruinan cosas como ul li div{}
Por supuesto, las clases no describen los contenidos, pero como CSS no permite la herencia de clases y tienes que admitir tecnologías antiguas como IE6 ... ¿realmente importa? ¿Y los nombres de clase como animal y pato realmente mejoran html? Me gustaría pensar que HTML es para el navegador y cuando el navegador lo renderiza, eso es para humanos.
Las clases de estilo deben ser semánticas . Este es un gran artículo sobre diseño de página web semántica (bueno, de todos modos, lo encontré útil).
EDITAR: Acabo de leer otro artículo que hace algunos buenos puntos para usar cosas como display: inline-block , display: table etc. en lugar de floats. Eso debería ayudar a evitar esas molestas clases floatleft y clearfix . Hacerlos semánticos siempre depende de ti.
Los nombres de clase y los ID que describen la función son mejores que los nombres que describen el diseño del elemento.
Por lo general, termino no haciéndolo religiosamente, porque en mi opinión es más conveniente, por ejemplo, elementos flotantes claros usando el famoso clearfix hack en lugar de agregar clear:both todas las hojas de estilo.
Pero creo que lesscss.org y SASS crean oportunidades interesantes para sacar lo mejor de ambos mundos, porque puedes tener mixins y funciones que describan algún estilo y sigan teniendo nombres semánticamente correctos simplemente incluyendo el "estilo" que desees.
En lugar de tener este HTML y CSS
<div class="navigation roundedcorners">...</div>
.roundedcorners {
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
border-radius: 5px;
}
podrías usar SASS para crear este mixin:
=rounded-corners
-moz-border-radius: 5px
-webkit-border-radius: 5px
border-radius: 5px
e .navigation en tu clase de .navigation esta manera:
.navigation
+rounded-corners-5px
que reduciría tu HTML a esto:
<div class="navigation">...</div>
y, por lo tanto, aún tiene la ventaja de tener nombres semánticos correctos al tiempo que tiene una forma conveniente de compartir estilos entre diferentes elementos.
No creo que agregar un nombre de clase descriptivo a su documento sea realmente un gran problema. Encuentro que es más fácil trabajar con nombres explícitos de clase como "floatleft" en lugar de elementos que son puramente semánticos o que dependen de la cascada. Por lo general, es más fácil para los desarrolladores posteriores que no tienen la estructura del documento en sus cabezas también. No desea usarlos para todo: no desea agregar una clase de flotación en cada li en un menú flotante a la izquierda, pero este tipo de estilos son muy buenos cuando necesita hacer algo específico a uno o más elementos, y desea que otros desarrolladores sepan que usted lo hizo. Es como poner <div class="clear"> o incluso <div style="clear:both;"> : quizás no el más bonito, pero seguro que es obvio lo que estás haciendo. Mi regla de oro es: lo que sea que te haga pensar menos, haz eso. EDITAR: Como dije en mi comentario anterior, esto es más cierto para las clases que se refieren a clearing y floats, es decir, a cosas que son puramente presentacionales, no semánticas y, sin embargo, deben mencionarse en el HTML. Creo que en este caso, es preferible indicar que está utilizando una clase puramente de presentación, como floatleft, en lugar de forzar que el flotador se una a algún elemento semántico.
Personalmente los nombre cosas cercanas a lo que estarán haciendo. Digamos que tengo una clase que está en una galería de imágenes y que es la clase primaria más utilizada, será algo así como "galería" o si estoy configurando bordes alrededor de las cosas que están destinadas a ser más decorativas, lo llamaré "decodificador". . Trato de mantenerlos semi cortos y algo relacionados con la tarea que brindan. No me gusta hacer cosas como "pequeño, grande, H1underlined" o cualquier cosa que pueda imitar a otra etiqueta o función porque eso puede ser confuso. Más allá de eso, creo que realmente deberías nombrarlo de la forma que sea más sensata para ti.
Por lo que he visto, los desarrolladores tienden a sobrecargar sus páginas HTML con demasiadas clases innecesarias y marcas adicionales. Estas clases no solo aumentan el tamaño de la página (y, por lo tanto, el tiempo de carga es más largo), sino que también aglomeran la página y dificultan su administración y modificación en el futuro.
Tener cosas como center y float-left puede ser útil cuando se trata de mostrar texto que fue ingresado por un usuario (como una publicación en un foro), pero para fines generales de marcado es mejor que simplemente al agregar text-align: center y float: left a las clases apropiadas. Esto es especialmente útil si intenta cambiar la apariencia de su sitio sin cambiar mucho el HTML. Cuanto menos haya codificado en su plantilla, más fácil será solo cambiar alrededor del CSS cuando modifique su plantilla. Solo ese pedazo me lo merece.
Como regla general, solo debería dar clases de elementos cuando describe qué es el contenido, no dónde o cómo se muestra. es decir, <span class="movie-information"> lugar de <span class="bold"> .
La única vez que siento que tiene sentido darle una clase a un elemento cuando no es necesario es si le preocupa la optimización del motor de búsqueda. Definitivamente debería leer en Microformats si está interesado en ver cómo agregar las clases correctas puede ayudar a los motores de búsqueda. Dicho esto, agregar clases que describan cómo se muestra visualmente la página no tiene nada que ver con los motores de búsqueda.
La única vez que alguna vez "grupe" clases es si ellos están mostrando lo mismo, o si son hermanos. Se pone muy complicado en tu CSS cuando tienes elementos de toda tu página definidos juntos. Es mucho mejor que agrupe las clases en su hoja de estilo de manera que pueda encontrarlas más tarde, en lugar de guardar algunas líneas combinándolas.
Por lo que vale, si mal no recuerdo, la palabra clave class en HTML no se usa actualmente para otra cosa que no sean hojas de estilo CSS. Por lo tanto, el ejemplo que proporcionó ...
<div class="foo">Some info about foo</div>
...
<div class="bar">Info about unrelated topic bar</div>
... no sería realmente una forma de identificar datos. Sugeriría el name o el atributo de id si realmente quiere identificar los datos dentro de sus etiquetas HTML. (Ambos tienen usos ligeramente diferentes: el name se utiliza generalmente para las consultas del lado del servidor mientras que el id se puede diseñar y es generalmente más versátil. Los ID deben ser únicos, pero los nombres no tienen que serlo). Puede consultar documentación adicional utilizando el Especificación W3C HTML.
En resumen, no se preocupe por vincular el contenido a la presentación a través de sus clases de etiquetas; hasta que se utilicen específicamente para cualquier otra cosa, no tendrán ningún efecto real en su contenido sin formato. Como tal, diría que nombre sus clases como lo desee, siempre que tenga sentido. Personalmente, me gustaría equivocarme por el nombre lógico versus el estilo (por ejemplo, el nombre de clase "editorcomment" en lugar de la clase "graybgfloatleft" o algo así), pero al final, los nombres de tus clases no te van a atar. datos para su presentación como una ID o un nombre.
Buena suerte.
Si la pregunta es solo una de nombrar, entonces para una clase específica ...
class="floatleft"
o
class="myClass"
o
class="gibberish"
.... no cambia absolutamente nada. Solo son diferentes nombres de clase. La programación funciona de la misma manera.
O bien tu contenido y tu presentación están separados, o no ... totalmente independientemente de cómo hayas creado los nombres.
Si tu pregunta es:
¿Se recomienda agrupar elementos basados en los estilos adjuntos para evitar la repetición en el CSS, incluso si esto significa que la información de presentación se introduce en el HTML?
Entonces mi respuesta plana sería que en el mundo real, la semántica y la presentación no son todo. Entonces mi respuesta sería: depende.
... depende si el ancho de banda es importante para ti ... En un sitio con muchos visitantes por hora, los nombres de clase podrían ser simplemente algo así como "c11" (sí, lo he visto) en lugar de significativo, pero la clase looong nombres.
... también depende si sabe perfectamente que cuando la apariencia cambie, el CÓDIGO también cambiará. (por ejemplo: rediseña un sitio hoy en XHTML, pero sabe perfectamente que cuando vuelva a hacer CSS en 2 años, querrá que el marcado sea HTML5, por lo que prácticamente cambiará la estructura). ..)
... también depende si ya estás 3 días tarde en una entrega. Cuando llegas 3 días tarde, créame, los nombres de clase como "nopadding" comienzan a aparecer, ya que no tienes más tiempo para pensar directamente en semántica (tampoco lo hace tu cliente).
Depende de muchas cosas, diría ... Ese es mi punto de vista de la "vida real" de tu pregunta.
Soy desarrollador antes que un programador, así que para mí uso algo así como una clase css "floatleft" como una especie de UtilityMethod.
Es decir, mi clase css es "floatleft" ... y eso es todo lo que hace la clase. así que si digo <div class="floatleft"></div> en mi mente, eso es decir "haz que este div flote hacia la izquierda".
Entonces, si esa Div también necesita un fondo azul y es mi encabezado principal, tendrá una clase diferente para eso y yo terminaré con <div class="mainheader floatleft"></div>
Hacerlo de esta manera también evita problemas con la refactorización. Si cambio mi diseño más tarde, sabré que "floatleft" SIEMPRE flota cosas y nada más.
Usted dice algo como esto:
.red
{
color:red;
}
entonces para usar esta clase:
<ul>
<li class="red">hello</li>
</li>
SOLUCIÓN ALTERNATIVA
ul li
{
color:red;
}
Uso:
<ul>
<li>Hello</li>
</ul>
Con esto, puedes eliminar la información de la presentación del contenido.
Nombres de clase de presentación
La especificación de HTML es clara en este tema:
No existen restricciones adicionales sobre los tokens que los autores pueden usar en el atributo de clase, pero se alienta a los autores a usar valores que describan la naturaleza del contenido, en lugar de valores que describan la presentación deseada del contenido.
¿ clearleft describe la naturaleza del contenido? Realmente no. Eric Meyer hizo una joke sobre esto hace un tiempo.
Intenta encontrar una relación estructural entre los elementos aparentemente no relacionados
Digamos que tienes párrafos sobre patos, párrafos sobre monos y párrafos sobre ranas. Quieres que tengan un fondo azul.
<p class="duck"></p>
<p class="monkey"></p>
<p class="frog"></p>
Puede agregar esta regla de CSS:
p.duck, p.monkey, p.frog {
background-color: blue;
}
Pero, ¿no son todos animales? Solo agrega otra ficha de animal :
<p class="animal duck"></p>
<p class="animal monkey"></p>
<p class="animal frog"></p>
Y cambie la regla de CSS a:
p.animal {
background-color: blue;
}
Es difícil y puede que no siempre sea posible, pero lo importante es no rendirse rápidamente.
¿Qué pasa si no puedes?
Si tiene muchos elementos sin ninguna relación estructural entre ellos, eso indica un problema estructural con su documento. Intenta disminuir estos elementos. Dicho esto, agrupar n selectores de CSS en una regla es aún mejor que agregar n tokens de clase de presentación en su documento HTML.