La historia se repite y aparece otra propuesta para CSS Variables, via New features proposed for CSS en CCS3.info.
Pero personalmente considero que no solucionan ninguna falencia de la especificación actual sino que sólo satisfacen el capricho de los desarrolladores.
Fallback
Entre los requerimientos mencionan que un navegador que no implementa variables puede utilizar una regla más convencial. En este caso es redundante con la propia funcionalidad de CSS porque si yo quiero que cierto elemento tenga sí o sí cierto color no voy a delegar eso a una funcionalidad que puede fallar. Entonces el sistema de variables termina en una redundancia como:
@variables {
mycolor: green;
}
p {
color: green; /* para asegurarme que el texto sea verde */
color: var(mycolor); /* redundante usando variables */
}Otro problema es que no se especifica cómo funcionaría en el caso de las tipografías. En este ejemplo no existe forma de incluir una regla que no produzca un conflicto entre los navegadores que implementan variables y los que no.
@variables {
myfont: monospace;
}
p {
font-family: sans-serif;
font-family: var(myfont);
}Un navegador que implementa variables usaría una fuente monoespaciada, pero en el caso contrario no se usa una fuente sans-serif sino la fuente que esté configurada como por defecto (generalmente una fuente serif) —font-family es un caso excepcional entre las demás propiedades.
Diferenciación por versiones
Esta funcionalidad rompe completamente (de una manera indirecta) con el proposito de CSS, que es que un navegador que no implemente cierta propiedad pueda aún así sacar provecho de todas las demás. Funciona como un filtro con el que si cierta funcionalidad no está implementada, no se puede acceder a todo el resto de las propiedades; por ejemplo, que se requiera contenido generado para que también se indique qué color de fondo usar. En el caso de las variables esto se logra de manera muy sencilla:
@variables {
mybg: black;
myfb: white;
}
html {
background-color: var(mybg);
color: var(myfg);es perfectamente equivalente a
html {
background-color: black;
color: white;
}
sólo que el primer ejemplo no podría ser interpretado por ciertos navegadores. El uso de variables crea un limite infranqueable (manejado por los desarrolladores) entre navegadores viejos y nuevos.
Organización
Esto no es tanto una falencia de la propuesta sino una cuestión más ideológica: el sistema de variables sólo existiría por la ineptitud de los desarrolladores. Si ciertos elementos tienen que usar el color rojo, lo más inteligente sería organizar las declaraciones de tal manera que la declaración sea hecha una sóla vez. En lugar de un despelote como
p {color: red; /* varias propiedades más */}
ul {color: red; /* varias propiedades más */}
h3 {color: red; /* varias propiedades más */}p, ul, h3 {color:red;}
p, ul, h3 { /* otras propiedades */ }Existen montones de artículos que repiten hasta el cansancio cómo organizar las declaraciones de CSS.
¿Algún pro-variables y pro-innovacion que quiera contradecirme?
10 comentarios. Agregá el tuyo →
mini-d
Cero compatibilidad atrás, aunque si ahora queremos hacer cosas parecidas tenemos que, lamentablemente, crear duplicados. Entiéndase como hacks, reglas para pisar otras reglas porque no soportan selección por atributos, etc.
Yo todavía tengo que utilizar varios background: para definir múltiples opciones dependiendo si es un navegador antiguo o un moderno.
Hombre, se quieren montar una hoja de estilos de valores para las hojas de estilos.
Si tenemos que definir de forma separada todos los valores para una hoja de estilo, entonces urge la necesidad, como dices, de saber organizarse más.
Hoy las variables, mañana, ¿los arrays?
Tengo la sensación que esto sólo soluciona en parte, los problemas de unos pocos.
10 de abril de 2008
Toredk
Claro, la cagada es que no podés hacer que eso falle grácilmente:
O sea, la única forma es tener un CSS con variables abajo de un CSS que use los valores directamente… haciéndolo un poco estúpido.
Por otro lado, hay formas de usar m4 o make para agregar macros a un CSS. La idea es tener un “estilo.src”, y si se me canta cambiar colores, lo hago, y después llamo un make, y me genera el CSS con todas las variables.
La idea es que, además, puedo armar mi CSS todo ordenadito y lindo, con mucho whitespace y comentarios, y cuando le doy make, me genera un archivo megacompacto (algunos evangelizan el hacer esto para evitar un par de syn/acks cuando el css es más grande que el tamaño del paquete).
10 de abril de 2008
Federico
@minid: Pero pisar reglas con otras reglas es cascada y especificidad.
@Toredk: Para preprocesar en el servidor es posible que muchos también se decanten por algo en PHP, como CSS Server-side Constants (por mencionar una que tuvo mucha prensa en su momento).
11 de abril de 2008
are
Sobre la barrera infranqueable, nada que decir, es un problema de compatibilidad hacia atrás. Cosas peores se pueden sufrir
No soy muy conservador con el tema.
Sobre la organización estoy en contra
los agrupadores de reglas son insuficientes. Muchos artículos han intentado explicar su forma de organizarse con los CSS debido a que los CSS de por sí tienden al desorden.
Cuando tratas con CSS enormes por mucho que dividas, por mucho que agrupes, por mucho que uses los “trucos” de organización, tu CSS será un verdadero caos que sin un conocimiento íntimo del mismo será ilegible y dificilmente mantenible.
No, no hablo de CSS pequeños.
De las variables propuestas lo que me parece un horror es la sintaxis pero que existan me parecería una pequeña mejora en la productividad y mantenibilidad, sin lugar a dudas.
Lo de usar pregeneradores de CSS no deja de demostrar la enorme deficiencia que existe de organización.
11 de abril de 2008
Juan
Me parece que de movida ya viene mal encaminado. Crear variables en las que sólamente se puedan guardar los valores y no las delcaraciones me parece completamente innecesario.
Distinto sería si en las variables se pudiesen guardar declaraciones completas. Ejemplo:
@variables {
myProp: 'color:olive; baground-color:black;';
}
Pero de todas maneras es algo que está solucionado con el agrupamiento de selectores.
Te apollo. Este tipo de funcionalidades son para un editor, no para la especificación en sí, ni para el browser.
Como bien lo dijeron, las CSS se pueden generar tranquílamente al vuelo con cualquier lenguaje de scripting.
Es como un bucle infinito: el template engine del template engine del template engine…
Si tan desarrolladores son deberían saber aprovechar los beneficios de la herencia.
PS:es bueno tenerte de vuelta
11 de abril de 2008
Angel
Para variar algo mas a lo que tenemos que adaptarnos, que mas da…
11 de abril de 2008
Federico
@are: Pero acá estamos hablando de romper la compatibilidad por algo que sólo beneficiaría al pajerismo de los desarrolladores y que no aporta algo que no pueda hacerse con lo que ya existe. Hoy pensaba que si fuera sólo por compatibilidad (e implementaciones), los selectores de CSS3 son también un problema; pero no hay duda que ¿ningún? nuevo selector es tan versatil como los más básicos de CSS1. Ignoro si
:nth-childfue pedido por su nombre por las masas, pero no tengo dudas que soluciona un problema (al evitas tener que modificar el documento para crear una clase diferente para cada fila).Sobre la cuestión del desorden, y con perdón por no ser programador, ¿pero acaso no código fuente es un despelote? Creo que yo fui ordenado sólo cuando aprendí Pascal y eso si la aplicación no era muy complicada.
Igualmente no parece haber demasiado interes en el tema ya si nos guiamos por las respuestas al subject original. El interes por las variables existe desde hace rato y el WG siempre estuvo muy cerrado el tema, aunque en este caso existe la diferencia de que haya sido propuesto por uno de los desarrolladores de WebKit.
11 de abril de 2008
are
Pues seguramente seré inocente pero cuanto más me ayude un lenguaje a trabajar ordenado menos errores cometo lo que se traduce en poder trabajar mejor y más rápido, lo que se traduce en que el resultado será mejor para el usuario que use mi web.
No creo que los lenguajes web actuales sean buenos. Son pobres y simplones. Se escudan en la simplicidad desdeñando la complejidad argumentando que sinó se complicaría innecesariamente. No estoy de acuerdo en esta filosofía. Me parece que nos hace perder el tiempo a todos.
Sobre romper con lo que hay hasta ahora, mejor sería no romper, pero tampoco sufro por ello…seré un personaje malvado?
Cierto que al WG no les hace ninguna grácia, que le vamos a hacer. Muchas veces me da la sensación que no sufren los CSS día a día.
En fin, últimamente no me gusta como “evoluciona” esto de la web, y esto de las variables me parece un pequeño soplo de aire.
15 de abril de 2008
Federico
No sé si realmente viven tan desconectados; fijate que el WG del W3C tiene expertos (diseñadores) invitados. De momento tengo entendido que el WHAT no se ha metido con CSS.
Si lo nuevo te gusta, entonces debes estar contento con la implementación de degradados en CSS que incluyeron en WebKit. Y yo que pensaba hacerlos con SVG ahora que se lo puede agregar desde
background-image.Lo curioso de esto último es que los degradados son algo que se había pedido en la lista de discusión pero se desecho por falta de una sintaxis sustentable. Y de pronto son los mismos desarrolladores de WebKit quien crear su propia manera (sin que sea noticia hasta ahora) —y tenes a Hyatt por el otro lado con el tema de variables.
No quiero ser rompebolas porque al menos le agregan el prefijo de experimental, pero saltar de un día para otro con una nueva propiedad no es un diferente de
BLINKoMARQUEE.15 de abril de 2008
are
Mientras mantengan el prefijo de experimental no me parece muy malo.
Los degradados me parecen una buena aportación. Las transformaciones no
no todo lo nuevo me gusta!
16 de abril de 2008