Google amélioré pour Firefox

[NaWer]

mais d'autre (comme le prefetch) ne devrait pas apparaître...

Le prefetch n'a rien à voir avec CSS...

je n'ai rien dit de tel. juste que le CSS (2.1 et même 3) est assez avancé pour l'utiliser comme un standard même s'il est encore en working draft a l'inverse du prefetch, vu qu'il n'y a rien/pas grand chose (spécification etc...) sur cette fonction.

Une question que je me pose, : comment apparaît une nouvelle norme ? (ou attribut, balise etc...)
sur un navigateur ?
sur une reflexion/thèse/étude/colloc ?
autour d'une table entre bourrins geeks bourrés a la bière ? ( )
... ?

Faut bien un début... peut être que la voie qu'a choisi Google (et donc Mozilla) n'est pas si mauvaise...
(bon, d'un autre coté, ils ont viré le SVG natif et bien d'autre choses relativement abouti, jugées pas assez stables... le prefetch l'est il ?)

[Benoit]

Le SVG natif n'a jamais été viré puisqu'il n'a jamais été terminé Par contre il arrive presque à un stade où il pourra être activé par défaut. Il y a eu la même évolution avec MathML avant.

[Benoit]

Mais alors dans ce cas pourquoi ne pas envisager une standardisation par le WhatWG ? Ils pourraient rapidement développer un profil pour le prefetch, et ainsi résoudre le problème rapidement tout en restant cette fois 100% compatible avec le HTML 4.01...

Je suis bien prêt à le proposer sur leur Mailing List mais en fait c'est plutôt ton idée, donc si jamais ils trouvent ça chouette ce serait ton nom qui devrait apparaître dans les remerciements :p T'en penses quoi ?

[calimo]

J'en pense que ce serait une excellente idée, et qu'à vrai dire je me fiche un peu du fait d'avoir mon nom dans un document (ils mettent autant de noms dans les documents ? Personne d'autre, comme un membre de Mozilla, ne l'a jamais proposé ?)

À vrai dire je prendrais volontiers un moment pour le faire si je savais par où commencer et quelle procédure suivre...

[Benoit]

On peut s'inscrire/voir les archives là :

http://whatwg.org/mailing-list

Ce que je ferais c'est simplement t'inscrire, et dire que tu as entendu parler dernièrement de la relation "prefetch" utilisée par Google[1], que tu t'es rendu compte que ce n'était standardisé nulle part mais que c'était documenté sur le site de Mozilla[2], et que d'après toi ce serait une bonne idée de l'ajouter à leur spécification Web Apps/HTML5 parce que HTML4 dit[3] qu'on ne devrait pas en ajouter sans utiliser de profil particulier. (ils aiment bien les références directes aux pages dont tu parles et autres spécifications; ça fait le type qui sait de quoi il parle et tout ça)

[1] http://www.google.com/help/features.html#prefetch
[2] http://www.mozilla.org/projects/netlib/ ... g_FAQ.html
[3] http://www.w3.org/TR/REC-html40/types.html#type-links

Là ils disent oui, ou non, ou peut-être mais au moins on en sait un peu plus

[calimo]

Ok je vais faire ça

[calimo]

En fait, tu pense qu'il vaudrait mieux que ce soit ajouté à la spécification Web Apps / HTML5 ou faire un profil ? Sont-ils compétents pour faire un profil ?
Je vais commencer par faire un brouillon, c'est impressionnant de voir toutes ces personnalités sur la liste, j'ai peur que mon anglais paraisse ridicule, je vous le soumettrai pour voir s'il n'y a pas trop d'horreurs

Merci en tous cas

Edit : QUID du rel="nofollow" ?

[Benoit]

Heu ben si ça fait partie d'une spécification pas besoin d'un profil. En même temps ils sont encore occupés à discuter comment les nouvelles fonctionnalités s'identifieront (DOCTYPE, attribut version sur la balise "HTML", etc.) donc si ça se trouve ce sera en soi l'équivalent d'un profil.

En fait, je les laisserais réfléchir sur ce point, c'est quand même leur boulot après tout. L'important étant surtout qu'ils ne puissent pas dire qu'ils n'ont pas pensé à prefetch

Pour le nofollow je ne sais pas, ça s'adresse vraiment à des UA très particuliers (les moteurs de recherche). Pour moi ça va dans la même catégorie que les balises META robots (noindex, nofollow(bis) etc.). Implicitement c'est un genre de profil. Je sais qu'ils sont viscéralement opposés aux profils genre PDA etc. qui vont dans le sens contraire de l'interopérabilité (alors qu'il suffit d'utiliser une feuille de style différente), mais là je ne sais pas, on est quand même au niveau sémantique.

[jv2759]

Pour le nofollow je ne sais pas, ça s'adresse vraiment à des UA très particuliers (les moteurs de recherche).

Non cela s'adresse à tout les outils d'indexation. Hors on vois bien aujourd'hui que de plus en plus les moteur d'indexation vont gagnier du terrain, au niveaux entreprise comme des particulier... Une normalisation est indispensable.

[calimo]

Bon, alors voilà un brouillon surement bourré de fautes :

I recently discovered that Google was using the "prefetch" relationship on the first links of the result page [1], in order to preload the page in browsers supporting this relationship. I realized that this is nowere standardized. However, Mozilla has documented this on their site [2].

HTML 4.01 states that :
"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types" [3]

There is no profile describing this value for the rel attribute. I think it would be interesting to either create a new profile for this value, or to include this value in the Web Apps specification.

Google (and other search engines) recently proposed another rel value, "nofollow" [4] to prevent comments spam on blogs. I think this value could also be standardized in the same way than the prefetch.

[1] http://www.google.com/help/features.html#prefetch
[2] http://www.mozilla.org/projects/netlib/ ... g_FAQ.html
[3] http://www.w3.org/TR/html4/types.html#type-links
[4] http://www.google.com/googleblog/2005/0 ... -spam.html

Qu'en pensez-vous ?

[Benoit]

Cela a l'air pas mal, mais j'ajouterais un peu de texte décrivant à quoi ça sert en dehors du contexte de Google.

Clairement, prefetch a plus d'intérêt dans le cadre d'un tutoriel, d'un manuel ou d'un article en plusieurs pages (ou pourquoi pas quelque chose comme une déclaration d'impôts en plusieurs écrans) que dans le cas de résultats de recherche situés n'importe où, à moins d'avoir une confiance absolue dans les résultats mais alors autant utiliser "j'ai de la chance"

[calimo]

Clairement, prefetch a plus d'intérêt dans le cadre d'un tutoriel, d'un manuel ou d'un article en plusieurs pages

Dans ce cas il y a la relation "next" qui existe et qui est aussi préchargée par Mozilla...
http://www.mozilla.org/projects/netlib/ ... g_FAQ.html
Du coup ce côté tombe un peu à l'eau vu que ça existe déjà, ça ferait double emploi.

[jv2759]

cela permet de charger plusieur lien? Car prefetch le permet... Dans le cas d'un tutoriel de plusieur pages, on pourais forcer le chargement de tout les pages ainsi on passe de l'une à l'autre plus facilement...

Ou alors dans le cadre de galerie d'image utilisant des miniature, on pourais précharger tout les pages, ainsi le passage d'une image à l'autre serais plus rapide...

[Benoit]

Pas con, va pour la galerie d'images alors

Fin bon ils sont pas stupides non plus ils peuvent trouver des "cas d'utilisation" tous seuls aussi.

[calimo]

Exact !
Alors voici donc un deuxième essai :

I recently discovered that Google was using the "prefetch" relationship on the first links of the result page [1], in order to preload the page in browsers supporting this relationship. I realized that this is nowere standardized. However, Mozilla has documented this on their site [2].

HTML 4.01 states that :
"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types" [3]

There is no profile describing this value for the rel attribute. I think it would be interesting to either create a new profile for this value, or to include this value in the Web Apps specification.

This relationship could be especially useful in case of an image gallery, for a long tutorial, or in any application where multiple pages need to be loaded. The following pages could be automatically preloaded to get a quicklier loading of the page for the visitor. This is somehow already possible with the "next" relationship, as Mozilla also prefetch these links (see [2]), but only for one page. "prefetch" would allow multiple page preloading.

Google (and other search engines) recently proposed another rel value, "nofollow" [4] to prevent comments spam on blogs. I think this value should also be standardized in the same way than the prefetch.

[1] http://www.google.com/help/features.html#prefetch
[2] http://www.mozilla.org/projects/netlib/ ... g_FAQ.html
[3] http://www.w3.org/TR/html4/types.html#type-links
[4] http://www.google.com/googleblog/2005/0 ... -spam.html

Je le trouve pas mal, mais l'autosatisfaction est facile. Et vous, qu'en pensez-vous ?