Macadames' blog

Le silence est d'or, jusqu'à ce qu'il devienne plomb.

Styliser plone3 : quelques trucs sortis du grenier de ma grand-mère.

with 3 comments

For beginner piano …

Dans cet article nous trouverez quelques conseils pour créer son produit de thème pour Plone3 à partir d’une maquette fournie par un graphiste.  Il évoluera dans le temps car j’y ajouterai quelques notes de travail au fure et à mesure que de nouvelles idées viennent, c’est pas tous les jours🙂 .  Nous n’aborderons pas les styles dynamiques (utilisation de collective phantasy par exemple) ni l’utilisation de delivrance (on garde ça pour nos expériences futures, car même si c’est alléchant, ce n’est pas encore facile à installer et on ne peut pas tout faire avec).

Cet article n’aborde pas ou alors seulement si c’est nécessaire les questions techniques (créer son produit de thème avec paster, utilisation du buildout), vous trouverez ces explications là sur bien d’autres sites.

Les conseils que l’on peut donner dés le départ sont :

  • Rester simple.
  • Garder l’oeil ouvert : ce qui est important peut vous échapper
  • Essayer d’utiliser au maximum les templates de Plone par défaut
  • Ne pas overloader les styles de Plone par défaut mais plutôt réécrire les styles de Plone que vous voulez changer voire même repartir de zéro sauf si les modifications à faire sont simples ou si vous maîtrisez bien le langage css.
  • Eviter les hacks css au maximum.

I. Rester simple

C’est simple à dire mais c’est sans aucun doute le plus difficile à faire. On pourrait écrire plusieurs tomes sur ce sujet et je vous conseille fortement de visiter les sites dédiés à l’intégration graphique d’un site web.

Pour rester simple il faut d’abord que les documents décrivant la charte graphique soient à la fois simples et complets, à savoir que le(a) graphiste doit vous donner au minimum un exemple de page intérieure du site qui permettra de ne pas se tromper sur la typographie des différentes parties du site. Il faut également que cette charte graphique corresponde aux cas d’utilisation, et qu’il n’y ait pas des éléments susceptibles de vous égarer, ou des éléments non décrits :

  • Si le site a parfois 3 colonnes avec une colonne à gauche et à droite, la présentation de ces colonnes et des boîtes qu’elles contiennent doit être fournie dans la maquette.
  • La typographie doit être suffisamment exhaustive : paragraphes et plusieurs niveaux de titres, couleur et autres effets typographiques sur les liens, par exemple
  • le(a) graphiste doit fournir un fichier où on peut voir quelles polices sont utilisées (un JPEG ou un PDF est sujet à caution, demandez un format Photoshop pour la maquette)

A partir de là, l’intégrateur doit rester simple et éviter ce genre de choses :

  • Ajouter des styles quand il n’en faut pas : on voit ça trop souvent. Pour la typo globale, il suffit de redéfinir les styles des balises html de base (p, h1, h2, h3 …) >  styles décris dans Plone par la feuille de styles base.css.dtml qu’il faudra réécrire si on choisit de ne pas overloader les styles.
    D’autre part du point de vue accessibilité et respect des normes un titre s’écrit <hx>My title</hx> et non pas <p class= »titlex »>My title</p>. Attention, accessibilité ne veut pas dire uniquement que votre site doit rester lisible par un appareil lisant le braille, ça veut dire aussi qu’il sera conforme à ce qu’on attend, et si par exemple dans le futur vous devez importer vos pages statiques vers une techno dynamique ce sera beaucoup plus simple si vous avez respecté les normes.
    Si sur certains templates les styles des titres ou de la typographie changent un peu, mieux vaut donner un id au template et écraser le style dans la css avec #mon-template hx {etc ….}
  • Réinventer la roue en réécrivant ses propres viewlets, ou portlets de navigation. La plupart du temps il vaut mieux répartir les différentes parties décrites dans la charte dans les différentes viewlets existantes de Plone (personaltools, global actions …). 95 fois sur cent, ces viewlets sonts suffisantes. 95 fois sur cent, il faut même en enlever.

Pour rester simple il faudra commencer par alléger les feuilles de style de Plone et enlever tout ce que vous ne voulez pas. Et cette démarche va vous éviter un nombre incalculable d’ennuis ou d’incompatibilités avec les différents navigateurs.

