comment ajouter un Favicon à votre Site

0 Comments

statut de ce Document

brouillon en cours de développement; peut changer radicalement à tout moment.

un favicon est une image graphique (icône) associée à une page Web et / ou un site web particulier. De nombreux agents utilisateurs récents (tels que les navigateurs graphiques et les lecteurs de nouvelles) les affichent comme un rappel visuel de l’identité du site Web dans la barre d’adresse ou dans les onglets. Wikipedia comprend unarticle surfavicons .,

pour ajouter un favicon à votre site Web, vous aurez besoin à la fois d’une image et d’une améthode pour spécifier que l’image doit être utilisée comme favicon. Thisdocument explique la méthode préférée par le W3C pour spécifier thefavicon. Il existe une autre méthode commune illustrée ci-dessous,avec une explication des raisons pour lesquelles cette méthode est incompatible avec certains principes de l’architecture Web. Les deux méthodes ne s’appliquent qu’à HTML etxhtml, l’une des limitations discutées ci-dessous.

ce document ne décrit pas en détail comment créer une faviconimage., Cependant, le format de l’image que vous avez choisi doit être 16×16 pixels ou 32×32 pixels, en utilisant des couleurs 8 bits ou 24 bits. Le format de l’image doit être PNG (norme aW3C), GIF ou ICO.

Méthode 1 (préférée): Utilisation d’un attribut rel valuedefined dans un profil

la première approche pour spécifier un favicon consiste à utiliser la valeur d’attributrel« icon » et à définir ce que signifie la valeur via un profil; les profils sont discutés plus en détail ci-dessous. Dans ce HTML 4.,01 exemple, le favicon identifié via L’URI comme étant un favicon:

la version XHTML 1.0 est très similaire:

Méthode 2 (découragée): placer le favicon à un URI prédéfini

Une deuxième méthode pour spécifier un favicon repose sur l’utilisation d’un URI root. Cette méthode fonctionne car certains navigateurs ont étéprogrammé pour rechercher des favicons en utilisant cet URI., Cette approche n’est pas compatible avec certains principes de l’architecture Web et est discutée par le groupe D’Architecture Technique(TAG) du W3C comme leur problème siteData-36.To résumez le problème: l’architecture Web autorise les gestionnaires de site à gérer leur espace URI (pour un nom de domaine donné) comme ils seefit. Les Conventions qui ne représentent pas un accord communautaire et qui réduisent les options disponibles pour un gestionnaire de site ne sont pas évolutives et peuvent donner lieu à des conflits (car il n’existe pas de liste bien connue de ces URI prédéfinis)., Une considération pratique illustre le problème: de nombreux utilisateurs ont des sites Web même s’ils n’ont pas leur propre nom de domaine. Ces utilisateurs ne peuvent pas spécifier favicons à l’aide de secondmethod s’ils ne peuvent pas écrire à la racine du serveur. Cependant, ils peuvent utiliser la méthode one pour spécifier un favicon car il est plus flexible et n’oblige pas le gestionnaire de site à utiliser un seul favicon à un seul endroit sur le site.

Il y a quelques autres empiétements bien connus sur L’espace URI,y compris les « robots.TXT  » et l’emplacement d’une politique privée P3P., Le groupe D’Architecture Technique explore des alternatives qui n’empiètent pas sur L’espace URI sans licence.

utilisation de profils pour définir des termes tels que « icône »

en termes vagues, un profil est une définition d’un ensemble d’ofterms. Idéalement, un profil comprend à la fois des informations lisibles par machine et des informations lisibles par l’homme. Dans HTML 4.01 et XHTML 1.0, quelques attributs tels que l’attributrel n’ont pas d’ensemble prédéfini de valeurs. Au lieu de cela, l’auteur peut fournir des valeurs en fonction des besoins, puis utiliser un profil pour expliquer ce que les valeurs signifient., Dans notre cas, nous recommandons aux auteurs d’utiliser la valeur « icône « et un profil quiexplique que « quand nous disons icône, nous voulons dire » c’est un favicon. » »

dans la méthode 1 ci-dessus, nous utilisons l’attribut relavec leelinkelement et choisissons un profil avec l’attribut profile sur L’élément HEAD.

Nous avons défini un profil que vous pouvez utiliser librement pour vos propres sites.,

Limitations

Il existe plusieurs limitations aux approches décrites ci-dessus,y compris la méthode préférée (c’est pourquoi la balise continue de fonctionnersur la question):

  • Les approches ne fonctionnent qu’en HTML ou XHTML
  • l’approche préférée associe un favicon à un document HTML,et non à une collection de documents (c’est-à-dire un site)
  • le profil proposé pour définir la valeur « icône » n’est pas une norme reconnue, ce qui signifie Il peut y avoir des problèmes d’interopérabilité dans la pratique.
  • Il n’y a pas de norme (au moins définie par HTML 4.,01) pour les profils lisibles par machine qui permettraient à un navigateur de savoir « cela signifie qu’une image est un favicon. »Ainsi, abrowser doit être programmé à l’avance pour reconnaître cette valeur particulière de rel. Pour plus d’informations sur l’utilisation des profilesen HTML et XHTML, voir GRDDL.

FAVICON-WIKIPEDIA Favicon, Wikipedia, disponible àhttp://en.wikipedia.org/wiki/Favicon . Grddl Glaning Resource Descriptions from Dialects of Languages, D. Hazaël-Massieux, D. Connolly, Editors, soumission de L’équipe W3C, 16 mai 2005, http://www.w3.org/TeamSubmission/2005/SUBM-grddl-20050516/ ., Latest version available at http://www.w3.org/TeamSubmission/grddl/ . HTML401 HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs, Editors, W3C Recommendation, 24 December 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . Latest version available at http://www.w3.org/TR/html401 . SITEDATA-36 Web site metadata improving on robots.txt, w3c/p3p and favicon etc., TAG, Available at http://www.w3.org/2001/tag/issues.html#siteData-36 . XHTML1 XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), S. Pemberton, Editor, W3C Recommendation, 1 August 2002, http://www.w3.org/TR/2002/REC-xhtml1-20020801 ., Dernière version disponible à http://www.w3.org/TR/xhtml1.

Remerciements

Les participants suivants du groupe D’intérêt QA et le personnel du W3C ont contribué de manière significative au contenu de ce document:Dominique Hazaël-Massieux (W3C), Chris Lilley (W3C), andOlivier Théreaux (W3C).


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *