CSS 3 | pour ou contre les effets de transition ?

Salut tout le monde.

Je viens de me rendre compte qu'il n'y a pas réellement de fil concernant CSS3 ( ou alors je ne l'ai pas trouvé ) donc voilà maintenant c'est fait.

Pour ce qui est des ressources sur le sujet il y a :
- CSS 3 Working Drafts - W3C (en)
- CSS3 . Info - All you ever needed to know about CSS3 (en)

Et pour lancer un "petit" débat : des effets de transition et d'animations seront peut-être intégrés à CSS 3 ( source (en) : New features proposed for CSS - CSS3 . Info ).
Qu'en penser ? Est-ce vraiment le rôle de CSS ? Cela n'empiète-t-il pas sur SMIL ? Si oui devrait-on supprimer SMIL ou les effets dans les CSS ?

Voila j'espère que ce fil sera utile.

Note aux modérateurs : je place dans le bar parce que c'est souvent ici qu'on met les débats et aussi parce que dans le salon CSS on va perdre le fil en deux jours à cause de la fréquentation.

Pas d'avis ? Florent, Benjamin, les autres, même pas un petit mot ?

Hello,

Au premier abord, ce n'est clairement pas le rôle de CSS3 puisque cela relève du comportement et non de la mise en page.

Néanmoins, tout comme les pseudo-classes, cela peut être un raccourci facilitant la tache du développeur.
C'est marrant d'ailleurs, il me semble avoir entendu le même type de propositions pour HTML5, fût un temps, mais je peux me tromper -> Je ne m'y suis pas penché .
Bref, c'est de coutume que de vouloir tendre vers des langages qui font tout (sauf le café )

L'objectif de SMIL, en revanche et d'après ce que je viens de lire, est de permettre l'intégration de contenus multimédias diversifiés (images, sons, textes, vidéo, animations, flux de texte) en les synchronisant afin de permettre la création de présentations multimédias (ce qui dépasse le simple cadre du web) et non seulement d'assurer des effets d'animation, chose qui peut être faite via un langage dynamique comme Javascript (adapté à la tâche).

a écrit :
Néanmoins, tout comme les pseudo-classes, cela peut être un raccourci facilitant la tache du développeur.

Certes. Mais au delà de ça n'est-ce pas pour éviter la mise en place de solutions quelques peu douteuses (peu robustes) en Javascript ?

a écrit :
Au premier abord, ce n'est clairement pas le rôle de CSS3 puisque cela relève du comportement et non de la mise en page.

La frontière entre comportement et présentation dans ce cas me semble très fine ...
Car après tout un comportement peut servir à présenter un certain contenu.

En tout cas un de ces sujets intéressants ou tout le monde n'aura pas le même avis ...

<edit>So wait and see ...</edit>
Modifié par yodaswii (14 Apr 2008 - 14:54)

Bonjour,

Personnellement je suis pour, au moins pour les transitions.
Beaucoup d'effets de transition et d'animations sont dépendants de la présentation, et du dispositif de restitution.

La frontière entre comportement et présentation est parfois ténue, mais ici, il ne s'agit pas vraiment d'un comportement au sens "réaction à l'action de l'utilisateur", mais d'une transition entre deux états.

Je préfère utiliser javascript pour modifier le document lui-même (principalement dans les formulaires), plutôt que sa présentation. Ou alors il faudrait pouvoir lier un script à un medium de la même manière qu'on le fait avec les feuilles de style.

yodaswii a écrit :
n'est-ce pas pour éviter la mise en place de solutions quelques peu douteuses (peu robustes) en Javascript ?

C'est douteux parce qu'on laisse chacun faire sa cuisine...

Mais pourquoi peu robustes ? C'est souvent parce que tel ou tel navigateur n'implémente pas (ou mal) une propriété... et CSS aussi est soumis à cette contrainte.

J'émettais plus l'idée d'un raccourci parce que c'est déjà ce qui se passe avec la pseudo-classe hover. On passe d'un état à un autre sans transition possible mais c'est très facile à mettre en place. En revanche, JS demande un travail légèrement plus verbeux mais permet de le gérer... On gagne en souplesse.

Ces effets de transition permettraient donc de combler ce manque mais n'auraient pas forcément meilleure allure. J'ai tendance à penser qu'ils seraient forcément plus limités puisque bridés d'entrée de jeu.

A vrai dire, ce qui se présente là ressemble fortement à ce qu'on peut retrouver dans Flash et "bizarrement", ce genre de chose... c'est ActionScript qui le gère...

Dans ActionScript, un événement peut être généré par l'animation (via un onClipEvent il me semble) et non plus que par des événements déclenchés par l'utilisateur. Et lorsqu'on regarde ce qui se fait dans les bibliothèques JS, on retrouve la même (les "domready" et autres qui ne dépendent plus de l'utilisateur mais bien de quelquechose qui se déroule en cours d'application...)
Modifié par koala64 (14 Apr 2008 - 16:30)

Même si JavaScript était bien implémenté dans les navigateurs il resterait toujours plus lent que quelque chose de natif au navigateur et à mon avis c'est ce problème de vitesse qui bride le web qui fait que les développeurs verraient bien les transitions dans les CSS ... Après je me trompe peut-être mais c'est ce qu'on entend souvent sur JS, que c'est lent ...

Par rapport à du C, Javascript est lent oui... C'est un langage interprété qui dépend des capacités de l'ordinateur qui se trouve en face et des vitesses de connexion puisqu'on est du côté client... comme CSS... ou encore comme Flash... Celà reste néanmoins suffisant.

Là où CSS va avoir un problème comparé à JS, c'est que toutes les transitions proposées dépendront d'algorithmes pré-établis. En tant que raccourci, ok mais de là à penser que CSS est plus adapté que JS, ça aussi c'est un drôle de raccourci.

Franchement, pour gérer une transition, si je dois faire le choix entre un langage de programmation et un langage de mise en page, j'ai quand même tendance à préférer le premier...

koala64 a écrit :
Là où CSS va avoir un problème comparé à JS, c'est que toutes les transitions proposées dépendront d'algorithmes pré-établis. En tant que raccourci, ok mais de là à penser que CSS est plus adapté que JS, ça aussi c'est un drôle de raccourci.

Pourquoi séparer les deux ? Si les transitions sont implémentées dans CSS elles seront souvent utilisées pour simplifier les scripts JS et à mon avis ils deviendront plus fluides ...

Hello,

Pas d'opinion pour ma part.

Changaco a écrit :
Pourquoi séparer les deux ? Si les transitions sont implémentées dans CSS elles seront souvent utilisées pour simplifier les scripts JS et à mon avis ils deviendront plus fluides ...

Il faut voir ce qu'on entend par fluide... Une animation basée sur le temps et non sur l'incrémentation d'un compteur apparait comme fluide pour nos yeux.

Les points bloquants peuvent être :

- une connexion dégradée ce qui fait que le temps de chargement de départ va être long... CSS serait soumis aux mêmes contraintes puisque ça passe par le même tuyau...

- un ralentissement de l'ordinateur sur lequel est éxécuté le script... ça, on n'y peut pas grand chose.

- le développeur qui n'a pas optimisé son script... Il y a, bien évidemment, plus de chance que ça arrive lorsqu'on n'est pas pro du langage.

PS : Je ne dis pas être pour ou contre cette implémentation (ce qui me dépasse un peu quand même) mais simplement qu'il y a peu de chance que je passe par CSS...
Modifié par koala64 (14 Apr 2008 - 20:04)

j'attends de voir ce qu'il en sera vraiment et surtout ce qu'en feront nos amis webmaster.

Ce qui m'intéresse surtout c'est de faire des jolies pages lisibles. Donc pas trop d'avis, ce sera certainement un gros plus pour certains sites et un gros moins pour le reste.

Le langages css est plutôt simple si on laisse de côté les différences entres browser, du coup, on peut se poser la question des bienfaits de telles propriétés qui ne visent pas vraiment à améliorer le langage en lui même mais plutôt à l'étendre.

je suis favorable à la séparation des différents langages. Plus on sépare moins c'est le bordel et ça permet aux utilisateurs de désactiver les parties qui les dérangent.

bzh a écrit :
j'attends de voir ce qu'il en sera vraiment et surtout ce qu'en feront nos amis webmaster.

En même temps c'est aussi à nous, webmasters, de dire ce que l'on veut ...

bzh a écrit :
je suis favorable à la séparation des différents langages. Plus on sépare moins c'est le bordel et ça permet aux utilisateurs de désactiver les parties qui les dérangent.

Je dirais plus que ça permet aux geeks de désactiver ce qu'ils veulent, l'utilisateur lambda il y connaît rien ... De plus l'idée a déjà été évoquée de rajouter des options dans les navigateurs permettant de désactiver les effets de transitions CSS.

Au final la question est toujours la même, est-ce le rôle des CSS de s'occuper des transitions ? À part le fait de voir fleurir des sites avec des effets de partout au chargement d'une page je ne vois pas vraiment d'inconvénients ... ( J'imagine déjà la "CSS Transitions Toolbar" permettant de désactiver/activer les effets de transition site par site. )

