Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
27 juillet 2008 7 27 /07 /juillet /2008 18:33

Troisième (!) mouture, en octobre 2008 grâce à Fred & Ben, de cet article de juillet 2007 déjà refondu en juillet 2008 sous l'influence de Marcovaldo (voir les commentaires – les vôtres sont tout aussi bienvenus !).


Attention, gros morceau !

La question est : comment est bâti mon  biniou  de navigation, alias le petit machin infernal en haut à droite ? C'est réalisable au niveau Confiance, mais oui.

Ce qui ne signifie pas que c'est facile – désolé. Le procédé repose sur un JavaScript certes assez simple et surtout qui ne demande que très peu d'adaptation, mais il emploie du CSS un peu délicat et touche de près à la structure du blog. Le chantier est donc gros, vous ne vous en sortirez pas avec un copier/coller/hop magie ça marche tout seul. Par conséquent lisez les explications avant de vous lancer, et ne vous lancez que si la chose vous paraît claire. Si ce n'est pas le cas, n'hésitez pas à poser vos questions en commentaires : cet article est imparfait, il lui manque sûrement un tas de petites choses qui vont sans dire mais tellement mieux en les disant. Votre aide est donc bienvenue.

Revue du problème

L'objectif

Les divers menus du biniou sont des modules habituels : derniers articles, derniers commentaires, etc. . Sur un blog  normal  ils s'empilent dans une interminable colonne, d'où l'idée de permettre au lecteur de n'afficher que le ou les modules qu'il désire, idéalement en allant promener sa souris dessus.

Comment faire ?

La solution la plus propre, de pur CSS, serait d'afficher les modules réduits (= cacher leur .box-content) et de ne les développer (= montrer leur .box-content) que si on les survole, quelque chose comme :

 .articlerecent .box-content {display:none} .articlerecent:hover .box-content {display:block} 

