Vous estimez comment la stabilité d'une spec W3C HTML5 ?
jpvincent
Working draft de la même manière, tu as 90% de chance pour que ton
code fonctionne encore lorsque la spec sera finalisée et implémentée
pour le reste du monde.
A votre avis, est ce légitime ?
est ce que vous avez des exemples où cela a marché ou au contraire ne
s'est pas vérifié ?
pour donner un peu de consistance à cette question un poil abstraite :
je suis sur un cas typique où je prends un risque en implémentant
quelque chose qui dépend de plusieurs APIs en cours de spécification.
Je fais un uploader en JS/HTML via drop de fichiers depuis le bureau
vers le browser, la voie que j'ai choisi (car il y a au moins 3
manières de faire) marche sur Safari 5 et Chrome 5, et FF3.6 et 4, et
ça utilise :
- l'API FileList / File : https://developer.mozilla.org/en/DOM/FileList
. Je ne trouve pas de page W3C dessus, mais l'interface est compatible
Webkit
- XHR2.upload et XHR2.progress, en working draft : http://www.w3.org/TR/XMLHttpRequest2/
- une petite partie de Drag&drop, en working draft aussi :
http://www.whatwg.org/specs/web-apps/current-work/#dnd
dans l'implémentation que j'ai faite, ces APIs sont compatibles sur
Safari / Chrome / FF et semblent se comporter de la même manière (je
n'ai pas encore testé les cas limite).
A votre avis, quelle est la probabilité pour qu'il n'y ait rien à
changer au code dans le futur ?
Julien Wajsberg
> . Je ne trouve pas de page W3C dessus, mais l'interface est compatible
> Webkit
http://dev.w3.org/2006/webapi/FileAPI/ et http://www.w3.org/TR/FileAPI/
et pour répondre à ta question, je dirais 70%.
Sachant qu'il y a la méthode à base de FormData qui pointe son nez
depuis Ffox4, cf
http://hacks.mozilla.org/2010/07/firefox-4-formdata-and-the-new-file-url-object/.
(et je ne sais pas à quel point elle est multi-browser ou conforme à
une spec)
--
Julien
Stephane Deschamps
b, xmlhttprequest, le offline, j'en oublie sans doute des tonnes)
Donc légitime je ne sais pas... inédit, sans aucun doute :)
2010/9/1 jpvincent <jeanpierr...@gmail.com>:
jpvincent
pour FormData, je l'ai justement écartée alors que c'était la voix
royale, parce qu'elle n'est pas encore supportée par les webkits, on
en revient au fond de ma question : je regarde d'abord si c'est
implémenté pareil sur 2 browsers différents plutôt que de regarder
l'état de la spec
l'autre manière de faire, c'est en utilisant XHR2 + FileReader
(https://developer.mozilla.org/en/DOM/FileReader), qui souffre presque
du même problème, à la différence que Chrome 6 (mais pas safari)
l'annonce. Mais je ne l'ai pas testé
On 1 sep, 18:35, Julien Wajsberg <fel...@gmail.com> wrote:
> 2010/9/1 jpvincent <jeanpierre.vinc...@gmail.com>:
> > . Je ne trouve pas de page W3C dessus, mais l'interface est compatible
> > Webkit
>
> et pour répondre à ta question, je dirais 70%.
> Sachant qu'il y a la méthode à base de FormData qui pointe son nez
jpvincent
wrote:
> b, xmlhttprequest, le offline, j'en oublie sans doute des tonnes)
disposaient, mais finalement c'est l'exact contraire : les
implémenteurs innovent, le W3C standardise.
et nous webdevs on rame :)
et si on prend de l'avance, ici avec un drop de fichiers, on prend des
risques, ma question c'était plus de savoir si le risque est grand ou
pas ?
> Donc légitime je ne sais pas... inédit, sans aucun doute :)
m'encombrais même pas de savoir si ça correspondait à une spec ou pas
>
> 2010/9/1 jpvincent <jeanpierre.vinc...@gmail.com>:
Julien Wajsberg
> On 1 sep, 22:33, Stephane Deschamps <stephane.descha...@gmail.com>
> wrote:
>> Jusque-là le W3C a souvent couru après les implémenteurs (img, frame,
>> b, xmlhttprequest, le offline, j'en oublie sans doute des tonnes)
> oui, j'ai longtemps cru que le W3C proposait et les autres
> disposaient, mais finalement c'est l'exact contraire : les
> implémenteurs innovent, le W3C standardise.
> et nous webdevs on rame :)
> et si on prend de l'avance, ici avec un drop de fichiers, on prend des
> risques, ma question c'était plus de savoir si le risque est grand ou
> pas ?
le risque existe. ;-)
Note que tu vas devoir de toute manière faire une alternative sans
drop de fichiers, donc est-ce si grave ?
jpvincent
c'était d'avoir de meilleures perfs, notamment sur mac et sur les
anciennes machines.
les risques c'est que le code casse dans 6 mois sur un IE9 (en
supposant que d'ici là ils implémentent quelque chose) ou dans un
FF4.0.x/webkit nouveau si ils décident de changer quelque chose d'ici
là.
mais oui je crois qu'on est tous dans le brouillard concernant
l'importance du risque :)
allez, on est une startup ou on ne l'est pas : l'upload chez nous est
une partie critique qu'on teste systématiquement, le jour où ça casse
sur un navigateur, on réagira rapidement.
On 2 sep, 09:18, Julien Wajsberg <fel...@gmail.com> wrote:
> 2010/9/2 jpvincent <jeanpierre.vinc...@gmail.com>:
Adrien Leygues
> et si on prend de l'avance, ici avec un drop de fichiers, on prend des
> risques, ma question c'était plus de savoir si le risque est grand ou
> pas ?
Où est-ce que tu places ton curseur de risque ? Je ne suis pas expert
en matière de constructions de specs, mais il y a à priori peu de
chance qu'elle change radicalement, surtout si elle est déjà
implémentée dans deux navigateurs. De là est-ce que tu es prêt à
offrir comme tu le soulignes des bonnes performances à tes
utilisateurs au risque de devoir passer 1 ou 2 journées à adapter ton
script en fonction des évolutions des specs ?
--
[ Adrien Leygues ]
http://www.paris-web.fr
http://www.bootleygues.net
Jacques PYRAT
> oui, l'alternative (applet java qui rame) est déjà en place, l'idée
> c'était d'avoir de meilleures perfs, notamment sur mac et sur les
> anciennes machines.
> les risques c'est que le code casse dans 6 mois sur un IE9 (en
> supposant que d'ici là ils implémentent quelque chose) ou dans un
> FF4.0.x/webkit nouveau si ils décident de changer quelque chose d'ici
> là.
>
> mais oui je crois qu'on est tous dans le brouillard concernant
> l'importance du risque :)
> allez, on est une startup ou on ne l'est pas : l'upload chez nous est
> une partie critique qu'on teste systématiquement, le jour où ça casse
> sur un navigateur, on réagira rapidement.
ce module d'upload, en mettant en plus le code dans une forge libre,
t'auras plus de chances que ce soit maintenu à moindre frais...
-- Jacques Pyrat
Eric Daspet
> Jusque-là le W3C a souvent couru après les implémenteurs (img, frame,
> b, xmlhttprequest, le offline, j'en oublie sans doute des tonnes)
>
> Donc légitime je ne sais pas... inédit, sans aucun doute :)
Ca dépend en fait.
CSS 2 et CSS 3 ont été plutôt en avance par rapport aux
implémentations. C'est d'ailleurs tout le problème puisque les
implémenteurs ont arrêté de courir après CSS 2 au bout d'un moment et
on finit tout juste d'implémenter des trucs comme les polices
téléchargeables qui étaient prévues en 98. Même chose pour XHTML 2.
Sauf erreur SVG est aussi plutôt en avance par rapport aux
implémentations (au moins sur les profils web et mobile).
Sur DOM on a un peu des deux. Sur Aria, XSLT, XForms, RDFa, SVG ...
c'est moins mon domaine mais je ne crois pas que ce soit le W3C qui
courre.
En fait le W3C est même plutôt une exception de ce que j'en sais.
D'ordinaire on tente plutôt de standardiser des choses existantes ou
déjà en gestation (en les adaptant, transformant), pas de les "créer"
directement. Il est donc relativement normal d'être en retard sur les
implémentations.
--
Éric Daspet
http://eric.daspet.name/