Impossible de lire le fichier video. Avec kaffeine, j'ai apparement du son (un bruit de rue) mais image noire. Avec d'autres, (VLC, Mplayer...), ça les fait carrément planté..
Quel est le codec à utiliser ? À moins que ce soit encore un vidéo dans un format propriétaire à peine supporté par les codecs libres ?
quand ils passeront à XulRunner 1.9.1/Firefox 3.1, z'auront plus besoin de faire ça :-) (enfin, pour les videos ogg en tout cas, pas sûr que le backend gstreamer soit inclus à temps)
Et sinon, quand ils passeront à XulRunner 1.9.2/Firefox 3.2 (pas sûr du numéro de version), ils pourront faire du SMIL pour les animations/présentations, plutôt que faire du Flash :-)
Et pour ceux qui n'aiment pas S5 (parce que c'est plutôt lent et lourd, sous Firefox en tout cas), il y a la possibilité de faire des pages HTML toute con, avec quelques classes bien placées (et que tu choisi), et tu installes l'extension FullerScreen pour Firefox, et c'est tout.
En plus, ça gère le media projection, et donc tu peux donner une apparence différente entre la visualisation traditionnelle et la visualisation en projection. Ça pourrait très bien être une page "normale" d'un site (donc c'est lisible "normalement", contrairement à S5, et par tout navigateur, même des vieux trucs), et quand on la met en projection, on vire par CSS les menus, entetes, tout ce qu'on ne veut pas en projection quoi, et avec un design adapté :-)
Et puis FullerScreen inclus un "navigateur" pour aller directement à une diapo donnée, en affichant une liste des screenshots de ces diapos. (merci la balise canvas)
ouuuhh là... Tu devrais te renseigner sur ce qu'on fait en PHP. Juste un exemple parce que je connais des devs de ces deux sites : les deux plus grosses plateformes de blogs françaises sont en PHP. (oui oui, une plateforme de blog, c'est une grosse appli, voir complexe, parce que cela doit apporter plein de fonctionnalités d'une part, mais aussi répondre à d'énormes contraintes comme la charge d'autre part)
Et je ne parle pas d'autres gros sites comme tf1, libé, lemonde.fr et cie.. Tous en PHP. Je pense ne pas me tromper en disant que parmis le top 10 des gros sites en france, la grande majorité sont en PHP.
Et je ne parle pas non plus de toutes ces applis métiers, intranet, complexes à souhait, en PHP (là c'est mon expérience qui parle).
>Le php de par sa nature bordelique et scriptee, non typee etc me parait une heresie pour developper une grosse appli.
Un peu de rigueur, de la programmation objet, et ça roule. Des applis propres en PHP, ça existent, et de plus en plus, grâce à l'utilisation de frameworks notamment, et à la "professionnalisation" des devs PHP.
En java, on peut en faire aussi du code très crade.
> Mais avant de pouvoir envoyer des données au serveur, le navigateur doit d'abord afficher un formulaire à l'utilisateur. Ce formulaire peut être vu comme une représentation de la ressource à modifier, au même titre que du HTML simple.
Pourquoi faudrait-il absolument un formulaire ?
Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.
1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables
Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.
Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.
Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.
Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefoxhttp://developer.mozilla.org/en/Online_and_offline_events
Amaya aussi permet l'édition de pages distantes et sait faire du PUT, DELETE et cie.
>Après, il reste le problème de l'autorisation de modification de ressources Web ...
Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..
M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.
Avoir une somme de contrôle correspondant à un fichier, c'est bien, mais il faut avoir le fichier pour calculer la somme et la comparer avec celle que l'on a récupéré, pour savoir si le fichier corresponds. Donc il faut nécessairement télécharger le fichier.
Je n'ai pas dit que la AGPL interdisait d'apporter des modifications.
Ce que j'en ai compris de la AGPL :
- tu dois fournir les sources à tout les utilisateurs de l'appli web
- si tu fais des modifs, tu dois aussi les fournir
Ce qui veut dire que tout utilisateur de la boite, doit avoir accès aux sources, et donc même aux modifications qui pourrait concerner la gestion de données spécifiques et sensibles. Donc même aux utilisateurs qui ne sont pas habilités à connaître la présence/la gestion de ces données sensibles, car n'ayant pas de rapport avec eux ou le service dans lequel ils travaillent.
Si ce que j'ai compris est bon, je trouve donc ça très moyen de mettre un tel logiciel sous AGPL.
Pas besoin d'une imprimante. Faut juste que tu branches un distributeur de billet sur ton laptop, via une prise USB, et un plugin flash gère la communication entre le navigateur et le distributeur.
C'est pourtant simple !!
Oui bon, faut se déplacer pour être à coté d'un distributeur de billet...
Mais il parait qu'ils vont améliorer ça, et bientôt les distributeurs pourront communiquer par wifi (parce que bon, se balader avec un cordon usb, c'est pas cool..).
Certains disent d'ailleurs qu'un jour peut-être, on n'aura plus besoin de prendre son laptop pour retirer de l'argent à un distributeur. Mouarf, y en a qui rêve quand même...
je trouve ça plutôt con, pour un logiciel utilisé en entreprise. Car cela veut dire que la boite ne peut pas apporter des modifications qui seraient propre à son fonctionnement, et donc des modifs qui ne sont pas forcément intéressantes pour les autres, encore moins si il s'agit de choses confidentielles.
Ah ouai ? et y a que ça à photographier en France ??? Arrête la mauvaise foi...
Si quelqu'un veut faire partager une photo d'un petit monument de son bled, ou même des fleurs de son jardin, il a 99% de chances que la carte openstreetmap n'a pas de plan du coin photographié.
Je ne dénigre absolument pas le travail remarquable fait par les contributeurs à OpenStreetMap, mais en toute franchise, je ne pense pas que ce soit utilisable en l'état pour une application comme Vision2pixels..
qu'est ce qu'on a à fiche de la somme de contrôle ici ? Le fichier a déjà été téléchargé avant de pouvoir vérifier cette somme. Et donc tu es déjà dans "l'illégalité" pour détention d'un fichier illicite.
(je dis pas qu'il faut pas vérifier la somme de contrôle hein... mais bon, dans le contexte...)
Ça serait une chouette idée, mais c'est pas gagné. Apparement, le méthane semble se libèrer sur plusieurs centaines de kilomètre carré, et pas seulement à des points précis. Donc pour le récupérer...
Non, je n'ai pas dit ça bien qu'en theorie ce serait possible (faisable même via une extension pour firefox si tu veux :-)). Webkit n'ont pas "triché" à ce point quand même (fort heureusement) :-)
Si j'ai bien tout compris, dans le test, il y a un truc dans le genre
if( element.laFonctionAnimationSmil !== undefined)
test ok.
Et dans webkit, cette fonction laFonctionAnimationSmil existe bien, mais elle ne contenait rien, elle ne faisait donc pas ce qu'elle était censée faire. (me rappel plus la fonction en question). c'est aussi un peu la faute du test de ne pas vérifier ce que fait la fonction, mais à la décharge de l'auteur du test Acid3 (Ian hickson), vérifier qu'une animation se fait bien, n'est pas très faisable en JS (puisqu'il faut vérifier le rendu..)..
Oui et non. C'est en cours, et ce sera peut-être prêt pour la sortie de Firefox 3.1. En tout cas, y a déjà des trucs qui marchent dans une branche, mais c'est pas encore intégré dans le trunk. Le patch est entré dans le processus de review :-)
La page sur SMIL, (que j'ai moi-même crée :-) ), n'est pas tout à fait à jour, mais pour vous tenir informé, allez suivre le bug indiqué.
(je vais de ce pas d'ailleurs corriger cette page)
Il n'y a pas de "gestion" des animations. Acid3 n'exécute pas des fonctions d'animations ou autre.
L'execution du test, pour qu'il soit déclaré gagnant, doit se passer de manière "fluide". C'est à dire qu'il ne doit pas y avoir un test qui prend plus de temps qu'un autre. L'affichage doit être donc progressif (puisqu'à chaque test, un truc est affiché montrant que le résultat est positif).
Bref, il n'y a pas de "gestion" des animations. Il y a juste une animation.
Bon sinon, 100% au test Acid3 (qui ne prouve pas grand chose), c'est bien, mais ce serait bien que webkit implémente un truc bien plus important que des trucs de geek : ARIA, pour l'accessibilité (ce que font Gecko et IE8).
Le test acid 3 test cent trucs (sans compter ceux pour l'apparence avec CSS) qui n'ont pas grand choses à voir les uns avec les autres, puisque ça teste :
- des trucs de Javascript
- des trucs de DOM
- des trucs de HTML
- des trucs de SVG
- des trucs de SMIL (animation SVG)
Maintenant, va faire un tour sur www.w3.org, regarder rapidement la taille des pages des spécifications de ces langages (pour javascript, il faut aller sur le site de l'Ecma), et tu te rendra compte qu'implémenter ces spécifications, ça ne se fait pas en trois coup de cuillère à pot. Toutes ces specs sont énormes, mais en plus complexe à implémenter (quand elles ne comportent pas des points "flous").
Et on se rendra compte aussi que ce test Acid 3, c'est du pignolage puisque ça ne fait qu'une centaine de tests, alors que si on veut vraiment tester l'implémentation sur toutes les technos cités, il en faudrait des centaines de milliers (et encore, ils ne seraient pas exhaustif, comme pour CSS, puisqu'il est impossible de tester toutes les combinaisons possibles de styles sur une seule balise).
M'enfin, des tests Acid3, c'est pas si mal, ça fait parler, ça fait baver, ça fait avancer les choses, même si finalement, ça ne prouve rien du tout. il y a un test par exemple qui test la présence d'une fonction pour les animations SVG, aussi la première fois que webkit a fait un 100%, les développeurs n'ont fait que créer ladite fonction qui était une coquille vide, pour faire passer le test (je ne sais pas si depuis elle a été vraiment implémentée).
>De même, la lecture des sites web utilisant la technologie ARIA a été implémentée.
il faut préciser : "avec les navigateurs supportant la technologie ARIA". Ce qui exclut les navigateurs à base de webkit, et inclus ceux à base de gecko 1.9 (1.8 ne supporte qu'une partie de ARIA il me semble...).
# format video ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Rasterman passe au Treo-650 et continue d'améliorer e17. Évalué à 3.
Quel est le codec à utiliser ? À moins que ce soit encore un vidéo dans un format propriétaire à peine supporté par les codecs libres ?
[^] # Re: Mes multiples expériences...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Nom de nos machines. Évalué à 2.
Bon sinon, moi j'utilise les noms des constructeurs de vaisseaux en tout genre dans la guerre des étoiles :-)
[^] # Re: SCENARI
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire une présentation pour une conférence ?. Évalué à 2.
quand ils passeront à XulRunner 1.9.1/Firefox 3.1, z'auront plus besoin de faire ça :-) (enfin, pour les videos ogg en tout cas, pas sûr que le backend gstreamer soit inclus à temps)
Et sinon, quand ils passeront à XulRunner 1.9.2/Firefox 3.2 (pas sûr du numéro de version), ils pourront faire du SMIL pour les animations/présentations, plutôt que faire du Flash :-)
[^] # Re: S5
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Faire une présentation pour une conférence ?. Évalué à 8.
https://addons.mozilla.org/fr/firefox/addon/4650
En plus, ça gère le media projection, et donc tu peux donner une apparence différente entre la visualisation traditionnelle et la visualisation en projection. Ça pourrait très bien être une page "normale" d'un site (donc c'est lisible "normalement", contrairement à S5, et par tout navigateur, même des vieux trucs), et quand on la met en projection, on vire par CSS les menus, entetes, tout ce qu'on ne veut pas en projection quoi, et avec un design adapté :-)
http://disruptive-innovations.com/zoo/fullerscreen/samples/p(...)
Et puis FullerScreen inclus un "navigateur" pour aller directement à une diapo donnée, en affichant une liste des screenshots de ces diapos. (merci la balise canvas)
[^] # Re: mon avis
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Cherche développeur web. Évalué à 4.
Et je ne parle pas d'autres gros sites comme tf1, libé, lemonde.fr et cie.. Tous en PHP. Je pense ne pas me tromper en disant que parmis le top 10 des gros sites en france, la grande majorité sont en PHP.
Et je ne parle pas non plus de toutes ces applis métiers, intranet, complexes à souhait, en PHP (là c'est mon expérience qui parle).
>Le php de par sa nature bordelique et scriptee, non typee etc me parait une heresie pour developper une grosse appli.
Un peu de rigueur, de la programmation objet, et ça roule. Des applis propres en PHP, ça existent, et de plus en plus, grâce à l'utilisation de frameworks notamment, et à la "professionnalisation" des devs PHP.
En java, on peut en faire aussi du code très crade.
[^] # Re: Ca arrive tout les jours...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Selon que vous serez puissant ou misérable.... Évalué à 6.
(oui, je chipotte)..
# Pourquoi un formulaire ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Éditer une ressource HTTP. Évalué à 2.
Pourquoi faudrait-il absolument un formulaire ?
Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.
1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables
Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.
Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.
Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.
Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefox http://developer.mozilla.org/en/Online_and_offline_events
[^] # Re: PUT -> remplacement ou création d'une ressource
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Éditer une ressource HTTP. Évalué à 3.
>Après, il reste le problème de l'autorisation de modification de ressources Web ...
Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..
M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 3.
Avoir une somme de contrôle correspondant à un fichier, c'est bien, mais il faut avoir le fichier pour calculer la somme et la comparer avec celle que l'on a récupéré, pour savoir si le fichier corresponds. Donc il faut nécessairement télécharger le fichier.
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 3.
[^] # Re: De bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource. Évalué à 2.
Ce que j'en ai compris de la AGPL :
- tu dois fournir les sources à tout les utilisateurs de l'appli web
- si tu fais des modifs, tu dois aussi les fournir
Ce qui veut dire que tout utilisateur de la boite, doit avoir accès aux sources, et donc même aux modifications qui pourrait concerner la gestion de données spécifiques et sensibles. Donc même aux utilisateurs qui ne sont pas habilités à connaître la présence/la gestion de ces données sensibles, car n'ayant pas de rapport avec eux ou le service dans lequel ils travaillent.
Si ce que j'ai compris est bon, je trouve donc ça très moyen de mettre un tel logiciel sous AGPL.
[^] # Re: Bonne imprimante ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La caisse d'épargne ne répond plus. Évalué à 1.
C'est pourtant simple !!
Oui bon, faut se déplacer pour être à coté d'un distributeur de billet...
Mais il parait qu'ils vont améliorer ça, et bientôt les distributeurs pourront communiquer par wifi (parce que bon, se balader avec un cordon usb, c'est pas cool..).
Certains disent d'ailleurs qu'un jour peut-être, on n'aura plus besoin de prendre son laptop pour retirer de l'argent à un distributeur. Mouarf, y en a qui rêve quand même...
[^] # Re: De bonnes idées
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Lundi Matin Business, un nouveau logiciel de gestion commerciale OpenSource. Évalué à 2.
je trouve ça plutôt con, pour un logiciel utilisé en entreprise. Car cela veut dire que la boite ne peut pas apporter des modifications qui seraient propre à son fonctionnement, et donc des modifs qui ne sont pas forcément intéressantes pour les autres, encore moins si il s'agit de choses confidentielles.
Je n'aime vraiment pas la AGPL...
[^] # Re: Géolocalisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Vision2Pixels: un moteur de critique photographique libre. Évalué à -1.
Si quelqu'un veut faire partager une photo d'un petit monument de son bled, ou même des fleurs de son jardin, il a 99% de chances que la carte openstreetmap n'a pas de plan du coin photographié.
[^] # Re: Géolocalisation
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Vision2Pixels: un moteur de critique photographique libre. Évalué à 8.
"Bonjour, j'ai pris ma photo ici : http://www.openstreetmap.org/?lat=48.42924&lon=-0.86181&(...) "
Ouai.. super... vachement intéressant..
Je ne dénigre absolument pas le travail remarquable fait par les contributeurs à OpenStreetMap, mais en toute franchise, je ne pense pas que ce soit utilisable en l'état pour une application comme Vision2pixels..
[^] # Re: C'est la deuxième lame ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'aurions-nous dans le c.. ?. Évalué à 5.
(je dis pas qu'il faut pas vérifier la somme de contrôle hein... mais bon, dans le contexte...)
[^] # Re: Et sinon le MathML...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 3.
Le coeur de Wbekit/khtml est vraiment trop différent de celui de Gecko, pour pouvoir reprendre le code Mathml de Gecko.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 1.
Bref, il va en falloir des tests acid ;-)
[^] # Re: \o/ on a résolu la crise du pétrole \o/
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Environnement: la bombe à retardement du méthane est enclenchée. Évalué à 4.
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 4.
Si j'ai bien tout compris, dans le test, il y a un truc dans le genre
if( element.laFonctionAnimationSmil !== undefined)
test ok.
Et dans webkit, cette fonction laFonctionAnimationSmil existe bien, mais elle ne contenait rien, elle ne faisait donc pas ce qu'elle était censée faire. (me rappel plus la fonction en question). c'est aussi un peu la faute du test de ne pas vérifier ce que fait la fonction, mais à la décharge de l'auteur du test Acid3 (Ian hickson), vérifier qu'une animation se fait bien, n'est pas très faisable en JS (puisqu'il faut vérifier le rendu..)..
[^] # Re: Et sinon le MathML...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 3.
[^] # Re: parce que webkit gère le smil maintenant ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 4.
La page sur SMIL, (que j'ai moi-même crée :-) ), n'est pas tout à fait à jour, mais pour vous tenir informé, allez suivre le bug indiqué.
(je vais de ce pas d'ailleurs corriger cette page)
# correction
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 3.
Il n'y a pas de "gestion" des animations. Acid3 n'exécute pas des fonctions d'animations ou autre.
L'execution du test, pour qu'il soit déclaré gagnant, doit se passer de manière "fluide". C'est à dire qu'il ne doit pas y avoir un test qui prend plus de temps qu'un autre. L'affichage doit être donc progressif (puisqu'à chaque test, un truc est affiché montrant que le résultat est positif).
Bref, il n'y a pas de "gestion" des animations. Il y a juste une animation.
Bon sinon, 100% au test Acid3 (qui ne prouve pas grand chose), c'est bien, mais ce serait bien que webkit implémente un truc bien plus important que des trucs de geek : ARIA, pour l'accessibilité (ce que font Gecko et IE8).
[^] # Re: Est-ce que quelqu'un comprend pourquoi ces tests sont si difficiles?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Encore une victoire de Webkit !. Évalué à 9.
- des trucs de Javascript
- des trucs de DOM
- des trucs de HTML
- des trucs de SVG
- des trucs de SMIL (animation SVG)
Maintenant, va faire un tour sur www.w3.org, regarder rapidement la taille des pages des spécifications de ces langages (pour javascript, il faut aller sur le site de l'Ecma), et tu te rendra compte qu'implémenter ces spécifications, ça ne se fait pas en trois coup de cuillère à pot. Toutes ces specs sont énormes, mais en plus complexe à implémenter (quand elles ne comportent pas des points "flous").
Et on se rendra compte aussi que ce test Acid 3, c'est du pignolage puisque ça ne fait qu'une centaine de tests, alors que si on veut vraiment tester l'implémentation sur toutes les technos cités, il en faudrait des centaines de milliers (et encore, ils ne seraient pas exhaustif, comme pour CSS, puisqu'il est impossible de tester toutes les combinaisons possibles de styles sur une seule balise).
M'enfin, des tests Acid3, c'est pas si mal, ça fait parler, ça fait baver, ça fait avancer les choses, même si finalement, ça ne prouve rien du tout. il y a un test par exemple qui test la présence d'une fonction pour les animations SVG, aussi la première fois que webkit a fait un 100%, les développeurs n'ont fait que créer ladite fonction qui était une coquille vide, pour faire passer le test (je ne sais pas si depuis elle a été vraiment implémentée).
# ARIA
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche GNOME 2.24 : un air de renouveau. Évalué à 3.
il faut préciser : "avec les navigateurs supportant la technologie ARIA". Ce qui exclut les navigateurs à base de webkit, et inclus ceux à base de gecko 1.9 (1.8 ne supporte qu'une partie de ARIA il me semble...).
Cependant dans webkit, le support de ARIA est en cours, mais ils doivent avant refactoriser d'autres choses pour que ce soit possible. http://mindforks.blogspot.com/2008/03/ie8-embraces-aria-and-(...)