Pas plus que webkit. Je crois que tu confond Gecko et XulRunner (qui embarque en plus de gecko, toutes les apis genre gestion d'extension, le toolkit d'interfaces etc, bref, tout ce qui fait la plateforme).
XUL, ce n'est qu'un dialect XML affiché via une feuille de style CSS et utilisant en trés grande partie XBL (un autre dialecte XML) pour l'api des composants d'interface.
Bref, supporter XUL, c'est supporter l'affichage du XML (ce qui est exactement pareil que d'afficher du HTML, c'est le même code dans le moteur de rendu), les langages CSS et XBL.
Et finalement, webkit sait faire en grande partie tout ça (XML+CSS) et saura tout faire plus tard puisqu'il est prévu un support de XBL2 dans Webkit (je rappel que David Hyatt, core-dev de webkit et ex-mozillien, est l'inventeur de XBL et celui qui a fait les premières implémentation de XBL dans Gecko, donc je ne me fait pas de souci, webkit supportera à coup sûr XBL). Et alors, à partir de là, supporter un XUL like sera une étape bien maigre pour arriver au niveau de Gecko.
Mouai, ils se sont franchement pas casser le cul à se documenter sur le sujet.
Parce que si ils s'étaient renseigné un peu sur Mozilla 2, ils auraient su qu'un des objectifs majeurs de Mozilla 2, c'est de simplifier encore plus l'embarquement de gecko dans les applis tiers, avoir quelque chose de plus propre, plus léger, avec le support XPCOM supprimé en interne etc... Car il faut savoir qu'un autre objectif principal de Mozilla 2, c'est Mozilla Mobile, autrement dit l'utilisation de Gecko dans l'embarqué.
Bref, donc en gros, Mozilla 2 correspondra beaucoup plus à leurs exigences. C'est une très mauvaise raison qu'ils ont donné là.
>Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
C'est totalement faux ! Il y a des dizaines de logiciels qui embarquent gecko (je ne parle même pas de ceux qui sont basés sur XulRunner). eclipse, camino maemo, pour ne citer qu'eux.
>Rajoutons à cela que l'utilisation de Gecko est très compliquée (très peu parmi les dev Epiphany osent y toucher)
Gecko est complexe, mais webkit aussi. Faut pas se leurrer, un moteur de rendu, c'est très compliqué. Si les dev d'epiphany n'osent même pas toucher Gecko, ils ne le feront pas non plus pour webkit. Ça demande des compétences en programmation beaucoup plus fortes que celles nécessaires à faire une interface à un moteur de rendu. Des mecs comme David Hyatt (l'un des core-developer de Webkit, et ex-mozillien), capable donc de toucher à webkit sans tout casser, ça ne se trouve pas à tout les coins de rues.
>Un nombre incroyable de bugs d'Epiphany sont en fait des bugs de gecko et ne sont pas résolus dans Gecko [...] si quelqu'un décide de maintenir le backend Gecko, les patchs sont les bienvenus.
Acid2 est ok depuis l'alpha2 (et presque l'alpha1). Et acid1 aussi depuis des lustres (mais j'ai eu la flemme de réinstaller Mozilla 1.0 pour le montrer, désolé).
> gimp qui fait une réelle concurrence à photoshop (les goûts, les couleurs, mais pour le reste ya pas de différence fondamentale).
Je ne absolument pas d'accord avec toi. Bon déjà, les arguments avancés par les autres commentaires.
Mais aussi une chose qui pour moi, met gimp à la poubelle, et qui est, en tout cas pour moi carrément indispensable : avec photoshop, tu peux modifier les filtres et les effets après coup. Dans gimp, tu peux toujours te brosser (pas la peine de dire "on peut faire un undo", va donc faire un undo après 20 manipulations, et surtout va te rappeler des valeurs saisies pour lesdits effets...)
Bref, photoshop a des "killer features" qui font de gimp un truc pas utilisable (et je ne parlerais pas de son horrible interface qui n'arrange pas son cas).
Firefox 3 depuis ses premières alpha passe le test acid 2. (et acid1 depuis quelques années quand même).
(t'es en retard d'une beta, si ce n'est de 2, la beta5 sortant la semaine prochaine, les builds pour les RC de la beta5 sont en cours ;-) )
La dernière nightly a un score de 71/100. Mais ça n'ira probablement pas beaucoup au delà, et en tout cas, pas à 100/100. J'ai déjà expliqué les raisons ici : http://linuxfr.org/2008/03/06/23804.html#911455
Ils préfèrent fournir des trucs qui fonctionnent bien, qui sont utiles, avec le moins de bugs possibles, que de faire des trucs implémentées à la va vite juste pour satisfaire 3 douzaines de geek et un test qui n'a finalement aucune valeur intrinsèque (car très très loin d'être exhaustif, à titre de comparaison, il y a des dizaines de milliers de tests unitaires dans les sources de mozilla, et pourtant ils sont encore loin de couvrir l'ensemble du code et l'ensemble des specs des standards http://ljouanneau.com/blog/2008/03/14/768-tests-unitaires-da(...) ).
Sinon, faut savoir que pour certains tests foireux d'acid3, des patchs existent (voir la grille http://spreadsheets.google.com/pub?key=pNgBCwWdyRTT2JeiZn4B2(...) ) mais il est trop tard pour les inclure. Ils ne prennent pas de risque. La stabilité avant tout. FF3 est prévu pour juin (les RC pour début mai).
C'est qu'avec 25% de part de marché, et des millions de mise à jour à venir, c'est plus l'époque pour jouer à la roulette russe :-) (Si microsoft peut se permettre de livrer des versions beta^W "stable" de IE au grand public, ce n'est pas le cas de Mozilla)
>Quant à la persistance des objets, en JAVA comme en PHP il faut passer par une surcouche (EJB3, JDO, Hibernate etc.. pour JAVA, Propel, PEAR, EZPDO, Metastorage etc... pour PHP. ) incluse ou non dans un framework. Le Zend Framework en inclue une, tout comme Jelix, Symphony et consors
Ah non pas du tout. Ces couches dans PHP n'ont rien de persistant. Ce sont juste des couches "objets" par dessus les bases de données. Le terme "persistance" qu'emploi certains ORM php (comme EZ), c'est de la publicité mensongère ! Une fois la page exécutée, les objets correspondant aux enregistrements sont détruits (mais pas les enregistrements bien sûr).
PHP ne permet pas la persistance des objets, quels qu'ils soient. Une astuce de bricoleur, est de stocker les objets en sessions (serialisation, tout ça) mais ce n'est ni performant, ni pratique (va donc stocker en session les objets issues des résultats d'une requete SQL, si tu fais pas gaffe, ton serveur explose). On peut utiliser aussi des trucs comme sharedance http://sharedance.pureftpd.org/project/sharedance mais là encore, il y a de la serialisation/deserialisation derrière.
Avec un serveur Java, on a de la "vraie" persistance, en ce sens où les objets restent en vie entre chaque requête http cliente (ils ne sont pas serialisés ou quoi que ce soit..).
Mon cher Zorro, il y a des dates affichées à chaque commentaire, c'est pas fait pour les chiens. Tu remarqueras donc que ce commentaire est plus vieux que la sortie de Safari 3.1. Je n'ai pas encore des dons de divinitations, et je n'ai pas installé non plus ipot. Donc tu aurais pu t'abstenir de ton "Et pourtant" :-p
Ils sont embêtants tout ces développeurs qui améliorent leur logiciel et ajoutent des trucs chouettes à chaque version.
D'ailleurs c'est pareil avec le dernier Photoshop CS3. On arrive à le lancer sur la dernière babasse octo processor et tout, mais alors sur le vieux pentium 1, pas du tout. Alors que pourtant Photoshop 1.0 passait sans problème sur cette vieille bécane. Ok avec la 1.0, je peux pas faire les super effets de la mort qui tue, mais quand même, merde quoi.
C'est nul la technologie. Ça fait que progresser, et les trucs les plus modernes ne fonctionnent pas sur des machines qui sont pas fait pour. Pffff.
Ah tiens, pareil pour les bagnoles. J'aimerai utiliser le super carburateur top moumoute de la dernière BMW sur ma vieille 4L, et ben tenez vous bien : ça n'est pas possible !
Permet moi d'en douter. On ne devient pas champion du monde comme ça, et à mon avis, il jouait au poker bien avant qu'il y ait tout ces casinos en ligne.
Maintenant effectivement, les casinos en ligne (et leurs spams) ont certainement beaucoup plus contribué à la mode du poker que Bruel :-)
la différence c'est que tu n'a justement pas à installer de plugin. L'autre différence c'est que c'est beaucoup plus facile pour les développeurs à écrire cette balise que cette balise object toujours imbitable. Sans compter qu'il y a une api standardisée pour contrôler la lecture (start stop et cie). Ainsi le développeur peut fournir ses propres boutons. Mais si il ne veut pas s'embêter, il peut aussi laisser le navigateur afficher lui même les boutons de contrôle.
Une conséquence heureuse de tout ça est que cela améliore aussi l'accessibilité.
Il n'y a pas le support de la balise vidéo, non pas pour te faire chier, mais parce que ce n'était pas prêt. C'est aussi simple que cela. Pas la peine d'imaginer un complot contre le monde entier (sous entendu par ton "motivé par des raisons honnêtes").
D'ailleurs, tu as oublié webkit dans ton journal. Ouai parce qu'ils ont livrés KDE4 avec un konqueror qui ne supporte pas la balise video. Ouuuuuuhhh attention, ça va être l'apocalypse !!
Non mais franchement, en quoi ça va faire mal à la communauté ? IE8 implementera à peine les 3/4 de ce que propose Firefox technologiquement parlant. Aucun navigateur "stable" n'implémente la balise video. Bref, je vois pas où est le retard.
Bon et puis je ne vais pas discuter sur le fait que la spec de la balise n'est pas encore "stable"... (du genre au début elle recommandait ogg/theora, et puis après plus rien etc..)
Et puis si tu as une solution simple sur les problèmes de brevet sur les codec et cie, n'hésite pas à le faire savoir à Mozilla et Webkit.
ok je me suis trompé pour FF2 et acid2. Cependant FF 1.5 et FF 2.0 sont basés sur la même branche de Gecko (1.8.x), et les developpements pour pouvoir passer les tests acid2 ont été trop important et non terminé pour FF 2.0. Le backport était trop important (car les devs étaient fait dans une branche à part qui suivait le trunk).
>alors autant le secouer bien fort, une bonne fois pour toutes, qu'il rattrape son retard et rentre un peu dans le chemin,
C'est ce qui se passe. IE8 promet être une bonne release (avec des trucs de HTML5, full support de CSS2..), et risque bien de rentrer à nouveau dans la course. Quelques bémols toutefois : pas de support prévu de SVG, implementation de xmlhttprequest boiteuse (alors que le brouillon pour xmlhttprequest 2 vient de sortir au W3C) et plein d'autres petits trucs manquant qui vont laisser encore quelques avantages aux navigateurs alternatifs.
Non, hélas, Firefox 3 ne passera pas le test acid3. Ça restera bloqué donc au score de 67/100 (à peu prés).
Cette version stable de acid3 est sortie trop tard par rapport à la feuille de route de Firefox 3 (comme pour acid2 d'ailleurs, sorti trop tard pour Firefox 2). Il y a des bugs bloquants plus critiques ( en est la preuve cette beta 5) qu'un fail dans un test dont madame michu n'en a strictement rien à fiche (et la majorité des devs web aussi, à par ceux qui aiment faire des concours de celui qui a la plus grande).
Et si tu regardes bien justement les bugs dépendants : implémenter les animations SVG, les CSS media queries, ou encore le support de @font-face, ce ne sont pas des petites corrections que l'on peut faire en 3 jours, mais des implémentations qui prennent beaucoup de temps, plusieurs semaines.
Bref, ils ont d'autres chats à fouetter, et ils n'ont pas envie de repousser Firefox 3 à novembre ;-)
Peut être pour la release suivante de Firefox donc..
Et puis faut arrêter aussi de donner une grande importance aux tests acid. D'une part parce que ça ne test pas tout (d'autant plus que acid3 test un peu tout et n'importe quoi), mais ensuite parce que ça test beaucoup de choses qu'on utilise rarement. Quand je regarde le source de feuilles de style dans les sites web, je me marre en voyant que la grande majorité de développeurs ne savent utiliser que 2-3 types de selecteurs sur les dizaines que comptent CSS2 ou CSS3 (alors que bon, même avec IE6 on peut en utiliser pas mal).
Bref, passer un test acid, c'est bien, mais ne pas le passer n'a jamais empêché de faire des sites web corrects. Et c'est pas un test acid OK qui va apprendre aux devs web d'arrêter de mettre des classes partout et d'utiliser autre chose que des ".truc" à tout bout de champs dans leurs feuilles CSS.
Et de toute façon, tant que ces bouses infâmes de IE6 et IE7 auront encore le monopole, tu pourras toujours te brosser en attendant de pouvoir utiliser les animations SVG ou je ne sais quoi d'autres.
PS: moi aussi j'aimerai que ça passe acid3, et d'ailleurs même que le nombre de bugs ouverts dans le bugzilla soit proche de 0.
>ben il est bon que ca sorte de temps en temps aussi, ne dit-on pas release often ?
Sauf quand on a des millions d'utilisateurs. Tu ne peux pas te contenter de balancer des releases *majeures* à tout va, au risque de laisser passer des trous de sécurité, des bugs qui font crasher le truc, et donc au risque de décevoir une majorité de gens, etc... Et puis ça le fout mal pour une release majeure, d'avoir des bugs critiques.
à propos de release often, je te signal que c'est le cas pour les releases correctives, hein...
Plus sérieusement. la beta 4 sort d'ici une semaine normalement. La beta 5 d'ici la fin du mois, et c'est la dernière beta si tout se passe bien. en comptant large on va donc dire que la finale sortira un mois après la beta5 (le temps des RC). On peut donc tabler sur une release fin avril, courant mai.
voilà quelques = 8 à 10 semaines si tout va bien, selon ma propre estimation, ce n'est pas un chiffre officiel.. Aucune date officielle. Ça sortira quand ça sera prêt. As usual.
Je ne comprend pas. Dans les commentaires plus haut, on se félicite du superbe score de webkit sur acid3, dans sa version en développement, et on n'a pas le droit de dire que Firefox 3.0 depuis les releases officielles de ses versions alpha et beta, passe le test acid 2, sans se faire moinsser ? (d'autant plus que la sortie de FF3 est prévue d'ici quelques semaines)
Thunderbird est un nom déposé par Mozilla. Vu qu'il s'agit d'un thunderbird pas mal patché, ce n'est plus le produit Thunderbird, mais un produit dérivé. Donc je pense qu'il y a la même problématique que pour l'usage du nom Firefox sur un produit dérivé de Firefox : tu n'as pas le droit.
[^] # Re: les buts divergent (et divergent, c'est trop)
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 4.
Pas plus que webkit. Je crois que tu confond Gecko et XulRunner (qui embarque en plus de gecko, toutes les apis genre gestion d'extension, le toolkit d'interfaces etc, bref, tout ce qui fait la plateforme).
XUL, ce n'est qu'un dialect XML affiché via une feuille de style CSS et utilisant en trés grande partie XBL (un autre dialecte XML) pour l'api des composants d'interface.
Bref, supporter XUL, c'est supporter l'affichage du XML (ce qui est exactement pareil que d'afficher du HTML, c'est le même code dans le moteur de rendu), les langages CSS et XBL.
Et finalement, webkit sait faire en grande partie tout ça (XML+CSS) et saura tout faire plus tard puisqu'il est prévu un support de XBL2 dans Webkit (je rappel que David Hyatt, core-dev de webkit et ex-mozillien, est l'inventeur de XBL et celui qui a fait les premières implémentation de XBL dans Gecko, donc je ne me fait pas de souci, webkit supportera à coup sûr XBL). Et alors, à partir de là, supporter un XUL like sera une étape bien maigre pour arriver au niveau de Gecko.
# erreur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 8.
Mouai, ils se sont franchement pas casser le cul à se documenter sur le sujet.
Parce que si ils s'étaient renseigné un peu sur Mozilla 2, ils auraient su qu'un des objectifs majeurs de Mozilla 2, c'est de simplifier encore plus l'embarquement de gecko dans les applis tiers, avoir quelque chose de plus propre, plus léger, avec le support XPCOM supprimé en interne etc... Car il faut savoir qu'un autre objectif principal de Mozilla 2, c'est Mozilla Mobile, autrement dit l'utilisation de Gecko dans l'embarqué.
Bref, donc en gros, Mozilla 2 correspondra beaucoup plus à leurs exigences. C'est une très mauvaise raison qu'ils ont donné là.
[^] # Re: Persch
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à -1.
>Gecko n'est pas conçu pour être réutilisé par d'autre navigateur
Ce qui est absolument faux.
[^] # Re: Re:
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 5.
C'est totalement faux ! Il y a des dizaines de logiciels qui embarquent gecko (je ne parle même pas de ceux qui sont basés sur XulRunner). eclipse, camino maemo, pour ne citer qu'eux.
Y a même des docs pour embarquer Gecko : http://developer.mozilla.org/en/docs/Gecko_Embedding_Basics
[^] # Re: Re:
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Epiphany va migrer vers du 100% WebKit. Évalué à 2.
Gecko est complexe, mais webkit aussi. Faut pas se leurrer, un moteur de rendu, c'est très compliqué. Si les dev d'epiphany n'osent même pas toucher Gecko, ils ne le feront pas non plus pour webkit. Ça demande des compétences en programmation beaucoup plus fortes que celles nécessaires à faire une interface à un moteur de rendu. Des mecs comme David Hyatt (l'un des core-developer de Webkit, et ex-mozillien), capable donc de toucher à webkit sans tout casser, ça ne se trouve pas à tout les coins de rues.
>Un nombre incroyable de bugs d'Epiphany sont en fait des bugs de gecko et ne sont pas résolus dans Gecko [...] si quelqu'un décide de maintenir le backend Gecko, les patchs sont les bienvenus.
Tes deux citations sont franchements paradoxales.
[^] # Re: Récidive
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Webkit passe l'acid test 3. Évalué à 2.
Des captures d'écrans sur différentes versions de firefox de acid1, acid2, acid3 : http://ljouanneau.com/standards/acid/
Acid2 est ok depuis l'alpha2 (et presque l'alpha1). Et acid1 aussi depuis des lustres (mais j'ai eu la flemme de réinstaller Mozilla 1.0 pour le montrer, désolé).
[^] # Re: Flash...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Inkscape 0.46 est disponible. Évalué à 6.
Je ne absolument pas d'accord avec toi. Bon déjà, les arguments avancés par les autres commentaires.
Mais aussi une chose qui pour moi, met gimp à la poubelle, et qui est, en tout cas pour moi carrément indispensable : avec photoshop, tu peux modifier les filtres et les effets après coup. Dans gimp, tu peux toujours te brosser (pas la peine de dire "on peut faire un undo", va donc faire un undo après 20 manipulations, et surtout va te rappeler des valeurs saisies pour lesdits effets...)
Bref, photoshop a des "killer features" qui font de gimp un truc pas utilisable (et je ne parlerais pas de son horrible interface qui n'arrange pas son cas).
[^] # Re: Il n'y a qu'un navigateur à éviter.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Webkit passe l'acid test 3. Évalué à 10.
(t'es en retard d'une beta, si ce n'est de 2, la beta5 sortant la semaine prochaine, les builds pour les RC de la beta5 sont en cours ;-) )
La dernière nightly a un score de 71/100. Mais ça n'ira probablement pas beaucoup au delà, et en tout cas, pas à 100/100. J'ai déjà expliqué les raisons ici : http://linuxfr.org/2008/03/06/23804.html#911455
Il y en a d'autres ici, de shaver (de Mozilla) http://shaver.off.net/diary/2008/03/27/the-missed-opportunit(...)
Ils préfèrent fournir des trucs qui fonctionnent bien, qui sont utiles, avec le moins de bugs possibles, que de faire des trucs implémentées à la va vite juste pour satisfaire 3 douzaines de geek et un test qui n'a finalement aucune valeur intrinsèque (car très très loin d'être exhaustif, à titre de comparaison, il y a des dizaines de milliers de tests unitaires dans les sources de mozilla, et pourtant ils sont encore loin de couvrir l'ensemble du code et l'ensemble des specs des standards http://ljouanneau.com/blog/2008/03/14/768-tests-unitaires-da(...) ).
Sinon, faut savoir que pour certains tests foireux d'acid3, des patchs existent (voir la grille http://spreadsheets.google.com/pub?key=pNgBCwWdyRTT2JeiZn4B2(...) ) mais il est trop tard pour les inclure. Ils ne prennent pas de risque. La stabilité avant tout. FF3 est prévu pour juin (les RC pour début mai).
C'est qu'avec 25% de part de marché, et des millions de mise à jour à venir, c'est plus l'époque pour jouer à la roulette russe :-) (Si microsoft peut se permettre de livrer des versions beta^W "stable" de IE au grand public, ce n'est pas le cas de Mozilla)
[^] # Re: Durée de vie des objets et connexions permanentes...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Zend Framework 1.5 : consolidation et disponibilité. Évalué à 4.
Ah non pas du tout. Ces couches dans PHP n'ont rien de persistant. Ce sont juste des couches "objets" par dessus les bases de données. Le terme "persistance" qu'emploi certains ORM php (comme EZ), c'est de la publicité mensongère ! Une fois la page exécutée, les objets correspondant aux enregistrements sont détruits (mais pas les enregistrements bien sûr).
PHP ne permet pas la persistance des objets, quels qu'ils soient. Une astuce de bricoleur, est de stocker les objets en sessions (serialisation, tout ça) mais ce n'est ni performant, ni pratique (va donc stocker en session les objets issues des résultats d'une requete SQL, si tu fais pas gaffe, ton serveur explose). On peut utiliser aussi des trucs comme sharedance http://sharedance.pureftpd.org/project/sharedance mais là encore, il y a de la serialisation/deserialisation derrière.
Avec un serveur Java, on a de la "vraie" persistance, en ce sens où les objets restent en vie entre chaque requête http cliente (ils ne sont pas serialisés ou quoi que ce soit..).
# TCPDF
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Zend Framework 1.5 : consolidation et disponibilité. Évalué à 5.
En même temps, ça fait longtemps que FPDF a un successeur, qui supporte l'UTF8 et d'autres évolutions : TCPDF
http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcp(...)
[^] # Re: soulant
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pas de ogg/theora/vorbis dans firefox 3. Évalué à 3.
[^] # Re: Mon pc est orphelin...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 2008 L'Odyssée de Arthur C. Clarke. Évalué à 2.
[^] # Re: 200 Mo ???
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Firefox et consommation de mémoire. Évalué à 7.
Ils sont embêtants tout ces développeurs qui améliorent leur logiciel et ajoutent des trucs chouettes à chaque version.
D'ailleurs c'est pareil avec le dernier Photoshop CS3. On arrive à le lancer sur la dernière babasse octo processor et tout, mais alors sur le vieux pentium 1, pas du tout. Alors que pourtant Photoshop 1.0 passait sans problème sur cette vieille bécane. Ok avec la 1.0, je peux pas faire les super effets de la mort qui tue, mais quand même, merde quoi.
C'est nul la technologie. Ça fait que progresser, et les trucs les plus modernes ne fonctionnent pas sur des machines qui sont pas fait pour. Pffff.
Ah tiens, pareil pour les bagnoles. J'aimerai utiliser le super carburateur top moumoute de la dernière BMW sur ma vieille 4L, et ben tenez vous bien : ça n'est pas possible !
Monde de merde.
[^] # Re: Qui a lancé la mode ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Linux et le Poker. Évalué à 0.
Permet moi d'en douter. On ne devient pas champion du monde comme ça, et à mon avis, il jouait au poker bien avant qu'il y ait tout ces casinos en ligne.
Maintenant effectivement, les casinos en ligne (et leurs spams) ont certainement beaucoup plus contribué à la mode du poker que Bruel :-)
[^] # Re: bof
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pas de ogg/theora/vorbis dans firefox 3. Évalué à 2.
Une conséquence heureuse de tout ça est que cela améliore aussi l'accessibilité.
http://ljouanneau.com/blog/2007/04/17/659-la-balise-video
# soulant
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pas de ogg/theora/vorbis dans firefox 3. Évalué à 7.
Il n'y a pas le support de la balise vidéo, non pas pour te faire chier, mais parce que ce n'était pas prêt. C'est aussi simple que cela. Pas la peine d'imaginer un complot contre le monde entier (sous entendu par ton "motivé par des raisons honnêtes").
D'ailleurs, tu as oublié webkit dans ton journal. Ouai parce qu'ils ont livrés KDE4 avec un konqueror qui ne supporte pas la balise video. Ouuuuuuhhh attention, ça va être l'apocalypse !!
Non mais franchement, en quoi ça va faire mal à la communauté ? IE8 implementera à peine les 3/4 de ce que propose Firefox technologiquement parlant. Aucun navigateur "stable" n'implémente la balise video. Bref, je vois pas où est le retard.
Bon et puis je ne vais pas discuter sur le fait que la spec de la balise n'est pas encore "stable"... (du genre au début elle recommandait ogg/theora, et puis après plus rien etc..)
Et puis si tu as une solution simple sur les problèmes de brevet sur les codec et cie, n'hésite pas à le faire savoir à Mozilla et Webkit.
[^] # Re: Firefox3 et Acid 3.0
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 3.
>alors autant le secouer bien fort, une bonne fois pour toutes, qu'il rattrape son retard et rentre un peu dans le chemin,
C'est ce qui se passe. IE8 promet être une bonne release (avec des trucs de HTML5, full support de CSS2..), et risque bien de rentrer à nouveau dans la course. Quelques bémols toutefois : pas de support prévu de SVG, implementation de xmlhttprequest boiteuse (alors que le brouillon pour xmlhttprequest 2 vient de sortir au W3C) et plein d'autres petits trucs manquant qui vont laisser encore quelques avantages aux navigateurs alternatifs.
[^] # Re: pas tout à fait
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 2.
Pardon, annonce officielle incessament sous peu certainement. Elle est sur les ftp.
[^] # Re: Firefox3 et Acid 3.0
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 8.
Cette version stable de acid3 est sortie trop tard par rapport à la feuille de route de Firefox 3 (comme pour acid2 d'ailleurs, sorti trop tard pour Firefox 2). Il y a des bugs bloquants plus critiques ( en est la preuve cette beta 5) qu'un fail dans un test dont madame michu n'en a strictement rien à fiche (et la majorité des devs web aussi, à par ceux qui aiment faire des concours de celui qui a la plus grande).
Et si tu regardes bien justement les bugs dépendants : implémenter les animations SVG, les CSS media queries, ou encore le support de @font-face, ce ne sont pas des petites corrections que l'on peut faire en 3 jours, mais des implémentations qui prennent beaucoup de temps, plusieurs semaines.
Bref, ils ont d'autres chats à fouetter, et ils n'ont pas envie de repousser Firefox 3 à novembre ;-)
Peut être pour la release suivante de Firefox donc..
Et puis faut arrêter aussi de donner une grande importance aux tests acid. D'une part parce que ça ne test pas tout (d'autant plus que acid3 test un peu tout et n'importe quoi), mais ensuite parce que ça test beaucoup de choses qu'on utilise rarement. Quand je regarde le source de feuilles de style dans les sites web, je me marre en voyant que la grande majorité de développeurs ne savent utiliser que 2-3 types de selecteurs sur les dizaines que comptent CSS2 ou CSS3 (alors que bon, même avec IE6 on peut en utiliser pas mal).
Bref, passer un test acid, c'est bien, mais ne pas le passer n'a jamais empêché de faire des sites web corrects. Et c'est pas un test acid OK qui va apprendre aux devs web d'arrêter de mettre des classes partout et d'utiliser autre chose que des ".truc" à tout bout de champs dans leurs feuilles CSS.
Et de toute façon, tant que ces bouses infâmes de IE6 et IE7 auront encore le monopole, tu pourras toujours te brosser en attendant de pouvoir utiliser les animations SVG ou je ne sais quoi d'autres.
PS: moi aussi j'aimerai que ça passe acid3, et d'ailleurs même que le nombre de bugs ouverts dans le bugzilla soit proche de 0.
[^] # Re: Firefox3 et Acid 3.0
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 2.
Sauf quand on a des millions d'utilisateurs. Tu ne peux pas te contenter de balancer des releases *majeures* à tout va, au risque de laisser passer des trous de sécurité, des bugs qui font crasher le truc, et donc au risque de décevoir une majorité de gens, etc... Et puis ça le fout mal pour une release majeure, d'avoir des bugs critiques.
à propos de release often, je te signal que c'est le cas pour les releases correctives, hein...
[^] # Re: pas tout à fait
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 1.
Ouvre un dictionnaire.
Plus sérieusement. la beta 4 sort d'ici une semaine normalement. La beta 5 d'ici la fin du mois, et c'est la dernière beta si tout se passe bien. en comptant large on va donc dire que la finale sortira un mois après la beta5 (le temps des RC). On peut donc tabler sur une release fin avril, courant mai.
voilà quelques = 8 à 10 semaines si tout va bien, selon ma propre estimation, ce n'est pas un chiffre officiel.. Aucune date officielle. Ça sortira quand ça sera prêt. As usual.
[^] # Re: Tests sur mac
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 1.
[^] # Re: pas tout à fait
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 1.
[^] # Re: Gardez Thunderbird dans le nom!
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Le projet Milimail désire changer de nom. Évalué à 4.
[^] # Re: tout à fait ok
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Concours de t-shirts firefox 3. Évalué à 4.
> In future contests, we will consider using a free license for all submissions
Bref, ça risque bien de se faire pour les prochains concours. Je ne vois pas ce qu'il te faut de plus. Il n'y a pas de quoi polémiquer.