L'empilage des feuilles de style

bazooka07 · mars 2014

Bonjour,

Pour quelques plugins que j'ai écrit et qui ont un rendu visuel côté public, j'ai besoin de proposer une feuille de style par défaut intégré au plugin.

Cela soulève un problème avec les thèmes. Si on prend le thème par défaut livré avec PluXml, dans header.php, les feuilles de style CSS du thème sont les premières chargées. Viennent ensuite les feuilles de style de tous les plugins.

Selon la logique CSS, ce sont les dernières feuilles de style chargées qui sont prioritaires. En conséquence, les créateurs de thèmes ne peuvent pas harmoniser le rendu visuel des plugins.

Autant il est bon de télécharger la feuille reset.css au début, autant il me semble préférable de télécharger la feuille style.css en dernier pour laisser la liberté aux créateurs de théme sans les obliger à plonger dans le code des plugins.

J'ai ce souci en particulier avec mon plugin myPager où on ne peut modifier tout l'aspect des boutons dans le thème.

Stéphane · mars 2014

Bonjour

Je comprends le problème que tu énonces, mais cela ne fait que renverser le problème, parce qu'après ce sont les développeurs de plugins qui vont se plaindre que leur css est modifié par celui du thème.

Si le plugin est bien développé avec des classes css adéquates, il ne devrait pas avoir de conflit avec ceux du thème si le plugin requiert une mise en page particulière. Sinon il me semble normal que le plugin hérite de la mise en page du thème en chargeant ses feuilles de style en dernier.

La logique veut que ce soit le plugin qui hérite du thème et pas l'inverse (ce qui se produira si le css du thème est chargé en dernier)

Gzyg · mars 2014

Il y a quelques temps, j'ai proposé que les développeurs de plugins ne mettent AUCUNE feuille de style dans leurs plugins et ne renseignent que les classes adéquates (les mêmes que dans le style par défaut) ce qui résoudrait beaucoup de "casses-tête" pour les thémeurs.

à plus,

Gzyg

je-evrard · mars 2014

Il faudrait tout simplement rajouter une option dans le plugin : activation ou non du css du plugin ?

bazooka07 · mars 2014

@Gzyg,

Je te prends un exemple comme le plugin myPager.
J'ai des boutons qui peuvent afficher 1 ou 2 chiffres, 1 chevron > ou un double chevron >>. Comment je fais pour afficher la même largeur pour tous les boutons. Sur des sites avec 30 pages d'articles, c'est horrible de voir 30 boutons à la queue leu-leu. Du coup, on affiche que quelques boutons au milieu ceux du début et ceux de la fin, et pour attirer l'attention de l'utilisateur sur les boutons manquants on crée un espace en les 3 groupes.
De plus, on mâche un peu le boulot pour le créateur de thèmes. Si la couleur ou les dimensions ne conviennent pas, il ouvre le déboggueur de Firefox ou de Chrome et il trouve de suite la régle CSS qui a le dernier mot, sans se casser la tête à trouver le bloc de balises HTML qu'il doit styliser. Et la correction est vite faite dans sa feuille de style si elle a le dernier mot.
Après tout le monde ne maitrise pas CSS. Si on demande à quoi correspond un "border-radius" ou "a:nth-last-child(2), on risque de voir beaucoup de gens la bouche bée. Donc, il faut à minima présenter un plugin prêt "out of the box".

@je-evrard,
Il y a une solution plus élégante qu'une option supplémentaire.
Dans PluXml, il y a pas plusieurs hooks pour agir :
plxShowTemplateCss, plxShowPluginsCss, et en dernier ressort, ThemeEndHead.
Le problème, c'est que style.css est appelé en premier. Donc toutes les feuilles de style suivantes lui passent dessus.

Il suffirait d'intercaler l'appel à style.css entre les appels de Hooks plxShowPluginsCss et ThemeEndHead. Cela permettrait de gérer la priorité de la feuille de style CSS du plugin selon le hook choisi.

Jerry Wham · mars 2014

C'est vrai que ça mérite réflexion.

Certes l'idéal est d'avoir des classes vraiment spécifiques aux plugins mais il est vrai que si un thème nécessite l'utilisation d'un plugin, il serait plus facile que la feuille de style du thème se charge après celles des plugins. Ainsi, il est possible au designer d'inclure directement le style voulu plutôt que via un commentaire ou une aide en ligne pas toujours comprise/lue.
Ce serait véritablement du clés en main et l'utilisateur final n'aurait pas à mettre les mains dans le cambouis.

Cela faciliterait également le partage des thèmes sur pluxml : le designer écrit son thème avec ses plugins activés. Et il uploade ensuite sur la plateforme pluxml uniquement le dossier de son thème. Dans la description, il donne la version de pluxml à utiliser ainsi que les versions des plugins à charger.
La sécurité de la plateforme serait ainsi renforcée et ne nécessiterait pas comme actuellement de télécharger tout ce qui est nécessaire (juste le script minimum).

