Mes impressions sur le web, les standards et autres…


Un site accessible pour tout le monde

Ce petit espace personnel que je me prépare n’est pas encore fonctionnel, mais je tenais à l’utiliser pour mon droit de réponse à l’article Un joli site, mais pas pour tout le monde (en effet, je n’ai pas réussi à utiliser le formulaire d’ajout de commentaire du site en question) (Bon, en fait, il fallait accepter les cookies…). Pour les rares personnes qui seraient venues se perdre sur ce petit coin de l’internet, je précise que l’auteur de l’article parle de mon autre site: phpCodeur.

Pour commencer, un certain site m’a effectivement inspiré, en l’occurence openweb :-). Outre leurs articles très réussis, j’ai apprécié leur design simple et agréable. Ceci dit, la palette de couleurs que j’ai utilisée reste la même que sur la précédente version de phpCodeur (dominante bleu avec des variantes, blanc, et orange)

L’auteur pose ensuite la question suivante: IE5 serait donc un navigateur obsolète ?. Tout à fait :-). Tout comme IE6 du reste.
phpCodeur (tout comme webnaute) n’étant pas un site commercial, je n’ai aucune contrainte particulière (satisfaire un client, me plier aux demandes d’un patron…). J’ai donc toute latitude pour gérer la chose comme je l’entend. Mon objectif principal n’est pas de faire un site joli, ce que je recherche, c’est à ce que le contenu du site (la partie intéressante d’un site finalement) soit accessible, et ce, en toutes circonstances. La présentation, le contenant, ne viennent qu’après. En l’occurence, le design de phpCodeur est très correct, j’ai créé les feuilles de style sans me soucier de tel ou tel navigateur. Ensuite seulement, j’ai procédé à quelques ajustements pour les navigateurs obsolètes afin d’améliorer la lisibilité du contenu (précisément, je pense à la propriété width que j’ai dùe utiliser pour que IE6 prenne en compte la propriété overflow: auto;).

Je ne met donc pas IE au rancart, comme l’a dit un intervenant. J’utilise simplement les outils que j’ai à ma disposition, teste mes pages avec les quelques navigateurs installés sur ma machine (pour info: Firebird, Mozilla 1.5rc2, IE6, Opera 7.20, Netscape 4.7x et Lynx) et compte sur les visiteurs utilisant ces navigateurs ou d’autres (dont IE5 donc) pour me faire des retours en cas de problème, surtout si ce problème touche à l’accessibilité au contenu. :-)

Current works

Bon, ça commence à prendre forme.
L’essentiel est là: Affichage des billets, système de commentaires, feuille de style correcte…
À prévoir à moyen terme :

  • Classement par rubriques
  • Archivage par mois et année
  • moteur de recherche
  • revoir un peu tout ce que je viens de faire parce que c’est pas la joie et que mon âme de geek se révulse devant cette bouillie infâme

Ah, vous vous dites peut-être : Que fait-il ? Il y a déja de très bons outils pour créer son blog en cinq minutes montre en main. Le problème est que j’ai un très gros défaut, je ne peux pas m’empécher de tout vouloir coder moi même, quitte à réinventer la poudre. Je sais, c’est idiot, mais voyons le bon coté des choses, cela ne peut que me faire progresser encore et encore même si je perd du temps au passage.

Bon, j’y retourne…

Attention, site non valide

Webnaute.net n’a pas une feuille de style CSS valide !
J’utilise le pseudo sélecteur :last-child pour centrer le bouton de soumission du formulaire d’ajout de commentaire. À terme, je ne me gènerai pas pour utiliser d’autres propriétés qui n’apparaitront qu’avec les css de niveau 3, voire même des propriétés non standards, propres à IE par exemple (enfin j’en vois pas ou n’en connait pas beaucoup d’utiles).

Le mot d’ordre est : accessibilité. Si cela ne réduit pas ou n’empèche pas l’accés au contenu, on peut l’utiliser. En l’occurence, que le bouton de soumission soit centré ou pas ne change rien. Je trouve simplement plus esthétique pour les navigateurs graphiques qu’il soit centré plutôt que d’être collé à gauche.

No pasará

top 10 des navigateurs dans les stats du site

Impression d’écran à mettre de coté car cette situation risque fort de ne pas durer.

Vous avez remarqué que le nom MS Internet Explorer était en gras ? Pourquoi ? Pourquoi, nom d’une pipe ? La domination de l’affreux se ressent partout et c’est vraiment désolant. Il n’y a pourtant pas eu d’évolutions majeures dans IE depuis 1999 je crois, année de la sortie de IE 5.0 (IE6 ne peut être considéré que comme une mise à jour mineure de la version 5.x). Le bien être et le confort devraient pourtant être l’exigence première des utilisateurs.
Si vous utilisez IE, testez Firebird, le meilleur navigateur actuel, ça ne prendra pas longtemps et vous me remercierez plus tard.

Rendu par défaut des navigateurs

Tout le monde ne consultant pas les recommandations du W3C de fond en comble, voici une page interessante de la recommandation concernant le CSS 2.1: Exemple de feuille de style.

Cette page montre simplement à quoi ressemblerait une feuille de style appliquant au plus près le rendu par défaut des navigateurs. Pratique pour connaître le comportement par défaut de la plupart des balises HTML.

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, 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.

Fil RSS

Comme on me l’a demandé hier, je viens d’ajouter un fil RSS pour le journal. Le fil RSS se trouve à cet adresse et est actuellement réactualisé toutes les six heures.

