Un, deux, trois… feuilles CSS !

Messages

• 26 janvier 2012, 15:22

  Temps que les styles sous le ’1’ de ton document ne sont pas atribués d’office et que ça ne concerne que la Dist, celà me va très bien

• 26 janvier 2012, 15:36, par esj

  Bonjour Romy

  Je ne sais trop si je dois intervenir sur le forum de cet article, celui de Base CC2 alias Petronille, ou celui de la méthode marguerite, en tout cas je lis celui-ci aujourd’hui et il m’inspire certaines réflexions.

  Si l’on veut optimiser le nombre de requêtes HTTP en ce qui concerne les feuilles de style, il faut que la page HTML n’en référence qu’une, et qu’elle ne contienne aucun @import, ceci provoquant une nouvelle requête HTTP. Pour atteindre ce but, le meilleur qu’offre SPIP est tout simplement d’écrire un squelette dont la compilation fournira cette feuille de style, squelette comportant des #INCLUDE, équivalent des @import mais réalisé par le serveur une fois pour toutes, plutôt que par chacun des clients à chaque visite.

  Si l’on veut en plus optimiser la feuille elle-même, il faut utiliser un outil de compression de CSS (voir une comparaison ici), et de nouveau il vaut mieux l’utiliser en amont pour réduire les calculs, et aussi disposer d’une forme canonique de son fichier, qui permet mieux suivre son évolution par la suite quand on utilise Diff sur ses différentes versions.

  Cette méthode donne de meilleurs résultats que #INSERT_HEAD qui ne fournit que des solutions approximatives à ces deux problèmes.

  Maintenant en ce qui concerne le découpage, traditionnellement on distingue la macro-typographie (en gros les gabarits), et la micro-typographie (le choix des polices et des couleurs). Ce découpage antérieur au Web lui va très bien : un néophyte qui veut modifier l’aspect graphique d’un site va s’aventurer à changer les polices et les couleurs, mais ne se risquera pas à changer les gabarits car ça demande une plus grande expertise. Donc à mon avis 2 feuilles suffisent, 3 si on veut séparer couleurs et polices. On peut aller plus loin au besoin, le recours au squelette permettant toujours de n’avoir qu’une seule feuille au final du point de vue du navigateur qui ignore comment elle a été fabriquée.

  Et avantage supplémentaire du recours au squelette : si je veux changer couleurs et polices, il me suffit d’écrire un squelette où les propriétés sur les fontes et les couleurs sont données par la balise #ENV donnant les valeurs souhaitées, ce qui permet de construire des séries de thémes très facilement.

• 27 janvier 2012, 10:46, par tetue

  @anonymous : non, justement : cette première passe sert à faire une mise à zéro, poser une base CSS, qui impacte donc tout… notamment les plugins qui, reposant sur cette base, n’ont plus à fournir de style intrusif (autre bénéfice non mentionné dans cet article). Ce qui est spécifique à la « dist » ou à ton-site-à-toi intervient en troisième position, le plus tard possible.

  Mais si ça t’embête, tu peux remplacer chacune des feuilles de style dont du ne veut pas, en en déposant une du même nom (avec les styles de ton choix ou vide pour l’annuler) dans ton dossier « squelettes » et… c’est tout ! Il n’est pas nécessaire d’éditer le moindre fichier squelette pour ce faire.

  Et… comme SPIP concaténe tous ces fichiers en un seul (à la demande, voir panneau de config ad hoc), il n’y a au final qu’un seul fichier CSS en service sur le site — ce qui répond à @esj : cette méthode avec #INSERT_HEAD_CSS + concaténation est au contraire très performante. Regarde pour exemple la feuille unique actuellement en vigueur sur mon site perso, qui porte un nom aléatoire barbare comme « 1903f5867288b8825ca4c56767036de2.css » car générée par SPIP, après concaténation et minification. Idem pour les scripts JS.

  Il n’y a plus lieu de bidouiller en squelettes SPIP. Mieux vaut utiliser des fichiers CSS, comme partout ailleurs… et s’assurer ainsi d’un minimum de compatibilité avec les thèmes distribués sur le Web ;)