Simple et expressif, marche partout… sauf hélas sous IE qui (au moins jusqu'à IE7) ne sait pas traiter :hover sur autre chose que des liens.

Comment faire même pour IE ?

Dans ces cas-là on s'en sort en réalisant en JavaScript ce qu'IE ne sait pas faire en CSS. Ici, on  grefferait  donc aux modules un petit gestionnaire JavaScript (onmouseover ou onclick) pour les réduire ou les développer quand on les survole ou les clique.

Comment ajouter ces gestionnaires ? On ne peut pas modifier à sa guise le HTML que produit OB – ce qui est bien compréhensible. Si l'on est autorisé à insérer des balises script, cette tâche d'ajouter les  petits gestionnaires  peut se déporter dans un script externe.

Mais on n'a pas droit à ces balises au niveau Confiance, niveau auquel se trouvait ce blog lorsque je me suis attaqué à la question.

Comment faire même pour le niveau Confiance ?

Est alors venue l'idée de placer la gestion de l'affichage des modules escamotables dans un module supplémentaire de texte libre.

Ce module auxiliaire, le  biniou navigatoire  (sic, appellation déposée), a une structure très simple (ce n'est qu'une série de liens) mais une forte teneur en JavaScript : chaque lien du  biniou  commande l'affichage d'un module, par une technique similaire à celle utilisée pour faire un  lire la suite .

Les plus anciens lecteurs de ce blog se rappellent peut-être la période où le petit bateau s'accompagnait de quelques hideux gros boutons où l'on cliquait pour afficher ou masquer tel ou tel module ? Dans les entrailles du monstre (= JavaScript) rien ou presque n'a changé depuis cette époque, or j'en savais moins qu'aujourd'hui en JavaScript. Le passage des hideux gros boutons au système actuel repose uniquement sur un travail de CSS. Le prochain chapitre en explique le principe, le suivant en donnera les détails, le dernier chapitre tentera de vous guider dans la mise en place du système.

Le travail de CSS

lire le reste de la présentation…

Faire un "lire la suite" : l'essentiel

Puisque le système de menus est un proche cousin des "lire la suite", révisons nos classiques. Faire un "lire la suite", comme d'ailleurs son symétrique "cacher la fin", repose sur les idées suivantes :

  1. le bout de page à cacher ou afficher est emballé dans un div, span ou tout autre élément, existant ou créé pour la circonstance, auquel on donne un identifiant (c'est indispensable) ;
  2. ce bout de page est, en général, caché lors du chargement de la page – autrement dit il est en display:none dans le CSS ;
  3. un premier lien, "lire la suite", situé en dehors de ce bout de page, permet de le faire apparaître. Le gestionnaire onclick de ce lien intervient sur le style du bout de page pour le mettre en display:block ou display:inline selon le cas. Puisque la suite est affichée, le lien "lire la suite" devient inutile et donc son gestionnaire onclick le cache – une forme de hara-kiri, en somme :
  4. si l'on souhaite que l'opération soit réversible (= cacher de nouveau cet élément, le renvoyer à son état initial) un deuxième lien, "cacher la fin", situé dans ce bout de page, permet de cacher le bout de page et de faire réapparaître le lien "lire la suite", toujours en intervenant sur le style de ces deux éléments.

Clair ? Quatre idées en tout, et cette architecture peut servir à faire autre chose que cacher ou masquer le bout de page (par exemple changer sa taille de caractères ou sa couleur de fond, plus généralement le faire passer d'une classe à une autre).

Le point important, pour ne pas désorienter le lecteur, est de n'afficher que le bouton de commande pertinent : "lire la suite" si le texte est caché, "cacher la fin" si le texte est affiché. C'est d'ailleurs ce qui se passe dans l'article que vous êtes en train de lire… et c'est ça qu'il est délicat de réaliser pour le système de menus : les liens "cacher le module" ne peuvent pas se trouver dans les modules puisque leur HTML, on l'a dit, est produit automatiquement par OB.

Passage au système de menus

Les boutons "afficher tel module" et "cacher ce même module" seront forcément dans le nouveau module de texte libre (= le biniou), charge à chaque bouton de cacher l'autre. On peut dès lors envisager deux grandes voies :

  1. chaque module s'affiche ou se masque indépendamment des autres.
    Il faut alors que chacun des deux boutons "cacher" et "afficher", d'une part cache ou affiche le module, d'autre part se cache lui-même et révèle le bouton opposé (déjà dit). Il y a en tout deux fois plus de boutons que de modules, un seul des deux boutons de commande est visible à un instant donné, on affiche au total autant de boutons que de modules.
    Il faut et il suffit de savoir fabriquer un "lire la suite" pour creuser cette idée, je ne le ferai donc pas dans ce papier déjà bien assez long.
  2. un seul module s'affiche à la fois (comme sur ce blog)
    Il faut alors que chaque bouton "afficher un module" affiche le module et se cache lui-même, comme auparavant, mais il faut aussi que ce bouton cache le module précédemment affiché et révèle le bouton d'affichage associé. Il n'y a plus besoin de bouton "cacher le module" mais, en échange, il faut savoir quel module est affiché. Ça, c'est possible avec une petite finesse de JavaScript que j'expliquerai plus loin. Jusque là, admettez seulement que c'est possible et qu'on sait en permanence quel module est actif.

L'effet de  menu glissant 

À première vue, le biniou regroupant les boutons de commande ne peut qu'être séparé des modules dont il commande l'affichage, puisqu'il est un module à part. Or, tel que je l'ai construit, mon biniou semble entremêler les deux, avec des boutons au-dessus et au-dessous du module affiché. J'espère que l'effet est joli et l'utilisation intuitive (c'était le plus important) mais il a fallu un peu de  jus de méninges … et de tromperie optique à base de positionnement absolu. Je vous avais bien dit que c'était du CSS délicat, faites chauffer le café.

Première idée : à coups de CSS, les modules à commander reçoivent tous la même hauteur, quitte à y faire apparaître une barre de défilement si cette hauteur est trop faible pour eux (exemples : les liens et les archives). Autrement dit, pour ces modules, on a une règle de CSS avec un looooong sélecteur :

 #module_1 .box-content, #module_2.box-content /* tous les modules concernés */ {height:une_hauteur_donnee; overflow-y:auto} 

Deuxième idée : le module "biniou navigatoire" ne contient que les liens de commande d'affichage, ne contient que des éléments a. À ce stade, le biniou ressemble à un gros bouzin informe.

Troisième idée : encore à coups de CSS, ces liens occupent la pleine largeur du module (autrement dit display:block pour tout le monde) et reçoivent l'aspect et les dimensions des barres de titre des modules. À ce stade, le biniou ressemble donc à une pile de barres de titre qui sont, en réalité, des boutons de commande.

Quatrième idée : le lien correspondant au module actif (car on postule qu'on le connaît, ce module !) est d'une classe différente de celle des autres liens. La seule différence entre cette classe et celle des boutons "au repos" porte sur sa hauteur, qu'on se débrouille pour rendre égale à celle d'un module complet (titre et contenu). À ce stade, le biniou ressemble donc à un module normal, en pleine hauteur, avec les barres de titres des modules cachés empilées en-dessus et en-dessous. C'est presque bien, mais le module n'est toujours pas là…

Cinquième et grandiose idée, préparée par les précédentes : les modules concernés sont mis en position:absolute, et puis :

  • on se débrouille (propriété CSS top) pour que le sommet de chaque module coïncide exactement avec le sommet de son bouton d'affichage,
  • comme les modules sont en positionnement absolu, ils viennent s'écrire par-dessus le biniou,
  • mais puisqu'un seul module est visible, les boutons du biniou situés plus haut que lui restent accessibles
  • et comme le bouton du module visible est aussi haut que ce module, il repousse les boutons suivants vers le bas, au-dessous du module, où donc ils sont accessibles eux aussi.

Peut-être qu'un petit schéma ? Tous les modules sont ici montrés, décalés vers la droite dans l'espoir d'y voir clair. En réalité tout le monde est aligné verticalement et invisible à l'exception du module actif (sur la figure, c'est le quatrième).

Notez que

  • chaque bouton du biniou  mime  la barre de titre du module correspondant ;
  • les boutons qui précèdent le module affiché ont donc l'air normal ;
  • le bouton du module affiché, lui, a la hauteur exacte de ce module et il se cache pile derrière ses larges épaules ;
  • la hauteur totale du biniou est constante : celle d'un module, augmentée de la hauteur des barres de titres de tous les autres.

Petit avantage technique : comme le module visible cache son bouton de commande, ce bouton n'a plus besoin de se cacher lui-même : un peu de JavaScript en moins.

Petit inconvénient technique : comme la hauteur des boutons change à tout bout de champ, ce procédé conduit à recalculer le biniou, et donc la page, à chaque changement de module – et ceci bien que les dimensions du biniou soient constantes. Cela ralentit sensiblement l'affichage, la solution vous sera donnée plus bas : un peu de CSS en plus.

… masquer la fin de la présentation

Si vous avez pigé l'idée, passons maintenant à la technique bestiale.

Les détails du système

lire les horreurs techniques…

Pour l'exposé le biniou se réduira à l'essentiel, quatre modules usuels : derniers articles, derniers commentaires, archives et liens. Au chargement de la page le module  Derniers articles  sera visible et les autres, cachés. Pas de décoration raffinée : les bordures et leurs petits pixels font faire beaucoup de calculs bourrins pour que rien ne déborde. À vous d'ajuster les valeurs numériques à vos besoins et de compléter la décoration.

Enfin, dans ce qui suit, le mot  module  sans autre précision ne désigne que les modules dont l'affichage est géré par le biniou – les autres modules, tels le calendrier dans mon blog, ne sont évidemment pas concernés.

Configuration OB

Chaque module DOIT avoir un id, ce qui n'est pas le cas par défaut. Dans l'admin OB, il faut donc aller dans Configurer/ Options globales / Réglages avancés et cocher la case  permettre la configuration des id XHTML des modules  . Après quoi, toujours dans l'onglet  configurer , donnez un id de votre choix aux modules (petit marteau). Deux modules ne sauraient avoir le même identifiant, évidemment, et nous les baptiserons ArticleRecent, CommentRecent, Archives et Liens. Vous prenez bien ce qui vous plaît, mais il faudra vous en resservir dans la suite.

Le biniou portera l'identifiant biniou (pourquoi pas ? même procédure que pour les autres). Il sera commode, pour commencer, de placer ce biniou au début de la colonne dans la config OB – justification et compléments plus loin.

HTML

Voici une première version du code source du biniou. Attention : le JavaScript ne sera donné qu'un peu plus tard, ne recopiez donc pas ce HTML.

 <a href="#" class="btn_on" id="btn_ArticleRecent">Derniers articles</a> <a href="#" class="btn_off" id="btn_CommentRecent">Commentaires</a> <a href="#" class="btn_off" id="btn_Archive">Archives</a> <a href="#" class="btn_off" id="btn_Liens">Ailleurs ...</a> 

Ça, c'est le niveau zéro du langage HTML : une suite de liens, même pas une liste (pourquoi ne pas faire une liste ? J'y ai renoncé après avoir observé qu'IE laisse toujours un ou deux pixels entre les éléments d'une liste, même en mettant à zéro les marges et remplissages. Ils sont un peu directifs, chez Microsoft).

Notez tout de même que :

  1. chaque bouton porte un id composé en ajoutant le préfixe  btn_  (restons cohérent) à l'identifiant du module associé. Respectez les majuscules et minuscules !
  2. le premier bouton est de classe btn_on parce que son menu sera initialement visible ,
  3. les autres boutons sont de classe btn_off (menu caché).

Et comment sait-on que btn_on ou off correspond à un menu visible ou caché ? C'est le JavaScript qui fera respecter la correspondance, nous verrons ça le moment venu.

CSS

Maintenant, le CSS de tout ça, en plusieurs sections qu'il faudra évidemment assembler.

Le noyau dur pour les modules :

 #ArticleRecent, #CommentRecent, #Archives, #Liens {visibility:hidden; position:absolute; width:210px} #ArticleRecent {visibility:visible;} /* module initialement visible */ 

On joue ici sur le visibility des modules alors que "lire la suite" joue sur leur display . Pourquoi ? Premièrement : les modules sont en positionnement absolu, donc on sait que leur apparition ou disparition ne changera rien à la page, donc les deux options sont ici équivalentes. Deuxièmement : l'expérience m'a montré que jouer sur visibility donne un meilleur temps de réponse, alors voilà.
La mention de width, si la largeur des modules n'est pas déjà définie ailleurs dans le CSS, est nécessaire pour que les modules en positionnement absolu gardent la même largeur que les autres.

Les deux classes possibles pour un bouton

 .btn_off { /*détails divers*/ } /* bouton inactif */ .btn_on { /*détails divers*/ } /* bouton actif */ 

Les "détails divers" sont ce que vous voulez, sauf la hauteur et le padding (voir plus loin).

Mise en forme minimale du biniou :

 #biniou a {display:block;} /* Les boutons en colonne */ #biniou .box-titre {display:none} /* Pas de titre pour le biniou */ 

Hauteurs et remplissages pour faire coïncider modules et boutons :

 /* Hauteur des modules (200px pour l'exemple) */ #ArticleRecent, #CommentRecent, #Archives, #Liens {height:200px;} /* Hauteur des boutons selon leur état */ #biniou a, .box-titre {height:15px;} /* Boutons et titres ont la même hauteur */ .btn_off {padding-bottom:0px;} /* inactif haut comme un titre : 15 + 0 = 15 */ .btn_on {padding-bottom:185px;} /* actif haut comme un module : 185 +15 = 200 */ 

L'important est ici que la hauteur totale (height et padding) soit la même pour, d'une part un bouton inactif et une barre de titre, d'autre part un bouton actif et un module complet. Ainsi le module affiché pourra se superposer exactement à son bouton de commande.

Complément pour gérer les débordements dans les modules :

 #ArticleRecent .box-content, #CommentRecent .box-content, #Archives .box-content, #Liens .box-content {overflow-y:auto;} /* Rétrécir les listes pour laisser place à une éventuelle scrollbar verticale */ #Archives li, #Liens li {width:195px;} 

Dans la dernière règle, la valeur de 195px n'est bien sûr qu'une indication, elle dépend de la largeur des modules : prévoyez 15 ou 20 pixels de diminution pour être tranquille. Notez aussi qu'il n'est pas obligatoire de faire porter cette règle sur tous les modules, seulement sur ceux qui risquent de déborder. Ici je suppose le gabarit de 185 pixels assez haut pour que les 10 liens maximum des  derniers articles  et  derniers commentaires  veuillent bien y rentrer.

Il faut se prémunir contre le recalcul de toute la page à chaque changement dans le biniou. La solution est de placer le biniou lui aussi en absolu : il sort ainsi du flux et le navigateur saura qu'il ne devra recalculer que le biniou plutôt que toute la page. Mais placer le biniou en absolu crée un grand vide dans la colonne de modules, vide compensé par un gros padding-top pour cette colonne.
Concrètement :

 #biniou {position:absolute} #biniou {height:245px} /* Hauteur biniou = un module + (4-1) titres */ #cl_1_1 {padding-top:262px} /* padding supérieur à la hauteur du biniou */ 

Avoir placé le biniou en début de colonne dans la config OB explique que le gros padding soit ajouté à cette colonne plutôt qu'au module qui suit ou précède le biniou. Cette place en début de colonne est importante aussi parce qu'elle garantit que les modules escamotables suivront le biniou – et viendront donc le recouvrir bien qu'il soit devenu absolu comme eux. Sans quoi, on s'en sortirait tout de même à coup de z-index mais c'est déjà bien assez tordu comme ça.

Reste enfin à étager les modules, en les espaçant d'une hauteur de bouton/barre de titre, soit 15 pixels dans notre exemple :

 #biniou, #ArticleRecent {top:170px;} #CommentRecent {top:185px;} #Archives {top:200px;} #Liens {top:215px;} 

L'ordre vertical des modules suit l'ordre vertical des boutons, le sommet du premier module coïncide avec le sommet du biniou (et donc du premier bouton) : chaque module recouvrira son bouton, le tour est joué !

Pas trop assommé ? Allez, on avance.

JavaScript

Jusqu'ici le système est complètement inerte : le premier module s'affichera, il s'affichera au bon endroit, mais rien ne pourra changer. En ajoutant à chaque bouton du biniou un gestionnaire onmouseover (ou onclick si on préfère un système à clic), on va mettre un peu d'animation.

Ce gestionnaire, revenons-y, doit accomplir les tâches suivantes :

  1. déterminer, d'après l'identifiant du bouton, le module qui lui correspond ;
  2. déterminer le module actuellement affiché, sachant qu'au chargement de la page c'est  Orientation  ;
  3. masquer le module affiché, montrer le module associé au bouton, et  noter dans un coin  que c'est désormais lui le module affiché ;
  4. voilà tout.

Le gestionnaire n'a pas besoin de masquer le bouton qui le porte, puisque c'est son menu associé qui s'en charge. Il n'a pas non plus besoin de se demander si le menu associé est déjà affiché, puisqu'alors le bouton est masqué et donc impossible à survoler ou cliquer.

Je vous balance ici le texte complet du premier bouton de commande, copiable/collable en l'état, nous disséquerons le JavaScript ensuite.

 <a href="#" id="btn_ArticleRecent" class="btn_on" onmouseover=" var cemodule=this.id.substring(4); if (typeof(moduleactif)=='undefined') {moduleactif='ArticleRecent';}; document.getElementById('btn_'+moduleactif).className='btn_off'; document.getElementById(moduleactif).style.visibility='hidden'; this.className='btn_on'; document.getElementById(cemodule).style.visibility='visible'; moduleactif=cemodule; return false; ">Orientation</a> 

Comme dit plus haut, le onmouseover doit être ajouté, tel quel, à tous les autres boutons du biniou. Exemple sur le bouton suivant :

 <a href="#" id="btn_CommentRecent" class="btn_off" onmouseover=" var cemodule=this.id.substring(4); if (typeof(moduleactif)=='undefined') {moduleactif='ArticleRecent';}; document.getElementById('btn_'+moduleactif).className='btn_off'; document.getElementById(moduleactif).style.visibility='hidden'; this.className='btn_on'; document.getElementById(cemodule).style.visibility='visible'; moduleactif=cemodule; return false; ">Derniers articles</a> 

Remarquez que, dans la troisième ligne, on n'a pas remplacé  ArticleRecent  par  CommentRecent  .

Dissection : vous n'êtes pas du tout obligé de lire la fin de cette section mais il peut être intéressant de voir, instruction après instruction, comment se réalisent les points précédents :

  1. this.id désigne l'id du bouton que l'on survole. C'est une chaîne de caractères et l'appel à substring(4) en extrait les caractères à partir du rang 4, sachant qu'on compte à partir de zéro. Pourquoi le rang 4 ? Parce que 'b', 't', 'n' et '_', ça fait quatre caractères. Le résultat est stocké dans cemodule, variable locale du gestionnaire (locale = qui retournera au néant après l'exécution du programme) ;
  2. la ligne suivante détermine le module déjà affiché, dont le nom est stocké dans moduleactif. Voici la kolossale finesse évoquée tout à l'heure : moduleactif n'est pas déclaré dans une instruction var comme la précédente. Qu'est-ce que ça change ? Cela signifie que, contrairement à cemodule vu juste avant, moduleactif est une variable globale, qui existait avant l'exécution du programme et subsistera après. Mais où donc reçoit-elle sa valeur initiale ? Deuxième kolossale finesse. Au départ (= la première fois qu'on active un gestionnaire) cette variable est inconnue au bataillon, elle est indéfinie, et c'est ce que détecte le test sur typeof. Dans ce cas, et dans ce cas seulement (= où l'on n'avait encore survolé aucun bouton) on sait par le CSS que le module affiché est  ArticleRecent  et l'on donne donc cette valeur à moduleactif ;
  3. puis on fait le ménage en quatre lignes : changement de visibility sur le bouton du module actif et le module actif, puis sur le présent bouton et son module associé ;
  4. enfin, on prend note de la nouvelle situation en mettant moduleactif à jour.
  5. et le programme se termine par l'habituel return false ; qui empêche de suivre le href parfaitement bidon du bouton de commande

Voilà, c'est tout.

Ne pas croire…

Quelques contresens possibles :

  • le seul module texte libre requis par le système est le biniou. Rien ne vous impose d'inclure un tel module dans les menus escamotables (comme je l'ai fait avec  Orientation ) :
  • dans la config OB, placer le module  biniou  en sommet de colonne n'est pas obligatoire mais seulement commode. S'il est précédé par des modules  normaux , il faudra remplacer le gros padding sur la colonne de modules par une grosse marge basse sur le module qui précède le biniou ou haute sur celui qui le suit. S'il est précédé par certains des modules escamotables, il faudra donner de bons z-index aux uns et aux autres pour s'assurer que le biniou s'affiche en-dessous des modules escamotables plutôt qu'au-dessus.
  • rien n'impose que le module initialement visible soit le premier. Il faut seulement veiller à ce qu'un module et un seul soit déclaré visibility:visible dans le CSS, à ce qu'un et un seul bouton du biniou soit de classe btn_on, et à ce que ces deux éléments se correspondent. Il faut enfin veiller à ce que le nom de ce module initialement visible soit inscrit dans le JavaScript.

Aparté technique : le temps de réponse

Ce point est important pour un système à survol. On en a déjà parlé au fil de l'article, résumons ici.

L'affichage et le masquage des modules sont instantanés, mais le changement de padding des boutons prend du temps parce que le navigateur doit réarranger toute la page – et c'est très lent.

Mettre le biniou en positionnement absolu (et donc le sortir du flux) arrange un peu les choses puisque le changement d'état d'un bouton ne fait plus recalculer que le biniou : on passe de  très lent  à  encore un peu trop lent .

En imposant une hauteur au biniou (ce qui n'était pas indispensable en principe) j'ai constaté qu'on arrivait à  acceptable  (mais pas encore  instantané ). Si vous avez une meilleure idée, je prends !

… masquer les détails techniques

Un guide de survie

C'est pas simple, hein ?

Quelques indications pratiques…

Petit mot pour conclure

Bien que ce gadget se contente de combiner des techniques assez connues (positionnement absolu, JavaScript simple), je ne crois pas qu'il puisse se mettre en place à l'aveuglette. Il m'a semblé important d'exposer les idées sous-jacentes (et puis j'aime bavarder…) pour comprendre ce à quoi riment les modifications nécessaires, qui sont volumineuses. J'aimerais vraiment savoir ce qui vous a semblé clair (s'il y en a) et moins clair dans ce papier.

par Aïe mes doigts ! - dans La gadgetière
commenter cet article

commentaires

Bill 16/07/2009 12:48

Je crois être enfin arrivé à quelque chose de correct. Je te remercie pour tes conseils et suggestions.

AïmD ! 16/07/2009 13:05


De rien :-)


Bill 16/07/2009 00:55

Ceci dit, ton système est beaucoup plus performant dans l'affichage des modules lorsque la souris se déplace vers le bas.
Le système simplifié que j'ai appliqué sur mon blog pour l'instant ne fonctionne vraiment bien que lorsque la souris parcourt les modules en les remontant.
Si tu as une solution simple, je suis preneur. Sinon, je tenterai peut-être un jour ton système assez complexe. Mais il me faudra alors une bonne dose d'énergie et de temps ... ;)

AïmD ! 16/07/2009 09:51


Tu n'auras pas besoin de tenter de dompter le monstre, je pense... D'ailleurs, depuis que ce blog est en privilège, j'utilise autre chose :)
Il y a deux aspects dans cet article (que je devrais réorganiser une fois encore, pfffouuu...)
1-la superposition des modules "élastiques" et du module texte libre qui les commande. Ceci m'était imposé par le niveau confiance : le seul JS possible est dans les gestionnaires d'événements, il
fallait donc un module pour recevoir ces gestionnaires.
Ca, tu peux laisser tomber.
2-le temps de réponse.
D'abord : en la matière il n'y a pas de réponse tranchée, parce que tout ce qui se passe dans le blog a une influence. Il me semble que le tien contient divers gadgets (un lecteur deezer, entre
autres) qui continuent à solliciter le micro et à charger des données alors même que la page semble complètement chargée : autant de ressources en moins pour le reste. Chez moi ce sont les gifs
animés qui tendent à geler la mécanique : arbitrages douloureux en perspective.
Je crois qu'il faut commencer par ça : tous ces gadgets sont-ils indispensables ?
Ensuite : ta solution repose sur une bascule display:none/display:block. Cette bascule oblige le navigateur à recalculer la page : la colonne de modules change, sa hauteur aussi, du coup le pied de
page est susceptible de bouger lui aussi. Tout ça fait beaucoup de calculs.
De plus, display:none a un effet radical : box-content ne crée pas de boîte (=de rectangle) à l'écran et rien de ce qui est à l'intérieur n'en créera non plus. Je soupçonne donc que le navigateur
se dispense de calculs qu'il sait inutiles, et qu'il les fait en urgence lorsqu'on revient à display:block.
Essaie donc de réduire le nombre des modules soumis à escamotage. C'est ce que j'ai fait (un peu) chez moi.
Peut-être aussi (supposition perso, non testée) qu'en remplaçant la bascule display:none/display:block par height:0/height:auto on perdra un peu de temps de chargement initial (car calcul de tous
les modules) mais qu'on gagnera un peu de temps de réaction au survol (car modules déjà calculés). En tout cas c'est simple à tester.
Bref : pas de réponse-miracle, pas non plus de tâtonnements en aveugle complet, seulement se poser la question : qu'est-ce qui bouffe du CPU ?


Bill 15/07/2009 17:43

Apparemment, le système fonctionne sous Firefox, Google Chrome, Internet Explorer 8 mais aussi 7. Qu'en est-il avec IE 6, Opera, ... ?

AïmD ! 15/07/2009 21:18


IE6 non, c'est certain (mais sa part de marché décroît rapidement)
IE7 ça c'est la bonne nouvelle - pour des raisons trop longues à donner ici je ne peux pas installer IE7 sur ma bécane
Opera et les autres : tous ces navigateurs récents respectent la plupart des standards, je ne suis donc pas inquiet a priori.
Tout ça est plutôt sympathique :)


Bill 15/07/2009 01:29

Un tout tout grand merci, Bren, pour cette présentation claire et didactique. Je te jure que j'ai tout lu.
Cependant, à ce jour, je ne tenterai de l'appliquer que si le solution initiale ne fonctionne pas car IE semble l'accepter à ce jour. Exemple sur un module texte libre que j'ai appelé div :
#div .box-content {display:none}
#div:hover .box-content {display:block}
Cela suffit.
Encore merci. Tes explications sont extrêmement didactiques et je me plais à me promener sur ton blog.

AïmD ! 15/07/2009 09:52


AHHHHH ! Depuis le temps qu'on l'attendait sans y croire ! Micromou a enfin bougé !
Ta solution est parfaite dans son principe (le choix du mot div pour nommer un texte libre est un peu trompeur, mais c'est un détail). Je crains (prétérition...) cependant qu'elle ne donne
rien sous IE7 ou antérieur...


Vanille 14/07/2009 01:04

Bonjour,

J'aimerai cacher un module particulier dans mon blog et je veux qu'il soit apparent seulement lorsqu'on clique dessus. Mais comment faire, sachant que je suis nulle en informatique et je me noie dans les termes informatiques, oui pour vous dire qu'il y a certains termes comme javascript ou css ou htlm où c'est carrément du charabia, mélanger à de l'anglais mais là...je suis face à un langage "extraterrestre"

tout ça pour vous dire que moi il faut pas m'expliquer ou m'apprendre mais me dire de placer ça et basta, peut être que pour vous ça semble de la fainéantise pas du tout c'est de l'ignorance totale

pourriez vous m'aider svp?

merci encore et désolée de vous déranger

vanille

Aïe mes doigts ! 14/07/2009 18:10


Pour faire ça, la technique décrite dans "Des modules repliables" sera beaucoup plus simple si ton blog est à un niveau supérieur à "Confiance".
La technique ici décrite est assez acrobatique, je le signale d'ailleurs à plusieurs reprises, ce n'est donc pas le bon article pour quelqu'un qui ne veut pas se prendre la tête.
Et puis faut pas rêver : le "presse-bouton intégral pile comme je veux" n'existe pas - le développement informatique, c'est tout de même un métier...


Marcovaldo 07/09/2008 17:00

Hélas, trois fois hélas, je ne comprends pas grand chose...
Et pourtant c'est un menu de ce style que j'aimerais vraiment mettre... Tant pis.

AmD 07/09/2008 17:27


Allons, allons... Haut les coeurs ! Je vais essayer de décomposer le mouvement, plus nettement peut-être que je ne l'ai fait dans l'article :
1- le mécanisme central est *simple* (si !) : masquer ou afficher un module en agissant sur un lien placé ailleurs dans la page (agir=cliquer ou survoler). C'est exactement le principe du "lire la
suite", appliqué à un module au lieu d'une portion d'article.
2 - comme on ne désire voir qu'un module à la fois il faut ajouter au JS du "lire la suite" qqs instructions pour que l'apparition d'un module provoque la disparition de celui précédemment
affiché.

Le reste, tout le reste, est un pur travail de CSS et de HTML visant à créer une illusion d'optique. Quelle illusion ? Que le module, quand il s'affiche,  recouvre exactement son bouton de
commande.
Le travail HTML est la création d'un module TL regroupant tous les liens de commande (le "biniou").
Le travail de CSS a deux faces :
1-rendre le bouton de commande du module qu'on affiche exactement aussi grand que ce module
2-superposer ce module à son bouton de commande.

Résultat :
1- quand on ne survole pas le bouton, il est "petit" et son module associé est invisible
2- quand on survole le bouton, il grossit (il décale donc tous les autres) et se trouve masqué par le module rendu visible

Est-ce plus clair ?


Julie 30/07/2008 19:56

Hello, grand manitou du CSS!

Je viens implorer ton aide...je suis désespérément à la recherche d'un article de ton blog où tu expliquais l'astuce des commentaires qui s'ouvrent en pop-up, ainsi que le formulaire d'ajout..

Pas moyen de le trouver, ça fait deux heures que j'épluche tes pages, alors ou bien je cherche mal ou bien j'ai rêvé et cet article n'a jamais existé!

Quoiqu'il en soit, est ce que tu pourrais me renseigner? Je suis en train de réaliser le blog d'un groupe, et cette petite fonctionnalité serait très utile vu ce qu'ils me demandent..

Bises!

Aïe mes doigts ! 30/07/2008 20:11


Hum...cet article n'a jamais existé... et sa rédaction n'est pas pour tout de suite, parce que c'est encore plus touffu que le biniou navigatoire ! (si si, on peut faire pire...)
Désolé de ne pouvoir te dépanner au vol, mais c'est un peu trop complexe à expliquer en deux lignes si tu n'as pas déjà écrit du JS toi-même. M'enfin, on peut causer par mail...
Autre chose : de quel formulaire d'ajout veux-tu parler ?


mebahel 30/07/2008 19:15

Je passe faire un petit coucou-bonjour.
Coucou-bonjour!!
Wala.
Mais nan, je lis pas.
Je tiens à préserver ma réputation de nulle en cé hesse hesse et autres javanaises.

Aïe mes doigts ! 30/07/2008 20:05


Bonjour-coucou. Sois rassurée, ta réputation reste intacte, liliale, toute de probité candide et de lin blanc...
Ca va, comme ça ? ;-D


Florence 27/07/2008 23:27

Trop fort pour moi !
je vais rester avec mon basique de chez basique
...merci quand même !
Attention aux doigts, alors
:-))
F.

Aïe mes doigts ! 27/07/2008 23:43


Ah certes, ce n'est pas du presse-bouton combiné à du copier/coller... je me suis efforcé de prévenir les lecteurs ! :-)


Marcovaldo 25/07/2008 20:33

Je suis tenté par faire un menu déroulant comme le tien mais je ne comprends rien, c'est du chinois pour moi. :(

Aïe mes doigts ! 25/07/2008 20:52


Je viens de relire l'article et j'avoue que tu as raison : c'EST du chinois ! De plus et de toute manière, c'est déjà assez relevé techniquement. Je crois que cet article est à refondre, et
probablement à couper en deux ou trois tranches.

Pfou....encore du boulot :-( Raconter Paris, c'est bien plus simple !


Archives