Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
6 novembre 2010 6 06 /11 /novembre /2010 22:00

Des p'tits trucs, des broutilles, des retouches, des gadgets, des miettes, des coups de pinceau, deux clous trois planches, des pipouilles… J'avais d'abord pensé ne rien dire, vous laisser découvrir vous-mêmes mais… mais vos marques d'admiration (spontanée), vos Oh ! et vos Ah ! (irrépressibles), vos péans, panégyriques et dithyrambes (totalement improvisés) sont un tel bienfait que j'ai souhaité leur donner quelque aliment. Voici donc, et dans le désordre :

  • l'adhésif jaune repositionnable (marque déposée) projette maintenant une vraie ombre sur le haut des articles – si votre navigateur sait traiter les fichiers PNG ;
  • une maquette revue pour les pages que personne ne va lire, comme la liste des articles d'une rubrique (désormais 8 articles par page au lieu de 6, toujours dans un volume espéré raisonnable) ou la liste complète des articles ;
  • d'ailleurs cette liste complète figure maintenant dans les menus de coin, ça m'a semblé pratique.

Des gains de rapidité, aussi. Je sais bien en avoir déjà souvent annoncés par le passé mais cette fois-ci, grande nouveauté, il ne s'agit pas de la correction en aveugle d'un défaut surgi on ne sait d'où : progrès substantiel ! Le petit bus roule vite, les fonds animés tournent comme je le souhaitais depuis le début, les menus du biniou s'ouvrent et ferment presque instantanément… je suis heureux. Et puisque j'ai l'impression d'avoir compris ce que je faisais, il y aura un supplément spécial geek – lecture parfaitement dispensable pour les non-geeks.

Dernier ajout et qui, en prime, s'est réalisé beaucoup plus vite que les autres. Le petit pavé de droite regroupe plusieurs modules, je l'ai fabriqué pour que le lecteur ait tous ces modules sous la main sans devoir faire défiler des kilomètres d'écran. Je persiste à penser que l'idée était bonne ; seulement, pour peu qu'on fasse défiler une page un peu longue, ce biniou sort du champ – c'était bien la peine de tout regrouper… Alors j'ai changé quelque chose…


Le coin des fondus, maintenant. Il ne s'agit ici que de ce que j'ai cru comprendre, surtout pas de certitudes gravées dans le marbre.

Il existe plusieurs manières de ralentir un site. L'une des plus efficaces et répandues est de le truffer d'animations Flash jolies, inutiles et mal programmées. Lorsqu'il n'y a, comme sur ce blog, pas un octet de Flash, on y arrive très bien tout de même. Il suffit de faire (re)dessiner par le navigateur plus de pixels que nécessaire. Tant qu'il ne s'agit que du premier affichage de la page ce n'est pas très grave : une demi-seconde de plus ou de moins, ma foi… ne vaut pas le coup de s'arracher les cheveux. Tout change lorsqu'on introduit des effets dynamiques, ne serait-ce qu'un simple hover. Une demi-seconde de plus ou de moins pour faire apparaître un menu, c'est énervant…

