variable tutorial sintaxis scss font family declarar css coding-style sass less

tutorial - scss sass



Estructuración de archivos CSS(SASS, LESS) por elementos, por función y por consultas de medios: ¿estructura de código 3D? (4)

Cero-D

Todo el mundo comienza a usar CSS con un solo archivo que contiene todos los estilos.

  • style.css

1D

Pronto se vuelve voluminoso y uno decide agrupar CSS en varios archivos por elementos de página:

  • html_elements.css
  • header.css
  • main-area.css
  • footer.css

Algunos pueden encontrar esto no lo suficientemente conveniente y agrupar los estilos por función:

  • typography.css
  • layout.css
  • sticky-footer.css (contiene declaraciones para muchos elementos, no solo pie de página)

2D

Cuando un proyecto tiene una gran cantidad de CSS, podría requerir el uso simultáneo de ambas agrupaciones. La estructura de los archivos CSS se convierte en bidimensional:

layout/

  • grid-system.css
  • header.css
  • sidebars.css

look/

  • typography/
    • main.css
    • headers.css
    • lists.css
  • backgrounds/
    • html_elements.css
    • header.css
    • main-area.css
    • footer.css

Bueno, el ejemplo está fabricado, pero seguro que entiendes lo que quiero decir.

Hasta este punto todo está bien.

Entrar en la consulta de medios

Aquí es donde mi estructura CSS se funky.

Además de la estructura 2D descrita anteriormente, tengo que estructurar mi código mediante consultas de medios:

  • Algunos de mis estilos son universales (aplicados en todas partes)
  • Algunos se aplican solo a cierto tamaño de pantalla:
    • pequeña;
    • medio;
    • grande;
    • extra grande.
  • Algunos se aplican a ciertos grupos de tamaños de pantalla:
    • Todo excepto pequeños (estilos no móviles);
    • pequeño y mediano (donde las barras laterales no están a los lados)
    • grande y xlarge (donde tienes barras laterales)

Intenté superar el problema dispersando los estilos consultados de los medios entre los archivos CSS existentes. La extensión Compass del breakpoint ayuda mucho, pero las hojas de estilo se vuelven demasiado desordenadas. Encontrar un cierto estilo cuando no está representado en los archivos genera mucho dolor.

Intenté agrupar por consultas de medios, luego por elementos y funciones. Pero la estructura de los archivos es bidimensional, por lo que no puede agregar una nueva dimensión, solo puede agregar otro nivel de jerarquía. Por lo tanto, no es elegante. Además, es muy voluminoso.

Así que termino con una estructura 2D con consultas de medios en un eje y una mezcla fea de elementos y funciones en el otro eje.

No estoy del todo satisfecho con eso, pero no consigo encontrar una solución elegante. Por favor sugiera uno.

¿Por qué no probar algo como esto?

/root /modules /header /html header.html /css module_styles.css /*Configure which style sheets are included with @media rule in this file*/ /at-media small.css medium.css large.css /js fancy-nav.js /site includes.css /*use @import to include each modules stylesheet in a file here and let each module control its own media issues*/

CSS ya es un lenguaje estructurado. Para bien o para mal, el orden de su código cambia su significado. Por eso, es importante que cualquier esquema de organización de CSS sea dictado principalmente por la cascada. El otro aspecto estructural de CSS es la semántica. Úsalo a tu favor. La preocupación de la organización es mantener las cosas significativas y mantenibles. Lo mejor que puedes hacer para conservar el significado es mostrar relaciones. Las relaciones ya están expresadas por semántica.

Ponga esas cosas juntas y terminará con el código organizado por especificidad primero y luego por semántica , pero nunca por conceptos externos como tipo frente a diseño o tamaño de pantalla. Aquí está mi esquema de nombres:

base/ - Sass imports and settings - no CSS output. - e.g _grid, _colors, _rhythm, etc. general/ - Initial CSS baseline with resets, defaults, font imports, and classes to extend. - e.g. _reset, _root, _fonts, _icons, _defaults, etc. layout/ - The rough outline of the site structure. - Not "layout" as a set of properties excluding type, "layout" as the overall site template which might well include typography. - e.g. _banner, _nav, _main, _contentinfo, etc. modules/ - All the details. First by effect (classes/general), then by widget (ids/specifics). - e.g. _users, _admin, _product-lists etc.

Las consultas de medios deben permanecer lo más cerca posible del código que afectan. Cuando es posible, van directamente en línea (con Sass media burbujeando). Si eso se vuelve voluminoso, se mueven fuera del bloque, pero nunca fuera del parcial . MQ son anulaciones. Cuando reemplaza el código, es especialmente importante que pueda ver exactamente lo que se está anulando.

En algunos sitios, puede llevar esta estructura más lejos. Ocasionalmente, he agregado dos carpetas al final: plugins/ para administrar códigos de terceros, y overrides/ para manejar inevitables (¡intenta evitarlos!) Reemplazos específicos de ubicación a un widget. También he profundizado, agregando una fonts/ carpeta con parciales para cada familia de fuentes, o una carpeta de users/ parciales para agregar, editar, ver, etc. Los detalles son flexibles, pero la organización básica sigue siendo la misma:

  • Inicio general.
  • Muévete hacia los detalles lo más lentamente posible.
  • Nunca divida según los conceptos externos (tipo / diseño, tamaños de pantalla, etc.).

Lo que acabo de hacer es tu solución 2D (aunque la mía tiene un poco más de anidación) y usar Breakpoint para escribir mis consultas de medios en línea cuando sea necesario. Una de las cosas con las que debemos lidiar es que nuestro CSS de salida no se verá igual que nuestro código escrito a mano, es una realidad al usar un preprocesador de CSS y abstraer específicamente las cosas. Pronto, las herramientas de desarrollo de Google Chrome vendrán con soporte parcial integrado de Sass , y FireSass para Firefox lo ayudará a descubrir de dónde provienen los estilos.

Espero que esta ayuda!

Ok, entonces esto es más una cuestión de gusto personal y puede que en realidad no esté respondiendo la pregunta, pero aquí está mi contribución:

Lo que hago es una organización "2D" como usted dice, con muchos menos archivos (digamos que estamos hablando de css con menos preprocesador)

Me resultó más fácil usar consultas de medios en el mismo archivo "menos" del elemento al que estoy diseñando.

Así, por ejemplo, tengo header.less y en el mismo archivo, sus consultas de medios.

#header { ... } //Header media queries ----------------------- @media screen and (min-width:480px) { ... } @media screen and (min-width:768px) { ... }

Ahora, ¿Por qué elijo hacerlo de esa manera? -> Porque (para mí) es un gran dolor en el ... tener que buscar en otro archivo (digamos responsive.less por ejemplo), buscar en él las consultas de los medios para el encabezado, hacer mis cambios, etc. En su lugar, con este método siempre sé dónde están mis consultas de medios y son fáciles de alcanzar / modificar para cada elemento y esto no agrega muchas más líneas al código.

El único problema con eso es que cuando se genera el css, terminamos con consultas de medios para elementos individuales repartidos por todo el código css. ¡No muy hermosa! (en este momento, less / winless no agrupa automáticamente consultas de medios).

Terminé de crear una pequeña aplicación para agrupar consultas de medios: http://nokturnalapp.com/mqhelper/ Lo uso para compilar los archivos CSS para la producción. (aún no está terminado, necesito agregar el código eliminado de la versión de consultas de medios, pero echarle un vistazo).

Espero que esto te ayude de alguna manera.