koala64 a écrit :
Il faut voir ce qu'on entend par fluide... Une animation basée sur le temps et non sur l'incrémentation d'un compteur apparaît comme fluide pour nos yeux.

Les points bloquants peuvent être :

- une connexion dégradée ce qui fait que le temps de chargement de départ va être long... CSS serait soumis aux mêmes contraintes puisque ça passe par le même tuyau...

- un ralentissement de l'ordinateur sur lequel est exécuté le script... ça, on n'y peut pas grand chose.

- le développeur qui n'a pas optimisé son script... Il y a, bien évidemment, plus de chance que ça arrive lorsqu'on n'est pas pro du langage.

[quote=koala64]PS : Je ne dis pas être pour ou contre cette implémentation (ce qui me dépasse un peu quand même) mais simplement qu'il y a peu de chance que je passe par CSS...

Moi j'imagine très bien un script du style :

unDiv.style.transition="effet temps etc";
unDiv.style.display="block";

Deux lignes de codes au lieu d'une fonction qui change la position constamment moi ça me paraît pas mal, non ?
Et si c'est plus léger ça va plus vite pour le télécharger et si encore en plus c'est bien optimisé dans le navigateur ça prends moins de ressources à l'exécution ... Certes ça fait beaucoup de "si" mais bon il faut garder espoir.

