Les soucis de l’encodage

Cela faisait déja plusieurs jours voire semaines que je butais sur un problème. Impossible d’envoyer mes pages encodées en UTF-8, cela faisait purement et simplement planter mon navigateur (Firebird, faut le faire quand même). Reprenant mes tests ce matin pour essayer de comprendre, j’ai constaté plusieurs choses au fur et à mesure :

1. Le fil RSS, pourtant encodé lui aussi en UTF-8 et à l’aide du même mécanisme (script), s’affichait très bien dans Firebird.
2. Les pages s’affichaient très bien dans Mozilla, Opera 7.22 et IE 6.0 lorsque encodées en UTF-8.
3. Et pour finir, je constatais que les pages de tests, indépendantes en terme de design du reste du site, s’affichaient très bien quelque soit le navigateur (Firebird compris donc).

À ce niveau là, je me disais que le problème venait des données même de la page et non pas des en-têtes HTTP envoyés par exemple. Et puis vient la lueur de lucidité, je retourne voir ma feuille de style principale pour finalement constater ceci :

div#menus li.menu > a:after { content: "\00A0»"; }

Et le problème venait évidemment de là. J’insérais un caractère non encodé en UTF-8 (la feuille de style n’étant pas elle-même encodées en UTF-8) et cela a suffi pour faire planter Firebird. Il m’a suffi de remplacer le caractère » par son code ISO 10646 \00BB pour que tout refonctionne, ouf :)

Que se serait-il passé si j’utilisais non pas Firebird mais Mozilla et que mes pages étaient encodées en UTF-8 depuis le début ? Mes pages auraient été inaccessibles aux visiteurs utilisant Firebird, et ceux ci n’auraient pas pu me prévenir même s’ils en prenaient le temps puisqu’ils n’auraient pu obtenir mon adresse email. Au mieux, j’aurais été prévenu par des amis utilisant Firebird ou par des personnes parvenues ici par l’adresse du site donnée dans ma signature sur les newsgroups.

Cet exemple démontre que, malgré l’application stricte des normes en vigueur, il est nécessaire de tester ses pages sous différents navigateurs car il suffit de peu pour les rendre involontairement inaccessibles à une partie des visiteurs.

Site en plein écran (2)

Site plein écran ! moi penser que bien ! vous pensez pas bien du tout ! bon et bien les boules !!! je repards donc de 0.
Mais bon, merci pour vos avis au moins on sait à quoi on s’attends comme réaction !!
Alors moi changer !!

Friendly !

Yes ! Encore une victoire de canard des standards. Voir le billet précédent.

Site en plein écran

Un site en plein écran .... Attention aux yeux !!! Merci de donner votre avis !!!!

http://****************

N’hésitez pas !

Berk. Les sites en plein écran sont une abomination. Personnellement, quand je tombe sur de tels sites, je tourne les talons aussitôt.

Ne mettez pas votre site en plein écran, c’est génant pour l’utilisateur, il ne sait plus où il est, n’a plus accés à la barre de menu, n’a plus accés à rien et c’est extrèmement frustrant. On peut envisager à la rigueur une page précise qui serait en plein écran (contenant par exemple une anim flash assez conséquente) et où l’utilisateur serait pleinement conscient de ce qui l’attend — C’est à dire qu’il aurait été prévenu sur la page précédente que la page qu’il va consulter s’affiche en plein écran — mais c’est tout. Un site en plein écran, c’est le meilleur moyen de faire fuir vos visiteurs.

Feuilles de style utilisateur

Les feuilles de style, c’est vraiment un outil formidable, non seulement par la facilité qu’elles apportent à gérer la présentation de ses pages, mais aussi en terme d’accessibilité. Une utilisation très peu connue et utilisée, quoiqu’un peu plus par les adeptes de Mozilla/Firebird mais de façon superficielle (via les bidouilles anti-pub), est la possibilité pour le visiteur de définir des règles CSS à appliquer aux sites qu’il visite.