• 27 janvier 2012, 11:16, par esj

  Ce que je dis de INSERT_HEAD c’est qu’elle offre un service redondant avec celui des squelettes, et en moins bien. Elle effectue une mise en cache, mais sur quel critère ce cache est vidé ? On n’en sait rien et il faut le vider à la main pendant les essais, c’est pas de la biidouille ça ?

  Avec un squelette, on met #CACHE{0} pendant les essais et on l’enlève ensuite. Je ne vois pas en quoi mettre dans son squelette « #INSERT_HEAD » est moins de la bidouille que de référencer dans la balise Link un squelette qui se réduit à une suite de #INCLUDE des CSS. Et au niveau performances, il n’y a que ce squelette à compiler une fois pour toutes les pages HTML, plutôt que de voir chaque page passer à la moulinette de la fusion des balises Link, et chaque CSS référencées par elles à la moulinette de la compression.

  Bref, c’est à se demander si tu as bien lu mon post, vu que tu n’en retiens qu’une seule chose, et sans tenir compte de mes arguments. Mais je sais bien que dès que j’explique que la multiplication des dénommées balises de SPIP (qui sont en fait des macros) transforme SPIP en usine gaz comprise par de moins en moins gens, on préfère ne pas entendre.

• 27 janvier 2012, 15:43, par b_b

  Salut Emmanuel,

  À mon avis le principal intérêt de insert_head est que pour utiliser un plugin qui nécessite des feuilles de styles on peut dire à un utilisateur :

  « Tu active le plugin et hop ça fonctionne »

  Sans insert_head on devrait lui dire :

  « Tu active le plugin + tu ouvre le squelette head de ton squelette pour y ajouter un appel à la css du plugin + et hop »

  Ce que je dis de INSERT_HEAD c’est qu’elle offre un service redondant avec celui des squelettes, et en moins bien. Elle effectue une mise en cache, mais sur quel critère ce cache est vidé ?

  INSERT_HEAD n’effectue pas de mise en cache par défaut, c’est le compresseur intégré à SPIP qui permet de « minifier » et de regrouper toutes les css dans un seul fichier. De plus, ce fichier est re-généré lors d’un recalcul d’une page (et lorsqu’on vide le cache du site).

  Avec un squelette, on met #CACHE0 pendant les essais et on l’enlève ensuite.

  Avec le compresseur, il suffit juste de l’activer quand le site passe en prod et hop :)

• 28 janvier 2012, 08:21, par esj

  Je suis curieux de voir un plugin qui pourrait insérer des feuilles de styles compatibles avec n’importe quel autre plugin sans en connaître les squelettes. Cet avantage me paraît purement théorique. Et je trouve absurde d’avoir développé un compresseur intégré alors que, comme je l’ai expliqué, il est préférable de compresser ses sources avec un compresseur standard pour faciliter le développement.. Et toute cette discussion tourne toujours autour du même problème : il vaut mieux renoncer à une micro-amélioration locale si ça alourdit la compréhension globale de l’outil.

• 2 février 2012, 23:38, par RastaPopoulos

  Si tu es si curieux, je te conseille de fouilloter la zone, car il y a là environ 300 utilisations du pipeline permettant d’insérer soit des CSS soit du JS par un plugin (les JS aussi sont compilés ensemble et compressés).

  Je suppose donc que ça doit être utile à pas mal de développeurs. Et je suppose aussi que les milliers de sites installés avec ces plugins (et souvent plusieurs de ces plugins à la fois !) ne râlent pas spécialement que ça leur casse leur squelette et qu’il y a des conflits, etc. C’est plutôt une exception.

  Ces gens sont sûrement contents que, sans rien avoir à faire de leur part, tous ces JS et CSS qu’ils n’ont pas choisi mais dont les fonctionnalités de leur site ont besoin, soient compressés magiquement.

• 8 février 2012, 13:42, par esj

  Tu réponds à mes arguments techniques par l’apparent succès de cette méthode auprès des utilisateurs. C’est du même ordre que de répondre à des inquiétudes écologiques sur un produit par le fait que pleins de gens l’achètent. C’est une autre illustration de ce que SPIP, qui était au départ un outil pour ceux qui se défiaient de l’argent (cf. le manifeste), est devenu un produit comme les autres, que l’équipe actuelle défend avec la rhétorique issu de la loi du marché : ça plait au plus grand nombre alors la ferme.

  Même les écureuils volants n’arrivent pas à tenir longtemps le cul entre deux chaises, savoir ici celle du fonctionnement dans une logique mercantile, et celle de vouloir être jugé sur les principes libertaires qui étaient au départ de SPIP.

• 8 février 2012, 17:45, par tetue

  Je suis — hélas — d’accord avec toi, esj. Ceci dit, pour répondre à ta question, il n’est pas difficile de trouver des plugins apportant leur style sans dommage, dans ou hors SPIP, comme par exemple le plugin Mediabox qui repose sur le script Colorbox.

  C’est moins une problématique spipienne qu’une question d’organisation du CSS. Les « plugins » disponibles sur le Web sont tranverses aux projets mais aussi aux outils de publication : carousels, menus déroulants, galeries, etc. chacun apporte plus ou moins de style, idéalement non intrusif. C’est ce qui impose cet ordre d’appel en trois temps (exposé dans la « méthode Daisy »), indépendamment de SPIP. Ma question est, via cet article : comment, dans SPIP, faire ça le plus simplement et pédagogiquement possible ? Un bon tuto suffirait-il à expliquer la logique ?

