🌍
Français
chrisaga a écrit:
yoDan a écrit:
- dans la version graphique, remarquerez-vous l'effet d'eclairement ? ;-)
... qui ne fonctionne pas avec IE, mais on s'y attendais.
Cela marche bien au contraire avec les dernières versions (patchs) de IE.
8;-)
marsue a écrit:
Je suis peut-être HS c'est possible en "générant" les css, par example sur notre projet on a "mappée une jsp qui produit du css en fonction des droits d'accès de l'utilsateur (si read-only le thème est différent pour que l'utilisateur voit de suite qu'il n'a rien le droit d'éditer), mais je ne sais pas si c'est possible en php :-(
l'idée est intéressante mais cela revient à avoir une feuille de style par personne. On pourrait tout de même imaginer de gérer cela pour une feuille de style nommée et pas la feuille de style permanente.
yoDan a écrit:
Je reponds « a la place » de l'equipe de PWG (ils ont peut-etre a l'esprit des arguments supplementaires) : generer automatiquement le fichier entier style.css est problematique pour plusieurs raisons.
1_ On ne peut pas demander a l'utilisateur de configurer « son » serveur web (entre guillemets parce que c'est peut-etre celui de son FAI) pour qu'il fasse passer les fichiers .css par un moteur php, jsp, ou autre.
2_ De toute facon, il faudrait que le style eventuellement calculé par PWG ne soit pas recalculé à chaque requete d'utilisateur mais soit mis en cache.
3_ L'administrateur peut vouloir modifier le CSS (pas besoin d'une option de configuration pour changer des couleurs, par ex.), il faut qu'il identifie facilement où faire ses modifications, il faut qu'il voie immediatement le resultat de ses modifications et il faut que ses modifications et celles eventuellement calculées à la volée par PWG ne s'annulent pas mutuellement.
1/ Je ne suis pas sûr de comprendre ce que tu dis. On peut parfaitement générer une feuille de style à la volée. Il n'y a rien à changer côté serveur; il suffit de lui donner une extension (.php) qui fait appel au parseur php.
2/ Pas de rapport avec le fait que la feuille de style soit générée dynamiquement. Elle peut très bien être cachée côté client; il suffit d'envoyer les bon entêtes http côté serveur!
3/ l'idée du colorpicker va dans ce sens. Non ? Pour pas que les modifications s'annulent il faut qu'il y ait deux feuilles de styles: une permanente non nommée (pas d'attribut title) et non modifiable et une que l'on pourrait nommé et qui serait modifiable.
Bon c'est juste une idée et surtout pour répondre à marsue sur ce qu'il est possible de faire.
Pour ma part, je pense qu'il serait aussi intéressant de n'avoir qu'une seule feuille de style aussi complexe que l'on voudrait mais minimaliste (sans couleur, avec le minimum de présentation; juste de la mise en page). On déconseillera fortement de la modifier. Cette feuille de style serait permanente (i.e sans attribut title).
Après j'ajouterais une feuille de style nommé qui contiendrait les couleurs, les icônes, les fontes, ... On pourrait (pour ne pas dire il faudrait) évidemment ajouter des feuilles de style alternatives. Par parenthèses il est aisé de gérer le changement de feuille de style par défaut dans des navigateurs non basé sur gecko avec un p'tit cookie.
Après un 2ème coup d'oeil, incluant le code cette fois, je confirme que l'on a probablement encore progressé
yoDan a écrit:
- je continue d'experimenter sur l'idee de reperer les proprietes de l'image (populaire, commentée) sur l'image elle-meme.
Intéressant ... et prometteur.
yoDan a écrit:
Les differences sont que j'impose l'alignement a gauche des vignettes et la hauteur fixe des etiquettes. Techniquement, ce sont des limitations, mais je trouve que cela produit de toute facon des galleries plus regulieres, plus agreables a l'oeil.
- Fixer la hauteur : je suis arrivé à la même conclusion
- Aligner à gauche : l'estétique est contestable, ce serait mieux si l'on pouvait équilibrer les marges de droite et de gauche.
yoDan a écrit:
- dans la version classique, l'effet d'epaississement (en plus du changement de couleur et de pseudo relief) me parait important visuellement. Je le precise parce que j'ai eu du mal a le faire fonctionner dans FF+IE+Opera.
Tu peux ajouter que ça fonctionne avec Konqueror, donc probablement aussi avec Safari :-)
yoDan a écrit:
- dans la version graphique, remarquerez-vous l'effet d'eclairement ? ;-)
... qui ne fonctionne pas avec IE, mais on s'y attendais.
yoDan a écrit:
- et puis on a beau dire que la beaute du code ne mene pas a grand chose, il n'y a qu'un SPAN pour l'image, un autre pour l'etiquette, et pas de <BR> :-P
<:oP
Finalement le positionnement initialement designé pour IE en remplacement de ce que l'on avait prévu au départ est adopté pour tous les navigateurs.
J'y avais pensé, mais je m'étais imaginé que c'était l'autre qui était la cible. En plus il fonctionne plutôt bien (sauf pour IE).
Bien évidemment ça fait déjà gagner un SPAN <:oP
Je vais voir comment ça pourrait s'intégrer en BSF
Salut à tous !
J'ai juste jeté un coup d'oeil avant de partir bosser et les exemples me paraissent très beaux.
Le coup de l'alignement à gauche, ça se discute. j'avais fait des essais en ce sens. A voir ...
Je n'ai pas vu le code, mais puisque yoDan dit que le sien et le mien convergent, on ne dois pas être loins d'avoir quelque chose de de génial ;-)
Je vais regarder ça rapidement, et voir si l'on peut converger un peu plus.
VDigital a écrit:
J'ai simplement rapproché, width et height.
En fait c'est juste, histoire de dire quelque chose, je mettrai volontiers ces deux définitions/parmétrages dans un fichier css séparé de façon à simplifier les corrections et adaptations.
Ça c'est déjà fait dans la BSF (remonté des paramètres globaux au site).
A+
Christophe
Bien le bonjour à toi yoDan, mais aussi à tous bien évidemment,
Objectif:
#floating_legends LI, #floating_legends SPAN {
width: 200px;
}
#floating_legends SPAN {
display: block;
overflow: hidden;
}
#floating_legends SPAN.thumbnail {
position: relative;
height: 200px;
background: transparent url(images/diapo-fond.png);
}nickel, certes, mais pourquoi ne pas l'écrire comme ceci:
#floating_legends LI, #floating_legends SPAN {
width: 200px; /* Only once width for all thumbnails */
}
#floating_legends SPAN.thumbnail {
height: 200px; /* Only once height for all thumbnails, for a very simple adaptation */
position: relative;
background: transparent url(images/diapo-fond.png);
}
#floating_legends SPAN {
display: block;
overflow: hidden;
}J'ai simplement rapproché, width et height.
En fait c'est juste, histoire de dire quelque chose, je mettrai volontiers ces deux définitions/parmétrages dans un fichier css séparé de façon à simplifier les corrections et adaptations.
Décidément, tes girafes étaient pourtant belles, mais Noël t'a réellement inspiré.
Laisse-nous un peu de temps pour digérer et revenir vers toi avec de plus concrêtes idées.
Merci bien. C'est un très beau cadeau en tout cas.
Vincent
Salut a tous,
J'ai laisse passer un peu de temps, je m'etais dit que j'y avais deja passe suffisament de temps, mais je n'ai pas pu m'empecher de m'y replonger ;-). Apres mes experiences, et au vu du code de demo.pwg.net, je suis arrive a ces conclusions (en esperant que ca serve a quelqu'un) :
- il ne sera probablement pas possible d'avoir un lien (A) englobant l'image et l'etiquette, la faute a un bug assez enorme d'IE qui rend l'image non-clickable. Le lien n'englobera donc que l'image, comme dans le code actuel de pwg
- en revoyant le code de chrisaga, je me suis dis que l'astuce pour centrer verticalement et horizontalement un objet dans un autre valait le coup d'etre utilisee. Je laisse donc tomber mes styles en ligne pour positionner chaque vignette dans son cadre. Un span de plus ? La belle affaire ! (merci de m'avoir rouvert les yeux sur ce coup).
- je continue d'experimenter sur l'idee de reperer les proprietes de l'image (populaire, commentée) sur l'image elle-meme.
Donc c'est un code qui a converge vers celui de chrisaga que je presente aujourd'hui. Les differences sont que j'impose l'alignement a gauche des vignettes et la hauteur fixe des etiquettes. Techniquement, ce sont des limitations, mais je trouve que cela produit de toute facon des galleries plus regulieres, plus agreables a l'oeil.
Je donne les liens, et vous en vante les merites ensuite :
version classique
version graphique, meme code HTML, CSS un peu modifié, bien sur
- dans la version classique, l'effet d'epaississement (en plus du changement de couleur et de pseudo relief) me parait important visuellement. Je le precise parce que j'ai eu du mal a le faire fonctionner dans FF+IE+Opera.
- dans la version graphique, remarquerez-vous l'effet d'eclairement ? ;-)
- le titre a rallonge d'une des images ne perturbe pas la page (tronquée)
- il n'y a qu'une seule valeur a changer pour modifier la largeur de la diapo (vignette + cadre), de meme pour sa hauteur, pour la hauteur de l'etiquette, l'espace lateral entre les diapos, et l'espace vertical.
- et puis on a beau dire que la beaute du code ne mene pas a grand chose, il n'y a qu'un SPAN pour l'image, un autre pour l'etiquette, et pas de <BR> :-P
yoDan a écrit:
Je pense que le maximum d'informations devrait etre accessible (sous la forme de {thumbnails.picture.*}), meme si bien sur les templates n'en utiliseraient que quelques uns ({thumbnails.picture.IMAGE_TITLE}, eventuellement {thumbnails.picture.NB_COMMENTS}, etc). [...]/[...], encore qu'il faudrait verifier qu'il est possible de differencier les images des sous-categories uniquement par cet attribut de facon satisfaisante).
J'adhère complètement à ton point de vue.
C'est la meilleure façon pour que de si nombreux utilisateurs développent des thèmes et templates différents et de plus en plus élaborés.
C'est une clé complémentaire qu'il nous faut proposer en réponse au succès grandissant de PWG.
Proposer bien plus, et laisser toute liberté au webmaster d'en utiliser bien moins.
bon ben c'est pas grave ...
je ne connais pas bien le php et donc je ne connais pas du tout ses limites .
juste pour expliquer :
the-css.jsp?mode=r/w
il s'agit d'appeler une jsp avec des paramètres (ici mode) qui produit du code css, sur notre projet, on se contente d'initaliser des tailles de caractères et les 2-3 couleurs principales du Thème. Mais il faut configurer un peu le serveur pour qu'il "écoute" les appels sur the-css.jsp du côté HTML, le naviguateur s'en fiche du moment qu'on lui donne du css peu importe de où ça vient.
L'appli à été conçue de cette manière pour avoir la possibilité d'avoir une interface graphique entièrement personalisable par l'utilisateur final qui pouvait choisir ses couleurs via un "colour picker" et enregistrer ses préférences sans avoir jamais consience du code qui se cache derrière.
Je voyais juste l'utilisateur final ici comme étant l'admin de la pwg ... (mais je le repète je ne suis pas au faite des limitations techniques du php - et je le regrète), d'où il pourrait changer à la volée les couleur d'un template donnée c'est-à-dire un nouveau thème du template, évidemment pour la construction d'un nouveau template, pas le choix il faut mettre ses doigts dans le code.
Mais ce fil m'interesse beaucoup, car j'aimerais bien me faire mon template personnalisé (pas seulement les couleurs, mais aussi la disposition des différents éléments) et je ne sais pas par où commencer ....
marsue a écrit:
Je suis peut-être HS c'est possible en "générant" les css[...]
Je reponds « a la place » de l'equipe de PWG (ils ont peut-etre a l'esprit des arguments supplementaires) : generer automatiquement le fichier entier style.css est problematique pour plusieurs raisons.
1_ On ne peut pas demander a l'utilisateur de configurer « son » serveur web (entre guillemets parce que c'est peut-etre celui de son FAI) pour qu'il fasse passer les fichiers .css par un moteur php, jsp, ou autre.
2_ De toute facon, il faudrait que le style eventuellement calculé par PWG ne soit pas recalculé à chaque requete d'utilisateur mais soit mis en cache.
3_ L'administrateur peut vouloir modifier le CSS (pas besoin d'une option de configuration pour changer des couleurs, par ex.), il faut qu'il identifie facilement où faire ses modifications, il faut qu'il voie immediatement le resultat de ses modifications et il faut que ses modifications et celles eventuellement calculées à la volée par PWG ne s'annulent pas mutuellement.
Dans le code actuel de PWG, il n'y a parait-il qu'une ligne a modifier dans le CSS pour obtenir une largeur de diapo differente dans la gallerie (bon, il faut aussi regenerer les miniatures). Je ne sais pas si les images sont centrees verticalement et horizontalement.
Dans le code que j'ai proposé dans ce fil, PWG doit etre informé de la taille maxi des diapos (mais il me semble que c'est deja le cas, non?, ne serait-ce que pour generer les miniatures a partir des photos) et doit generer, a chaque fois que cette taille change, un fichier non-standard-size.css de quelques lignes qui "corrige" les dimensions codées dans standard-style.css.
Je n'ai pas compris l'histoire du the-css.jsp?mode=r/w :-/.
Mais on pourrait revenir à la question initiale de cette discussion : quelles informations faut-il mettre a la disposition des auteurs de template ? et quel code HTML ?
Je pense que le maximum d'informations devrait etre accessible (sous la forme de {thumbnails.picture.*}), meme si bien sur les templates n'en utiliseraient que quelques uns ({thumbnails.picture.IMAGE_TITLE}, eventuellement {thumbnails.picture.NB_COMMENTS}, etc). Les styles en ligne que « mon » code impose pourraient se trouver dans {thumbnails.picture.CSS_POSITIONING}. PWG pourrait egalement fournir {thumbnails.picture.ID} (au cas où l'utilisateur prendrait le temps de styler une image en particulier) et {thumbnails.picture.CLASS} (qui vaudrait "image" ou "subcategory", encore qu'il faudrait verifier qu'il est possible de differencier les images des sous-categories uniquement par cet attribut de facon satisfaisante).
yoDan a écrit:
Je vais etre provocateur : et alors ? Si cela permet a l'utilisateur d'avoir juste un champ a remplir dans un formulaire pour modifier la taille de ses miniatures, sans qu'il ait a modifier le fichier .tpl/.css, est-ce que ca ne vaut pas le coup ?
Bon, pas de mauvaise foi : je reconnais sans probleme que ce serait encore mieux si les dimensions max ne pouvaient apparaitre qu'une fois dans le CSS et qu'aucune autre ligne n'etait a modifier pour changer la taille des miniatures, mais j'ai reessayé, sans y arriver.
Je suis peut-être HS c'est possible en "générant" les css, par example sur notre projet on a "mappée une jsp qui produit du css en fonction des droits d'accès de l'utilsateur (si read-only le thème est différent pour que l'utilisateur voit de suite qu'il n'a rien le droit d'éditer), mais je ne sais pas si c'est possible en php :-(
ce qui nous fat une tuc du genre dans le html:
<html> <head> <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>title</title> <link title="test" type="text/css" rel="stylesheet" href="/reources/the-css.jsp?mode=r/w">
et du coup en piochant la valeur d'une variable dans une BdD, il suffit de l'initialiser qu'une seule fois et on peut l'utliser autant de fois qu'on veut, on peut aussi l'initialiser d'un fichier propriétés ...
je sais pas si ça aide...
chrisaga a écrit:
yoDan rajoutes des tailles fixes (mêmes si elles sont calculées par PWG) et ça, ça ne va faciliter la personnalisation.
Mmm-oui. Ce que je suppose ou impose, c'est que les miniatures ont une taille maximale (horizontalement et verticalement, en fait juste verticalement) et qu'elles sont centrées (horizontalement et verticalement) au milieu d'un espace disponible qui lui a une taille minimale (cas avec "panoramas") ou fixe (cas des diapos carres). Est-ce acceptable ?
chrisaga a écrit:
Vous allez demander à Zorglub de gérer des tas de paramètres d'affichage ( paramètres de conf en table ou en fichier .php ...)
Je vais etre provocateur : et alors ? Si cela permet a l'utilisateur d'avoir juste un champ a remplir dans un formulaire pour modifier la taille de ses miniatures, sans qu'il ait a modifier le fichier .tpl/.css, est-ce que ca ne vaut pas le coup ?
Bon, pas de mauvaise foi : je reconnais sans probleme que ce serait encore mieux si les dimensions max ne pouvaient apparaitre qu'une fois dans le CSS et qu'aucune autre ligne n'etait a modifier pour changer la taille des miniatures, mais j'ai reessayé, sans y arriver.
chrisaga a écrit:
Personnellement, je pense que le webmaster se fiche du nombre de SPAN imbriqués
Oui, mais le code est tellement technique que peu de personnes savent modifier le code (HTML ou CSS) sans casser la page dans tel ou tel navigateur.
chrisaga a écrit:
Réintégrer le travail de présentation dans PWG ne va pas dans ce sens.
Pour prendre un exemple simple, dans l'état actuel du template, on doit pouvoir avec 2 modifs dans le CSS passer la barre de menu de gauche à droite (je n'ai pas essayé dans la version de travail actuelle, mais si ce n'est pas possible c'est que j'ai fait une erreur). Si l'on demande à PWG de calculer la marge gauche du pavé principal (#content), c'est fichu. On doit demander à PWG de gérer des options différentes de présentation droite/gauche, et à mon avis, ce n'est pas sont rôle.
Heureusement, on est d'accord.
chrisaga a écrit:
Je n'ai malheureusement pas beaucoup de temps pour contribuer à ce topic.
Et les membres de l'équipe en sont tous là...
On va finir par trouver quelque chose de bien, laissons yoDan chercher un peu.
Et d'autres membres peuvent nous donner de bonnes nouvelles idées.
VDigital a écrit:
[...]
Pour moi, on est exactement pour une fois dans l'alignement..., pardon dans l'axe fixé par le topic. 8-)
Je sais bien que vos réflexions vont dans le bon sens, c'est juste pour rappeler un point essentiel, mais que l'on peut oublier rapidement :
On sort les instructions de présentation du HTML (pour nous des fichiers *.tpl) pour rendre la présentation indépendante des éléments affichés. Sans toucher au code, on peut avoir un maximum de présentations - couleurs, polices, ... (le theme), mais aussi positionnement, différents. Réintégrer le travail de présentation dans PWG ne va pas dans ce sens.
Pour prendre un exemple simple, dans l'état actuel du template, on doit pouvoir avec 2 modifs dans le CSS passer la barre de menu de gauche à droite (je n'ai pas essayé dans la version de travail actuelle, mais si ce n'est pas possible c'est que j'ai fait une erreur). Si l'on demande à PWG de calculer la marge gauche du pavé principal (#content), c'est fichu. On doit demander à PWG de gérer des options différentes de présentation droite/gauche, et à mon avis, ce n'est pas son rôle.
Je n'ai malheureusement pas beaucoupp de temps pour contribuer à ce topic.
chrisaga a écrit:
Dites les gars, vous êtes biens gentils à virer les SPAN, mais yoDan rajoutes des tailles fixes (mêmes si elles sont calculées par PWG) et ça, ça ne va faciliter la personnalisation.
On voit déjà que mes deux tailles max perturbent pas mal les webmasters.
Réfléchissez un peu ...
Pas de soucis, il faut simplement se secouer les synapses.
chrisaga a écrit:
Vous allez demander à Zorglub de gérer des tas de paramètres d'affichage ( paramètres de conf en table ou en fichier .php ...)
Personnellement, je pense que le webmaster se fiche du nombre de SPAN imbriqués, si l'on a bien isolé les parties de CSS qui permettent de personnaliser l'affichage.
L'autre risque est que si l'on fait faire trop de chose à PWG au lieu de les mettre en CSS, on fige trop le style d'affichage et que la personnalisation se limite à un changement de couleurs.
L'idée est bien de reporter le max de la config vers le css mais on essai juste de trouver la façon la plus simple et celle qui réserve le plus de fonctionalités au webmaster.
Pour moi, on est exactement pour une fois dans l'alignement..., pardon dans l'axe fixé par le topic. 8-)
Dites les gars, vous êtes biens gentils à virer les SPAN, mais yoDan rajoutes des tailles fixes (mêmes si elles sont calculées par PWG) et ça, ça ne va faciliter la personnalisation.
On voit déjà que mes deux tailles max perturbent pas mal les webmasters.
Réfléchissez un peu comment vous allez faire pour contenter les gas qui comme Vincent "aiment les galleries aérées". Pour chaque valeur numérique calculée par PWG, il faudra un paramètre de configuration qui permette au webmaster de jouer sur l'espacement horizontal et vertical, la largeur des bordures (dans le cas d'un affichage type diapo,) etc.
Vous allez demander à Zorglub de gérer des tas de paramètres d'affichage ( paramètres de conf en table ou en fichier .php ...)
Personnellement, je pense que le webmaster se fiche du nombre de SPAN imbriqués, si l'on a bien isolé les parties de CSS qui permettent de personnaliser l'affichage.
L'autre risque est que si l'on fait faire trop de chose à PWG au lieu de les mettre en CSS, on fige trop le style d'affichage et que la personnalisation se limite à un changement de couleurs.