Pour les utilisateurs de Mozilla ou Firebird, c’est très simple, il suffit de modifier le fichier userContent.css présent dans le dossier chrome/ de votre profil (renommer d’abord le fichier userContent-example.css en userContent.css si besoin est). Pour les utilisateurs de IE6, vous pouvez spécifier une feuille de style utilisateur via outils -> options internet... -> accessibilité. Je ne sais ce qu’il en est pour les autres navigateurs. Les règles de style que vous indiquerez dans cette feuille utilisateur s’appliqueront si l’auteur du document (la page que vous visitez) n’a pas déja précisé cette règle dans la feuille de style du site (s’il y en a une). Pour outrepasser cette ordre de priorité, faites suivre chaque règle de style que vous voulez appliquer par !important (avant le point virgule, et il y a un espace avant le point d’exclamation). Bien entendu, cela suppose que vous ayez un minimum de connaissances en CSS, mais on peut espérer une généralisation de l’utilisation des feuilles de style utilisateur, et l’apparition à l’avenir de sites listant plusieurs règles de style basiques et généralistes à appliquer dans ces feuilles utilisateur.

Si vous avez bien suivi jusque là, vous vous êtes sùrement posé la même question que moi. Que se passera t-il si je définis cette règle dans ma feuille de style utilisateur :

body {
    background-color: black !important;
}

La règle s’appliquera en effet, et d’autant plus qu’elle aura un ordre prioritaire (avec !important) sur la même règle éventuellement définie dans la feuille de style de l’auteur, mais elle s’appliquera à tous les sites que vous visiterez. En effet, il n’existe pas de mécanisme natif pour lier des règles de style à un site en particulier. Une pratique commence à se répandre parmi les adeptes des standards et de l’accessibilité qui consiste à utiliser l’attribut id du HTML pour fournir à leur site un identifiant unique, ce qui a pour effet immédiat de donner un caractère d’unicité du site vis à vis de la feuille de style utilisateur. Ainsi, j’ai placé un attribut id dans la balise html (on peut aussi bien le placer sur la balise body) avec pour valeur site_webnaute — Attention cependant, l’attribut id sur l’élément html n’existe pas dans la recommandation sur le HTML 4.01 ni dans aucune des DTD du XHTML 1.0 mais bizzarement, ma page est tout de même valide aux yeux du validateur du W3C aussi bien que de celui du WDG (Anne Vankesteren propose d’ailleurs l’ajout pur et simple de cet attribut id si besoin est comme elle il l’explique ici) Mise à jour : En fait, l’attribut id n’est pas défini dans la première version de la recommandation sur le XHTML 1.0 mais il l’est dans la deuxième édition de cette recommandation — Notre essai précédent sur la couleur d’arrière plan deviendrait donc :

html#site_webnaute body {
    background-color: black !important;
}

Admettons tout de même que cette solution est loin d’être pratique, en plus du fait que l’ajout d’un attribut id unique sur les éléments html ou body reste très marginal voire inexistant parmi les concepteurs de site. Anne Vankesteren, toujours elle il, propose l’ajout d’un nouveau mécanisme dans une future version des feuilles de style CSS. Ainsi :

@address "annevankesteren.nl"{
    /* user specific styling */
}

J’avoue que l’idée m’a paru séduisante au départ, mais après mùre réflexion, je ne pense pas que ce soit une bonne idée. Un tel mécanisme ne devrait rien avoir à faire dans une feuille de style CSS. Leur rôle se limite à la présentation de document, sans avoir à dicerner tel ou tel document. Et cela vaut encore plus pour faire la distinction selon le nom de domaine car la feuille ne s’appliquerait alors pas si le document est visualisé en local. Non, à mon avis, point de salut si ce n’est dans les concepteurs de navigateurs web :/.

L’autre visage de l’accessibilité

On parle beaucoup de l’accessibilité des pages en termes de code propre, aux normes et respectant les règles d’accessibilité telles que l’attribut alt sur les images, de vrais entêtes (balise th) pour les tableaux de données et bien d’autres choses encore. Mais on oublie souvent que la question de l’accessibilité se joue également à d’autres niveaux.

Définir une nomenclature pour ses URLs

On y pense pas souvent, ou pas avec l’importance qui lui est dû mais choisir des URLs représentatives est très important. (Note pour les puristes : Attention, je fais court et simple)

Tout d’abord, il faut dissocier clairement l’URL qu’utilise le visiteur du véritable chemin du document cible sur le serveur. Vous pensez vous trouver dans le dossier /journal/ de mon espace web ? raté, l’URL http://webnaute.net/Journal/ pointe sur http://webnaute.net/scripts/journal.php. Pour les archives (quand elles seront en place), l’URL http://webnaute.net/Journal/2003/10/ par exemple pointera sur http://webnaute.net/scripts/journal.php?​annee=2003&mois=10 (la première est tout de même plus belle et plus significative que la seconde vous ne trouvez pas ?). Les deux exemples précédents sont rendus possibles par quelques lignes simples dans mon fichier .htaccess :

