Para administrar CSS de manera más efectiva, Sofish explica los conceptos y perspectivas del "CSS modular" a continuación. Espero que esto le resulte útil.
En los primeros días de aprender CSS, entré en contacto con el concepto de "CSS modular", pero nunca lo entendí bien. Hablando de eso, la razón es muy simple: debido a que casi todo el código es para el diseño del blog, y para una estructura tan pequeña como un blog, no es necesario tener muchos archivos CSS, porque la cantidad de código En sí es pequeño y no hay muchas plantillas de página que utilicen diferentes expresiones. Menos es más conveniente de administrar. Por lo tanto, mi comprensión del CSS modular es muy confusa, lo que me lleva directamente a pensar que el siguiente método de división es muy razonable:
reset.css // Restablece el estilo predeterminado del navegador.
layout.css //Administrar el diseño de la página
typeset.css // Disposición gráfica y de texto y
color.css // Gestión unificada de combinación de colores
print.css //Estilo de efecto de impresión
ie.css // No es cierto separar hacks para IE. Recientemente trabajé y entré en contacto con el sitio web de la compañía. El líder tuvo que escribir sus propias especificaciones de escritura CSS, así como algunas especificaciones HTML unificadas, y también escribió nuevas. canales/páginas/tiendas. Sólo entonces me di cuenta de que la división anterior era todavía demasiado idealista. Personalmente, creo que se puede utilizar el siguiente método de división. Primero escribámoslo y luego comparemos estos dos métodos de división para encontrar un método de división modular CSS adecuado que resuelva mejor la administración de archivos CSS:
reset.css
header.css // Todos los estilos del encabezado
container.css // Estilo del área media excepto encabezado/inferior
footer.css // Estilo inferior
imprimir.css
es decir.css
Podemos ver que hay tres archivos CSS diferentes. El primer método de división es un buen enfoque, pero es más problemático de administrar. Aunque es "modular", el estilo del contenido mostrado está separado. Sin embargo, dado que es imposible que todos comprendan el contenido de cada archivo CSS al 100%, esto puede generar los siguientes problemas:
1. Los problemas de eficiencia y el objetivo final radican en el contenido del sitio web, si es el contenido de un área determinada. se cambia, ¿cuántas veces puede ser necesario cambiar todo el CSS? Como resultado, lo que originalmente era una simple modificación comenzó a complicarse. Además, si se realizan varios cambios, es posible que pasemos por alto algo y necesitemos una mayor depuración. Esto no solo retrasará la consecución del objetivo final, sino que también provocará un problema de eficiencia.
2. Llame a la menor cantidad de archivos CSS posible. En la mayoría de los casos, un sitio web se divide en encabezado, medio e inferior y, en general, al crear nuevos canales/páginas y similares, el encabezado y la parte inferior no se cambiarán. sólo se cambia la parte media. De esta manera, se deben llamar todos los archivos CSS, porque la modularidad de HTML y CSS no es consistente. Esto hará que el servidor soporte más presión. Este es un aspecto. Otro aspecto es que si algunos elementos de la nueva página entran en conflicto con otras páginas, es posible que tengamos que escribir mucho código sobre la selección de prioridad, aumentando la cantidad de código. Nada de esto es lo que queremos. Es por eso que header.css y footer.css deben estar separados.
3. Problemas con la cooperación de varias personas Si hay más de uno trabajando, la división del trabajo puede ser que alguien complete la navegación en la cabecera, alguien complete la barra de búsqueda en la parte inferior y alguien complete la construcción del nuevo página en el medio. De esta forma, todo el mundo está cambiando varios archivos al mismo tiempo y las cosas que cambian son diferentes. Si desea actualizar al servidor, primero debe comparar y luego actualizar. (Por supuesto, ahora existe software como el de gestión de versiones. Sin embargo, si trabaja al mismo tiempo, la versión también es un problema. Debe creer que tal vez las actualizaciones nunca la cambien).
Conclusión:
Por supuesto, el método de división anterior es sólo un modelo simple. La arquitectura de diferentes sitios web puede requerir una clasificación más detallada. Una cosa que hay que recordar aquí es que con CSS modular, siempre debemos tener claro que estamos aquí para facilitar la gestión, modificación y colaboración entre varias personas, en lugar de una simple división. Si tengo alguna sugerencia, creo que la modularidad de CSS debería ser coherente con la modularidad de HTML. El consenso aquí es que ya sea la división de archivos o la división de contenido CSS, es consistente con la modularidad de HTML. Esto será más beneficioso para nuestro trabajo.
¿Y tú qué piensas?