Ca me parait de bonnes idées, toutefois, j'alerte sur les risques de casse :
Il y a des gens en production, ce chantier va durer un certain temps, ne
serait-il pas préférable de le lancer à l'issue de la gestion des
périodiques ?

En effet, à l'issue de la gestion des périodiques, on devrait avoir une
version qu'on pourra considérer comme complète un certain temps... le temps
qu'il faudra pour entamer ce travail...

Ces modifications impliquent aussi que chacun soit en mesure de comprendre
et de travailler avec les CSS... je dois bien reconnaitre un manque certain
dans ce domaine en ce qui me concerne !

Pour ma part, je souhaitais aborder un point de mise en page :

Nous avons en haut et à gauche deux barres de menus et sous-menus. Ces
barres défilent et disparaissent avec les ascenseurs... peut-on envisager
une solution pour qu'elles restent visibles ? C'est toute la différence
entre une application web et une application client/serveur classique : les
boutons ne défilent pas avec tout le paquet !!!

Les solutions que je connais pour garder ça à l'écran : des frames ou alors
les menus dans un layer, lequel reste toujours visible à l'écran, enfin je
crois que c'est un truc comme cela. Voir
http://www.lib.ox.ac.uk/jafer/publications/www2002-paper.html où le menu
bleu de gauche reste toujours visible.

Eric




----- Original Message ----- 
From: "François Lemarchand" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 28, 2003 11:23 PM
Subject: [PMB-DEVEL] Re: PMB : passage aux standards (blablabla)


