Coucou,
je ne suis pas d'accord avec
http://trac.rezo.net/trac/spip/changeset/12985 qui diminue encore la
lisibilité de ces balises déjà difficiles à comprendre.
Le #INSERT_HEAD et le #FILTRE{compacte_head} sont deux concepts
distincts, il ne faut pas les mélanger dans une seule balise
-- Fil
Hello,
Ce qui me chagrine dans le
#FILTRE{compacte_head}
est qu'on se retrouve avec une fonctionalité configurable dans l'espace privé mais qui ne marchera que si la directive est présente dans le squelette
Autrement dit, cela ne marchera qu'avec la dist de la 2.0, et obligera a reprendre tous les autres squelettes et les sites développés précédemment pour bénéficier de cette fonctionnalité.
L'autre raison est qu'#INSERT_HEAD re-insère de façon atomisée les js de jquery car compacte_head est supposé passer derrière, mais dans la pratique cela va impacter négativement les sites existants.
Dans la mesure où on a encouragé les utilisateurs à ajouter #INSERT_HEAD depuis plusieurs versions, il me semble le plus naturel de lier l'application du filtre à cette balise, pour en faire bénéficier le plus grand nombre :
ceux qui n'utilisent pas #INSERT_HEAD sont soit des gens qui savent ce qu'ils font et peuvent mettre le #FILTRE{...} à la main, soit des gens qui utilisent un vieux squelette, pas de jquery et n'ont pas besoin du filtre.
#INSERT_HEAD est deja une "boite noire qu'il faut mettre" pour beaucoup de monde, je ne vois pas ce qu'on a à gagner à en ajouter une seconde.
Je ne pense pas que nécessiter les deux balises soit très avantageux : ca ne rend pas leur compréhension plus simple, et cela fait deux "trucs" à ajouter dans le head au lieu d'un.
Il serait préférable de documenter en disant
"cette balise est nécessaire pour permettre à Spip d'ajouter ses feuilles de styles et ses scripts, et optimiser votre site si vous activez la fonctionnalité dans l'espace privé"
Cédric
Oui j'ai bien compris que c'est gagnant à court terme. Mais pour celui
qui veut comprendre comment SPIP fonctionne c'est vraiment une couche
supplémentaire de complexité => à bannir
-- Fil
Bonjour,
pour ma part je rajouterais juste un élément : j’ai la “fâcheuse” habitude d’insérer les fichiers javascript en fin de page, afin que son chargement ne soit pas bloqué le temps de la “digestion” du javascript. C’est une des recommandations classiques pour accélérer un site, et c’est impossible avec #INSERT_HEAD qui mélange tout : jQuery et les bibliothèques qui ne vont l’utiliser qu’une fois la DOM chargée.
En ce qui me concerne, j’aimerais bien que jQuery puisse être déconnecté de #INSERT_HEAD (car l’utilisateur l’a plus souvent dans son cache que notre assemblage maison, et ça peut nous permettre de choisir une version de jQuery disponible sur un serveur externe plus rapide), et que les javascript puissent être placées en fin de page (comme pour la création des boutons d’administration).
Mais ma capacité actuelle à étudier le code dépasse de loin mes souhaits…
mes 2 cents,
.Gilles
2008/10/19 Fil <fil@rezo.net>
pour ma part je rajouterais juste un élément : j'ai la "fâcheuse" habitude
d'insérer les fichiers javascript en fin de page, afin que son chargement ne
soit pas bloqué le temps de la "digestion" du javascript. C'est une des
recommandations classiques pour accélérer un site, et c'est impossible avec
#INSERT_HEAD qui mélange tout : jQuery et les bibliothèques qui ne vont
l'utiliser qu'une fois la DOM chargée.
Hum... As-tu esayé de mettre #INSERT_HEAD dans le pied de page ?
-- Fil
Non, car il me semble que #INSERT_HEAD ajoute aussi les CSS qui, pour le coup, doivent toujours toutes être dans le , si possible
(Sinon j’aurais un flash du plus désagréable effet)
.Gilles
Hum... As-tu esayé de mettre #INSERT_HEAD dans le pied de page ?
Non, car il me semble que #INSERT_HEAD ajoute aussi les CSS qui, pour le
coup, doivent toujours toutes être dans le <head>, si possible
(Sinon j'aurais un flash du plus désagréable effet)
seulement ceux des plugins, non ?
-- Fil
2008/10/20 Fil <fil@rezo.net>
Hum… As-tu esayé de mettre #INSERT_HEAD dans le pied de page ?
Non, car il me semble que #INSERT_HEAD ajoute aussi les CSS qui, pour le
coup, doivent toujours toutes être dans le , si possible
(Sinon j’aurais un flash du plus désagréable effet)seulement ceux des plugins, non ?
Peut-être, mais vu que je ne l’utilise jamais…
En tout cas, ça reste une mauvais stratégie, à mon avis, d’obliger les plugins à tout inclure en entête, en compressant toutes les infos.
Il y a un temps pour développer / débugguer et un temps pour optimiser.
.Gilles
la compression n'a rien d'automatique : elle doit être activée dans le menu configuration de l'espace privé.
Mais si l'appel a compacte_head n'est pas fait, cette activation est sans effet, d'où le sens du commit.
Sur ce qui concerne l'optimisation, j'ai une approche plus générique.
Je considère que les squelettes doivent s'écrire avec
#INSERT_HEAD
parce que c'est la façon normale de l'écrire.
Ensuite c'est le rôle de spip d'optimiser tout ce qui peut l'être automatiquement
En particulier, aujourd"hui déplacer tout le js de la page en fin de body est mieux, donc si on est prêt à faire le sacrifice sur la conformité xhtml, rien n'empêche spip de le faire automatiquement. C'est profitable pour tout le monde.
Mais cette optimisation vaut pour le moment, et un parc de navigateurs existants. Rien ne dit qu'elle sera perenne. La placer dans un filtre est donc plus judicieux, car cela permet d'adapter la stratégie au mieux, sans jamais modifier le squelette.
Cédric Morin
En particulier, aujourd"hui déplacer tout le js de la page en fin de body
est mieux, donc si on est prêt à faire le sacrifice sur la conformité xhtml,
rien n'empêche spip de le faire automatiquement. C'est profitable pour tout
le monde.
pas sûr, ça dépend des cas et de ce que tu fais sur le DOM
il faudra que ce soit une option
-- Fil
* Fil tapuscrivait, le 20/10/2008 15:12:
pour ma part je rajouterais juste un élément : j'ai la "fâcheuse" habitude
d'insérer les fichiers javascript en fin de page, afin que son chargement ne
soit pas bloqué le temps de la "digestion" du javascript. C'est une des
recommandations classiques pour accélérer un site, et c'est impossible avec
#INSERT_HEAD qui mélange tout : jQuery et les bibliothèques qui ne vont
l'utiliser qu'une fois la DOM chargée.Hum... As-tu esayé de mettre #INSERT_HEAD dans le pied de page ?
Euh, là, c'est #INSERT_FOOTER qui manque, non ?
(remarque : ça fait partie des point d'entrée de joomla).
c'était implicite : toutes les optimisations de perfo doivent pouvoir être debrayables.
D'ailleurs, cela risque de vite devenir une jungle dans laquelle le webmestre n'y comprendra rien.
Je pense qu'il faudra passer à un simple curseur 'Niveau d'optimisation' en fonction duquel on active ou non certaines des mesures.
Cedric
Dans spip aussi :
#PIPELINE{insert_footer}
il ne tiens qu'à toi d'ouvrir le point d'entrée et d'y mettre ce que tu veux.
J'avais fait cela dans le plugin phpmyvisites, mais j'en suis revenu à cause de problèmes avec IE
Cédric
Oui,
on peut se rapprocher de ce que fait getrpo mentionné sur spip-blog (vous savez, le gain de 750$ 
http://www.getrpo.com/support/Optimizations/Optimization-Overview
Le curseur se fait dans leur cas sur 9 niveaux.
.Gilles
En particulier, aujourd"hui déplacer tout le js de la page en fin de
body est mieux, donc si on est prêt à faire le sacrifice sur la
conformité xhtml, rien n'empêche spip de le faire automatiquement.
Je pensait aussi que ça n'était pas valide, mais en fait ça l'est, l'élément
script peut se trouver n'importe où dans head et body.
Cf. Les scripts dans les documents HTML :
"L'élément SCRIPT installe un script dans le document. Cet élément peut
apparaître un nombre quelconque de fois dans les éléments HEAD ou BODY d'un
document HTML." et la seule indication concernant script dans XHTML1 est
XHTML 1.0 : Le langage de balisage hypertexte extensible : "les éléments script et style
elements sont déclarés comme ayant un contenu de type #PCDATA".