J’ai pris le parti de suivre le format RSS 1.0 car c’est la dernière version reconnue et j’aurais trouvé dommage de me cantonner aux versions précédentes. Je n’utilise pas la version 2.0 de Userland car elle ne semble pas être officielle.

Type MIME des fils RSS

J’ai pu constater sur plusieurs blogs la présence du lien relationnel suivant :

<link rel="alternate" href="path/fichier.rss" type="application/rss+xml" Title="Fil RSS" />

Ok, un lien menant au fil RSS du blog. Je clique. Et là, je constate que le contenu que l’on me sert est envoyé avec le type MIME text/xml ?! Plait-il ? On prétend donc m’envoyer un contenu de type application/rss+xml (le type indiqué dans la balise link) et je reçois du text/xml.

Je ne suis pas sùr que ce soit une bonne idée, au sens strict. L’idéal serait de n’utiliser que l’un des deux types MIME, le "désavantage" du type application/rss+xml étant que le fichier est téléchargé, et non affiché dans le navigateur… (manifestement parce que le type MIME n’est pas reconnu)

Pour limiter les dégats et faire les choses correctement, on peut, tout comme pour les pages xhtml, détecter si le client supporte le type application/rss+xml et si c’est le cas, d’utiliser ce type.

Webnaute: deuxième étape

Bien. Le fil RSS est en place, ainsi que le système des archives, la compression des pages (gérée par PHP en attendant de me pencher plus attentivement sur le module mod_gzip d’apache) et la gestion du cache coté client (l’entête 304 Not Modified est mon ami).
Notez que le cache coté client est géré également pour le fil RSS, ainsi que la compression gzip (je ne sais pas si des lecteurs de fil RSS gèrent la compression gzip).

Prochaine étape donc, une feuille de style plus travaillée, le design actuelle étant des plus simplistes, quoique pas moche à mon goût et très lisible.

Consultation hors ligne

Je ne sais plus comment j’en suis venu là, mais je me suis rendu compte que si une personne tente d’enregistrer une page du site, les choses ne se passent pas tout à fait comme prévu. Sur tous les navigateurs avec lesquels j’ai testé, le comportement est plus ou moins le même : Le navigateur propose d’enregistrer la page en lui donnant pour nom son titre, et éventuellement en lui proposant de lui même l’extension .html ou .htm. D’une part, ce n’est pas très pratique (voir le titre de l’index du journal par exemple), et d’autre part, comme je le disais, certains navigateurs n’affectent ou ne proposent aucune extension au fichier (Firebird par exemple) (Ok, en fait, cela concerne uniquement les pages servies avec l’entête application/xhtml+xml. Pour les pages servies en tant que HTML, le navigateur télécharge la page et tous les éléments qui la composent), ce qui est assez génant.

Et puis je me suis rappellé de l’entête Content-Disposition. Outre la possibilité de définir comment est fourni le document (je ne vois pas d’autres façons de décrire), on peut également spécifier un nom de fichier pour le document. Ainsi, si vous enregistrez le document qui est à l’adresse http://webnaute.net/Journal/RSS, le nom de fichier par défaut que devrait vous proposer votre navigateur est "journal.rdf". Pour les pages du site, voici le code que j’utilise au moment de l’envoi des entêtes :

if( $filename == '' )
{
    $filename  = str_replace(' ', '_', trim(str_replace('/', ' ', $_SERVER['REQUEST_URI'])));
    $filename .= ( $this->output_xhtml ) ? '.xhtml' : '.html';
}

header('Content-Disposition: inline; filename="' . $filename . '"');

J’ai remarqué au passage que si la page est enregistré avec l’extension .xhtml, Firebird considèrera implicitement que le contenu est de type application/xhtml+xml (vérifiable avec click droit -> View Page Info).

PS : Dois-je préciser que IE, encore une fois, joue les trouble fêtes en ignorant complètement l’entête Content-Disposition ?

L’entité qui tue

Aujourd’hui, je me suis interessé (à nouveau) à l’entité &shy; ainsi qu’à l’espace nul (&#x200B;, pas trouvé d’entité définie).

L’entité &shy; permet d’insérer un tiret conditionnel dans un mot. Ainsi, si le mot est trop long, au lieu de déformer le bloc parent, il est coupé en deux et un tiret apparaît. Bémol: Cela ne marche pas sous Firebird/Mozilla, par contre, ça marche très bien sous IE (oui, vous avez bien lu).
L’espace nul quant à lui porte bien son nom. En le plaçant au milieu d’un mot, l’espace n’apparaît toutefois pas (d’où le qualificatif "nul"). Tout comme pour le tiret conditionnel, si le mot est trop long, il est coupé en deux au lieu de déformer la mise en page. Évidemment, l’espace nul ne fonctionne que sous Firebird/Mozilla.

Bref, m’insurgeant contre le fait que l’entité &shy; est inopérante dans mon navigateur fétiche, je me rend sur bugzilla et entreprend une recherche…

Malheur !
Bugzilla me recrache une page listant pas moins de 27000 bugs. Firebird se prend donc une page de 13 Mo dans le cornet et évidemment, ça lui plaît pas trop. Luttant vaillamment dans le chaos qui s’ensuit (je suis sous windows), je fais une impression d’écran de la fenêtre "page info" histoire d’avoir des preuves quand je raconterai ça à mes petits enfants. Et là, je fais le truc à ne pas faire: Je tente de fermer phpEdit et dans la foulée, je lance paint shop pro histoire de sauvegarder ma copie d’écran.
J’ai lutté, lutté de longues minutes, mais là, c’était l’apocalypse et je n’ai dù mon salut qu’à la touche reset ornant mon unité centrale.

Voilà, c’était la petite histoire du jour :)