II. Garder l’oeil ouvert

Le plus important quand on regarde une maquette graphique ce ne sont pas les pleins mais les déliés. Essayez de voir ce que les autres ne voient pas.

Le premier travail à faire est de définir les espacements, les margin et padding. Bien sûr ça va de pair avec les dimensions.  Alors par exemple la dimension des colonnes et le padding autour des portlets c’est primordial. Encore plus primordial est la largeur du portail et les marges qui vont autour. Si la largeur est fixe à 980px et que le contenu est centré horizontalement, ça prend deux lignes et votre feuille de style commence avec ça :

#visual-portal-wrapper {
width: 980px;
margin: 0 auto;
}

La deuxième chose concerne la typographie. Beaucoup de personnes se lancent dans l’intégration d’un site avec la mauvaise fonte et quand ils arrivent au bout sont obligés de tout recommencer à cause de ça.  Donc définir la police globale, et les polices de titre, les tailles de police (pas toujours facile).

La troisième chose concerne les couleurs :

  • ça a l’air bête mais quelle est la couleur du texte #333 c’est pas du noir et ça change tout
  • la couleur des liens
  • des liens survolés ou actifs
  • des liens visités
  • couleur des titres

Quelques trucs un peu moins importants comptent aussi :

Epaisseur et styles des bordures.

Si vous êtes un habitué vous aurez reconnu que nombre de ces choses importantes sont dans le base_properties.props associé à votre skin. Ce n’est pas pour rien que ce truc existe, et c’est par là qu’il faut commencer.

III. Templates de Plone

Actuellement il est très rare d’être obligé de surcharger le main_template ou d’autres templates de Plone parceque vous disposez des viewlets.

Ce qu’il faut faire :

  • surcharger les viewlets (avec un overrides.zcml) ce qui permet de réécrire les templates, les méthodes (n’oubliez pas les tests sur les nouvelles méthodes sinon votre chef de projet ne va pas être content) ou plus simplement associer une viewlet à un autre viewletManager (vous voulez des site_actions et personal tools dans le footer par exemple, c’est qq lignes dans le overrides et dans le profil)
  • réordonner les viewlets avec votre profil viewlets.xml
  • ajouter de nouvelles viewlets avec un configure.zcml

Ce qu’il ne faut pas faire sauf par exemple si vous êtes obligé d’ajouter des viewletManagers dans le main_template ce qui est rare, sachant qu’un viewletManager peutêtre ajouté dans un autre viewlet :

  • overloader les templates dans les skins (après ce sera très dur de faire un upgrade du site, pensez à ceux qui prendront la relève sur votre travail et au temps que ça va prendre de scruter les diff entre les templates sur la bonne version de Plone), un calvaire.
  • faire des templates dans les skins pour la même raison et parcequ’on ne peut pas tester ces templates sans lancer Zope. Utilisez plutôt les vues, c’est un peu plus long mais vous oeuvrez pour quelquechose de pérenne.

Bien sûr si vous manquez de temps ou de budget sur un projet rien n’interdit de faire les deux choses susdites. Cependant si vous voulez juste changer un « > » en « / » (breadcrumbs)  ou supprimer un élément graphique (remplacer le « search site » de la boîte de recherche par « OK ») personnellement je préfère faire un display: none en css ou changer le label via un minuscule jQuery, plutôt que d’overloader un template et compliquer la vie de ceux qui viendront après moi.

D’ailleurs si vous manquez vraiment de temps (par exemple vous devez faire le design d’un site en 1 jour) et que vous voulez déplacer les site actions et personal tools dans le footer, vous faites ça en trois lignes de jQuery et de css (après tout ce n’est que de la présentation):

C’est un exemple à ne pas suivre sauf si vous êtes pris à la gorge par un budget digne d’une aide aux pays en voie de développement :

/* d’abord on masque dans le css pour ne pas avoir l’effet que ça bouge en direct */

#portal-siteactions {
display: none;
}

#portal-personaltools-wrapper {
display: none;
}

Ensuite on bouge les personal tools dans les site actions puis les site actions dans le footer

javascript :

