Animaciones CSS mediante JS ( Factoría de ideas @juandopazo :)

[Jose Antonio Perez]

Hace unas horas Juan tuiteó lo siguiente:

https://twitter.com/#!/juandopazo/status/124973354838003713

Idea: implement a CSS parser that looks for CSS animations and runs them with JavaScript when they're not supported by the browser

Le respondí que consumiría demasiado tiempo de ejecución pero tal vez fue una exageración por mi parte. Si el CSS está bien diseñado no creo que la cascada sea costosa ya que buscaríamos cosas concretas. Podríamos intentarlo:

1. Pescamos todo el texto CSS
2. Lo analizamos con una gramática de "grano grueso" en la que no nos entraríamos en el nivel de las declaraciones. En las declaraciones comprobamos directamente mediante regex si son transformaciones y vamos haciendo un map donde las claves son las declaraciones de transformación y cada valor el conjunto con los selectores correspondientes. Nos olvidamos de la specificity (contamos con que el usuario ha seguido ciertas "reglas").
3. Filtramos las declaraciones-transformaciones y sus respectivos conjuntos de selectores y empezamos a "repartir" animaciones.

Hay dos cuestiones que responder:
1. ¿Lo ha hecho ya alguien?
2. Merecería la pena el esfuerzo?

[gnz/vnk]

> Hay dos cuestiones que responder:
> 1. �Lo ha hecho ya alguien?

*Creo* que la mayor�a de lo que hay sigue la estrategia inversa. Es
decir, haces la animaci�n desde Javascript. Si detectas que hay soporte
para animaciones CSS, entonces las generas. Si no, entonces lo haces
manipulando el DOM.

> 2. Merecer�a la pena el esfuerzo?
No sabr�a decir, pero realmente me parece mucho esfuerzo... Considerando
adem�s los m�ltiples "vendor prefixes"... no s�, creo que casi me
convence m�s lo de generar las animaciones CSS.

[Juan Ignacio Dopazo]

La idea sale de una discusión acerca de la falta de herramientas para diseñadores. Si usar CSS es la "forma web" de hacer animaciones, podríamos pensar en un polyfill.

No me parece que exista. Claramente la parte de las animaciones la delegamos a alguna librería como jQuery y listo. Para encontrar las reglas estaba pensando usar el parser de CSSLint https://github.com/nzakas/parser-lib/blob/master/docs/css.md. Pero parece que no es muy rápido.


Juan

[joseanpg]

En mi anterior intervención sólo hice referencia a la estrategia a
seguir en el análisis del CSS. Juan, insisto en que no sería necesario
un analizador sintactico completo como seguramente será el que has
enlazado. El trabajo pesado vendría en la interpretación de la
cascada.

Pero hay otros aspectos a tener en cuenta:

-----------------------------------------------------------------------------------------------------------------------------------
Requerimientos de coherencia: modificación dinámica de los stylesheet
y elementos style
------------------------------------------------------------------------------------------------------------------------------------
¿Y si desde JavaScript se modifican las `document.styleSheets` o se
"juega" con `document.createElement('STYLE')`? Necesitariamos un
pseudothread que periódicamente fuera comprobando si dichas entidades
han sido modificadas y en caso de que así fuera analizarlas y
aplicarlas. Más trabajo para el browser.

----------------
¿jQuery ?
----------------
¿Estás sugiriendo que la mecánica de los efectos sea delegada en
jQuery?. A ver, es un simple framework, célebre, utilizado por mucha
gente. Vale. Pero me temo que sus capacidades para realizar
animaciones son las que son (ver siguiente apartado).

Además no me parece 'agradable' montar una cosa como la que se esta
planteando para que al final sea tratada como un triste "plujin" de
jQuery.

--------------------------------------------
TRANSFORMers ... ¡avanzad!
--------------------------------------------
Bien, para poder aplicar `transform` necesitariamos crear un para cada
elemento implicado un Canvas cuyo contenido sea replica del elemento
en cuestión. Un reto interesante :)


