zardoz a écrit :
Le problème réside dans le fait qu'on rattache tout ça à HTML5 alors que c'est programmer en javascript pour la plupart des jeux. Mais il y fort longtemps que javascript peut faire animation.
On programme en JavaScript mais c'est l'API HTML5 (canvas et son API font partie de HTML5 et pas de JavaScript). Exactement comme en Flash il y a un moteur d'affichage et un langage de programmation (l'ActionScript).
Oui et je vais m'y interresser davantage à cette API.
J'avoue que j'ai pas toute connaissance de HTML5 mais je ne suis pas trop éloigner non plus.
Ce que je trouve bizarre c'est de renier une technologie au dépand d'une autre. Espérer voir Flash mourrir. Espérer voir IE mourrir.
C'est comme renier le rectangle aux coins 90° parce que CSS3 offre des coins arrondis comme possibilité. Le rectangle classique và donc mourrir aussi.
Seulement les coins arrondis on connaît depuis longtemps quand même. Via Flash ou SVG.
D'accord pour l'API je vérifie, j'y suis interresser. Thank.
..
J'avoue que j'ai pas toute connaissance de HTML5 mais je ne suis pas trop éloigner non plus.
Ce que je trouve bizarre c'est de renier une technologie au dépand d'une autre. Espérer voir Flash mourrir. Espérer voir IE mourrir.
C'est comme renier le rectangle aux coins 90° parce que CSS3 offre des coins arrondis comme possibilité. Le rectangle classique và donc mourrir aussi.
Seulement les coins arrondis on connaît depuis longtemps quand même. Via Flash ou SVG.
D'accord pour l'API je vérifie, j'y suis interresser. Thank.
..
zardoz a écrit :
Quoi de new ? - rien.
- Les éléments ne sont plus engobés dans un plug-in, il font partie de la page HTML directement et il peuvent interagir les uns avec les autres (et ça c'est une révolution et Flash ne permettra jamais de le faire).
- Avoir un standard libre et ouvert pour faire ce qu'on faisait avec un plug-in dépendant d'une société privé.
Je sais pas si tu as vu WebGL aussi, c'est une API basé sur OpenGL qui permet de faire de la 3D en temps directement dans un élément Canvas.
Une démo sympa :
http://madebyevan.com/webgl-water/
Et une autre :
http://googlewebtoolkit.blogspot.com/2010/04/look-ma-no-plugin.html
Modifié par jb_gfx (27 Aug 2011 - 01:07)
Une démo sympa :
http://madebyevan.com/webgl-water/
Et une autre :
http://googlewebtoolkit.blogspot.com/2010/04/look-ma-no-plugin.html
Modifié par jb_gfx (27 Aug 2011 - 01:07)
Tony Monast a écrit :
Ma réponse est non.
Évident. Ne serait-ce que pour garantir l’accès aux anciens sites, Flash sera toujours là.
Ce sera comme le support des anciennes versions de HTML et le Quirks Mode, ce ne sera plus un choix pour les nouvelles initiatives, mais ce sera toujours là, … pour l’éternité
En arrivant sur certains site, on peut aujourd'hui se dire «c’est amusant, il utilise des balise FONT», il n’y avait pas encore le CSS à l’époque de ce site. On pourra se dire «c’est amusant, il utilise Flash, il ne savait pas que JavaScript existait ou alors HTML5 n’existait pas encore».
jb_gfx a écrit :
Je sais pas si tu as vu WebGL aussi, c'est une API basé sur OpenGL qui permet de faire de la 3D en temps directement dans un élément Canvas.
Yes sir : Thank for this. C'est sûr que je vais allez voir.
@jmlapam : en effet tout est facultatif. Mais j'apprécie quand même les efforts du W3C que j'ai toujours respecter. Mais jamais je vais renier Flash, jamais.
..
Une démo : http://videos.mozilla.org/serv/mozhacks/flight-of-the-navigator/
Il y en a plein d'autres sur le site de Mozilla.
Sinon le support de webm est prévu dans flash également.
Il y en a plein d'autres sur le site de Mozilla.
Sinon le support de webm est prévu dans flash également.
@jmlapam » HTML5 Canvas : Asteroids
Bon j'avoue le manque de puissance et toujours loin de la beauté Flash en matière de jeu.
Seulement 2 points peuvent être retenus ici »
1 ) Une techologie nouvelle est toujours évolutive.
2 ) Tout dépend aussi de la capacité du développeur en programmation (performances).
On est loin de la fluidité en Flash mais quoiqu'il en soit certains points resteront quand même intéressants.
Celui-ci a été créer en 2005 » Canvascape avec un demo sous texture. Ou encore Torus
Faut admettre y'a du bon. Sans compter que dans l'avenir certains développeurs sauront nous surprendre.
Par contre en AS3 la notion des packages et des namespaces nous offrent une bien meilleur organisation du code (POO), que nous ne retrouverons pas en HTML5. Et ce point est un plus pour Flash. Oublions les packages en API HTML5. D'ailleur je ne sais pas si l'API HTML5 traite même des namespaces. Je verrai plus tard.
Les namespaces sont l'équivalent des packages, pour l'organisation des codes. Par le fait même, c'est pour éviter les collisions de variables, de nom de fonctions et/ou de nom de méthodes de classes. Les packages sont indispensables en programmation et nous l'avons en AS3.
Javascript assurément accuse un retard à ce niveau tout comme PHP d'ailleurs. Ce sont pourtant des langages objets (qui dit objet dit organisation). Il doit en être ainsi de l'API HTML5, avec un risque important de scripts non organisés. Les bibliothèques et les frameworks offrirons une facilité en utilisation pour les développeurs, mais n'ont rien à voir avec l'organisation des scripts personnelles.
Sans compter les risque de popularité (c'est déjà commencé), la notion de package et/ou namespaces devrait être utile. On ne parle plus de fonctionnalité ici, mais d'animation, de jeux, d'application web (formulaires ou autres), sous canvas, et j'en passe.
Ouf ! » un dernier ? Spirograph
..
Modifié par zardoz (27 Aug 2011 - 19:27)
Bon j'avoue le manque de puissance et toujours loin de la beauté Flash en matière de jeu.
Seulement 2 points peuvent être retenus ici »
1 ) Une techologie nouvelle est toujours évolutive.
2 ) Tout dépend aussi de la capacité du développeur en programmation (performances).
On est loin de la fluidité en Flash mais quoiqu'il en soit certains points resteront quand même intéressants.
Celui-ci a été créer en 2005 » Canvascape avec un demo sous texture. Ou encore Torus
Faut admettre y'a du bon. Sans compter que dans l'avenir certains développeurs sauront nous surprendre.
Par contre en AS3 la notion des packages et des namespaces nous offrent une bien meilleur organisation du code (POO), que nous ne retrouverons pas en HTML5. Et ce point est un plus pour Flash. Oublions les packages en API HTML5. D'ailleur je ne sais pas si l'API HTML5 traite même des namespaces. Je verrai plus tard.
Les namespaces sont l'équivalent des packages, pour l'organisation des codes. Par le fait même, c'est pour éviter les collisions de variables, de nom de fonctions et/ou de nom de méthodes de classes. Les packages sont indispensables en programmation et nous l'avons en AS3.
Javascript assurément accuse un retard à ce niveau tout comme PHP d'ailleurs. Ce sont pourtant des langages objets (qui dit objet dit organisation). Il doit en être ainsi de l'API HTML5, avec un risque important de scripts non organisés. Les bibliothèques et les frameworks offrirons une facilité en utilisation pour les développeurs, mais n'ont rien à voir avec l'organisation des scripts personnelles.
Sans compter les risque de popularité (c'est déjà commencé), la notion de package et/ou namespaces devrait être utile. On ne parle plus de fonctionnalité ici, mais d'animation, de jeux, d'application web (formulaires ou autres), sous canvas, et j'en passe.
Ouf ! » un dernier ? Spirograph
..
Modifié par zardoz (27 Aug 2011 - 19:27)
C'est déjà mieux cela asteroids...
Je suis tellement fan des jeux flash qu'il faudra un max de qualité pour me les faire quitter...
Jb a peut-être déjà répondu mais y a moyen de rendre moins copiable les animations hml5?
Je sais qu'avec flash on peut y arriver mais c'est déjà moins à la portée de tout le monde... 
Je suis tellement fan des jeux flash qu'il faudra un max de qualité pour me les faire quitter...
Jb a peut-être déjà répondu mais y a moyen de rendre moins copiable les animations hml5?
Je sais qu'avec flash on peut y arriver mais c'est déjà moins à la portée de tout le monde... Je sui entièrement d'accord avec toi question sécurité. Avec HTML5 et canvas, on est encore loin de Flash AS3. Et sur bien des points techniques. Dont la sécurité. De plus la question de sécurité, ce n'est pas pour demain en HTML5 et canvas. Peut-être même jamais.
Ne sois surpris ici que la plupart des expériences en animation en HTML5 se tourneront vers du déjà vu, du déjà expérimenté en Flash. Peuvent-ils réinventé ? - non sûrement pas. La plupart des expériences ont des tendances à vouloir hisser le HTML5 et canvas à la hauteur de Flash (on veut tuer Flash), mais techniquement, ils en sont loin, et très loin. De même en JQuery avec les caroussels, les parallaxes, ne serait-ce que les sliders ou autres fantaisies. C'est du déjà vu.
Exemple d'une animation réactive au pointeur : Warfield.
Cependant, comme déjà citer plus haut, le développeur joue un rôle de pointe. Faut savoir programmer pour faire animation et performance à la fois. Ce qui n'est pas le cas dans le dernier exemple. Des fautes décisionnelles importantes dont la dimension. Le réactif est tout simplement affreux, aucune fluidité. Avec un temps de réponse retardé.
..
Ne sois surpris ici que la plupart des expériences en animation en HTML5 se tourneront vers du déjà vu, du déjà expérimenté en Flash. Peuvent-ils réinventé ? - non sûrement pas. La plupart des expériences ont des tendances à vouloir hisser le HTML5 et canvas à la hauteur de Flash (on veut tuer Flash), mais techniquement, ils en sont loin, et très loin. De même en JQuery avec les caroussels, les parallaxes, ne serait-ce que les sliders ou autres fantaisies. C'est du déjà vu.
Exemple d'une animation réactive au pointeur : Warfield.
Cependant, comme déjà citer plus haut, le développeur joue un rôle de pointe. Faut savoir programmer pour faire animation et performance à la fois. Ce qui n'est pas le cas dans le dernier exemple. Des fautes décisionnelles importantes dont la dimension. Le réactif est tout simplement affreux, aucune fluidité. Avec un temps de réponse retardé.
..
Bah moi le côté sécurité, je trouve cela inacceptable pour des appli web, et aussi pour la vidéo et l'audio. YouTube est mal dans ce cas là.
Sinon je suis d'accord avec toi y a du chemin... flash est bien plus inspirant... et techniquement mieux adapté surtout la version cs5, mais même cs3 est au-dessus.
Sinon je suis d'accord avec toi y a du chemin... flash est bien plus inspirant... et techniquement mieux adapté surtout la version cs5, mais même cs3 est au-dessus.
Ce n'est pas le logiciel qui compte ici mais le niveau de langage : AS1 AS2 ou AS3.
Et je peux même te dire que peut importe le niveau de langage, y compris AS1, Flash est de loin beaucoup plus puissant que HTML5 et canvas.
Mais même en terme logiciel (CS3 +), pour ceux et celles qui ne développerons qu'en scénario, que sur la Timeline, avec peu de programmation, Flash restera « The best ».
Une particularité de Flash, que l'on programme à 100%, ou qu'on développe sur la Timeline (scénario), celui-ci exigera un très bon raisonnement, une bonne organisation (de laTimeline et/ou des programmes à exécuter) en développement d'application.
Mais Flash (le logiciel) est conçu dans ce sens, avec une pédagogie (Adobe) de pointe. De même avec la programmation AS2 et AS3.
En dehors du W3C, en ce qui concerne HTML5 et canvas, et à partir des démos c'est : télécharger la source. On favorise le copier/coller. Mais rien en pédagogie. Prend gratuit, et bonne chance.
..
Modifié par zardoz (27 Aug 2011 - 21:43)
Et je peux même te dire que peut importe le niveau de langage, y compris AS1, Flash est de loin beaucoup plus puissant que HTML5 et canvas.
Mais même en terme logiciel (CS3 +), pour ceux et celles qui ne développerons qu'en scénario, que sur la Timeline, avec peu de programmation, Flash restera « The best ».
Une particularité de Flash, que l'on programme à 100%, ou qu'on développe sur la Timeline (scénario), celui-ci exigera un très bon raisonnement, une bonne organisation (de laTimeline et/ou des programmes à exécuter) en développement d'application.
Mais Flash (le logiciel) est conçu dans ce sens, avec une pédagogie (Adobe) de pointe. De même avec la programmation AS2 et AS3.
En dehors du W3C, en ce qui concerne HTML5 et canvas, et à partir des démos c'est : télécharger la source. On favorise le copier/coller. Mais rien en pédagogie. Prend gratuit, et bonne chance.
..
Modifié par zardoz (27 Aug 2011 - 21:43)
Le copier-coller, donc n'importe qui s'attribue n'importe quoi, pourquoi pas à des fin commerciales 
donc un coup en plus au droit d'auteur.
EDIT: oui tu as raison c'est AS qui importe, je parle du logiciel parce qu' est vraiment bien fait aussi bien pour le pro que l'amateur..
Modifié par jmlapam (27 Aug 2011 - 21:25)
donc un coup en plus au droit d'auteur.EDIT: oui tu as raison c'est AS qui importe, je parle du logiciel parce qu' est vraiment bien fait aussi bien pour le pro que l'amateur..
Modifié par jmlapam (27 Aug 2011 - 21:25)
C'est exacte. Mais c'est HTML donc on pardonne. Côté client.
Pour ce qui est de Flash quand on parle de sécurité, nous ne parlons pas de voler des oeuvres d'auteurs mais de cette impossibilté de modifier une oeuvre par programmation.
En exemple lorsque tu importe un Lecteur Flash (distant) dans un autre, nous ne pouvons pas modifier quoique ce soit, pas même la dimension du Lecteur Flash importer, ni atteindre aucune propriété ou méthode par programmation.
Sauf si un climat de confiance (crossdomain.xml) est établi entre le Lecteur d'importation et le Lecteur importer. Même chose en local, sauf que le fichier xml n'est pas nécessaire. Nous devons utilisé des classes en Flash comme LoaderInfo (et plusieurs autres) pour avoir accès à la modification d'objet importer (donc communication entre les objets Flash).
Mais en HTML5 il ne faut surtout pas rêver qu'un jour la sécurité des oeuvres sera complète.
PS : D'accord aussi pour les logiciels de Adobe CS3 et plus. Ce sont de solides logiciels fait par des pros, et pour des pros. Et comme tu le dit si bien, accèssibles aux amateurs. C'est payant comme logiciels seulement faut comprendre toute la structure de prise en main de ces logiciels (pdf ou en ligne). Adobe ne recule pas en ce qui concerne la pédagogie, tant pour les logiciels que les niveaux de langages.
Adobe c'est 2 frères intellectuels, puis ils savent où ils sont rendu avec leur produits. Ils connaissent les besoins de leurs clients, et les prennent en considérations.
..
Modifié par zardoz (27 Aug 2011 - 23:04)
Pour ce qui est de Flash quand on parle de sécurité, nous ne parlons pas de voler des oeuvres d'auteurs mais de cette impossibilté de modifier une oeuvre par programmation.
En exemple lorsque tu importe un Lecteur Flash (distant) dans un autre, nous ne pouvons pas modifier quoique ce soit, pas même la dimension du Lecteur Flash importer, ni atteindre aucune propriété ou méthode par programmation.
Sauf si un climat de confiance (crossdomain.xml) est établi entre le Lecteur d'importation et le Lecteur importer. Même chose en local, sauf que le fichier xml n'est pas nécessaire. Nous devons utilisé des classes en Flash comme LoaderInfo (et plusieurs autres) pour avoir accès à la modification d'objet importer (donc communication entre les objets Flash).
Mais en HTML5 il ne faut surtout pas rêver qu'un jour la sécurité des oeuvres sera complète.
PS : D'accord aussi pour les logiciels de Adobe CS3 et plus. Ce sont de solides logiciels fait par des pros, et pour des pros. Et comme tu le dit si bien, accèssibles aux amateurs. C'est payant comme logiciels seulement faut comprendre toute la structure de prise en main de ces logiciels (pdf ou en ligne). Adobe ne recule pas en ce qui concerne la pédagogie, tant pour les logiciels que les niveaux de langages.
Adobe c'est 2 frères intellectuels, puis ils savent où ils sont rendu avec leur produits. Ils connaissent les besoins de leurs clients, et les prennent en considérations.
..
Modifié par zardoz (27 Aug 2011 - 23:04)
De même pour moi.
En ne rejetant aucune technologie on laisse porte ouverte à sa propre évolution.
Pour ce qui est des modifications d'objets Flash importer, je ne le fais que via mes travaux personnels, ou encore lorsque c'est négocié avec des travaux d'autres auteurs. De là le fichier de régulation crossdomain.xml qui établi un climat de confiance.
Dans l'exemple ici » crossdomain.xml, j'autorise à tous de modifier par programme l'importation d'un objet Flash distant. Encore faut-il négocié puisque nul ne sais mes travaux Flash distant. Mais je pourrais très bien distribuer les cibles Flash à importer à quiquonque désire partager des oeuvres et vise versa.
C'est bien que tu ne rejette aucune technologie. Pour ma part je crois HTML et CSS suffisant pour communiquer (c'est d'ailleurs ce que je fais maintenant) simplement. Sinon quelques technologies nouvelles ajoutées intelligemment ne fait pas de mal non plus.
On apprend, on s'améliore, on avance tranquillement.
..
Modifié par zardoz (28 Aug 2011 - 23:28)
En ne rejetant aucune technologie on laisse porte ouverte à sa propre évolution.
Pour ce qui est des modifications d'objets Flash importer, je ne le fais que via mes travaux personnels, ou encore lorsque c'est négocié avec des travaux d'autres auteurs. De là le fichier de régulation crossdomain.xml qui établi un climat de confiance.
Dans l'exemple ici » crossdomain.xml, j'autorise à tous de modifier par programme l'importation d'un objet Flash distant. Encore faut-il négocié puisque nul ne sais mes travaux Flash distant. Mais je pourrais très bien distribuer les cibles Flash à importer à quiquonque désire partager des oeuvres et vise versa.
C'est bien que tu ne rejette aucune technologie. Pour ma part je crois HTML et CSS suffisant pour communiquer (c'est d'ailleurs ce que je fais maintenant) simplement. Sinon quelques technologies nouvelles ajoutées intelligemment ne fait pas de mal non plus.
On apprend, on s'améliore, on avance tranquillement.
..
Modifié par zardoz (28 Aug 2011 - 23:28)