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.
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 :)
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à.