ruby on rails 3 - ¿Cuál es el valor de Compass for Rails 3.1?
ruby-on-rails-3 sass (4)
Estoy tratando de decidir si debo incluir Compass al iniciar un nuevo proyecto Rails 3.1 . No he usado Compass antes.
Rails 3.1 ahora soporta SCSS directamente. El canal de activos de Rails 3.1 (a través de ruedas dentadas) ahora compila hojas de estilo automáticamente. Y puedo usar una versión SCSS de un marco CSS como Blueprint directamente.
¿Qué beneficios obtendré al usar Compass con Rails 3.1?
Compass es un marco de diseño independiente, por ejemplo, no tiene que preocuparse por los navegadores que tienen los usuarios.
por ejemplo, Compass tiene complementos, como por ejemplo las funciones de navegador cruzado CSS3: http://compass-style.org/reference/compass/css3/ esta manera puede especificar cosas en sus archivos .scss independientes del navegador
Nota al margen:
La forma en que Rails 3.1 procesa los archivos .scss es uno a la vez; por ejemplo, si define variables en un archivo, no se transfieren a los otros archivos .scss. En mi humilde opinión no es realmente una solución óptima.
El html5boilerplate brújula html5boilerplate es un gran ahorro de tiempo, por lo que por estas razones yo usaría brújula
Bourbon (por Thoughtbot) es una alternativa ligera a la brújula que se integra bien con los rieles 3.1.
Tiene la mezcla principal de css3 que se obtiene con la brújula (imágenes de fondo, cuadro de sombra, radio de borde, gradientes ...). También tiene ayudantes para los botones de estilo, "cuadrícula" de su diseño y algunas otras cosas más.
Es posible que se pierda algunas de las funciones de potencia que tiene la brújula, pero que pueden superarse fácilmente con la potencia de Sass: ¡simplemente copie / cree su propia mezcla!
Compass a menudo me daba dolores de cabeza al actualizar mi aplicación de rieles. Aprecio la simplicidad de Borbón (aunque también podría causarle dolores de cabeza ... por la mañana :-))
Compass proporciona una gran cantidad de buenos mixins, un generador de sprites bastante potente y una estrecha integración con Blueprint de una manera que significa que no tiene que usar clases de código no semántico en todo su HTML.
Realmente no hay mucho beneficio al usar Compass si no está usando los mixins, pero tampoco hay muchos beneficios en el uso de SCSS si no los está usando (el agrupamiento y las variables son agradables, pero los mixins ayudan a mantener el navegador específico Implementación de propiedades en una sola ubicación).
Sin embargo, encontré que Blueprint es más problemático de lo que vale. Todavía usaría Compass para los mixins, pero en este momento la compatibilidad entre Rails 3.1 y Compass es terrible (tienes que saltar a través de algunos aros y aún debes sacrificar algunas funcionalidades).
En una nota un tanto relacionada, la forma en que Rails 3.1 compila los activos es más bien "rota". No tiene en cuenta cómo la comunidad ha estado utilizando Sass durante el último año o dos: las variables de mantenimiento, los mixins y los parciales de página se deben separar para incluirlos en un archivo maestro en orden. La forma "automática" en que Sprockets carga y compila Sass desasocia los archivos entre sí, por lo que incluso si define el orden de carga manualmente en su application.css
, las variables que configura en un archivo no están disponibles para los archivos cargados posteriormente.