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.
Catégorie :
Vos réactions, opinions, insultes…
Rétroliens
Faire un rétrolien sur ce billet : [xxxxxxxx]
Commentaires
Arg, décidément, c’est une épidémie. C’est quoi ces navigateurs à la noix sérieux :/
Bon, ils ne bénéficieront pas de mon sélecteur de style alors.
C'est pour ça que je n'envoie du XHTML qu'aux Geckos. Les autres navigateurs ne sont pas encore prets.
Et même, en étant plus précis, je n'envoie du XHTML qu'aux geckos basés sur Moz 1.4 ou plus. Essaye de regarder ton switcher avec un Moz anterieur ;-Þ
(D'ailleurs, tout ça est résumé sur cette page : http://soirees.ehol.org/inc/tc.php )
Un vieux sniffing d'UserAgent…
*Se cache*
$ver_gecko=0;
preg_match("/rv *: *([^ab]+)[^0-9\)].*Gecko\/([0-9]+)/i",$_SERVER['HTTP_USER_AGENT'],$ver_gecko);
define("IS_GECKO",($ver_gecko[1]>=1.4) or eregi("Amaya|W3C|Google",$_SERVER['HTTP_USER_AGENT']) or !strlen($_SERVER['HTTP_USER_AGENT']));
Puis :
header('Content-Type: '.(IS_GECKO?'application/xhtml+xml':'text/html').'; charset=iso-8859-15');
(Et pour etre complet, en "mode Gecko", je change aussi le doctype pour le mettre à XHTML 1.1 ;¬])
PS : Vivement les balises <code> ;¬)
Arg, hérétique! ;-]
Arg (bis), ma mise en pageeuhh !
Bon, je vois pas où est le problème, si le navigateur dit gérer ce content-type, je lui envoie celui-là. Je dégage toutes responsabilité après si cela s’avère faux, c’est pas mes oignons.
En tant que développeur web, je veux bien faire des efforts au niveau des feuilles de style, au niveau du javascript et DOM parfois différent entre la norme W3C et les méthodes Microsoft, mais ce genre de bugs, non, je ne suis pas là pour les contourner et corriger le tir (Et comme de toute façon, l’absence du DOM ne devrait pas géner l’accés à la page et au contenu, je m’en bat l’œil).
Site créé et maintenu par Aurélien Maille aka Bobe. Toutes les heures sont au format CEST.
Revenir à l’accueil – Zone de développement – Informations et accessibilité –
Le problème de la non gestion du DOM en XHTML chez Opera se retrouve sur les navigateurs KHTML (Konq et Safari). Donc chez eux non plus ça ne doit pas marcher ;¬]