Mes impressions sur le web, les standards et autres…


Sélecteur de style

Je viens de finir de mettre en place le sélecteur de style (Style switcher pour les intimes). La gestion se fait entièrement du coté client à l’aide du javascript et du DOM, et sans appui coté serveur.

En effet, il est généralement d’usage de prévoir un mécanisme de secours coté serveur au cas où le javascript est désactivé ou absent dans le navigateur. Dans ce cas là, la soumission du formulaire de sélection se fait effectivement. L’information est donc reçue du coté du script serveur et la nouvelle page générée contient l’appel à la feuille de style du style choisi, suivi de ceux pour les autres feuilles de style qui sont donc indiquée comme alternatives.

Cela me pose problème de deux façons :

  • Tout d’abord, et c’est le plus important, je gère finement le cache du client en lui envoyant les en-têtes HTTP adéquats et tient à en exploiter toutes les possibilités. Le problème est que le choix effectué par l’utilisateur va modifier la structure du document puisque le style choisi doit être indiqué comme style par défaut et les autres doivent être indiqués comme alternatifs. Or, les pages déja mises en cache ne tiennent pas compte de ce changement dans la structure primaire du document.
  • Le document doit être envoyé tel quel au client. S’il y a des aménagements ultérieurs à faire dans le document en fonction de choix utilisateur, ils doivent l’être avec un script approprié coté client.

Le sélecteur de style est donc ici généré entièrement à l’aide du DOM, puis intégré dans le document. Lorsqu’un choix dans la liste est effectué et que le bouton est activé, la fonction d’activation du style est lancée grâce au gestionnaire d’évènements du DOM et le style sélectionné est activé, les autres étant désactivés. Un cookie est également envoyé afin que le style choisi soit persistant, c’est à dire automatiquement utilisé sur chaque page.

Bon, évidemment, cela nécessite que le javascript soit présent et que votre navigateur comprenne un tant soit peu le DOM, mais comme ce n’est pas une fonctionnalité indispensable pour l’accés au site et la lecture du texte, ce n’est pas génant. Pour finir, le script du sélecteur de style est libre de droit, librement réutilisable et patati et patata…

Pour ceux qui sont sous Opera, ne chercher pas le sélecteur de style, Opera est un navigateur assez bizzare qui dit gérer le type MIME application/xhtml+xml. Fatalement, mon appli envoie donc la page sous ce type MIME. Le problème est que dans ce cas précis, le DOM ne semble plus fonctionner dans Opera…

Bah, je sais pas pour vous, mais moi, je reste sous Firebird hein. À bon entendeur.

La guerre des navigateurs n’aura pas lieu

Cette année 2003 aura été riche en rebondissement dans le monde des navigateurs web. De la sortie de Safari, le navigateur maison d’Apple, à l’affaire du brevet Eolas, en passant par la mort de Netscape et l’abandon par Microsoft du développement de IE sur Windows et Mac, je me demande même si ce petit monde n’a jamais été aussi animé depuis ses débuts.

Ces temps ci, on murmure dans les recoins du web qu’un nouvel épisode de la guerre des navigateurs s’annonce à l’horizon et pourrait faire mal. L’entreprise de Redmond serait en train de préparer dans ses laboratoires secrets un monstre, un tueur de navigateurs web pour sa prochaine mouture de Windows, Longhorn. Celui ci apporterait de fantastiques nouveautés devant lesquelles les autres navigateurs feraient pâle figure. Ainsi, ce dernier sursaut dans la guerre des navigateurs s’achèverait par la mort ou l’agonie pour les navigateurs alternatifs et par le triomphe de Microsoft dans sa conception du Web.

Que nenni mes amis, de guerre point n’aura lieu et la victoire des navigateurs alternatifs, et par là même des normes du W3C, est déja acquise d’avance. Ce que Microsoft nous prépare, c’est MSN Explorer, son logiciel de navigation internet/gestion d’emails/etc. payant. C’est un grand classique : Prendre le plus de parts de marché possibles, et ceci à n’importe quel prix, fidéliser sa clientèle et/ou museler la concurrence, puis rendre tout ça payant. Avoir sous sa coupe 90% et plus de parts de marché d’un marché gratuit n’a pas grand intérêt pour Microsoft alors qu’avoir 15 à 20% d’un marché payant est beaucoup plus rentable.

Je vous le dis, observez bien les statistiques de parts de marché des navigateurs durant l’année qui vient et admirez béatement la (trop ?) lente agonie de IE et l’ascension des navigateurs alternatifs et particulièrement de la famille Gecko :)

Détecter le javascript et les fichiers PDF

Personnellement, je n’aime pas trop les documents PDF. Ne me demandez pas pourquoi, je n’en sais trop rien. Je les trouve pas très pratique et j’ai du mal à naviguer dans les pages. Cependant, je ne doute pas que ce format ait ses avantages. D’autre part, je déteste tomber sur des liens javascript, c’est à dire qui commencent par javascript: ou sur lequel se trouve par exemple un attribut onclick. Alors j’ai placé les règles CSS suivantes dans le fichier userContent.css qui se trouve dans le dossier chrome/ de mon profil Firebird :

a[href^="javascript:"]:hover, a[onclick]:hover {
	background-color: red !important;
	color: blue !important;
}
a[href$=".pdf"]:hover, a[type$="pdf"]:hover {
	background-color: blue !important;
	color: red !important;
}

Je sais pas pour vous mais perso, je trouve ça diablement pratique. Vous n’utilisez pas Mozilla ou Firebird comme navigateurs web et vous souhaitez en savoir plus ? C’est par là.