MozEuCamp de Pragues
Anthony Ricaud
Je viens vous embêter pour recueillir des opinions. Pendant cet
événement, il y aura une table ronde regroupant développeurs web et
développeurs de Firefox. Le but étant d'en savoir plus sur ce
qu'attendent les devs web pour prioriser les développements de Firefox.
Comme l'explique Paul Rouget et Vladimir (http://blog.mozbox.org/post/2009/09/23/%5BEU-Mozilla-Camp%5D-The-developer-Track-Round-table
), voilà ce qu'ils attendent (attention, english) :
• We are interested to hear what you think we could be doing better
at, in terms of support for current or emerging web standards. Are
there existing features in other browsers that you want to take
advantage of that we don't support? What about those features is
compelling?
• What's missing from the web platform? Where do you want to see us
take it? If you could pick one capability to add to the web, what
would have the biggest impact on your web app development?
• Of the currently supported standards, what's painful? What would you
like to see us focus on improving, whether through enhancement or
through change?
C'est une chance de pouvoir exprimer ce genre de besoins directement
aux développeurs des navigateurs. Donc n'hésitez pas à commenter le
blog de Paul (en français si vous voulez) ou en répondant ici (vu que
j'aurais la chance de participer à cette table ronde).
Déchainez-vous ! :)
br1o
J'aimerais bien une version light de Firefox : juste le core et
pouvoir installer des extensions, épivala !
--
Bruno Bichet
http://css4design.com
http://notoriousblog.fr
samuel
ça c'est une chouette initiative,
pour ma part j'ai toujours regretter de ne pouvoir installer plusieurs instance de firefox.
une pour bosser et une pour naviguer plus tranquillement par exemple.
Thomas Bassetto
lancer plusieurs profils en même temps. Je fais honteusement de
l'auto-promo :
http://tb4.fr/blog/post/89-comment-et-pourquoi-creer-un-profil-firefox-different-pour-le-developpement-web
Sinon les 2 remarques déjà faites touchent plus le logiciel que le
support des standards (qui est le thème principal de la table ronde)
:o
A+
samuel
par contre merci pour l'info... je me sens un peu bête pour le coup :)
samuel
Un moteur plus rapide à la chrome mais je pense qu'ils y songent déjà
Et j'ai presque honte mais je trouve le débugger de ie plus précis sur les erreurs que celui de firefox.
Autre point que je trouve assez sympa c'est la barre d'adresse dans opera je crois qui est intégrée à l'onglet et pas au-dessus, ça parait logique en fait.
Et pour reprendre ton poste ( que j'ai juste commencé à lire mais que je vais finir de ce pas ) toutes les extensions bien connu des développeur qui pourrait être intégrée directement au navigateur.
Thomas Bassetto
> du coup, je penserais plus au javascript.
> Un moteur plus rapide à la chrome mais je pense qu'ils y songent déjà
pas V8 (Chrome) en rapidité. J'ai déjà vu des développeurs Firefox
dire que sur certains points TM est mieux mais je ne sais pas
lesquels, c'est un sujet au delà de mes compétences. Peut-être y a
t-il moyen d'avoir une réponse lors du MozCamp.
> Et j'ai presque honte mais je trouve le débugger de ie plus précis sur les
> erreurs que celui de firefox.
> Autre point que je trouve assez sympa c'est la barre d'adresse dans opera je
> crois qui est intégrée à l'onglet et pas au-dessus, ça parait logique en
> fait.
que la version de fin d'année est numérotée 3.6) :
https://wiki.mozilla.org/Firefox/Sprints/Windows_Theme_Revamp/Direction_and_Feedback
Ça reste des prototypes, hein :)
Thomas Bassetto — tb4.fr
Élève-ingénieur de l'INSA de Rouen en Architecture des Systèmes
d'Information — 5ème année
samuel
En tout cas je ne me fais pas de soucis pour les prochaines versions.
Pour ce de qui est tm, je ne sais pas si tu as déjà essayé de grosses applis en js ( http://benfirshman.com/projects/jsnes/ )
ce sont des projets intéressants souvent mais seul chrome les faits tourner convenablement.
David Larlet
Le 24 sept. 2009 à 19:37, Anthony Ricaud a écrit :
> C'est une chance de pouvoir exprimer ce genre de besoins directement
> aux développeurs des navigateurs. Donc n'hésitez pas à commenter le
> blog de Paul (en français si vous voulez) ou en répondant ici (vu que
> j'aurais la chance de participer à cette table ronde).
>
> Déchainez-vous ! :)
# Identité
Je pense que la gestion de l'identité devrait être déléguée au
navigateur qui procure un environnement plus sécurisé qu'un site web
(en théorie du moins). Pour cela il faudrait pouvoir gérer ses OpenID
directement dans le navigateur afin de certifier/vérifier les
redirections effectuées et éviter le phishing. Niveau UI, les champs
de formulaires OpenID étant standards et facilement identifiables, le
navigateur devrait proposer une liste déroulantes des identités
enregistrées.
Si on part sur du FOAF+SSL, c'est encore plus simple car la gestion
des certificats est déjà implémentée dans les navigateurs (mais c'est
une horreur avec Firefox), il suffirait de revoir l'UI pour la faire
davantage ressembler à une gestion de l'identité.
# Données liées
L'exploration des données devrait pouvoir se faire dans un navigateur,
on devrait pouvoir parcourir un graphe de relations, afficher un
fichier rdf, etc... avec une ergonomie potable. Je laisse le requêtage
des données à du Ubiquity ou autre mais l'affichage ne devrait pas
demander de plugin.
# XMPP
On n'arrête pas de lire que c'est l'année du real-time (buzzwordons
ensemble mes frères) et ça me fait copieusement suer que Chrome
s'apprête à devenir le seul navigateur qui gère un poil xmpp, ça va
être son avantage concurrentiel associé à Wave et j'aimerais bien que
Firefox soit une alternative (performante) possible :)
Après quelques Guinness j'arrive même à imaginer un web où je pourrais
pusher des pages html via xmpp à mes amis de façon décentralisée mais
c'est peut-être trop en demander pour le moment.
# Documentation
Aujourd'hui si je veux m'amuser avec du @font-face ou l'inclusion de
svg je trouve très peu de sources (même en anglais) expliquant comment
faire simplement, je préfèrerais avoir du tuto à lire que des specs du
W3C. Il serait intéressant que la MoFo arrive à faire ce type
d'évangélisation, marre des discours marketing de Tristan, on veut de
la matière pour les geeks ! ;)
David, déchaîné.
Julien Wajsberg
Anthony Ricaud
En gros, je retiens :
- plus de flexibilité pour lancer un Firefox adapté au débuggage
- Identité : OpenId, FOAF + SSL
- XMPP
Le 25 sept. 2009 à 00:25, David Larlet a écrit :
>
> Hello,
>
> # Données liées
>
> L'exploration des données devrait pouvoir se faire dans un navigateur,
> on devrait pouvoir parcourir un graphe de relations, afficher un
> fichier rdf, etc... avec une ergonomie potable. Je laisse le requêtage
> des données à du Ubiquity ou autre mais l'affichage ne devrait pas
> demander de plugin.
Quelles données liées (microformats, rdfa, microdata) ? Pourquoi filer
à un end user une interface rustre destinée aux devs ?
> # Documentation
>
> Aujourd'hui si je veux m'amuser avec du @font-face ou l'inclusion de
> svg je trouve très peu de sources (même en anglais) expliquant comment
> faire simplement, je préfèrerais avoir du tuto à lire que des specs du
> W3C. Il serait intéressant que la MoFo arrive à faire ce type
> d'évangélisation, marre des discours marketing de Tristan, on veut de
> la matière pour les geeks ! ;)
>
http://developer.mozilla.org ne te convient pas ?
> David, déchaîné.
Goulven CHAMPENOIS
Le seul truc qui m'ennuie c'est la gestion du proxy avec authentification. La fenêtre modale login/mot de passe s'affiche à la première connexion, alors que ces informations sont enregistrées par le gestionnaire de mot de passe. Il vaudrait mieux que le login/mot de passe soient enregistrés avec le informations de proxy comme le font d'autres applications (Eclipse par exemple).
Ce n'est peut-être pas grand-chose à changer, mais au démarrage ça provoque l'apparition d'une fenêtre modale pour chaque onglet ET pour chaque requête de mise à jour navigateur ou extension. Fermer 15 fois la même boîte de dialogue à chaque démarrage du navigateur, ça soûle...
Je suis sûr que si les devs de Mozilla étaient coincés derrière un proxy avec login, cette nuisance aurait déjà été corrigée ! :-)
Ah, et l'impression aussi pourrait être améliorée. L'interface n'est pas évidente, elle ne devrait pas être modale, les <pre> sont en overflow hidden (ça la fout mal pour du code indenté), et on devrait pouvoir lister les URLs des liens en fin de page.
Et une dernière chose : si on implémentait les transformation CSS, on pourrait faire de jolis boutons flash, mais sans flash !
Tant qu'à parler de flash, permettre de tabuler de la page vers flash et vice-versa...
Voilà, c'était "le" truc que j'aimerai voir changer. :-)
--
Goulven Champenois
David Larlet
Le 25 sept. 2009 à 00:59, Anthony Ricaud a écrit :
> Le 25 sept. 2009 à 00:25, David Larlet a écrit :
>>
>>
>> # Données liées
>>
>> L'exploration des données devrait pouvoir se faire dans un
>> navigateur,
>> on devrait pouvoir parcourir un graphe de relations, afficher un
>> fichier rdf, etc... avec une ergonomie potable. Je laisse le
>> requêtage
>> des données à du Ubiquity ou autre mais l'affichage ne devrait pas
>> demander de plugin.
>
> Quelles données liées (microformats, rdfa, microdata) ? Pourquoi filer
> à un end user une interface rustre destinée aux devs ?
Mmh je comprends pas très bien la seconde question.
Pour donner un exemple concret, j'aimerais bien qu'en consultant http://david.larlet.fr/foaf.rdf
j'ai une interface qui ressemble plus à http://xml.mfd-consult.dk/foaf/explorer/?foaf=http%3A%2F%2Fdavid.larlet.fr%2Ffoaf.rdf
Après tout ce qui est dans le html (exemples cités), je suis d'accord
sur le fait que ça devrait être l'objet de plugins comme ça l'est fait
actuellement.
>
>> # Documentation
>>
>> Aujourd'hui si je veux m'amuser avec du @font-face ou l'inclusion de
>> svg je trouve très peu de sources (même en anglais) expliquant
>> comment
>> faire simplement, je préfèrerais avoir du tuto à lire que des specs
>> du
>> W3C. Il serait intéressant que la MoFo arrive à faire ce type
>> d'évangélisation, marre des discours marketing de Tristan, on veut de
>> la matière pour les geeks ! ;)
>>
> http://developer.mozilla.org ne te convient pas ?
Je te réponds dès que c'est plus en Service Unavailable ;)
David
Adrien Leygues
> Tant qu'à parler de flash, permettre de tabuler de la page vers flash et
> vice-versa...
Et si on pouvait aussi saisir des "@" quand le flash est wMode transparent
https://bugzilla.mozilla.org/show_bug.cgi?id=347185
--
[ Adrien Leygues ]
http://www.paris-web.fr
http://adrien.leygues.free.fr
samuel
Julien Wajsberg
>
> 2009/9/25 Goulven CHAMPENOIS <goul...@gmail.com>:
>> Tant qu'à parler de flash, permettre de tabuler de la page vers flash et
>> vice-versa...
>
> Et si on pouvait aussi saisir des "@" quand le flash est wMode transparent
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=347185
ah oui, je plussois complètement.
--
Julien
Nico
faire avec plus ou moins de succès ? (Plutôt moins pour le moment je
trouve mais ce projet promet).
On 25 sep, 10:26, samuel <zoulil...@gmail.com> wrote:
> Bonjour,Le xmpp m'a rappelé une vieille question a laquelle j'ai ma réponse
> > sur le fait que ça devrait être l'objet de plugins comme ça l'est fait
> > actuellement.
>
> > >> # Documentation
>
> > >> Aujourd'hui si je veux m'amuser avec du @font-face ou l'inclusion de
> > >> svg je trouve très peu de sources (même en anglais) expliquant
> > >> comment
> > >> faire simplement, je préfèrerais avoir du tuto à lire que des specs
> > >> du
> > >> W3C. Il serait intéressant que la MoFo arrive à faire ce type
> > >> d'évangélisation, marre des discours marketing de Tristan, on veut de
> > >> la matière pour les geeks ! ;)
>
Anthony Ricaud
améliorations pour les développeurs, pas les utilisateurs. Qu'est-ce
qui doit être ajouté à Firefox pour améliorer la vie des développeurs.
Les 3 points étaient (traduction approximative, maladroite et rapide) :
• Nous aimerions entendre parler de ce que nous pourrions améliorer en
terme de support des standards actuels ou émergents. Y a-t-il des
fonctionnalités d'autres moteurs que vous aimeriez utiliser et que
nous ne supportons pas ? Lesquelles sont indispensables ?
• Que manque-t-il à la plateforme web ? Dans quelle direction doit-on
l'emmener ? Si vous deviez choisir une nouveauté, laquelle aurait le
plus d'impact sur votre développement d'applications web ?
• Des standards actuellement supportés, qu'est qui est embêtant ? Sur
quoi devrions-nous nous concentrer, à travers une amélioration ou un
changement ?
Julien Wajsberg
>
> Je recentre un peu la discussion. La table ronde tournera autour des
> améliorations pour les développeurs, pas les utilisateurs. Qu'est-ce
> qui doit être ajouté à Firefox pour améliorer la vie des développeurs.
>
> Les 3 points étaient (traduction approximative, maladroite et rapide) :
>
> • Nous aimerions entendre parler de ce que nous pourrions améliorer en
> terme de support des standards actuels ou émergents. Y a-t-il des
> fonctionnalités d'autres moteurs que vous aimeriez utiliser et que
> nous ne supportons pas ? Lesquelles sont indispensables ?
> • Que manque-t-il à la plateforme web ? Dans quelle direction doit-on
> l'emmener ? Si vous deviez choisir une nouveauté, laquelle aurait le
> plus d'impact sur votre développement d'applications web ?
> • Des standards actuellement supportés, qu'est qui est embêtant ? Sur
> quoi devrions-nous nous concentrer, à travers une amélioration ou un
> changement ?
J'aimerais bien qu'on aboutisse sur les websockets, cet espèce de XHR
à double sens, pour éviter des hacks à la Comet. Par ailleurs,
l'advanced layout CSS3 me semble aussi important et permettra à terme
d'arrêter de se prendre la tête avec des float dans des float.
J'aimerais qu'on puisse définir des "composants" dans une page, qui
soient réutilisables facilement. Si je ne me trompe pas, il y a des
trucs un peu comme ça en CSS3 qui permettent de bouger facilement le
DOM ("move-to"), mais rien pour faire de la "copie" de DOM. Peut-être
pouvoir importer ces composants afin de pouvoir les réutiliser.
J'admets que ça a peut-être plus sa place côté serveur, mais je sens
bien que ce sont des besoins présents dans la totalité des sites, même
peu complexes, et à ce titre, ça pourrait bien être dans le standard.
J'aimerais qu'on ait du SQL côté client, ce qu'il n'y a pas encore
chez Firefox si je ne m'abuse (sauf pour les développeurs
d'extensions).
Voilà, ça te va ça ? :)
Pascal Gautronneau
j'aimerais pouvoir utiliser "display: inline-block". FF3 le supporte mais FF2 et comme on ne peux pas les différencier, ça prohibe l'usage de cette propriété sauf à avoir un truc cassé sous FF2.
Pascal
Pascal Gautronneau
Coordination projets - Associé
04 76 09 55 08 - p.gaut...@webu.fr
Webu - utile et créatif
Grenoble / Paris
www.webu.fr
Mobile : 06 46 46 78 34
Fax : 09 57 43 74 69
Noëlie Amiot
Anthony Ricaud
>
> 2009/9/25 Anthony Ricaud <rik...@gmail.com>:
>>
>> Je recentre un peu la discussion. La table ronde tournera autour des
>> améliorations pour les développeurs, pas les utilisateurs. Qu'est-ce
>> qui doit être ajouté à Firefox pour améliorer la vie des
>> développeurs.
>>
>> Les 3 points étaient (traduction approximative, maladroite et
>> rapide) :
>>
>> • Nous aimerions entendre parler de ce que nous pourrions améliorer
>> en
>> terme de support des standards actuels ou émergents. Y a-t-il des
>> fonctionnalités d'autres moteurs que vous aimeriez utiliser et que
>> nous ne supportons pas ? Lesquelles sont indispensables ?
>> • Que manque-t-il à la plateforme web ? Dans quelle direction doit-on
>> l'emmener ? Si vous deviez choisir une nouveauté, laquelle aurait le
>> plus d'impact sur votre développement d'applications web ?
>> • Des standards actuellement supportés, qu'est qui est embêtant ? Sur
>> quoi devrions-nous nous concentrer, à travers une amélioration ou un
>> changement ?
>
>
> J'aimerais bien qu'on aboutisse sur les websockets, cet espèce de XHR
> à double sens, pour éviter des hacks à la Comet. Par ailleurs,
> l'advanced layout CSS3 me semble aussi important et permettra à terme
> d'arrêter de se prendre la tête avec des float dans des float.
J'avais déjà noté les sockets, les server sent events et grid
positionning et template layout.
> J'aimerais qu'on puisse définir des "composants" dans une page, qui
> soient réutilisables facilement. Si je ne me trompe pas, il y a des
> trucs un peu comme ça en CSS3 qui permettent de bouger facilement le
> DOM ("move-to"), mais rien pour faire de la "copie" de DOM. Peut-être
> pouvoir importer ces composants afin de pouvoir les réutiliser.
> J'admets que ça a peut-être plus sa place côté serveur, mais je sens
> bien que ce sont des besoins présents dans la totalité des sites, même
> peu complexes, et à ce titre, ça pourrait bien être dans le standard.
Je ne connais pas trop, mais il semblerait que ce soit un peu le but
de XBL ?
> J'aimerais qu'on ait du SQL côté client, ce qu'il n'y a pas encore
> chez Firefox si je ne m'abuse (sauf pour les développeurs
> d'extensions).
>
> Voilà, ça te va ça ? :)
Parfait !
Yves Van Goethem
Le plus simple qui est moins prise de tête c'est -moz-inline-box et -moz-inline-block (attention le comportement n'est pas le même) https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions
Firefox 2 n'est plus supporté de toute manière, donc le bug ne sera jamais corrigé ;)
--
Yves Van Goethem
Gestionnaire webdevfr
Anthony Ricaud
> Bonjour,
>
> j'aimerais pouvoir utiliser "display: inline-block". FF3 le supporte
> mais FF2 et comme on ne peux pas les différencier, ça prohibe
> l'usage de cette propriété sauf à avoir un truc cassé sous FF2.
>
> Pascal
Je fais mon gros rabat joie du lundi matin, mais bien que cela soit un
sujet très intéressant, il n'a absolument rien à voir avec la
discussion en cours. Vous pouvez discuter de la solution de Yves dans
un sujet à part peut-être ?
Pascal Gautronneau
• Nous aimerions entendre parler de ce que nous pourrions améliorer en
terme de support des standards actuels ou émergents. Y a-t-il des
fonctionnalités d'autres moteurs que vous aimeriez utiliser et que
nous ne supportons pas ? Lesquelles sont indispensables ?
• Des standards actuellement supportés, qu'est qui est embêtant ? Sur
quoi devrions-nous nous concentrer, à travers une amélioration ou un
changement ?
A tout hasard, je vais essayer de reformuler ma réponse :
Internet Explorer avait jusqu'à la version 7 un système de commentaires conditionnels qui permettait d'utiliser, par exemple, un fond avec un png24 dans IE7 et de le remplacer par un gif dégradé sous IE6.
Ce système a plein de défaut et il a d'ailleurs été abandonné dans la version 8.
J'aimerais donc avoir un système le plus "propre" possible me permettant de gérer la dégradation d'affichage dans les anciennes versions sans en passer par des contournements compliqués, parfois risqué et faisant souvent perdre de la performance.
Et que FF2 ne soit plus supporté n'a pas pour autant fait disparaitre cette version de tout les postes où c'est un ami / petit-fils / etc. geek qui est venu l'installer et qui n'est pas repassé pour mettre la version 3 à la place ;-).
Pascal
Anthony Ricaud
- Webforms
- SVG en tant que background CSS
- Plus de données sur <audio> (pour faire des visualisateurs, synchroniser des animations avec le son, etc, ce que sait faire Flash)
- CSS transitions (bon, ils ont fait les premiers commits quelques semaines après donc ça doit pas être grâce à nous)
- CSS template modules (Template Layout and Grid Positionning)
- Un standard pour styler les formulaires
- Server Sent Events
- Standardiser les filtres SVG appliquables en CSS
- Détection de fonctionnalités en CSS (ouais, finalement :) )
Pour les gens qui avaient le bug de Flash et wmode=transparent, c'est presque réglé dans Firefox 3.5 (comme le dit le bug mozilla) et on m'a aussi filé http://bugs.adobe.com/jira/browse/FP-40 qui apparemment dit que c'est réglé avec Flash 10.1 (je n'ai pas de compte Adobe donc je ne sais pas ce qu'il y a derrière ce lien)
On a aussi parlé de Firebug et des démarches que Mozilla pourrait faire pour améliorer l'adoption des nouveaux standards, aidez les développeurs web à savoir ce qu'ils peuvent utiliser, etc etc.
J'ai aussi fait un petit compte rendu de l'événement (en anglais uniquement, désolé) : http://hanblog.info/blog/post/2009/10/30/Mozilla-Europe-Camp-2009
Le 24 sept. 2009 à 19:37, Anthony Ricaud a écrit :
> Bonsoir,
>
> Je viens vous embêter pour recueillir des opinions. Pendant cet événement, il y aura une table ronde regroupant développeurs web et développeurs de Firefox. Le but étant d'en savoir plus sur ce qu'attendent les devs web pour prioriser les développements de Firefox.
>
> Comme l'explique Paul Rouget et Vladimir (http://blog.mozbox.org/post/2009/09/23/%5BEU-Mozilla-Camp%5D-The-developer-Track-Round-table), voilà ce qu'ils attendent (attention, english) :
Yves Van Goethem
Je suis curieux de voir les propositions pour la détection de fonctionnalités en CSS et le standard pour styler les formulaires :)
Et très intéressé des idées pour <audio>
--
Yves Van Goethem
Stephane Deschamps
2009/11/24 Anthony Ricaud <rik...@gmail.com>:
> Pour les gens qui avaient le bug de Flash et wmode=transparent, c'est presque réglé dans Firefox 3.5 (comme le dit le bug mozilla)
Jamais entendu parler d'un bug de Flash+ Mozilla[1], quelqu'un peut
nous en parler ?
[1] à part le sempiternel problème dû au fait qu'on ne peut pas
tabuler nativement de HTML vers Flash et inversement, mais bon, ça on
le sait depuis longtemps.
--
Stéphane Deschamps
perso: http://www.nota-bene.org/
org: http://www.pompage.net/
nicolas_froidure
une fois, ça affiche un fond blanc à la place de rendre le flash
transparent.
--
Nicolas Froidure
http://www.elitwork.com
On 30 nov, 12:56, Stephane Deschamps <stephane.descha...@gmail.com>
wrote:
Julien Wajsberg
je sais pas ce qu'il en est avec la version 10, mais il me semble pas
que ce soit corrigé
par ailleurs, toujours avec le player linux, avec un wmode, la saisie
clavier était toute cassée, dès qu'on voulait mettre des accents ça
faisait n'importe quoi.
2009/11/30 nicolas_froidure <nicolas_...@elitwork.com>:
Adrien Leygues
>> 2009/11/24 Anthony Ricaud <rik...@gmail.com>:
>>
>> > Pour les gens qui avaient le bug de Flash et wmode=transparent, c'est presque réglé dans Firefox 3.5 (comme le dit le bug mozilla)
>>
>> Jamais entendu parler d'un bug de Flash+ Mozilla[1], quelqu'un peut
>> nous en parler ?
Hello,
Lorsque le flash est en wmode="transparent", comme par exemple lorsque
tu as besoin de faire passer des éléments html comme un menu déroulant
par dessus un flash, toutes les zones de saisies d'un formulaire
remplacent les caractères saisie par d'autres.
Par exemple, tu saisies "@" qui est restitué dans le champ du flash
par "à", pas très pratique pour saisir une adresse mail. Et c'est pire
lorsque tu dois utiliser des polices cyrilliques par exemple.
Tu peux tester sur http://www.laroche-posay.fr
Adrien Leygues
>
> c'est juste le player flash linux, ouaip.
non c'est le cas sur FireFox par exemple:
https://bugzilla.mozilla.org/show_bug.cgi?id=338797
Julien Wajsberg
>
> 2009/11/30 Julien Wajsberg <fel...@gmail.com>:
>>
>> c'est juste le player flash linux, ouaip.
>
> non c'est le cas sur FireFox par exemple:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=338797
okep
le flash player linux ajoute juste le bug du "wmode n'est pas pris en
compte" alors
Yves Van Goethem
Suffit de taper "flash" sur bugzilla de Mozilla ;)
--
Yves Van Goethem
samuel
ça a l'air très appétissant tout ça. :)
Par contre qu'est ce que tu entends pas "Server Sent Events" ?
Le 30 novembre 2009 15:43, Yves Van Goethem
<yves.va...@gmail.com> a écrit :
Julien Wajsberg
du push ajax, mais natif :)
2009/11/30 samuel <zoul...@gmail.com>:
Adrien Leygues
>
MER ! Si je ne m'abuse c'est bien le principe utilisé dans node.js ?
je trouve ça énorme !
Julien Wajsberg
>
> 2009/11/30 Julien Wajsberg <fel...@gmail.com>:
>>
>> c'est ça : http://www.w3.org/TR/eventsource/
>>
>> du push ajax, mais natif :)
>
> MER ! Si je ne m'abuse c'est bien le principe utilisé dans node.js ?
> je trouve ça énorme !
mais de quoi tu parles, adrien ? :-)
Anthony Ricaud
Là c'est pour faire, côté client, du Comet en natif, sans se casser le chignon. Comme le dit Julien.
node.js, c'est pour faire du JS côté serveur.
Adrien Leygues
>
> Rien à voir avec node.js.
>
> Là c'est pour faire, côté client, du Comet en natif, sans se casser le chignon. Comme le dit Julien.
>
> node.js, c'est pour faire du JS côté serveur.
node.js est bien présenté comme "Server-Side Events Driven Server", du
moins c'est comme ça cela que je l'ai compris à Full Frontal.
En conséquence je fais le parallèle entre node.js qui envoie également
des données en push suite à un événement.
Julien Wajsberg
>
> 2009/11/30 Anthony Ricaud <rik...@gmail.com>:
>>
>> Rien à voir avec node.js.
>>
>> Là c'est pour faire, côté client, du Comet en natif, sans se casser le chignon. Comme le dit Julien.
>>
>> node.js, c'est pour faire du JS côté serveur.
>
> node.js est bien présenté comme "Server-Side Events Driven Server", du
> moins c'est comme ça cela que je l'ai compris à Full Frontal.
>
> En conséquence je fais le parallèle entre node.js qui envoie également
> des données en push suite à un événement.
C'est pas pareil; enfin, merci de m'avoir fait découvrir nodejs, ça a
l'air chouette :)
Comet, c'est un moyen pour le client JS de maintenir une connexion
permanente avec le serveur... et ce, quelque soit le serveur, que ce
soit du RoR, du PHP, du Java, ou du Node. Les server-sent events
(c'est pas pareil que server-side events, attention), c'est une spec
pour que ce genre de choses, assez pénibles à implémenter en JS (les
libs existantes font plusieurs ko), soit natif navigateur.
nodejs, c'est un moyen d'implémenter une logique serveur en JS... Donc
aucun rapport, même si tu peux faire du Comet avec.
--
Julien
samuel
merci pour le lien.
J'ai survolé tout ça vite fait mais aprioris c'est bien le navigateur
qui se charge de faire du comète : le navigateur fait des requêtes
http et attend la réponse.
Ce n'est pas encore le server qui envoie des messages quand il veut un
peu comme des socket ?
Nicolas Hoizey
Le 1 déc. 2009 à 09:53, samuel a écrit :
> J'ai survolé tout ça vite fait mais aprioris c'est bien le navigateur
> qui se charge de faire du comète : le navigateur fait des requêtes
> http et attend la réponse.
Des exemples en prod à grande échelle ?
> Ce n'est pas encore le server qui envoie des messages quand il veut un
> peu comme des socket ?
> Le 30 novembre 2009 21:17, Julien Wajsberg <fel...@gmail.com> a écrit :
>>
>> 2009/11/30 Adrien Leygues <aley...@gmail.com>:
>>>
>>> 2009/11/30 Anthony Ricaud <rik...@gmail.com>:
>>>>
>>>> Rien à voir avec node.js.
>>>>
>>>> Là c'est pour faire, côté client, du Comet en natif, sans se casser le chignon. Comme le dit Julien.
>>>>
>>>> node.js, c'est pour faire du JS côté serveur.
>>>
>>> node.js est bien présenté comme "Server-Side Events Driven Server", du
>>> moins c'est comme ça cela que je l'ai compris à Full Frontal.
>>>
>>> En conséquence je fais le parallèle entre node.js qui envoie également
>>> des données en push suite à un événement.
>>
>> C'est pas pareil; enfin, merci de m'avoir fait découvrir nodejs, ça a
>> l'air chouette :)
>>
>> Comet, c'est un moyen pour le client JS de maintenir une connexion
>> permanente avec le serveur... et ce, quelque soit le serveur, que ce
>> soit du RoR, du PHP, du Java, ou du Node. Les server-sent events
>> (c'est pas pareil que server-side events, attention), c'est une spec
>> pour que ce genre de choses, assez pénibles à implémenter en JS (les
>> libs existantes font plusieurs ko), soit natif navigateur.
>>
>> nodejs, c'est un moyen d'implémenter une logique serveur en JS... Donc
>> aucun rapport, même si tu peux faire du Comet avec.
>>
>> --
>> Julien
>>
>>>
>>
>
> >
--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/
samuel
>
> Lurker depuis peu, mais déjà connu par certains d'entre vous, je crois que c'est ma première contribution, alors bonjour... ;-)
Tu te dé-lurke ? ( je connaissais pas lurker mais heureusement que
wikipedia est là )
>
> Le 1 déc. 2009 à 09:53, samuel a écrit :
>> J'ai survolé tout ça vite fait mais aprioris c'est bien le navigateur
>> qui se charge de faire du comète : le navigateur fait des requêtes
>> http et attend la réponse.
>
> Oui, c'est ça. Et j'ai un doute sur la montée en charge de ce genre d'archi, vu qu'il faut conserver les connexions actives sur le serveur...
>
> Des exemples en prod à grande échelle ?
place ( tchat gpmail et facebook par exemple ) mais en regardant un
peu ce qu'il se passe sur le réseau avec firebug tu verras que c'est
assez fréquent.
Nicolas Hoizey
> Le 1 décembre 2009 10:33, Nicolas Hoizey <nic...@hoizey.com> a écrit :
>>
>> Lurker depuis peu, mais déjà connu par certains d'entre vous, je crois que c'est ma première contribution, alors bonjour... ;-)
>
> Salut bienvenue :)
> Tu te dé-lurke ?
Yep, faut savoir oser ! ;-)
> ( je connaissais pas lurker mais heureusement que
> wikipedia est là )
Ah oui, désolé pour l'anglais...
>> Le 1 déc. 2009 à 09:53, samuel a écrit :
>>> J'ai survolé tout ça vite fait mais aprioris c'est bien le navigateur
>>> qui se charge de faire du comète : le navigateur fait des requêtes
>>> http et attend la réponse.
>>
>> Oui, c'est ça. Et j'ai un doute sur la montée en charge de ce genre d'archi, vu qu'il faut conserver les connexions actives sur le serveur...
>>
>> Des exemples en prod à grande échelle ?
>
> Je crois que tous les sites à très grosses audiances l'ont mis en
> place ( tchat gpmail et facebook par exemple ) mais en regardant un
> peu ce qu'il se passe sur le réseau avec firebug tu verras que c'est
> assez fréquent.
OK, je creuserais ça si un jour j'en ai besoin...
Dire que j'ai développé un chat (phpMyChat) il y a dix ans et qu'on n'avait ni Ajax ni Comet... on tenait en gros 50 utilisateurs simultanés ! :-D
samuel
Coté server je ne pense pas que ce genre de requêtes soient destinée à
du php mais plus à des langages live qui ne doivent pas être trop
dérangés par ces connexions dormantes .
Nicolas Hoizey
> Comme l'a dit un célèbre poète français les temps changent.
> Coté server je ne pense pas que ce genre de requêtes soient destinée à
> du php mais plus à des langages live qui ne doivent pas être trop
> dérangés par ces connexions dormantes .
Julien Wajsberg
réduisant de beaucoup la complexité côté client JS.
Et peut-être que la spec W3C va englober la spec Bayeux, qui sait ? :)
2009/12/1 samuel <zoul...@gmail.com>:
Julien Wajsberg
>
> Oui, c'est ça. Et j'ai un doute sur la montée en charge de ce genre d'archi, vu qu'il faut conserver les connexions actives sur le serveur...
En fait, c'est effectivement pas super scalable sur les archis du type
"une connexion = un thread ou process", mais on s'en éloigne peu à
peu.
Côté Java (ce que je connais le mieux), Jetty a apporté le concept des
Continuations qui permettent de laisser dormir une requête; la spec
Servlet 3.0 va aussi apporter un mécanisme similaire (je sais pas où
on en est de sa définition).
Côté serveur Web, on a des choses comme lighttpd qui utilisent du code
événementiel pour aussi s'abstraire du "connexion = thread"... et à
mon avis, c'est justement pour permettre Comet sur une grande échelle.
--
Julien
Nicolas Hoizey
OK, merci pour ces précisions.
Anthony Ricaud
Pour les server sent events, vous pouvez jouer avec Opera et les nightlies WebKit.
Le 1 déc. 2009 à 09:53, samuel a écrit :
>
samuel
Julien Wajsberg
très bien avec des tableaux ?
2009/12/1 samuel <zoul...@gmail.com>:
samuel
Stephane Deschamps
En fait les premières CSS ont été introduites avec IE3 et pas IE4,
mais la moitié des contributeurs de ce groupe n'étaient pas encore
nés... ;)
On ne pouvait y faire que font-family et font-size, et seuls les
pixels marchaient normalement, le reste foirait terriblement (avec le
recul, c'en est cocasse, mais sur le moment je n'y connaissais rien,
c'était assez frustrant).
Pour revenir à IE4, il a été le premier à faire du positionnement CSS
(ou css-p) comme on disait alors, qui a permis les premières
expérimentations de mise en page CSS.
Pendant ce temps Netscape 3 ne faisait rien. Netscape 4 s'est tout de
même pas mal débrouillé de tout ça, mais il a souffert de la lutte
d'influence entre CSS et JSss (autrement dit la logique de Netscape
était d'implémenter un genre de CSS objet-orientée basée sur une
syntaxe de type javascript comme on la connaît aujourd'hui, et le truc
marrant c'est que son moteur CSS était désactivé dès qu'on désactivait
JS puisque, je suppose, basé sur un interpréteur de CSS en JS).
Voilà voilà.
Pour le reste je suis sincèrement passionné par ce que vous dites
tous, ça promet de jolies avancées en termes de performances.
2009/12/1 samuel <zoul...@gmail.com>:
> Oula ne nous énervons pas je parlai de priorité pas de nécessité.
> En tout cas pour IE4 je ne savais et je dois avouer que je ne m'en serais
> vraiment pas douté :)
>
> Le 1 décembre 2009 17:06, Julien Wajsberg <fel...@gmail.com> a écrit :
>>
>> Pourquoi IE4 a introduit CSS alors que, finalement, on s'en sortait
>> très bien avec des tableaux ?
--
Thomas Parisot // Oncle Tom
Ceci dit, les serveurs Web déploient des trésors d'ingéniosité pour arriver à palier à ces problèmes.
Nginx a récemment sorti Push Module qui va dans ce sens. PubSubHub via Jabber serait super efficace, et probablement plus performant. Event, event ... ;-)
C'est un sujet abordé dans un chapitre d'Event Faster Web Sites pour les curieux.
--
Thomas PARISOT
Consultant Web, accessibilité et respect des standards
http://case.oncle-tom.net/
http://twitter.com/oncletom
Mobile : +336 08 40 35 49
Julien Wajsberg
2009/12/1 Thomas Parisot // Oncle Tom <tho...@oncle-tom.net>:
Julien Wajsberg
Je suis pas loin de croire que c'est ce qui l'a tué.
2009/12/1 Stephane Deschamps <stephane....@gmail.com>:
Yves Van Goethem
Adrien Leygues
>
> Mais Netscape 4 souffrait d'un problème majeur : il ne supportait pas :hover :-)
>
> Je suis pas loin de croire que c'est ce qui l'a tué.
J'étais agence à ce moment là et ce qui l'a tué c'est notre ignorance
et éventuellement le fait que le site du W3C n'était pas du tout
attractif :
http://web.archive.org/web/20000510033830/www.w3.org/
http://web.archive.org/web/20010617192316/www.w3.org/
La ressource de l'époque pour nous c'était allhtml.com où chacun
faisait des retours sur son expérience propre et non sur des
recommandations officielles. Pour moi c'est venu un peu plus tard avec
pompage-list par ex.
Stephane Deschamps
> Mais Netscape 4 souffrait d'un problème majeur : il ne supportait pas :hover :-)
>
> Je suis pas loin de croire que c'est ce qui l'a tué.
Ce qui l'a tué à mon avis c'est un ensemble de choses, dont :
- manque de stabilité logicielle
- lenteurs énormes
- pas d'évol de Netscape pendant longtemps, le temps que le code
qu'ils ont ouvert soit apprivoisé par la communauté
- plantages *systématiques* quand une classe comportait un sous-tiret
- CSS en positions absolues : tu donnais à 5 éléments les mêmes
propriétés, et sans que tu saches pourquoi le premier était décalé de
N pixels vers le bas et la droite de temps en temps
- l'hallali final c'est l'introduction de IE4 en standard dans Windows
95, rendant caduque pour le profane le téléchargement d'un navigateur
alternatif... (et en plus le téléch en RTC c'était laborieux).
Enfin bref.
Julien Wajsberg
>
> 2009/12/2 Julien Wajsberg <fel...@gmail.com>:
>> Mais Netscape 4 souffrait d'un problème majeur : il ne supportait pas :hover :-)
>>
>> Je suis pas loin de croire que c'est ce qui l'a tué.
> - pas d'évol de Netscape pendant longtemps, le temps que le code
> qu'ils ont ouvert soit apprivoisé par la communauté
quand ils l'ont filé à la communauté, il était déjà mort.
si je parle du a:hover, c'est bien parce qu'il a fleuri partout sur le
web à ce moment-là, et que c'était joli sous IE.
Et si c'est joli... ça marche :)
Nicolas Hoizey
Alors qu'il était si simple de faire de jolies applets Java pour ça... ok, je sors...
Frank Taillandier
Et si c'est joli... ça marche :)
Frank Taillandier
Vincent Aniort
avancer les choses...
(pffffffff, on s'en fout, il est tout mort aussi !)
On 02/12/2009, Frank Taillandier <frank.ta...@gmail.com> wrote:
>>
>>
>> Et si c'est joli... ça marche :)
>>
>
Anthony Ricaud
Exemple d'utilisation des WebSockets côté client avec node.js côté serveur. Tu vois Adrien, c'est pas pareil :)