-----------------------
CONCLUSIÓN
----------------------
Resumiendo: es muuuuuucho trabajo para que en un año quede obsoleto
gracias a la mejora de los navegadores.

[gnz/vnk]

> -----------------------
> CONCLUSI�N
> ----------------------
> Resumiendo: es muuuuuucho trabajo para que en un a�o quede obsoleto

> gracias a la mejora de los navegadores.

Para mi, esta es claramente la conclusi�n. :)

[Valentin Starck]

> --------------------------------------------

> TRANSFORMers ... ¡avanzad!
> --------------------------------------------
> Bien, para poder aplicar `transform` necesitariamos crear un para cada
> elemento implicado un Canvas cuyo contenido sea replica del elemento
> en cuestión. Un reto interesante :)

Interesante pero posible, mirar el caso de html2canvas: http://html2canvas.hertzen.com/

[joseanpg]

Valentín, observo que has captado en toda su plenitud la acepción
implícita en mi "interesante" :)

[Juan Ignacio Dopazo]

On Sunday, October 16, 2011, joseanpg <jose...@gmail.com> wrote:
> -----------------------------------------------------------------------------------------------------------------------------------
> Requerimientos de coherencia: modificación dinámica de los stylesheet
> y elementos style
> ------------------------------------------------------------------------------------------------------------------------------------
> ¿Y si desde JavaScript se modifican las `document.styleSheets` o se
> "juega" con `document.createElement('STYLE')`? Necesitariamos un
> pseudothread que periódicamente fuera comprobando si dichas entidades
> han sido modificadas y en caso de que así fuera analizarlas y
> aplicarlas. Más trabajo para el browser.

Eso no lo había tenido en cuenta. =\

> ----------------
> ¿jQuery ?
> ----------------
> ¿Estás sugiriendo que la mecánica de los efectos sea delegada en
> jQuery?. A ver, es un simple framework, célebre, utilizado por mucha
> gente. Vale. Pero me temo que sus capacidades para realizar
> animaciones son las que son (ver siguiente apartado).

jQuery, YUI, dojo, la que mas te guste o todas. La idea básica era mapear:

  h1 {  
    -moz-animation-duration: 3s;  
    -moz-animation-name: slidein;  
  }  
    
  @-moz-keyframes slidein {  
    from {  
      width: 300%  
    }  
      
    to {  
      width: 100%;  
    }  
  }  

A:

$('h1').css('width', '300%').animate({ width: '100%' }, 3000);

> --------------------------------------------
> TRANSFORMers ... ¡avanzad!
> --------------------------------------------
> Bien, para poder aplicar `transform` necesitariamos crear un para cada
> elemento implicado un Canvas cuyo contenido sea replica del elemento
> en cuestión. Un reto interesante :)

Eso ya es demasiado. Nunca se me cruzo por la cabeza reemplazar todo CSS3 desde JavaScript. Como te muestran por ahí esta html2canvas pero es verdaderamente una locura.

[Andrés Fernández]