Pour le coup, bazooka a mis dans le mille sans dégât collatéral ]:D

danielsan · mars 2014

hello,

il faut différencier la composition de la stylisation ...
*/ la composition ne s'occupe que du flux, de la taille des éléments, le positionnement, l'alignement ...
*/ la stylisation est pour la couleur, bordure, font, etc ...

La feuille CSS du plugin organise/compose et celle du thème donne l'esthétique.

J'ai pour habitude de donner une class et un id au body.
ça permet de cibler un mode, un template, une catégorie, un article, une static ...

Jerry Wham · mars 2014

@danielsan : certes, mais que ce soit pour composer ou styliser, si la feuille de style du thème est placée avant celle des plugins, tu ne pourras pas faire grand-chose depuis le thème, même en intervenant sur la balise body. Il faudra nécessairement modifier la css du plugin.

En écrivant, je pense également au sélecteur de thèmes : ce qui convient à l'un ne conviendra pas forcément à un autre thème. Et si l'on veut utiliser le même plugin mais avec des thèmes différents, le seul moyen valable et de mettre la css des plugins avant celle des thèmes.

danielsan · mars 2014

il y a quand-même une priorité dans les CSS ... un style général se fait écrasé par un ciblé. non ?
donc si tu crées un plugin, tu attributs un identifiant/class pour prendre le pas sur la feuille générale, quelle soit placée avant ou après.
Corrigez-moi si je me trompe ...
je n'ai jamais eu de soucis de hiérarchie des CSS

Jerry Wham · mars 2014

Oui, je suis d'accord avec toi mais l'intérêt serait ici de ne pas mettre les mains dans le cambouis. Cela est valable si tu modifies toi-même ton thème et si tu sais comment faire.

Mais quid du néophyte ? Et du sélecteur de thèmes ?

Frédéric · mars 2014

Pour ma part je préfère lister toutes mes feuilles de style 'brut' pour le dev et les sortir en buffer en un seul fichier et les minifier à la volée, ce qui évite tout problème...
Il faudrait cette modification en natif pour chaque appel css/js.
Cela permettrai de charger un seul fichier css et un seul fichier js après a voir s'il est utile on non d'utiliser un cache.

Jerry Wham · mars 2014

Oui mais même si tu les minifies, il y a un ordre de chargement des feuilles. Comment procèdes-tu ?

Stéphane · mars 2014

Par définition un plugin vient se greffer pour rajouter quelque chose. Il me semble donc normal que les feuilles de style d'un plugin viennent après celle du thème pour si besoin venir surcharger les classes css du thème.

Si le plugin est bien pensé et bien programmé, il gère ses propres classes css sans rentrer en conflit avec celles d'un thème. Au mieux il vient les compléter, voir les modifier.

Inverser l'ordre de chargement des feuilles (plugin et apres theme), c'est prendre le problème à l'envers parce que ça vous arrange dans vos devs, soit par facilité, méconnaissance ou fénéantise.

Cela ne doit en aucun cas être un argument technique ou fonctionnel: en tout cas c'est ma conception theme/plugin.

Gzyg · mars 2014

Je suis d'accord avec Stéphane et c'est pour ça que je plaide pour des plugins sans feuille de style : un plugin est censé apporter un plus technique et non décoratif.

à plus,

Gzyg

bazooka07 · mars 2014

@Jerry Wham,
Je suis d'accord avec toi.
On aura toujours plus de néophites que des pro des feuilles CSS.
Les plugins doivent être livrés avec une version minimale prête à fonctionner.

@Gzyg,
Si je reprends mon plugin myPager, je n'envoie que le minimum syndical dans la page html : une suite de balises : <a href ="..">..</a>.
Si je n'utilise pas quelques règles CSS, cela ne va ressembler qu'à une suite de chiffres. Je ne suis pas sûr que beaucoup de gens accrochent devant un tel désign. Faute de quoi, je serais obligé d'utiliser la balise <table>. C'est pas top !!

@Frédéric,
Les créateurs de style peuvent utiliser le hook ThemeEndHead. Il est appelé en dernier dans index.php. Ils sont alors sûrs d'avoir le dernier mot et conserver l'unité graphique du site.