Premier exemple de souffrance : les fonds animés. Longtemps je les avais implantés (par un coup de JavaScript) comme image de fond (background-image) du body de la page. Parfait comme résultat visuel : le fond est bien en-dessous de tout le reste. Seulement c'est le fond du body, donc de tout l'écran, même si ce fond n'est pas répété (background-repeat:no-repeat). Lorsque ce fond est un gif animé, je pense donc que chaque nouvelle image du gif oblige le navigateur à au moins vérifier l'ensemble de l'écran, quitte à conclure qu'il n'y a rien à y changer. Remède apporté : le fond est désormais image de fond d'un div rajouté à la volée. Ce div est en position:fixed, doté de dimensions juste suffisantes selon le  film  à montrer et, surtout, il est en overflow:hidden. Ceci, je pense, donne au navigateur la certitude qu'il n'a pas à s'inquiéter de ce qui se passe en-dehors du div, qu'il ne doit gérer que 100x50 pixels (= le fond animé) plutôt que 1200x1000 (= l'écran complet). Observation qui confirme ce raisonnement : avec l'ancienne technique (fond appliqué au body), le film se déroule bien mieux si on rétrécit la fenêtre aux dimensions du film.

Deuxième exemple de souffrance : les menus du biniou. J'ai longtemps cherché, là… C'est encore une question d'overflow, reste à savoir de quoi.

Il y a du débordement dans ces menus : les infobulles. Mettre le biniou en overflow:hidden, juste pour essayer, rogne bien ces bulles mais n'accélère pas sensiblement les choses. Autre chose, ailleurs dans la page, déborde aussi : les images au coin supérieur gauche des articles (ici le morphing entre Einstein et Frankenstein). Même traitement pour la cellule des articles, même résultat : rognage sans gain de performance. Autre chose encore déborde : les menus non affichés, que le CSS envoie très loin en dehors du cadre… j'en oublie encore certainement.

Ce qui a finalement tout réglé a été de mettre le corps de blog #global en overflow : hidden et lui seul, quitte à lui ajouter assez de padding sur les côtés pour que bulles, icônes et menus se voient en entier. Tout bénéfice : les infobulles et les icônes continuent de déborder gaiement et le biniou réagit au quart de tour ! Pourquoi est-ce efficace ? Je ne suis pas pleinement certain de ce qui va suivre. Tout d'abord :

  1. à force d'ajouter des bricoles à ce blog je ne sais plus toujours très bien qui est rattaché à quoi, qui déborde de quoi ;
  2. donc, au moment d'intervenir pour tenter de corriger, je ne sais pas forcément non plus qui doit autoriser les débordements et qui peut les rogner ;
  3. de toute manière, même un retour au CSS d'origine .ln,.cl{overflow:hidden} ne suffit pas !

Dans ce dernier essai j'observe que les éléments placés en position absolue avec top ou left ou les autres ne sont pas rognés, contrairement à ceux qui ne sont placés qu'avec des marges. Par exemple, les infobulles (calées avec des marges) sont rognées, le postit (flûte pour la marque déposée), calé avec top et right ne l'est pas alors qu'il déborde largement de son élément parent. Ahhhh ? Serait-ce que le placement par des marges a d'autres effets secondaires que le placement par top et right ? Un peu surprenant, quand on y songe. Mais, toujours à propos de cet adhésif etc., quel est ce parent dont il déborde (ou pas) ? Ici commencent les finesses, accrochez-vous un peu.

Pour des raisons diverses, et malgré les apparences, j'ai placé ce postit-flûte dans le pied de page du blog (maintenant que j'ai compris ce qui se passait, je le remonterai peut-être dans l'en-tête). Bon.

Donc, du point de vue de l'arborescence du document, le parent du postit-flûte est le même que celui du bandeau grisé  Bren du fat !  ou du petit module  Voies rapides . Si je mets le pied de page en overflow:hidden et que je tente de faire déborder le bandeau ou le module, ils seront rognés comme on pouvait s'y attendre.

Le postit-flûte, lui, est en position : absolute et ce n'est pas indifférent. Un élément en positionnement absolu n'est pas forcément calé par rapport à son parent au sens de l'arborescence du document (= l'élément qui le contient, ici le pied de page), mais par rapport au premier de ses ancêtres placé en position absolute, fixed ou relative. Ici, les (principaux) ancêtres du postit sont le pied de page #footer, puis #cl_2_0, #ln_2, #global, #body et enfin l'élément html, ancêtre de tout le monde (= racine de l'arbre).

Comme je voulais caler ce postit-flûte par rapport à l'ensemble du blog, je m'étais bien gardé de toucher au positionnement de #footer, #cl_2_0 et #ln_2 et j'avais ajouté au CSS du blog #global {position:relative}. En jargon de CSS, j'avais fait de #global le  bloc conteneur  du postit. Si le postit n'avait pas été en positionnement absolu, son bloc conteneur aurait été son parent, situation la plus fréquente.

Je savais tout cela depuis lurette, j'ai même tenté de l'expliquer quelque part… Le résultat, en tout cas, était conforme à mes espérances.

Seulement j'avais négligé une chose. La propriété overflow:hidden, en somme, détermine un rectangle dont tout ce qui dépasse est rogné (ou pas si on choisit overflow:visible). C'est quoi,  tout  ? C'est tous les éléments auxquels celui dont on définit l'overflow sert de bloc conteneur. Relisez lentement : cela veut dire que, pour rogner ou non le postit, les limites qui comptent sont celles de #global (= son bloc conteneur) et pas celles du pied de page (= son parent) ! Cela veut dire, pour commencer, que tripoter la valeur d'overflow pour le pied de page ou ses divers étages ne pouvait avoir aucun effet sur le postit.

De plus, #global avait été promu bloc conteneur de pas mal de monde, et en particulier du biniou (lui aussi en position absolue). Tout changement d'aspect de ce  pas mal de monde  impliquait de recalculer #global, en tout ou en partie. Tant que #global n'était pas rogné, ce  en tout ou en partie  couvrait tout l'écran.