Changaco a écrit :
En même temps c'est aussi à nous, webmasters, de dire ce que l'on veut ...

il faut surtout comprendre ce que l'utilisateur veux :
-des mises en pages fixes
-des sites qui remuent

pour un site commercial, il est indéniable qu'un site avec des éléments animés ça en jette mais du point de vue de la lisibilité et de l'ergonomie... Sans compter que dans les "websmaster", il y a de tout donc les dérives dans l'utilisation de ce genre de propriétés seront certainement nombreuses.

Changaco a écrit :
Je dirais plus que ça permet aux geeks de désactiver ce qu'ils veulent, l'utilisateur lambda il y connaît rien ... De plus l'idée a déjà été évoquée de rajouter des options dans les navigateurs permettant de désactiver les effets de transitions CSS.

donc des options qui ne serviraient à rien? L'utilisateur lambda n'a généralement pas besoin de plus de chose que d'agrandir la police dans son navigateur. C'est surtout pour ceux qui peuvent éprouver de grosse gènes que je dis ça.

mais bon j'attends de voir de quoi seront faites les css demain, combien de temps les navigateur mettront a les prendre correctement en compte et y a le temps

bzh a écrit :
mais bon j'attends de voir de quoi seront faites les css demain, combien de temps les navigateur mettront a les prendre correctement en compte et y a le temps

Vu comment ça bouge du côté de chez Microsoft ( et pour ça on peut remercier Mozilla ) je pense que pour le coup c'est les navigateurs qui vont finir par attendre le W3C et non plus l'inverse ...

A ma connaissance il y a peu d'exemples où les navigateurs ont attendu le W3C... C'est plutôt l'inverse, W3C vient souvent valider tel ou tel choix proposé par untel ou untel. Voir WHATWG par exemple qui a fini par faire "plier" W3C l'an dernier.
Modifié par Arsene (15 Apr 2008 - 09:46)

Arsene a écrit :
A ma connaissance il y a peu d'exemples où les navigateurs ont attendu le W3C... C'est plutôt l'inverse, W3C vient souvent valider tel ou tel choix proposé par untel ou untel.

C'est un peu ce que je voulais dire, par exemple pour le sujet qui nous intéresse ça a été implémenté dans Webkit puis intégré par le W3C donc c'est bien le navigateur qui a de l'avance donc on peut dire que c'est le navigateur qui attend le W3C et non l'inverse ...

Bah, les deux sont vrais.

Aucun navigateur n'a une implémentation complète de CSS 2.1 ou même d'HTML 4.01, sauf erreur de ma part.

L'idée semble intéressante, la seule chose qui me fait un peu douter c'est la qualité de ces animations.

Dire que ce serat forcement plus robuste que javascript c'est peut être vite dit.

En effet on regarde la tentative d'intégration de la propriété border-radius ça fait peur! je préféré encore les bidouilles mutlidiv, multi <b>, ou même les "round corners" javascript.

Si on regarde de prés le document on voit que pour l'initialiser il faut quand même un bon bout de code :

div {
  animation-name: 'diagonal-slide';
  animation-duration: 5s;
  animation-iteration-count: 10;
}

@keyframes 'diagonal-slide' {
  
  from {
    left: 0;
    top: 0;
  }

  to {
    left: 100px;
    top: 100px;
  }
  
}

si on compare avec une transition réalisé avec un bon framework comme mootools :

var fx = new Fx.Styles( 'diagonal-slide', {
   duration: 1000, 
  transition: Fx.Transitions.Quad.easeInOut
});

fx.start({
   'left': 100,
   'top': 100
});

Je triche un peu parce que mon exemple suppose que les style initiaux soit spécifier dans la feuille de style pour que l'on puisse réellement comparer. Toujours est il que ce n'est pas beaucoup plus compliqué d'utilisation.

Par contre et c'est la ou je voulais en venir on a beaucoup plus de possibilité parce qu'on peux choisir entre une palette plus riche d'effet de transitions (voir http://demos.mootools.net/Fx.Transitions ).

Sur le principe séparation présentation / comportement je ne vois pas trop le problème parce qu'un effet sur un menu peut très bien être considéré comme de la présentation.

<edit>Il y a quand même un truc sympa qui est quasi impossible a faire aujourd'hui c'est la propriété "rotate" </edit>
Modifié par matmat (15 Apr 2008 - 22:02)