• 20 février 2012, 13:58, par RastaPopoulos

  Tu réponds à mes arguments techniques par l’apparent succès de cette méthode auprès des utilisateurs. C’est du même ordre que de répondre à des inquiétudes écologiques sur un produit par le fait que pleins de gens l’achètent.

  À la différence que tes arguments techniques précédents ne prouvent à aucun moment qu’il y a un danger écologique dans ce produit.

  Il y a des outils ou techniques qui portent en eux-mêmes un aménagement néfaste du monde quelque soit la manière dont on les utilise (le nucléaire, le téléphone portable, la voiture) et d’autres dont seul l’usage permet de juger (un couteau).

  Ici, je pense que #INSERT_HEAD (et assimilé) fait partie de la deuxième catégorie.

  Car l’inquiétude vient d’un usage précis, dont tetue parle : ajouter à mauvais escient des styles CSS intrusifs, par exemple. Et non pas de problèmes de performances ou de cache dont je n’ai aucun souvenir qui m’ait marqué.

  En revanche, il existe un nombre énormes de cas où on a besoin d’insérer du JS et/ou du CSS car la fonctionnalité offert par le plugin le demande, et ce n’est absolument pas à l’utilisateur de se soucier du comment c’est fait par derrière : on active le plugin et la fonctionnalité fonctionne, on peut alors l’utiliser.

  Faire en sorte que ce soit simple à utiliser n’est pas une logique mercantile, mais une logique de sympathie envers l’utilisateur, notamment celui qui n’est ni technicien, ni n’a justement l’argent pour payer des techniciens qui vont améliorer les performances de son site. Il peut, grâce au système actuel, à la fois ajouter des fonctionnalités et avoir le code de celles-ci compressées automatiquement sans intervention de sa part.

  Lorsque ce pipeline est bien utilisé (sans CSS intrusif), les milliers de sites dont je parlais, et dont certains sont assez gros, n’ont pourtant pas constaté de problèmes de performance ou de cache (pas de problème écologique).

  La rhétorique n’est donc pas « ça plait au plus grand nombre alors la ferme » mais « c’est utilisé à grande échelle sans pour autant qu’un problème écologique majeur ait été reporté, donc pour l’instant on pense que c’est une bonne idée ».

  Mais si tu penses avoir découvert un scandale sanitaire majeur, éclaires-nous (sans nucléaire) avec plaisir.

• 5 mars 2012, 07:19

  Je suppose que ta réponse est ironique, mais cette manière de répondre à côté est tout de même inquiétante. Et après tout, je peux répondre au premier degré : oui, l’écureuil SPIP est victime d’un scandale sanitaire.

  Dans le manifeste qui a fondé SPIP, il était dit que sa communauté adoptait une « défiance à l’égard de l’argent », l’intention étant de fournir un outil permettant à l’internaute lambda de ne pas surfer idiot.
  Or depuis quelques années SPIP a chopé le virus de la rentabilité : tout ce que j’ai voulu faire pour que son code reste le plus simple possible a été systématiquement refusé au motif qu’il ne fallait pas gêner les développeurs de plugins (c’est-à-dire surtout le plus présent d’entre eux). Il est donc tout à fait clair que SPIP ne s’adresse plus à l’internaute lambda, mais aux développeurs qui font du fric avec.

  Je peux comprendre que la dureté des temps présents obligent certains à renoncer à certaines activités militantes. Mais qu’ils empêchent les autres d’en avoir, oui c’est un scandale.

• 11 avril 2012, 01:29, par tetue

  Trêve de troll, on fera simple, en trois feuilles — et tant pis pour la « méthode Daisy » et toutes ses merveilleuses possibilités : http://zone.spip.org/trac/spip-zone/changeset/60300

  Je vous laisse achever.

• 21 avril 2012, 13:20, par Marcimat

  Le découpage était pourtant vraiment sympa, et cette discussion qui a suivi le dépot http://thread.gmane.org/gmane.comp.web.spip.zone.cvs/56177 semble militer pour retrouver ces multiples feuilles découpées.

  Pour ma part, je trouve cela aussi plus simple et surtout ça me force à être un peu plus organisé, car un fichier CSS devient vite le bazar à mettre des règles un peu n’importe où.