Dernière question : et alors, pourquoi les absolus placés par marges (= les infobulles) semblent-ils obéir à des principes différents ? Parce qu'il se trouve que, pour des raisons qui n'ont rien à voir avec les infobulles, j'ai été conduit à placer les modules en position:relative eux aussi, ce qui en fait les blocs conteneurs des infobulles. Si j'indiquais (ce que je ne fais pas) top:10px pour une infobulle, les 10 pixels seraient comptés à partir du sommet du module et non du sommet de la page. Donc indiquer overflow:hidden pour les modules conduit bien à rogner les infobulles. La cohérence est sauve…

Voilà mon interprétation, je crois qu'elle contient du vrai mais elle ne rend pas compte de tout : si je décide de rogner explicitement tout ce qui est placé par rapport à #global (= le postit, le biniou, le petit menu des fonds animés) et même, pour faire bonne mesure, tous les .ln et les .cl, mais sans rogner #global lui-même, il me semble que le navigateur  devrait comprendre  qu'il a du travail en moins. Or j'ai observé qu'une telle mutilation (car visuellement c'en est une !) n'améliorait que très peu les temps de réponse. Le CSS, c'est plein de mystères…

Dernier rappel tout de même : je ne me suis posé toutes ces questions que parce qu'il y a un tas de trucs qui bougent dans ce blog à l'architecture peu simple. Un design moins pathologique est à l'abri de ces inquiétudes :-)

par Wilhelm von Schmürz - dans Journal du savant fou
commenter cet article

commentaires

christina 15/11/2010 22:18


oulala, vous êtes en train de bricoler encore ??
je découvre la nouvelle pagination, bonne idée, mais en revanche en accueil le pied de page a disparu (y compris legals) et en haut plus de pellicule pour les fonds animés...


WvS 16/11/2010 09:58



Voui, travaux en cours... Avez-vous vidé le cache du navigateur ?



christina 07/11/2010 20:07


vous nous gâtez, la présentation des comms est belle et lisible ainsi, merci :)


WvS 07/11/2010 22:35



De rien. Votre gravatar est très bien lui aussi :-)



christina 07/11/2010 19:19


yééhhhh, merci, ça marche impec maintenant !
et le petit bateau en gravatar (quel mot horrible) est bien aussi
(m'en vais quand-même voir comment on fait ces machins-là)


WvS 07/11/2010 20:01



héhé... je vous avais bien dit que j'avais compris l'idée. Tant que j'y étais, j'ai aussi remis mes réponses en text-align:left ; leur lecture est moins fatigante lorsqu'elles sont longues :-)



brendufat 07/11/2010 14:25


Spécial Christina : le déplacement du biniou est corrigé : il s'efforce désormais de s'afficher aussi haut que possible :-)


Anna 07/11/2010 10:07


"Un design moins pathologique est à l'abri de ces inquiétudes :-) "

Bon, je m'en vais dire une neuvaine de remerciements, moi. ;-)
Pour info : le bloc est lisible en entier chez moi quel que soit le niveau où j'en suis dans l'article, par contre le fond fait des trucs bizarres quand j'ouvre la fenêtre de commentaires !


WvS 07/11/2010 12:53



On dirait bien que la dernière phrase n'était pas de trop !


Bloc lisible : tout dépend de la hauteur d'écran ou fenêtre de navigateur - cf. comm précédent et sa réponse.


"Trucs bizarres dans le fond" : je veux bien quelques précisions...



christina 07/11/2010 01:46


très très bien le temps de réponse plus rapide au survol du biniou !
MAIS... le biniou "toujours sous la main", c'est pas au point (sur mon écran en tout cas) : ça va quand on est en début ou en fin de page, mais dès qu'on la déroule il saute d'une centaine de
pixels vers le bas et du coup je ne peux plus accéder au-delà de 'documentation' - il faut pour cela attendre d'arriver en bout de page...
(je ne sais pas si je m'explique bien - photo demain si vous voulez - je suppose que sur un écran plus haut ça tient en entier ?)


WvS 07/11/2010 11:57



Ne vous fatiguez pas, je comprends l'idée. Vous avez raison, je n'avais pas pensé à tout !


Principe : le sommet du biniou reste à la même hauteur dans l'écran (soit 130px du bord)
J'ai ajouté une correction pour l'arrivée en bas de page, pour "freiner" la descente et ne pas empiéter sur le bandeau inférieur. Je n'ai pas pensé au haut de page. En fait, le biniou devrait se
percher aussi haut que possible (0px du bord) en restant, comme aujourd'hui , dans l'intervalle entre les deux bandeaux. apuka.



Archives