moveElements = function() {
var personalAc = jQuery(« #portal-personaltools li »);
var siteAct = jQuery(« #portal-siteactions »);
var footer = jQuery(« #portal-footer »);
siteAct.append(personalAc);
footer.html(«  »);
footer.prepend(siteAct);
}

jQuery(document).ready(moveElements);

ensuite on réafiche dans la css :

#portal-footer #portal-siteactions {
display: block;
}

et voilà ni templates (le pire) ni viewlets (le meilleur mais plus cher).

IV. Faut-il écraser les styles Plone par défault ?

La réponse est simple : si vous maitrisez bien la css et que vous manquez de temps vous pouvez choisir de ne pas écraser les styles Plone par défaut, même si ce sera au détriment des performances (taille de css envoyé plus importante), ce dernier point n’étant vraiment pas primordial si vous savez cacher correctement vos css. Le vrai problème étant qu’overloader des styles est beaucoup plus compliqué qu’il n’y parait, vous rencontrerez des tas de soucis avec IE et Safari par exemple.

Si écrire du css ce n’est pas votre tasse de thé, commencez par copier-coller base.css.dtml et public.css.dtml dans votre produit de skin et élaguez (ça va vous faire plaisir en plus), vous verrez qu’ensuite tout deviendra limpide et que si ça se trouve il ne sera même pas utile de surcharger IEFixes.css, et oui pour gagner du temps il faut savoir en perdre.

V. Eviter les hacks css au maximum

En général si vous avez besoin d’un hack pour Mozilla ou Safari c’est qu’il y a une erreur quelque part dans l’écriture de vos feuilles de style. Il ya bien sûr des cas particuliers (le vertical align dans un div par exemple nécessite des pirouettes inhabituelles).

Quant à IE, le IEFixes.css de plone est en général suffisant, pour ma part je le surcharge et j’enlève le *html devant tous les float bugs de manière à appliquer le patch également à IE7, ça résout pas mal de choses.

Pour éviter les bugs avec Safari éviter de surcharger les styles de Plone ou bien faites le proprement car si vous écrivez :

background: mycolor url(myimage) myreepat myposition;

et que plus bas vous surchargez pour le même style

background-image: url(mynewimage);

le background repeat est perdu.

Je ne sais pas vraiment pourquoi ….

V. Eviter les positions absolues

Bien sûr parfois on ne peut faire autrement et je comprends aussi ceux qui aiment la rapidité d’affichage, mais sauf si vous aimez absolument les ennuis je vous le déconseille pour skinner la globalité d’un site.
La position absolue est valable sur des petits tools en javascript, sinon essayez de faire sans, je sais que ce n’est pas toujours simple de manipuler des éléments flottants mais si tout le monde se casse la nénette à faire ça ce n’est pas pour rien.

Suite au prochain numéro🙂

Written by macadames

27, novembre 2008 à 8:20

3 Réponses

Subscribe to comments with RSS.

  1. Cependant si vous voulez juste changer un “>” en “/” (breadcrumbs)

    En style css pure via des images c’est possible aussi.
    exemple ::

    #breadcrumbs-you-are-here, #portal-breadcrumbs .breadcrumbSeparator {
    display: none;
    }

    #portal-breadcrumbs span a, #portal-breadcrumbs span span {
    background: transparent url(&dtml-portal_url;/++resource++&dtml-ressourceName;/sep_breadcrumb.png) left bottom no-repeat;
    padding-left: 12px;
    }

    Eviter les positions absolues:

    je ne suis pas tellement d’accord avec toi. Les positions absolues ont moins d’effet pervers que les floatant à mon avis. Pour ma part je les utilise assez souvent pour positionner les elements de la page à l’intérieur des elements en position relative.

    youenn

    2, décembre 2008 at 1:31

  2. pour le changement de labl tu peux effectivement faire un displaynone puis un background en css , juste une question de goût🙂

    Les positions absolues à l’intérieur d’un div en relatif, pourquoi pas avec de petits éléments, mais pas pour de grosses parties de la page (le #content en absolu tu peux avoir de méchantes surprises). De manière générale j’évite.

    macadames

    3, décembre 2008 at 9:00

  3. Les float n’ont pas tellement d’effets pervers il faut juste bien les appréhender et par exemple ne pas mettre de margin-left sur un float left (toujours un margin-right sur l’élément flottant précédent) car sinon tu auras un comportement différent avec différents navigateurs.

    macadames

    3, décembre 2008 at 9:02


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :