Ça fait deux posts où tu dis que le SVG ne permet qu'un dixième de ce que permet Flash, moi j'aimerais bien savoir ce que contiennent ces 9/10e, en dehors de la vidéo. J'espérais un peu en te répondant que tu donnerais des détails, mais non...
Je suis peut-être un libriste pas réaliste mais, aujourd'hui, pour tous les cas où moi je peux avoir besoin de Flash, je sais faire la même chose en XHTML+SVG+Javascript. D'autre part, je ne considère pas que mélanger plusieurs sous-ensembles de XML dans un même document soit "usine à gaz", dans la mesure où ces langages ont été conçus dans cet objectif. Finalement la seule chose qui pourrait m'inciter à choisir Flash est le manque de support de SVG dans IE et la lenteur des implémentations des autres navigateurs.
Mon expérience (pas réaliste) avec le SVG a consisté comme je l'expliquais plus haut à inclure des plans (de bâtiment) dans une interface web et à modifier des parties de ces plans en fonctions des actions de l'utilisateur dans le reste de l'interface et d'évènements externes. On a fait ça avec Rails. L'intégration d'un plan s'est faite en 15 secondes (prendre le fichier généré par Inskcape, le mettre dans le bon dossier et le renommer en .rxml). À partir du moment où le plan est une vue comme une autre, on peut y inclure du code Ruby comme dans du XHTML, donc par exemple on peut trivialement obtenir un contrôleur qui permet de zoomer/tourner le document SVG à partir des paramètres GET/POST.
Ensuite, il ne reste plus qu'à écrire les fonctions de Javascript dont on a besoin, et le tour est joué.
Je ne sais pas faire la même chose avec Flash, donc je ne peux pas comparer la difficulté, mais ce que je sais, c'est que:
- Flash est typiquement l'outil qu'on aurait utilisé il y a 5 ans pour faire ça
- Manipuler du SVG ne demande quasiment aucun apprentissage si on sait manipuler du XHTML
- Tout le monde dans ma boîte a été impressioné par la rapidité avec laquelle l'intégration du plan s'est faite. On savait que c'était possible, pas que c'était aussi simple.
[^] # Re: SVG n'est pas un concurent de Flash
Posté par Yusei (Mastodon) . En réponse au journal Le SVG peut-il remplacer le flash ??. Évalué à 5.
Je suis peut-être un libriste pas réaliste mais, aujourd'hui, pour tous les cas où moi je peux avoir besoin de Flash, je sais faire la même chose en XHTML+SVG+Javascript. D'autre part, je ne considère pas que mélanger plusieurs sous-ensembles de XML dans un même document soit "usine à gaz", dans la mesure où ces langages ont été conçus dans cet objectif. Finalement la seule chose qui pourrait m'inciter à choisir Flash est le manque de support de SVG dans IE et la lenteur des implémentations des autres navigateurs.
Mon expérience (pas réaliste) avec le SVG a consisté comme je l'expliquais plus haut à inclure des plans (de bâtiment) dans une interface web et à modifier des parties de ces plans en fonctions des actions de l'utilisateur dans le reste de l'interface et d'évènements externes. On a fait ça avec Rails. L'intégration d'un plan s'est faite en 15 secondes (prendre le fichier généré par Inskcape, le mettre dans le bon dossier et le renommer en .rxml). À partir du moment où le plan est une vue comme une autre, on peut y inclure du code Ruby comme dans du XHTML, donc par exemple on peut trivialement obtenir un contrôleur qui permet de zoomer/tourner le document SVG à partir des paramètres GET/POST.
Ensuite, il ne reste plus qu'à écrire les fonctions de Javascript dont on a besoin, et le tour est joué.
Je ne sais pas faire la même chose avec Flash, donc je ne peux pas comparer la difficulté, mais ce que je sais, c'est que:
- Flash est typiquement l'outil qu'on aurait utilisé il y a 5 ans pour faire ça
- Manipuler du SVG ne demande quasiment aucun apprentissage si on sait manipuler du XHTML
- Tout le monde dans ma boîte a été impressioné par la rapidité avec laquelle l'intégration du plan s'est faite. On savait que c'était possible, pas que c'était aussi simple.
Et en prime, ça tourne sans plugin dans FF ;-)