strong span font css

css - span - strong html



¿Cuál es una buena estrategia de CSS? (13)

Creo que la mejor opción es dividir css en:

-layout.css

-content.css

Luego, si necesita otro más específico, puede agregar más como un CSS para los anuncios: ads.css o un CSS para una sección específica.

También agregaría ie.css para IE css hacks.

No hablaría sobre crear un CSS para una sola página: el problema que puede tener si usa demasiados CSS es que su página tendrá que hacer más solicitudes al servidor y esto ralentizará su página. Es por eso que le recomiendo implementar un HttpHandler que creará una copia de caché en solo un archivo del CSS que necesita en este momento. Mira aquí: http://blog.madskristensen.dk/post/Combine-multiple-stylesheets-at-runtime.aspx

Tenemos un gran sitio web ASP.Net que tiene una sola hoja de estilo css que está fuera de control.

Estoy pensando en utilizar la siguiente estrategia (tomada de http://www.techrepublic.com/article/developing-a-css-strategy/5437796/ ) que me parece lógica ...

Es posible que tenga un archivo CSS dedicado a estilos de todo el sitio y archivos CSS separados para subconjuntos identificables de páginas del sitio (como páginas para un departamento específico o páginas con un estilo de diseño diferente). Para los estilos que son exclusivos de una página específica, use un archivo CSS separado para cada página (si hay demasiados estilos para caber cómodamente en el encabezado del documento). Vincula o importa los archivos CSS apropiados para cada página, de modo que carga todos los estilos necesarios para mostrar esa página, pero muy pocos estilos innecesarios que solo aparecen en otras páginas.

¿Es esta una buena manera de proceder? ¿Cuáles son las alternativas?

Elabore algunas reglas simples que funcionen para usted (o su empresa).

Divida su CSS en archivos separados, como:

layout.css content.css menu.css typography.css

Decida qué declaraciones irá en cada archivo, por ejemplo, asegúrese de:

font-weight, text-decoration, font-family

y

h1, h2, h3, h4, h5, h6, a, p, li

Todos residen en el tipo de archivo CSS. Decida qué hacer para los casos extremos, como propiedades de borde en encabezados, relleno y márgenes en elementos de texto (diseño o tipografía).

Si sus conjuntos de declaraciones son cada vez más difíciles de manejar, a algunas personas les gusta organizarlas alfabéticamente.

Sangra tu css, por ejemplo:

#logo h1 {text-indent: -9999px} #logo h1 a {display: block; width: 200px; height: 98px; backround...}

Comente su CSS, incluidas las referencias a otros archivos si reside allí otra regla para ese selector específico.

Si divide su CSS en archivos separados, considere la posibilidad de consolidarlos y comprimirlos en un archivo como parte de su proceso de compilación e implementación.

Asegúrese de que cada desarrollador conozca bien su estándar de CSS.

Además, algo relevante, acabo de enterarme de un complemento de Firefox para encontrar selectores innecesarios. Se llama Dust-Me Selectors .

Lo que puede hacer es tener muchos archivos separados y fáciles de administrar para el desarrollo, luego combinarlos en un solo archivo y minificarlo en su sitio en vivo.

Este es un poco más de trabajo para configurar, pero le ofrece lo mejor de ambos mundos: fácil de administrar el sitio y cargas de página rápidas.

Editar: El compresor YUI de Yahoo parece ser el mejor minificador. Puede comprimir CSS y Javascript.

Me pregunto lo mismo con respecto a los archivos de JavaScript. Si su sitio es altamente dependiente de Ajax hasta el punto en que casi todas las páginas requieren algún tipo de Javascript personalizado, entonces, ¿se lo quedó todo?

Las mejores prácticas de spout no tienen javascript en la página sino como archivos externos (como con css). Pero si tiene un archivo .js por página, las cosas se irán de las manos.

No estoy seguro acerca de los equivalentes de Windows, pero en la Mac puede obtener CSSEdit , que le permite agregar carpetas a archivos CSS y administrarlos de esa manera. Hay una buena explicación de esto en este artículo .

Verificaría YUI CSS. Tal vez no es la respuesta que estabas buscando, pero YUI CSS elimina gran parte de la molestia con diferentes navegadores, etc ...

netadictos hace algunos buenos puntos y yo estaría de acuerdo. Es fácil buscar razones para obtener más Css, pero los beneficios de mantenerlos delgados son mucho mayores a largo plazo.

Además, ¿ha analizado el uso de temas y archivos de máscara dentro de asp.net? La combinación de .css y .skin puede reducir drásticamente el tamaño total de su Css, que es marginalmente bueno para el rendimiento pero muy bueno para una administración más fácil.

Algunas excepciones podrían estar contenidas dentro del archivo css, pero si las cosas son radicalmente diferentes dentro de uno, entonces puede considerar un css separado o incluso un sitio separado si son diferentes. Obviamente, puede cargar diferentes versiones de los temas dependiendo de qué usuario sea. Aquí es donde podría tener una explosión de archivos Css. Es decir, digamos que tenía un CSS para cada página y luego deseaba tener diferentes clientes diferentes en su sitio, entonces estaría creciendo exponencialmente. Por supuesto, esto supone que tienes este desafío.

Hay tres métodos principales utilizados para dividir hojas de estilo: basado en propiedades, basado en estructuras e híbrido. El método que elija debería basarse principalmente en el flujo de trabajo y las preferencias personales.

Basado en la propiedad

La forma más básica y representativa de una ruptura basada en propiedades sería usar dos hojas de estilo: structure.css y style.css. El archivo structure.css contendría reglas que solo utilizarían propiedades como altura, ancho, margen, relleno, flotación, posición, etc. Esto contendría efectivamente los "bloques de construcción" necesarios para organizar los elementos de la página de la manera que desee. El archivo style.css contendría reglas con propiedades como fondo, fuente, color, decoración de texto, etc. Esto efectivamente actúa como una máscara para la estructura creada en la otra hoja de estilo.

La separación adicional puede incluir el uso de un archivo tipográfico.css, donde colocaría todas sus propiedades de fuente. O un archivo colors.css, donde colocaría todas sus propiedades de color y fondo. Trate de no exagerar porque este método se convierte rápidamente en un problema más de lo que vale.

Basado en estructura

El método basado en la estructura para dividir hojas de estilo gira en torno a las reglas de segregación basadas en los elementos a los que se aplican. Por ejemplo, puede ver un archivo masthead.css para todo en el encabezado, un archivo body.css para todo en el área de contenido de la página, un archivo sidebar.css para todo en la barra lateral y un archivo footer.css para todo en la parte inferior de la página.

Este método realmente ayuda cuando tienes un sitio con muchas secciones distintas en cada página. También ayuda a minimizar el número de reglas encontradas en cada hoja de estilo. A diferencia del método basado en propiedades, que tiende a tener una regla en cada hoja de estilo para cada elemento en la página, con este método solo tiene una regla en una hoja de estilo para cualquier elemento dado.

Híbrido

Como era de esperar, el método híbrido combina lo mejor de ambos métodos y es mi elección preferida. Aquí puede crear un archivo structure.css, como en el método basado en propiedades, usando solo las propiedades que necesita para crear el diseño básico. Luego creas hojas de estilo adicionales como masthead.css, que muestra el encabezado; body.css, que revisa el contenido; etc.

Otras Consideraciones

Un problema que afecta a cada uno de estos métodos es que al crear varias hojas de estilo, necesita que el navegador del cliente obtenga muchos archivos. Esto puede tener un efecto negativo en la experiencia del usuario porque la mayoría de los navegadores solo realizarán dos solicitudes concurrentes al mismo servidor. Si tiene siete hojas de estilo, eso significa agregar potencialmente cientos de milisegundos en la carga inicial de la página (este efecto se reduce una vez que las hojas de estilo han sido almacenadas en la memoria caché, pero desea hacer una buena primera impresión en esas visitas nuevas). Es por esta razón que se creó la técnica de sprites de CSS. Al desglosar tus hojas de estilo, puedes eliminar cualquier ganancia que se haya logrado con el uso de sprites.

La solución consiste en comprimir las hojas de estilo fragmentadas en una hoja de estilo cuando el usuario realiza una solicitud de página.

Para obtener lo mejor de ambos mundos, considere usar un metalenguaje CSS como Sass . Esto le permite a un autor de CSS dividir una hoja de estilos en muchas y seguir presentando una sola hoja de estilo en el navegador. Esto agrega un paso al flujo de trabajo de autoría de CSS (aunque podría ser un script para compilar el Sass en CSS cada vez que se actualiza un archivo Sass), pero puede valer la pena, especialmente cuando se consideran algunos de los muchos otros beneficios de Sass.

Cualquiera que sea su elección, evite usar la directiva @import .

Hace que el navegador cargue hojas de estilo de forma secuencial, lo que ralentiza la carga y el procesamiento de su página.

Los archivos css globales me han causado dolores de cabeza antes. Por lo general, CSS no tiene espacio de nombres, por lo que si dos módulos diferentes crean un div con una clase de "cuadro", entonces la intención de uno sobrescribe al otro. Además, los estilos en la etiqueta [a], la etiqueta [p] y otras etiquetas básicas (es decir, estilos que no se basan en clases o identificadores) harán estragos en los controles de terceros a medida que la hoja de estilos global vaya en cascada a un componente html diseñado ningún otro CSS en la página. El uso inapropiado de centrar el texto en los elementos centrales puede provocar un centrado global difícil de depurar. Así que prefiero múltiples archivos css. He visto administradores de css (módulos http que combinan css juntos en el momento de la solicitud), pero decidí que las solicitudes http adicionales valen la pena para limitar el alcance del daño que css puede hacer a mi aplicación.

Usamos Ruby on Rails para tener un par claro de controlador / acción, usamos esto para hacer referencia tanto a las clases de CSS como a las vistas de Javascript.

Específicamente, tome el nombre del controlador + nombre de acción e incrústelo como ID en la vista, colóquelo en la etiqueta del cuerpo o su div de contenido principal.

<body id="users_list_body">

Donde "usuarios" es el nombre del controlador, "lista" es la acción. Luego en tu CSS tienes reglas como "me gusta"

#users_list_body

Por lo tanto, puede abarcar todo su CSS específico para esa vista. Por supuesto, también tiene CSS más general para manejar el estilo general. Pero tener esta identificación definida más fácilmente le permite crear CSS específicos para páginas individuales (ya que un controlador / acción se asigna a una página específica).

Terminas teniendo reglas como esta

#users_list_body table #users_list_body table thead

Haz lo mismo con Javascript. Entonces, en el pie de página de cada página, toma su mismo par de nombre de controlador / acción y lo inserta en una llamada de función

//javascript if(V.views.users_list) { V.views.user_list(); }

Luego, en su Javascript externo, tiene algo así como

V = {}; V.views = {}; V.views.user_list = function() { //any code you want to run for the Users controller / List action.. //jQuery or something $(''#save_button'').click({ ... }); }

con todo su código Javascript enfocado a una función específica, termina siendo todo encapsulado. A continuación, puede combinar todos sus archivos Javascript en uno, comprimirlo y luego servirlo como un archivo y ninguna de sus lógicas entrará en conflicto. El JS de una página no entrará en conflicto con el JS de ninguna otra página porque cada página tiene el alcance del nombre de su método.

Esto es lo que hago: mantengo mis hojas de estilo separadas, de alguna manera en la línea de lo que otros han sugerido. Sin embargo, tengo un script que los concatena, los minimiza, agrega los encabezados y luego los gzips. El archivo resultante se utiliza como la hoja de estilo y, si va más allá de la fecha de caducidad, se vuelve a compilar automáticamente. Lo hago en todo el sitio para todos los archivos comunes y luego también en una página específica para CSS que solo aparecerá en esa página. A lo sumo, solo tendré 2 archivos CSS llamados por página y se comprimirán, lo que minimiza el tiempo y el tamaño de descarga y el número de solicitudes de página, pero aún tendré la ventaja de separarlos de cualquier manera que tenga sentido. yo. La misma estrategia también se puede usar para JavaScript.

Mi solución, en medio de mucho:

  • base.css / reset.css : su base {diseño base, tipo, color} - 100% de reutilización
  • helper.css : reglas de diseño básicas para módulos y ''clases de utilidad'' {variaciones de cuadrícula, formularios, tablas, etc.} - 90 +% de reutilización
  • module.css : reglas de diseño complejas para módulos {módulos semánticos como .post o .comment} - 75% de reutilización
  • layout.css : reglas basadas en plantilla {#hd, #bd, #ft, #homePage, etc.} - casi sin reutilización
  • color.css : todas las reglas de color, combinadas: 50% de reutilización
  • type.css : reglas de todo tipo, combinadas: 75% de reutilización (el estilo del texto tiene menos variaciones)
  • esta separación también permite versiones móviles e impresas para las hojas de diseño, todas controladas por @import a través de la hoja de estilo que enlazo al html.

Estoy usando esto para un sitio de tamaño mediano. Para una organización adicional, guardo cada hoja seccionada básicamente igual {envoltorio, general, único, etc.}. También etiqueto mis selectores y propiedades, y los marco por orden de dependencia dentro del mismo grupo de selectores, de modo que sé a qué reglas me refiero o extiendo. Este marco permite una expansión casi infinita a la vez que mantiene las cosas organizadas, comprensibles y reutilizables. Tuve que refactorizar un archivo master.css de más de 7000 líneas hace un mes, así que este es un nuevo sistema que estoy probando. Descubrí que el CSS 100% semántico de contenido no es tan escalable y fácil de entender como un híbrido semántico / de diseño, ya que para eso se usa CSS.

1.25-yr-later-edit : Otro método que podría ser más relevante es usar un buen editor de texto CSS. Estoy seguro de que VS es basura para trabajar con CSS, a menos que ocurra con algunas extensiones. Si está en Windows, ejecute E Photo Editor , b / c es un puerto TextMate de Windows y tiene paquetes diseñados para CSS y etiquetas que le brindan mucho mejor resaltado de sintaxis y autocompletado. Lo que entonces puede hacer es organizar, incluso una hoja de estilo de 8000 líneas, en pliegues plegables:

/** Start Module 1 */ [css] /* End Module 1 **/

Y use la lista de símbolos para mostrarle un TOC rápido sobre la marcha con una consulta como Start o Module 1 También indexa líneas con /** these types of comments **/ (ideal para áreas de etiquetado) y todas las cadenas de selector de CSS. No deberías tener problemas para trabajar con archivos grandes individuales con E. Además, a menos que estés mejorando progresivamente tu CSS, todo se va a minimizar. También me aseguraré de sangrar tu CSS para imitar de algún modo la estructura de la sección DOM a la que se refiere.

.container {} .container .inner {} .container .head {} .container .inner.alt {}

De lo contrario, estoy de acuerdo con el método ''1 base CSS y 1 página / sección CSS'', aunque depende completamente de los requisitos de su empresa.