Coincido en que no vale la pena el esfuerzo. El camino usado hoy
(detectar si hay soporte css (Modernizr?) y usarlo cuando sea posible
o usar la alternativa javascript en caso contrario me parece lo más
adecuado: http://www.html5rocks.com/en/tutorials/speed/html5/).

El día 16 de octubre de 2011 12:06, Juan Ignacio Dopazo
<dopaz...@gmail.com> escribió:

[Juan Ignacio Dopazo]

On Sunday, October 16, 2011, Andrés Fernández <mobius...@gmail.com> wrote:
> Coincido en que no vale la pena el esfuerzo. El camino usado hoy
> (detectar si hay soporte css (Modernizr?) y usarlo cuando sea posible
> o usar la alternativa javascript en caso contrario me parece lo más
> adecuado: http://www.html5rocks.com/en/tutorials/speed/html5/).

Para nosotros no tiene ningún sentido. Se me ocurrió como herramienta para diseñadores. Harían el CSS, tirarían el script por algún lado y listo.


Juan

[Andrés Fernández]

En ese caso, en mi opinión, el parser debería hacerse con lenguaje de
servidor (he visto con horror proyectos de más de 5000 líneas de css y
no quiero no pensar en lo que pasaría en esos casos) .

El día 16 de octubre de 2011 16:24, Juan Ignacio Dopazo
<dopaz...@gmail.com> escribió:
>
>

[Juan Ignacio Dopazo]

2011/10/16 Andrés Fernández <mobius...@gmail.com>

En ese caso, en mi opinión, el parser debería hacerse con lenguaje de
servidor (he visto con horror proyectos de más de 5000 líneas de css y
no quiero no pensar en lo que pasaría en esos casos) .

Otro muy buen punto. Los CSS tienden a crecer mucho. Justo hoy cruce unos tweets con un Googler sobre el estado de su propuesta de mixins en CSS http://www.xanthir.com/blog/b4Av0.

He visto como expresiones regulares recortan archivos asi de grandes bastante rapido, pero ya suma la complejidad de recortar antes de pasar por el parser. Claramente lo mejor para diseñadores va a seguir siendo que se siga avanzando sobre las herramientas de generacion de contenido como Adobe Edge, Sencha Animator, etc.

Juan

[AltIvan]

> Resumiendo: es muuuuuucho trabajo para que en un año quede obsoleto> gracias a la mejora de los navegadores.

Nos guste o no Internet Explorer 8 va a estar presente al menos por
dos años mas en muchos navegadores. Igualmente Internet Explorer 9 no
soporta muchas de las animaciones CSS3: http://www.the-art-of-web.com/css/css-animation/
(Abrir con IE9 para probar este punto)

La solucion que sugeriria yo es hacerlo trayendo el CSS con una
llamada sincrónica, parsearlo con una expresion regular, y aplicar los
eventos equivalentes (hover = mouseover... en realidad tocaría un
mouseenter tipo jquery).

Las animaciones son la parte facil; CSS3 no saca nada del contexto
original asi que no modifica el DOM por lo que fácilmente puede ser un
objeto con posición absoluta; y la matemática para todas las
animaciones CSS3 ya las saco este tipo: http://gsgd.co.uk/sandbox/jquery/easing/

Yo si creo que hay espacio para este desarrollo e incluso puede llegar
a convertirse en una extension de CSS3; o sea, que los diseñadores no
tuvieran que aprender javascript si no solo pseudo-CSS3 para hacer
animaciones que todavia no estan implementadas en CSS3 (ej:
transformacion de gradientes)

[gnz/vnk]

Nos guste o no Internet Explorer 8 va a estar presente al menos por
dos años mas en muchos navegadores. Igualmente Internet Explorer 9 no
soporta muchas de las animaciones CSS3: http://www.the-art-of-web.com/css/css-animation/

Para mi el problema no está tanto en IExplore como en el soporte general del resto.

Tal como dice el artículo que has enlazado:
> Firefox and Opera now support these transforms with an almost identical syntax - just replace -webkit with -moz or -o

Y para mi la clave es que siendo que necesitas 4 (por lo menos) prefijos diferentes y que en algunas ocasiones la sintaxis -a día de hoy- es sólo "**casi** idéntica", resulta mucho más fácil/productivo/rápido, generar el CSS que parsearlo. (Y ojo, que no digo generarlo en Javascript necesariamente)

Si, esperamos, en un futuro no demasiado lejano se adoptan el estándar sin necesidad de prefijos y con la misma sintaxis, entonces podría ser más razonable tratar de hacer transparente el caso de IExplore y que los diseñadores no tuvieran que aprender a usar un par de cosillas de Javascript (eh.. uh... en fin...). Pero tal como están las cosas hoy, no creo que esto realmente quite carga o ayude demasiado a un diseñador.


Sólo mi opinión, claro :)

gnz/vnk