RewriteEngine on
RewriteRule ^Journal/([0-9]{4})/([0-9]{1,2})/?$ scripts/journal.php?annee=$1&mois=$2 [L]
RewriteRule ^Journal/?$ scripts/journal.php [L]

On peut donc de façon simple définir des URLs qui ont un sens pour le visiteur (après tout, qu’est ce qu’il en a à foutre qu’il y ait .html ou .php à la fin) en ayant par ailleurs toute latitude pour gérer et modifier le classement des fichiers et dossiers de son espace web sans que cela affecte le visiteur (vous savez, les erreurs 404 à la pelle lorsqu’on fait une recherche avec un moteur de recherche. cf les deux dernières parties de ce billet).

Apache fournit des outils très pratiques pour arriver à ce résultat, tels que la négociation de contenu et/ou la réécriture d’URLs grâce au module mod_rewrite (Voir aussi ce tutoriel très clair).
Lisez surtout l’article Les URLs sympas ne changent pas assez long mais très enrichissant, et qui expliquera bien mieux que moi et de façon beaucoup complète.

Compression des pages

C’est très simple à faire en PHP, voir ici, là ou encore sur cette page. Et c’est trèèès efficace. Vos pages seront beaucoup moins grosses et donc beaucoup plus rapides à charger pour les navigateurs qui gèrent les pages compressées (Pensez aux personnes, majoritaires, qui utilisent une connexion bas débit en France).
Et si le module mod_gzip (Apache) ou mod_deflate (Apache 2) est installé sur votre serveur, vous pouvez même envoyer la plupart des fichiers textes (feuilles de style, fichiers javascript, …) en compressé également. :)

Gestion de l’indexation

Vous est-il déja arrivé, en faisant une recherche via un moteur de recherche, et en suivant le lien d’un des résultats retournés, de tomber sur une page qui n’a plus grand chose à voir avec l’objet de votre recherche ? Moi, ça m’arrive souvent.
Ne permettez pas aux robots des moteur de recherche d’indexer n’importe quoi ! Les moteurs de recherche sont là pour indexer des documents (ou pages si vous préférez), pas des sites. La nuance n’est pas forcément évidente, et pourtant, elle existe. Prenons l’exemple d’un site portail. La page d’accueil affiche par exemple les derniers articles publiés, les derniers liens ajoutés dans l’annuaire ou que sais-je encore. Ce genre de page change au fil du temps (du genre, plus rien à voir d’un mois sur l’autre).
La règle d’or dans l’idéal est de ne permettre l’indexation que des documents qui ne changent pas ou pour lesquels il n’y a pas de suppression de contenu. Pour cela, vous pouvez utiliser le meta tag robots dans votre code HTML en indiquant les valeurs qui vont bien, ou placer un fichier robots.txt à la racine de votre site, comme l’explique cet article (Premier lien retourné après une rapide recherche sur Google).

Ne laissez pas tomber vos visiteurs

Le titre n’est pas très évocateur. Je m’explique.
Il n’y a rien de plus frustrant que de suivre un lien (résultat d’une recherche, lien qui traine au fin fond des marques-pages) et de tomber sur une page d’erreur 404 (à recouper avec les deux premières parties de ce billet). Le document a t-il été simplement supprimé ? déplacé ? Impossible de savoir, sauf à faire une recherche potentiellement longue et laborieuse sur le site en question. Le protocole HTTP (Voir entre autre la RFC 1945 sur le protocole HTTP 1.0 et la RFC 2616 sur le protocole HTTP 1.1) contient tout ce qui est nécessaire pour réaliser un dialogue clair et riche en informations avec le client (navigateur web ou autres…). Pour un document supprimé, l’idéal est de renvoyer l’entête HTTP/1.1 410 Gone ce qui signifie littéralement que l’url est correcte mais que le document n’existe plus. Pour un document déplacé, deux cas de figure :

• Le déplacement est temporaire. On veillera dans ce cas à renvoyer l’entête 307 Temporary Redirect
• Le déplacement est définitif. On renvoie l’entête 301 Moved Permanently

Pour envoyer les entêtes nécessaires au client, PHP dispose de la fonction header(). Vous pouvez aussi utiliser les directives Apache RedirectPermanent, RedirectTemp et RedirectMatch dans un fichier .htaccess.