> bleu pétrole, mauve et vert, tout ce qu'on veut, du moment que c'est
> clean !!! ;-)
>
> J'aime bien l'idée d'éclater la feuille en trois... cela avait été entamé
> dans 'newlook' et rend les modifs plus aisées : les couleurs c'est dans
> color.css, les polices dans fonts.css, etc... les fichiers sont plus
petits et
> plus faciles à maintenir.
>
> Petite précision quand même. En ce moment la table users stocke un nom de
> feuille de style (aka 'seabreeze.css'), si je comprend bien, il faut y
mettre
> un nom de dossier maintenant. C'est pas grand chose, mais il y a une
> petite adaptation à prévoir dans ./account.php (justement une petite
regexp qui
> jete l'extension des fichiers css présents dans /styles pour proposer
juste un
> nom de thème à notre utilisateur). Adaptation valable aussi dans la page
> d'administration/users). Je tiens à cette idée : ajouter un nouveau thème
=
> juste copier un nouveau dossier dans /styles.
>
> L'abandon des tableaux au profit de <div> ou <span> me paraît une bonne
chose
> (depuis le temps qu'on en cause...). A priori vous ne devriez intervenir
que
> dans les templates (justement, ça sera l'occasion de voir si des choses
qui
> traînent encore dans le code peuvent y être déportées). J'insiste sur deux
> points : au fil du temps, certaines classes ont été perverties pour finir
par
> être utilisées en place les une des autres (je pense à formtitle et
listheader,
> notamment). Il faudrait unifier cela et trouver des noms plus 'explicites'
(de
> toute les manières ce sera du temps de gagné pour la suite des choses).
> Et aussi éviter de supprimer ou modifer dans les templates les séquences
du type
> !!value!!, sinon, là, je garantis un sacré bazar !!!
>
> Tu t'attaques là à un très gros morceau ;-)
>
> Je pense à cela aussi : certaines pages qui s'affichent dans des iframes
ont
> des petites sections <style> ' inline.
>
> A+ l'ami.
>
> PS. français impeccable, on dirait que ça fait 10 ans que tu es là ;-)
> PPS. Je n'ai pas bien compris l'astuce qui consiste à cacher du code css à
> certains navigateurs. Pourras-tu m'expliquer un jour comment ça marche et
le
> but de faire cela ?
>
>
>
> Selon Jesir VARGAS <[EMAIL PROTECTED]>:
>
> > Salut les amis !
> >
> > Suite a un manque de temps soudain, je voudrais proposer le passage aux
> > standards web tout en conservant l'interface actuelle en tant q possible
> > ( de ma part, j'aime bien les couleurs du "francois_theme", q je viens
> > de découvrir sur les pages démo., peut-être que cela pourrait devenir
> > l'enjeux de couleurs à défaut ? )
>
>
> > Il faut savoir q les changements du passage aux standards entraînera
> > forcément des problèmes _temporaires_ d'affichage, etc.   Il est ainsi
> > parce que notamment on change la structure des balises des pages et,
> > biensûr, un réarrangement des fichiers CSS, des images, etc.  (C'est
> > pour cela qu'il faudrait faire, e.g., une release et puis ensuite
> > avertir les utilisateurs du << danger >> du CVS pendant la transition...
> > ?)
> >
> > Voilà, donc, par rapport aux CSS, je voudrais proposer ceci :
> >
> > * Les << thèmes >> seront mis dans des dossiers homonymes (e.g.,
> > seabreeze/).
> >
> > * Dans ces dossiers-là, il y aura les fichiers suivants :
> >     * layout.css   (toutes les propriétés de la disposition)
> >     * fonts.css    (les polices)
> >     * colors.css   (couleurs)
> >
> >   A noter q ces fichiers CSS auront _tous_ les memes selecteurs CSS.
> > E.g.,
> >
> > Dans le dossier << seabreeze/ >> :
> >
> > fonts.css :
> > ^^^^^^^^^^^
> > body
> > {
> >   font-family: sans-serif;
> > }
> >
> > a:hover
> > {
> >   text-decoration: underline;
> > }
> >
> > layout.css :
> > ^^^^^^^^^^^
> > body
> > {
> >   padding: 5em;
> > }
> >
> > a:hover
> > {
> >    /* notez q cela est vide mais on l'inclu d toutes les façons */
> > }
> >
> > colors.css :
> > ^^^^^^^^^^^
> > body
> > {
> >   background-color: red-hell;
> >   color: heaven-blue;
> > }
> >
> > a:hover
> > {
> >   color: black;
> >   background-color: #fff;
> > }
> >
> > * Accessibilité.  Gros mot.  On va suivre _au moins_ les conseils donnés
> > ici :
> >
> > http://www.la-grange.net/accessibilite/
> >
> > * Le DTD des fichiers sera-t-il celui du XHTML 1.0 Transitional ou bien
> > celui du XHTML 1.0 Strict, au moins.
> >
> > * Le << layout >> (positionnement, disposition) de l'interface sera géré
> > _intégralement_ avec CSS (version 2.0 au moins).  Pas de tableaux !
> > Veuillez regarder les excellents articles chez OpenWeb :
> > http://openweb.eu.org/css/ si jamais voulez-vous en savoir davantage.
> >
> > * L'usabilité (convivialité).  PMB doit être _forcément_ facile et
> > intuitive à utiliser, punto.  Pourquoi pas, donc, suivre les conseils
> > des gourous chez
> >
> > A List Apart (web usability) :
> > http://alistapart.com/topics/usability/ ,
> >
> > UseIt (web usability) :
> > http://www.useit.com/ ,
> >
> > Apple :
> >
> >
>
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelin
> es/index.html,
> >
> > et GNOME :
> >
> > http://developer.gnome.org/projects/gup/hig/ ??
> >
> > * Par rapport à cela, les fautes de convivialité seront regardées en
> > tant que bogues.  C'est à dire, ça c'est sérieux.
> >
> > Peut être que j'aie oublié des trucs mais je crois que cela suffit pour
> > l'instant.  Je vous remercie de vos commentaires, opinions, sages
> > conseils et numéros de cartes bleues.  :)
> >
> > Merci de votre temps,
> >
> > jsr
> >
> >
> >
> >
> > Liste de diffusion phpmybibli.devel
> > Pour se désinscrire :
> > mailto:[EMAIL PROTECTED]
> >
> >
>
>
> -- 
> François Lemarchand
> homepage : http://balno.free.fr/
> PhpMyBibli : http://phpmybibli.sourceforge.net
>
> Liste de diffusion phpmybibli.devel
> Pour se désinscrire :
mailto:[EMAIL PROTECTED]
>
>


Liste de diffusion phpmybibli.devel
Pour se désinscrire : mailto:[EMAIL PROTECTED]

Répondre à