@Stéphane,
Non, je ne suis pas d'accord. Aucun plugin, pas plus que PluXml ne devrait indiquer de classe. Cela alourdit les pages HTML et au final on ne sait plus qui fait quoi. Le seul truc qui doit être permis est l'utilisation de l'attribut id dans les balises html pour servir de point de repère. C'est la tendance actuelle sur le net, surtout avec la diversité des tailles de terminaux (Ecran Mac 27", PC de bureau, portable, tablette, smartphone, montre, ...).
Si on a inventé les sélecteurs d'attribut et les pseudo-classes, c'est qu'il y a une raison.

Stéphane · mars 2014

@bazooka07: bon apparement on n'est pas d'accord sur toute la ligne, mais ce n'est pas grave, cela n'empeche pas d'échanger et de confronter nos idées.

Maintenant si tu veux les feuilles css des plugins chargées avant celle du theme, dans le fichier header.php de ton theme remplace

<link rel="stylesheet" href="<?php $plxShow->template(); ?>/css/reset.css" media="screen"/>
<link rel="stylesheet" href="<?php $plxShow->template(); ?>/css/style.css" media="screen"/>
<?php $plxShow->templateCss() ?>
<?php $plxShow->pluginsCss() ?>

par

<link rel="stylesheet" href="<?php $plxShow->template(); ?>/css/reset.css" media="screen"/>
<?php $plxShow->pluginsCss() ?>
<link rel="stylesheet" href="<?php $plxShow->template(); ?>/css/style.css" media="screen"/>
<?php $plxShow->templateCss() ?>

et le tour est joué

je-evrard · mars 2014

C'est la souplesse de pluxml

Jos · mars 2014

Moi je suis plutôt d'accord avec Stéphane. Un plugin hérite du thème, enfin c'est comme çà que je vois les choses aussi. Maintenant je comprend pourquoi çà peut perturber dans certains cas, mais en renversant les choses, le problème sera inversé.

danielsan · mars 2014

n'oublions pas que des balises HTML bien choisies permettent une mise en page logique ...

exemple :
Une suite de liens est une liste.
Avec un simple display:inline-block sur les LI, un text-align:center sur UL et on a une composition du contenu ...
suffit de rajouter un id à UL et une classe active/no-active (qui correspond à PluXml) aux liens pour donner la liberté d'adapter le décorum ...

bazooka07 · mars 2014

@Stéphane,
Exactement !
C'est ce que j'ai que j'ai fait sur mon site

Petit aparté: Si tu jettes un œil sur le source de la page, note la balise <meta name="generator">. Il faut la rajouter dans le thème par défaut.

@Jos,
Si on te suit dans ton raisonnement, il va falloir un plugin par thème. On n'est pas rendu. Ce n'est pas la logique habituelle : on maquette, on code, on stylise.

@Danielsan,
On est bien d'accord. C'est ce que j'ai fait dans myPager. Sauf qu'il n'y a pas de <li>, on attaque directement avec <a>. Et dans le <div> parent fourni par PluXml, le "id" me va bien. Donc inutile d'en rajouter un autre.

En parlant de feuille de style, cela serait bien d'en rajouter une pour le media="print" dans le thème par defaut. Imprimer le menu ou la side-bar me semble être d'un intérêt limité.

danielsan · mars 2014

bazooka07 a écrit:

@Danielsan,
On est bien d'accord. C'est ce que j'ai fait dans myPager. Sauf qu'il n'y a pas de <li>, on attaque directement avec <a>. Et dans le <div> parent fourni par PluXml, le "id" me va bien. Donc inutile d'en rajouter un autre.

c'est très simple, pour savoir si tu as utilisé les bonnes balises HTML, tu supprimes toutes tes feuilles de style.
Si la structure/composition de ta page te semble cohérente, alors c'est bon.

note : il m'arrive de surfer avec un navigateur textuel, et là ... c'est très drôle !

Stéphane · mars 2014

bazooka07 a écrit:

Petit aparté: Si tu jettes un œil sur le source de la page, note la balise <meta name="generator">. Il faut la rajouter dans le thème par défaut.

c'est noté

bazooka07 · mars 2014

@Danielsan,

C'est pas si drôle que tu le crois.
Comment font les mal-voyants ou les aveugles ?
Voir sites labelisés
Quand on remplace les yeux par un synthétiseur vocal, cela ne doit pas toujours être évident.
Cela voudrait le coup de faire un essai.
C'est sûr qu'il y a des talents cachés pour faire des grandes usines à gaz. :mad:

danielsan · mars 2014

c'est pourquoi la première règle est d'utiliser les balise HTML.
Une suite de liens EST UNE LISTE de liens ... d'où l'usage de UL/LI car c'est reconnu comme tel.
On n'utilise pas assez les listes, moi j'aime bien, et les imbriquer en plus ]:D

Jos · mars 2014

@bazooka07 : en effet dans certains cas c'est pas pratique, mais si on renverse, le thème prendrai la priorité sur les plugins, et le problème se poserai à nouveau.

