Logiciel : David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror
Posté par Laurent J (page perso, ). Modéré le 28 avril 2005.
Cerise sur le gâteau, David Hyatt fourni les patches des corrections appliqués dans le moteur KHTML, qui, rappelons-le, est basé sur le moteur (open source en licence LGPL) de Safari mais également de Konqueror, le navigateur fourni avec KDE. On peut donc parier que les prochaines versions de Konqueror passeront également ce test avec succès.
Le test Acid2 vise à juger du degré d'implémentation de CSS 2 dans un navigateur. Il contient une page HTML comportant des balises HTML sur chaque ligne du dessin. Chaque ligne se voit attribuer des styles et sélecteurs spécifiques, et montre donc le résultat de l'implémentation d'une fonctionnalité de CSS. Si le résultat de l'affichage de cette page web est identique au dessin attendu, alors l'implémentation de CSS 2 dans le navigateur est théoriquement conforme à la spécification CSS 2.
Concernant Gecko (moteur de Firefox et Mozilla), d'après Robert O'Callahan, développeur Mozillien, ils sont un peu en retard sur ce qui avait été prévu pour la sortie de Gecko 1.8, et qu'ils ont des bugs plus urgent à corriger que les bugs CSS montrés par le test Acid2. Il va donc falloir patienter quelques mois...
NdM : le KHTML de Safari diffère de celui de Konqueror, ce qui pose problème pour l'intégration des patchs. Voir les commentaires.
![[en]](../images/en.png)
L'annonce de David Hyatt et les patches (846 hits)-
Le test Acid2 (2822 hits)
-
Konqueror (535 hits)
-
Safari (639 hits)
![[fr]](../images/fr.png)
Des captures de résultats de tests sur d'autres navigateurs (4058 hits)-
Acid : comment ça marche ? (947 hits)
> Lire la dépêche (109 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #568436.
Run by 
Cette page a été générée par Templeet en 0.1055s (dont 0.009 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Alors...
C ki ki disait qu'Apple ne contribuait pas à l'Open Source ???
;o)
[^]Re: Alors...
Ca dépends ce qu'on entends par contribuer.
Si contribuer c'est fournir les sources à un projet tierce alors on peut dire qu'Apple contribue à tous les projets GPL de la planète.
Maintenant si contribuer à un projet c'est fournir travailler en collaboration (même CVS, même mailing-list,...) avec un projet tierce en fournissant des patchs qui s'appliquent bien à ce projet. Alors non dans ce cas Apple ne contribue pas à ce projet.
Apple contribue aux libres en fournissant les sources mais Apple ne travaille pas sur le moteur de Konqueror. Ils ont juste fait un fork de khtml (je ne le leur reproche pas) dont ils ont conservé comme nom "khtml" (Ca je le leur reproche).
[^]Re: Alors...
>Si contribuer c'est fournir les sources à un projet tierce alors on peut dire qu'Apple contribue à tous les projets GPL de la planète.
Contribue, contribue. Bon, ne crachons pas sur le fait qu'une entreprise améliore un logiciel Libre. Mais ne leur léchons pas non plus les pieds, ce n'est pas une fleur qu'ils font là, ils remplissent leur obligation légale de publier les sources puisque le soft est GPL. Encore heureux donc qu'ils publient les sources de la correction.
OK, ils contribuent, mais ce n'est pas à sens unique, je ne pense qu'ils aient choisi le moteur de Konqueror simplement pour pouvoir contribuer, mais aussi parce que ça leur évitait de tout redévelopper.
Rappelons donc c'est une entraide et non pas seulement "un cadeau d'Apple" comme certains semblent le penser.
[^]Re: Alors...
Ben oui hein. Et personne n'a besoin ni envie de lécher les pieds d'Apple. C'est si irritant que ça qu'une entreprise commerciale contribue à faire avancer les choses?
Exact, et ils avaient le droit. Et s'ils ont choisi KHTML c'est tout bêtement parce que c'est le moteur le plus compact
Là pour le coup tu sembles être le seul à le penser. Apple ne fait que se conformer à la GPL
[^]Re: Alors...
C'est l'expression utilisée par Laurent qui m'a fait réagir de la sorte :
Rassure toi, je ne suis pas irrité, au contraire. Mais c'est juste qu'Apple mène une politique pour le moins controversée vis à vis du Libre et qu'il me semblait utile de rappeler le fait que ce soit bien une obligation et non une "Cerise sur le gâteau", même si c'est très bien dans l'absolu puisque ça contribue à l'amélioration du libre :-).
[+] [^]Re: Alors...
rha ben oui mais toi aussi hein, tu fais ton soupe-au-lait. :D
Je suis un MacUser depuis longtemps mais j'ai toujours essayé de garder les yeux ouverts. Je sais bien que l'attitude d'Apple vis-à-vis du libre est sujette à critiques, mais avec KHTML ils ont toujours été corrects. C'est pas les gars de KDE qui diront le contraire ;-)
Ce que je trouve cool dans cette histoire c'est que tous les patches sont dispos et que "demain" on peut avoir un Konqueror au top.
Mais j'attends la "réaction" de Moz, je l'espère rapide parce que même si Safari est cool, Firefox pour le Webdesign c'est quand même le top
[^]Re: Alors...
>C'est pas les gars de KDE qui diront le contraire ;-)
Ah, c'est surement pour ca que depuis le fork de khtml par Apple, j'entends les developpeurs de Kde se pleindrent du comportement d'Apple, de l'impossibilité d'intégrer leur modifications, ...
D'ailleurs, on parle pas d'Apple la mais d'un développeur de Safari qui fournit les patch pour khtml. Alors certe c'est une très bonne chose mais je pense qu'il faut raison garder avant d'envoyer des fleurs à Apple.
L'avenir nous dira si cet évenement marque un changement de politique de la part d'Apple vis à vis de khtml.
[^]Re: Alors...
En tout cas il y a deux jours un développeur de chez Apple a annoncé sur la liste de diffusion de GNUstep avoir soumis des patchs pour le support de l'Objective-C et de l'Objective-C++ dans gcc.
Initiatives isolées ou changement de politique ?
[^]Re: Alors...
Heu
C'est normal de leur part qu'ils patchent gcc pour l'obj-c/c++ : ils l'utilisent et le fournissent avec leur MacOS X, et emploient ces langages !
[^]Re: Alors...
>C'est normal de leur part qu'ils patchent gcc pour l'obj-c/c++
Oui sauf qu'Apple a longtemps trainé pour montrer le code.
De plus il semblerait que Apple patch gcc pour que le runtime objectiv-C de GNU *ne puisse pas fonctionner* avec leur gcc.
[^]Re: Alors...
Heu, non pas exactement hein !!!
Oui, pour le moment le gcc d'apple ne permet pas de compiler GNUstep (ou autre projet utilisant le runtime GNU). Pour compiler GNUstep sous MacOSX ou Darwin, il faut recompiler un gcc FSF ...
Mais ce n'est pas une question de patcher gcc *exprès* pour que le runtime ne marche pas, c'est juste qu'ils en avaient pas grand chose à fiche à l'époque (on peut les comprendre, améliorer/optimiser gcc et le runtime NeXT était largement plus prioritaire pour eux comme boulot !). Ceci dit, Andrew Pinski et Zem Laski ont (si je ne me trompe pas) commité ce qu'il fallait pour que ça passe, donc bon, avec un peu de chance (je ne sais pas quelle version de gcc est livré avec XCode2) ça marche directement maintenant; sinon, ça sera probablement pour la version suivante, mais on est loin d'un complot contre le runtime GNU hein :-P
Côté gcc FSF, on aura probablement ObjC++ pour la prochaine release mineure...
Pour rappel ce qu'on pouvait lire à propos de la release 4.0 sur le wiki de gcc:
In addition, the GCC Steering Committee has promised Apple (Zem Laski) that we will get Objective-C++ into GCC 4.0. Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. (Update) Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.
:-)
Mais bon, Mike Stump a l'air de pousser les choses un peu plus que Laski (et je trouve que c'est sympa à lui d'avoir envoyé un mail sur discuss-gnustep pour dire ce qu'il faisait).
[^]Re: Alors...
Pas autant "normal" que ça, pour la simple raison qu'Objective-C nécessite un runtime; et Apple utilise un runtime (le runtime de NeXT) qui est différent du runtime utilisé par GNUstep (il s'agit du runtime GNU). Ca fait longtemps qu'Apple a mis à disposition ses patchs concernant Objective-C++, mais si ce n'est toujours pas officiellement intégré à gcc, c'est que ça nécessitait une tripotée de changements:
- dans les frontends C/C++/ObjC
- dans le runtime
Comme en plus ça a "coincidé" avec le gros nettoyage C++ chez gcc... c'est resté en plan. Un nouveau mainteneur vient d'être récemment nommé (Mike Stump, voir http://gcc.gnu.org/ml/gcc/2005-04/msg01178.html)(...) et il a posté un message indiquant qu'il passait ObjC++ sur la mainline mardi soir (plus une série d'améliorations, dont certaines assez intéressantes ;-)
Bref, les choses bougent enfin, donc cool.
[^]Re: Alors...
Ca vois-tu je suis curieux d'apprendre. Qu'est ce qui pose probleme? Est ce que c'est du au fait qu'Apple a tellement modifié KHTML que cela complique le boulot des devs KDE?
LE papa de Safari. Bon, on est pas crétins au point de croire qu'il est tout seul mais c'est le seul qui semble être le plus communiquant et le plus actif.
[^]Re: Alors...
Apple a bossé plus d'un an dans son coin sur une version de KHTML et a ensuite sorti Safari et le KHTML qu'ils avaient modifié (Webcore).
Sauf qu'en un an KHTML (le vrai) a eu le temps de beaucoup changer et intégré les modifications de Safari est d'autant plus difficile, et inversement.
C'est pourquoi on a maintenant 2 moteurs totallement différents qui ne sont pas au même niveau dans plusieurs domaines.
Qui plus est le normes de codage de Apple et du projet KDE diffèrent donc un patch doit être travaillé, et étudié avant d'être intégré.
A noter que KHTML supporte maintenant lui aussi la propriété shadow de CSS3 (de meilleur façon que WebCore) mais de façon différente.
A noter aussi que KHTML supporte maintenant aussi les numérotations des éléments via CSS (Opera l'ayant devancé et Safari et Mozilla ne le supportant pas encore).
[^]Re: Alors...
FWIW, ca arrive dans gecko, un patch a été intégré dans le tronc le premier avril (mais ce n'est pas un poisson :), ca devrait donc arriver a terme dans FF 1.0 avec un peu de bol. Pour plus d'infos, suivez ce bug: https://bugzilla.mozilla.org/show_bug.cgi?id=3247(...)
[^]Re: Alors...
Lire le commentaire de Zack Rusin sur son blog.
http://www.kdedevelopers.org/node/view/1001(...)
Une traduction rapide et résumée:
Les patches de Safari ne seront probablement jamais inclus dans KHTML. Les différentes améliorations devront être ré-implémentées "from scratch"
Certaines partie du code de safari dépendent de l'API de OS X. Les changement dans safari sont interdépendants. Apple ne donne pas d'historique de modifications, ils sortent juste une nouvelle version de leur webcore complet périodiquement.
Malgré les requête de certain développeur de signer des NDA pour avoir accès aux changement incrémentals.
En gros, ils font juste le strict minimum pour respecter la LGPL.
Et ils sont dans leur droit.
Autrefois, si un développeur passait des heures pour implémenter quelque chose dans KHTML, il était bien remercié. Maintenant, on lui dit plutôt: « C'est pas trop tôt ! Ça fonctionnais déjà avec Safari depuis longtemps. Les développeur de Konqueror sont vraiment paresseux »
Tout ce qu'il souhaite, c'est qu'on arrête de parler de la coopération entre Safari et Konqueror [Ce que fait cette dépèche]
!!!NOUVEAU!!!
[^]Re: Alors...
tu m'a devancé, ca a effectivement l'air de les gonfler un peu la comparaison KHTML/Safari
[^]Re: Alors...
> Certaines partie du code de safari dépendent de l'API de OS X.
De Safari, je veux bien (de toute manière, Safari n'est pas libre). Mais de WebCore, en est-on si sûrs ? Non pas que je veuille mettre en doute les dires d'un dev de KDE, mais apparemment, des gens ont pu prendre le WebCore et le porter sous GTK+ [http://gtk-webcore.sourceforge.net/(...)]. Le béotien que je suis aurait donc tendance à penser qu'il n'est pas si lié que ça à MacOS X…
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™
[^]Re: Alors...
Dans le cas de l'intégration d'ObjectiveC++ dans la branche principale de GCC, c'est manifestement des personnes de chez Apple qui font la majeure partie du boulot : le mainteneur du frontend ObjC++ - Mike Stump, de mémoire - signe ses posts avec une adresse @apple.com. Après, il fait peut-être cela sur son temps libre, mais la plupart des gens qui bougent alentour semblent également être de chez Apple.
J'ai pas d'actions chez ces gens-là (j'ai même pas de matériel de chez eux), mais je trouve qu'il y a largement pire en matière de collaboration avec le libre.
[^]Re: Alors...
Ils ont changé le nom, ils ont appelé ça “Webcore”
La dépêche contient donc une erreur à ce niveau là.
Les patches ne sont donc pas applicables tels quels à KHTML
!!!NOUVEAU!!!
[^]Re: Alors...
Négatif. Je parle du nom utilisé par le navigateur pour s'identifier ou pour les attributs CSS propriétaires.
Webcore utilise bel et bien -khtml-* comme notation ce qui fait qu'entre Webcore et KHTML c'est la merde.
Merci Apple pour avoir fait un fork sans faire un fork propre qui ne dérange pas le logiciel original :(
[^]Re: Alors...
comme Internet Explorer alors, qui s'identifie comme Mozilla depuis des lustres ?
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90)
Mozilla/4.0 (compatible; MSIE 5.14; Mac_PowerPC)
Microsoft Internet Explorer/666.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021208 Debian/1.2.7-5
(oui, bon, j'ai des doutes sur la santé mentale du dernier)
Windows has no users. It has hostages.
[^]Re: Alors...
> comme Internet Explorer alors, qui s'identifie comme Mozilla depuis des lustres ?
C'est plutôt le contraire, non ?
[^]Re: Alors...
non. IE, par le fait d'inclure la chaine "mozilla" dans son user agent, indique qu'il se fait passer pour Mozilla, où plutot pour netscape à l'origine. (en fait, c'est pour emmerder le monde, et tirer la langue à netscape)
Mozilla = un nom inventé par les fondateurs de Netscape, et signifie Mosaic Killer (killer = gozilla), Mosaic étant l'un des touts premiers (le premier meme il me semble) navigateur web graphique. (souvenir souvenir...)
Le moteur de IE, quant à lui, est dérivé de celui de Mosaic (voir les infos de copyright dans la boite "à propos" de IE).
[^]Re: Alors...
Non.
Voir la petite histoire des user-agent ou "Comment faire partir une norme en cacahouète" : http://www.pgts.com.au/pgtsj/pgtsj0208b.html(...)
Pour voir le bordel actuel : http://www.pgts.com.au/pgtsj/pgtsj0208c.html(...)
Peu respecte le fait de mettre le nom du navigateur en premier, certains font allusion à d'autres navigateurs et à d'autres moteurs "like Gecko" ou "Mozilla/...."
[^]Re: Alors...
Et c'est pas IE 7 qui va arranger les choses à ce niveau : http://blogs.msdn.com/ie/archive/2005/04/27/412813.aspx(...)
Ils gardent leur anachronique Mozilla/4.0 (compatible, ...) :(
[^]Re: Alors...
Au fait, à quoi ça peut servir d'ajouter "SV1" dans le UA... À part le fait que son absence signifie que IE n'est pas mis à jour (donc vulnérable), je ne vois pas.
http://blogs.msdn.com/ie/archive/2004/09/02/224902.aspx(...)
[^]Re: Alors...
Mais pourquoi faudrait il arranger quoi que ce soit a ce niveau ? Je ne vois vraiment pas le probleme avec cette chaine... Au contraire, changer encore, meme de facon subtile, l'user agent d'IE ne ferait que compliquer les choses... La, ils ont fait simple, ca reste grosso modo ce a quoi on s'attend, bref ya pas de problemes...
[^]Re: Alors...
Le problème est qu'elle ne respecte pas les RFC définissant la syntaxe du user-agent : http://www.mozilla.org/build/user-agent-strings.html(...)
"Mozilla" n'est pas le produit utilisé par Internet Explorer donc il ne devrait pas être indiqué.
"4.0" n'est le numéro de version rien du tout dans Internet Explorer.
Cette critique est aussi valable pour Konqueror ou Safari.
Une norme c'est fait pour être respecté sinon c'est la porte ouverte à toutes les fenê^W dérives :)
[^]Re: Alors...
Cela avait été défini comme ça à l'époque où Netscape était dominant sur le marché, pour passer outre les sites qui faisaient un test sur le user-agent.
Comme quoi...
[^]Re: Alors...
Je pense que tu n'as pas compris le problème évoqué :
Dans les CSS, lorsque tu veux utiliser une propriété unqiuement disponible sous Mozilla tu utilises -moz- (exemple : -moz-border-radius), sous IE -ie-, sous KHTML tu utilses -khtml- et sous WebCore -khtml-, or les deux moteurs khtml et webcore sont aujourd'hui trés dissemblable, n'implémente pas les mêmes fonctionnalités, ... d'où le soucis.
Apple aurait du renommer complètement son moteur et pas à moitié !
NB : les -XXX- sont dans la norme
[+] [^]Re: Alors...
Comme quoi, je n'étais en tord en critiquant Apple dans la news précèdente.
Ceci dit, que ça soit GPL ou BSD (celle que je critiquais),
on voit quand même qu'une boîte (içi Apple) arrive à filouter, elle n'a pas violé la GPL en fournissant des patch, mais ne contribue pas réellement.
Apple est encore plus vicieux que Crosoft finalement (ouille le moinssage)
Question de bleu, je pensais qu'on était obligé de fournir les sources complètes du logiciel modifié outre peut-être les parties proprio bienque je me demande si la GPL n'interdit pas cela justement?
C'est sûrement une question de bleu, j'imagine bien que la batterie d'avocat d'Apple ont préparé le terrain. :)
++
moué...
[^]Re: Alors...
Les sources complètes de Webcore sont disponibles sur le net : http://developer.apple.com/darwin/projects/webcore/(...)
[^]Re: Alors...
La participation d'Apple à divers logiciels open source (khtml, mais aussi les utilitaires BSD, gcc etc) n'est pas négligeable.
En revanche ils se montrent très peu coopératif lorsqu'il s'agit de diffuser les spécifications de leurs chipsets (des chipsets qu'ils utilisent) et lorsque celà concerne les droits de diffusion des firmwares nécessaires à ces chipsets.
Apple choisit souvent des fournisseurs parmis les moins coopératifs (Broadcom et Ati par exemple) et refuse très souvent (malgrè une forte demande des devs noyau Linux et *BSD) de livrer les spécifications détaillées (ou de demander à ses fournisseurs de le faire, après tout Apple est là en position de force) et des licences adéquates pour la distribution des firmwares et drivers binaires.
Concernant la remontée des contributions en upstream, elle n'est parfaite pour aucun Unix (Mac OS X compris) et aucune distribution GNU/Linux. Les developpeurs "upstream" ont depuis longtemps apris à aller chercher d'eux même dans les bugtrackers et les patchsets des divers distros (et dans les ports *BSD). Ou pas.