2011-05-25 8 views
8

Supongamos que está creando un widget conceptual denominado Awesome Widget y desea protegerlo por completo contra conflictos con elementos circundantes o elementos secundarios que residen como contenido dentro del widget.CSS estilo prevención de conflictos y técnicas de creación de nombres

Lo que no queremos

div ul li {} 

Solución 1: CSS combinador niño

Uso del selector de combinador niño CSS para especificar que sólo los niños directos deben ser dirigidos.

.awesomewidget > div > ul > li {} 

Solución 2: Clase de espacios de nombre del

Usando aw (Widget impresionante) como espacio de nombres para cada clase, disminuyendo la posibilidad de cualquier otro elemento en la página utilizando ese espacio de nombres exacta + nombre de la clase.

.awesomewidget .aw-container .aw-list .aw-listitem {} 

También hay algo así como @namespace en CSS pero eso es solo para XML.

Además de las soluciones 1 y 2, ¿hay otras que se puedan usar? ¿Cuál preferirías? ¿Alguna mejor práctica?

EDIT: ejemplo de un problema que se presenta sin los espacios de nombre adecuado/estilizar la prevención de conflictos

Widget estilo:

.awesomewidget > div ul li { 
background-color:red; 
} 

estilo del usuario:

ul li { 
background-color:blue; 
} 

de marcado:

<div class="awesomewidget"> 
<div> 

<ul> 
<li> 
<!-- user content starts here --> 

<p>I am the user and I want to add some content here. Let's add a list:</p> 

<ul> 
<li>Why is this list-item red and not blue?</li> 
</ul> 

<!-- user content ends here --> 
</li> 
<li> 
<!-- user content starts here --> 

<!-- user content ends here --> 
</li> 
</ul> 

</div> 
</div> 

Respuesta

3

yo preferiría utilizar una combinación de las dos soluciones como:

.awesomewidget > div ul li {} 

Debido a que el segundo añade mucho peso innecesario a la marca.

actualización

Para su ejemplo, me gustaría añadir un envoltorio sobre el contenido del usuario con la clase .user y luego anteponer su CSS con .user. Sin embargo, esto no es elegante, agrega un margen de beneficio, y creo que sería propenso al fracaso.

+1

Puedo ver su punto. Pero, ¿qué pasa con el contenido dentro del li (podría ser cualquier elemento en un widget no conceptual) que no forma parte del widget en sí (el contenido) y que es diseñado por otra persona? – DADU

+0

@DADU Mi cerebro acaba de explotar. Contenido que está dentro del widget, pero que no forma parte del widget y que es diseñado por otra persona. ¿Qué significa esto? – rockerest

+0

@rockerest Debo aclarar esto. Supongamos que está creando un widget de pestañas. Usted tiene los botones de pestaña, pero también tiene las secciones de pestaña. Dentro de cada sección de pestaña, el usuario puede agregar su propio contenido HTML y darle un estilo. Entonces el widget es solo un marco. – DADU

1

XBL podría ayudar si alguna vez se implementa en los navegadores, ya que tiene formas de diseñar widgets que pueden evitar transmitir información de diseño.

Otra ventaja, por cierto, para incluir el combinador infantil es el rendimiento. No es necesario verificar todos los niveles de posibles hijos para determinar cómo renderizar.

Pero si usted va a hacer por razones de brevedad namespacing clase, dos a lo sumo debería ser suficiente yo creo, a menos que usted no está lo suficientemente nombrar claramente:

.awesomewidget .aw-listitem {} 

También podría dar un contenedor (con una clase con buen espacio de nombres) a las secciones de contenido no de usuario en el nivel más alto posible que no encerra el contenido del usuario, salvándose de ese riesgo. <div/> es bastante práctico para ese tipo de agrupación arbitraria y con ese fin ...

0

Aquí hay un par de soluciones:

  • comprobar el orden de origen para asegurarse de que los estilos globales están vinculados antes de la página estilos específicos en la cabeza
  • uso target para desencadenar usuario CSS
  • uso generated content para unir estilos
  • uso attribute selectors para aumentar la especificidad
1

Si está experimentando muchos conflictos de espacios de nombres CSS, tal vez es hora de considerar cambiar a un marco JS front-end como el ReactJS de Facebook. Esto, en conjunto con Webpack Module Loader, le permitirá aprovechar muchas bibliotecas finas de JS que agilizarán su flujo de trabajo de desarrollo. CSS-loader, por ejemplo, lo ayudará a administrar su desarrollo de CSS al hacer local scoping, que es justo lo que está buscando.

Cuestiones relacionadas