Pour ceux qui veulent tester leurs site avec une synthèse vocale : la majorité des aveugles utilisent Jaws (payant et cher) mais certains utilisent une solution gratuite. http://www.nvda-fr.org/

Suricat · mars 2014

Frédéric a écrit:

Pour ma part je préfère lister toutes mes feuilles de style 'brut' pour le dev et les sortir en buffer en un seul fichier

Je suis d'accord avec Frédéric, charger plusieurs fichiers CSS est plus long que d'en charger un seul.
On perd des points dans PageSpeed si on utilise plusieurs fichiers CSS, ce qui peut être dommageable pour le référencement.

Pour voir la notation PageSpeed de son site : http://gtmetrix.com/

danielsan · mars 2014

attendez là, je débarque ... c'est quoi la méthode pluginsCss ?

faut-il nommer la feuille de style du plugin d'une manière particulière pour qu'elle soit appelée automatiquement (genre elle porte le même nom)
ou faut-il l'envoyer dans le hook plxShowPluginsCss ? (il manque ces infos dans la doc en ligne)
j'essai de la nommer de différente manière mais ça veut pas :rolleyes:
moi j'en suis toujours à envoyer ça dans ThemeEndHead

Stéphane · avril 2014

@danielsan: regarde dans la doc des plugins

Pour résume:
A partir de l'écran de gestion des plugins, pour chaque plugin tu as un menu "Code css".
Tu peux à partir de là mettre le css nécessaire au fonctionnement du plugin coté admin ou coté visiteur.
Pour définir du css par défaut: dans le dossier de ton plugin créez un dossier css, dedans mets un fichier site.css et admin.css.
Le contenu de site.css sera visible et modifiable sur l'écran "Code css" du plugin. Idem pour admin.css
De cette façon tu peux initialiser le code css par défaut nécessaire au plugin, qui pourra etre personnaliser sans éditer les fichiers à partir de l'écran "Code css". Plus besoin de coder le css dans le fichier .php du plugin
Le moteur des plugins de PluXml charge les fichiers css s'ils existent, pour les mettre dans une sorte de cache qui sera appelé par l'instruction pluginsCss déclarée dans le fichier header.php de ton thème.

bazooka07 · avril 2014

Pour 2 ou 3 régles CSS pour le visiteur, je préfère les coder dans le plugin sous le hook plxShowPluginsCss. S'il y en beaucoup plus, je crée une feuille de style avec le nom du plugin. Avec l'attribut id dans les blocs HTLM (div, form, p), on peut faire la distinction entre les partise admin et visiteur dans la même feuille. En normalisant les noms, le code pour charger une feuille de style ou un script javascript devient ceci quelque soit le plugin :

[== PHP ==]
public function AdminTopEndHead() {
    global $plugin;

    if (!empty($plugin) && $plugin == __CLASS__) {?>
         <link rel="stylesheet" type="text/css" media="screen" href="<?php echo PLX_PLUGINS.__CLASS__.'/'.__CLASS__; ?>.css" />
         <script type="text/javascript" src="<?php echo PLX_PLUGINS.__CLASS__.'/'.__CLASS__; ?>.js" ></script>
<?php	}
}

Je n'ai plus qu'à faire du copiez-collez d'un plugin à l'autre. Et dans le dossier du plugin myPlugin, j'ai donc, selon le besoin, myPlugin.php, myPlugin.css, myPlugin.js.
Je fais la même chose pour le hook plxShowPluginsCss, sauf qu'il n'y a pas de test sur la variable plugin.

La multitude de feuilles CSS augmente le temps de réponse du serveur.
Il faudrait un plugin ou un bouton dans le panneau de config qui permettrait de cumuler dans une grosse feuille, les feuilles du thème avec les feuilles de chaque plugin. Le problème est le même pour javascript.

danielsan · avril 2014

Stéphane a écrit:

Pour résume

ok merci, ça marche !
par contre,
1/ en activant ckEditor dans les pages statics, c'est aussi actif pour le CSS ... du coup ça me met des balises dedans

2/ ça ne marche pas pour l'écran de config mais que d'admin ...

Stéphane · avril 2014

bazooka07 a écrit:

La multitude de feuilles CSS augmente le temps de réponse du serveur.
Il faudrait un plugin ou un bouton dans le panneau de config qui permettrait de cumuler dans une grosse feuille, les feuilles du thème avec les feuilles de chaque plugin. Le problème est le même pour javascript.

C'est ce qui est fait par le moteur de plugin de PluXml.
Chaque code css (coté admin ou visiteur) ajouté dans l'écran "Code css" des plugins est regroupé dans 1 seul fichier afin de ne pas multiplier les appels. L'instruction pluginsCss ne fait que charger cet unique fichier, fichier qui est lui meme minimisé.

L'empilage des feuilles de style

Réponses