Bonjour,
1) Félicitation
2) Est-il envisagé (ou envisageable dans l'esprit dans lequel SPIP a été
créé) de permettre l'inscription de membres (attention pas auteurs ou
peut-être auteurs sans droit d'écriture ni d'accès à l'interface
d'administration) afin de leur donner accès à certaines rubriques. Rubriques
qui bien sûr ne seraient consultables que par les membres connus en base.
Je propose cela suite au module http://xprotector.sourceforge.net.
Merci
Vincent
2) Est-il envisagé (ou envisageable dans l'esprit dans lequel SPIP a été
créé) de permettre l'inscription de membres (attention pas auteurs ou
peut-être auteurs sans droit d'écriture ni d'accès à l'interface
d'administration) afin de leur donner accès à certaines rubriques. Rubriques
qui bien sûr ne seraient consultables que par les membres connus en base.
Oui, tu peux le faire en proposant, sur un article donné, un "forum sur
abonnement". Du coup les gens qui s'abonnent à ce (faux) forum recoivent un
login par mail...
Je propose cela suite au module http://xprotector.sourceforge.net.
...en fait SPIP contient déjà des éléments qui permettent de faire ce que
fait xprotector. Cf "auteur_session" dans la doc de SPIP (qui a maintenant
un moteur de recherche !)
-- Fil
fait xprotector. Cf "auteur_session" dans la doc de SPIP (qui a maintenant
un moteur de recherche !)
Marrant :
http://www.uzine.net/article1827.html?var_recherche=auteur_session
le surlignement s'applique aussi au milieu du <cadre>...</cadre> et ça
introduit quelque problème... je ne vois pas comment éviter ça, sauf à
exfiltrer spécifiquement les <cadre>...</cadre> avant d'appliquer le
surlignement... d'autres idées ?
-- Fil
Bien que n'ayant pas encore testé Xprotector, je suis également
intéressé par une fonction qui permettrait de gérer une (même) base
d'utilisateurs avec gestion des droits d'accès / rédaction /
d'administration.
En bref, cela permettrait d'attribuer l'accès de la rubrique privée "1"
à "Paul" sans lui donner l'accès à la rubrique privée "2", etc., en
utilisant une interface d'administration adaptée.
Bien sûr, le moteur de recherche devrait tenir compte des droits de
l'utilisateur, ce qui ne simplifie pas la tâche.
Est-il envisageable d'implémenter une telle fonction dans la version
officielle de SPIP ? Xprotector, pour ceux qui l'ont testé, répond-il à
cette demande ?
Merci de vos réponses,
Olivier.
-----Message d'origine-----
Quelqu'un a-t-il déjà essayé de limiter l'accès a des rubriques ou articles
suivant les droits définis dans un forum phpBB2 ?
chez moi (IE 5.06 sur Mac OS9) je n'ai pas ce comportement. je n'ai pas de
surlignement entre les cadres
@+
nicolas R
Je suis à compléter un tutoriel pour l'utilisation d'un "stylesheet
switcher" en javascript et/ou php pour les sites sous SPIP, accompagné des
fichiers de support.
Objectif: dans la même veine que "CSS Zen Garden", à partir d'un jeu unique
de squelettes SPIP, constituer un réservoir de feuilles de styles
alternatives parmi lesquelles un webmestre pourrait puiser ou qu'il pourrait
offrir comme choix aux visiteurs (à la manière openweb.eu.org).
Le tutoriel se concentre sur le jeu de squelettes et de feuilles de styles
par défaut de SPIP. Pourquoi? Parce qu'ils possèdent presque toutes les
qualités nécessaires à ce projet: multilingue, parfaite conformité aux
standards (notamment, le choix du <DOCTYPE> est des plus pertinents, dans
l'état actuel du web et de SPIP), excellente accessibilité, bonne structure
sémantique bien adaptée au contenu géré par SPIP, tout le design est
contrôlé par CSS (aucun tableau), excellente compatibilité avec les
navigateurs modernes et une dégradation acceptable pour les navigateurs plus
anciens; mais surtout, respect des contenus développés avec les versions
antérieures de SPIP. La cascade des feuilles de styles est bien organisée et
convient parfaitement au projet. On ne le redira peut-être pas assez, mais à
mon avis, ce jeu de squelettes est d'excellente facture et d'une grande
souplesse; il peut se prêter à de très nombreuses variantes.
À date tout baigne dans l'huile.
Ce qui me reste à valider:
- assurer que les squelettes par défaut restent intacts si on n'utilise pas
de feuilles de styles alternatives. Autrement dit, le design originel reste
intact, tant que le webmestre n'active pas les nouvelles feuilles de style,
tout en pouvant expérimenter à loisir;
- que ça ne provoque pas de gonflement du cache;
- que la sécurité ne soit pas compromise;
- que ça reste simple à implanter; le minimum de choses à copier ou
modifier;
Si ça intéresse, je peux commencer à fournir les premières étapes
d'implantation de tout cela avec quelques exemples sur spip_contrib dans la
section Squelettes, sinon j'attend que ce soit plus complet et surtout plus
pédagogique (désolé, la pédagogie, c'est mon job).
Références en attendant:
Pour le projet CSS Zen Garden, voir:
http://www.csszengarden.com/tr/francais/?cssfile=/017/017.css&page=1
Plus particulièrement:
http://www.csszengarden.com/tr/francais/?cssfile=/017/017.css&page=1
Qui se dégrade ainsi, sans feuille de styles:
http://www.csszengarden.com/tr/francais/?cssfile=/017/
Pour les "style switcher" voir:
http://www.alistapart.com/stories/alternate/ (version javascript)
http://www.alistapart.com/stories/n4switch/ (version javascript)
http://www.alistapart.com/stories/phpswitch/ (version php)
http://www.alistapart.com/stories/phpswitch/discuss/ (discussion sur
l'article précédent)
http://www.contrastsweb.com/switcher/ (un autre php)
http://martin.f2o.org/php/designcustomization (encore un autre php)
André Vincent
Objectif: dans la même veine que "CSS Zen Garden", à partir d'un jeu unique
Je ne connaissais pas ce site ; j'avoue que je suis carrément bluffé !
http://www.mezzoblue.com/zengarden/alldesigns/
Ce qui me reste à valider:
- assurer que les squelettes par défaut restent intacts si on n'utilise pas
de feuilles de styles alternatives. Autrement dit, le design originel reste
intact, tant que le webmestre n'active pas les nouvelles feuilles de style,
tout en pouvant expérimenter à loisir;
le design originel n'est pas si beau que ça 
- que ça ne provoque pas de gonflement du cache;
je ne vois pas le risque
- que la sécurité ne soit pas compromise;
là non plus
Si ça intéresse, je peux commencer à fournir les premières étapes
d'implantation de tout cela avec quelques exemples sur spip_contrib dans la
section Squelettes, sinon j'attend que ce soit plus complet et surtout plus
pédagogique (désolé, la pédagogie, c'est mon job).
oui, c'est très intéressant !
Pour les "style switcher" voir:
http://www.alistapart.com/stories/alternate/ (version javascript)
http://www.alistapart.com/stories/n4switch/ (version javascript)
http://www.alistapart.com/stories/phpswitch/ (version php)
http://www.alistapart.com/stories/phpswitch/discuss/ (discussion sur
l'article précédent)
http://www.contrastsweb.com/switcher/ (un autre php)
http://martin.f2o.org/php/designcustomization (encore un autre php)
A mon avis il est plus logique de "switcher" en javascript qu'en php, car ça
ne concerne pas du tout le serveur.
-- Fil
si, regarde dans le code du cadre, il y a bien :
$<span class="spip_surligne">auteur_session au lieu de $auteur_session.
et pour répondre à Fil, la 1ere chose qui me soit venue à l'esprit est celle
qu'il a proposée.
l'autre soluce qui m'est venue après avoir cherché un truc compliqué à
souhait :), est de convertir le contenu de cadre en image (image qui serait
donc nommée et insérée à la place du cadre même) et un javascript pour
coller le contenu dans le presse papier (puisque l'intérêt du cadre est de
pouvoir en copier/coller le code contenu).
mais d'une part c'est pas très simple à gérer, puis d'autre part ça ralenti
le serveur puisque le contenu de l'image devrait être généré à chaque
modification du texte.
alors si en plus avec ça et pour courronner le tout, on vexe les designers
qui ne peuvent plus personnaliser la police, la couleur d'arrière-plan du
cadre la largeur... c'en est fini 
donc en ce qui me concerne je ne vois que la 1ere soluce...sorry
"Nicolas RIQUOIS" <nicolasriq@free.fr> a écrit dans le message de
news:BB45A670.D74B%nicolasriq@free.fr...
pour le moment, xprotector ne fait que protéger l'accès d'une rubrique et
non son contenu.
du coup, un filtre un peu large ou le moteur de recherche remontent tous
deux les articles des rubriques à accès restreint.
donc dans ce sens xprotector ne répond pas à ton besoin.
cependant tu dois pouvoir adapter la restriction d'accès aux articles.
j'ai testé l'utilisation du formulaire #LOGIN_PUBLIC comme l'a conseillé
Fil.
mais le code de l'article http://www.uzine.net/article1827.html me pose
problème.
lorsque je suis identifié tout fonctionne, mais si j'ai le malheur de me
délogger, alors il ne reconnaît plus mon login et j'ai le droit à un éternel
"L'identifiant << @login@ >> est inconnu."... snif
120
"Olivier" <taxe@free.fr> a écrit dans le message de
news:000601c351dc$8adfe5d0$0200a8c0@x1...
Bien que n'ayant pas encore testé Xprotector, je suis également
intéressé par une fonction qui permettrait de gérer une (même) base
d'utilisateurs avec gestion des droits d'accès / rédaction /
d'administration.
En bref, cela permettrait d'attribuer l'accès de la rubrique privée "1"
à "Paul" sans lui donner l'accès à la rubrique privée "2", etc., en
utilisant une interface d'administration adaptée.
Bien sûr, le moteur de recherche devrait tenir compte des droits de
l'utilisateur, ce qui ne simplifie pas la tâche.
Est-il envisageable d'implémenter une telle fonction dans la version
officielle de SPIP ? Xprotector, pour ceux qui l'ont testé, répond-il à
cette demande ?
Merci de vos réponses,
Olivier.
En réponse à fil@rezo.net a écrit:
Je ne connaissais pas ce site ; j'avoue que je suis carrément bluffé !
http://www.mezzoblue.com/zengarden/alldesigns/
Moi aussi! Ces gars sont non seulement des partisans des standards, mais ce
sont surtout des PRATICIENS du web. Particulièrement, Douglas Bowman,
(http://www.stopdesign.com) qui a refait le site de wired.com et certaines
sections de yahoo.com entièrement en CSS, sans tableaux. Ça prend des
clients qui ont du culot.
le design originel n'est pas si beau que ça
Tu seras surpris de voir ce que mes étudiants peuvent en tirer.
Mais bon, évidemment on pourrais refaire un jeu de squelette un peu plus
souple et par défaut un peu plus design. Ce sera le travail de la 2e moitié
de session pour mes étudiants (ce sont, pour la plupart, d'excellents
graphistes). On verra.
- que ça ne provoque pas de gonflement du cache;
je ne vois pas le risque
En javascript pas de soucis. En php, selon les solutions que j'ai regardé et
les commentaires que j'ai lu, je me fais du soucis.
- que la sécurité ne soit pas compromise;
là non plus
En effet, j'ai moins de soucis, du moins certainement pas en javascript.
A mon avis il est plus logique de "switcher" en javascript qu'en php, car ça
ne concerne pas du tout le serveur.
Moi aussi, pour l'instant je préfère javascript, mais...
1. La version javascript utilise des cookies (certaines versions de php
aussi, mais d'autre uniquement les sessions php, sans cookie)
2. L'interprétation du javascript repose sur le dos du client; on ne peut
garantir que ça passe partout; des versions légèrement anciennes d'Omniweb,
Opera, Windows Explorer, et Safari ont de la difficulté; par contre ça passe
bien dans les versions les plus récentes. Pour Netscape 4, on s'en fiche, on
ne lui donne pas de choix de style.
3. C'est effectivement beaucoup plus simple en javascript: pas de soucis
côté serveur. Mais par contre une solide version php3 serait universelle:
plus de soucis du côté navigateur, plus de soucis de cookie, plus de soucis
de javascript.
Conclusion: on commence avec javascript, on verra pour php plus tard.
oui, c'est très intéressant !
Bon, je vais de l'avant pour une petite contribution.
André Vincent
PS - Au fait, merci pour:
Mais bon, évidemment on pourrais refaire un jeu de squelette un peu plus
souple et par défaut un peu plus design. Ce sera le travail de la 2e moitié
de session pour mes étudiants (ce sont, pour la plupart, d'excellents
graphistes). On verra.
Excellente idée !
1. La version javascript utilise des cookies (certaines versions de php
aussi, mais d'autre uniquement les sessions php, sans cookie)
Et quel est le problème ? Si on parle du côté webmestre (j'essaie plein de
designs différent avatn de stabiliser celui de mon site), il peut bien
accepter les cookies. Si on parle du côté visiteur du site, s'il refuse les
cookies il ne change pas de feuille de style (tant pis pour lui).
2. L'interprétation du javascript repose sur le dos du client; on ne peut
garantir que ça passe partout;
Ca c'est vrai aussi et surtout de CSS. Le javascript qui switche est quand
même assez simple, et plus simple à tester que les feuilles de style....
-- Fil
Salut,
Objectif: dans la même veine que "CSS Zen Garden", à partir d'un jeu
unique
de squelettes SPIP, constituer un réservoir de feuilles de styles
alternatives parmi lesquelles un webmestre pourrait puiser ou qu'il
pourrait
offrir comme choix aux visiteurs (à la manière openweb.eu.org).
Je ne suis pas convaincu de l'utilité du "style switcher" en soi.
Pour plusieurs raisons :
- un site Web cherche à avoir une mise en page, pas plusieurs
- même avec une feuille de style, le HTML n'est pas indépendant de
la mise en page (imbrication et ordre des <div> - très important
pour les "float" -, etc.) ; faire plusieurs mises en page très différentes
pour le même HTML, c'est pas évident et ça limite les possibilités
- une mise en page doit être adaptée à la structure du site ; pour
Zen Garden ce n'est pas compliqué, y a trois textes qui se battent
en duel (et tu vois que déjà certaines CSS utilisent des images à place de
certains titres de "rubriques"...) ; pour un vrai site, il est difficile
de maintenir plusieurs mises en pages distinctes qui collent toutes à la
structure du site.
Je pense qu'il serait carrément plus utile de faire différents jeux
de feuilles de style, ou de squelettes, indépendant(e)s.
a+
Antoine.
Je ne suis pas convaincu de l'utilité du "style switcher" en soi.
Pour plusieurs raisons :
- un site Web cherche à avoir une mise en page, pas plusieurs
Tout à fait d'accord. Le but d'intégrer un "sélecteur de style" n'est pas
tant d'offrir aux visiteurs des styles différents (ceci n'étant qu'une
option possible), mais plutôt de faciliter la vie au concepteur:
1. En pouvant gérer les feuilles de styles de TOUS les squelettes d'un site
à partir d'un seul fichier (donc inclusion).
2. De permettre, en phase d'expérimentation ou de développement au
concepteur de basculer à un autre jeu de feuilles de styles, sans
compromettre le site existant et sans nécessairement offrir aux visiteurs la
possibilité de les choisir. Pour activer le tout, on n'aurait qu'à changer
"Alternate Stylesheet" par "Stylesheet" à un seul endroit.
3. On pourrait facilement faire basculer les feuilles de styles
contextuellement (par BOUCLE) selon le secteur ou la rubrique, sans devoir
se taper un nouveau squelette (pour simplement changer la palette de
couleur, par ecxemple). Pour un périodique en ligne, on pourrait même faire
basculer par BOUCLE la palette de couleur basé sur une date de sortie.
4. Quant aux options pour les visiteurs (si, et seulement on désire utiliser
cette option), ça pourrait se limiter à fort peu de chose, du genre: voir
avant d'imprimer, typo +, typo -... Si on en veut plus tout le mécanisme
serait en place.
- même avec une feuille de style, le HTML n'est pas indépendant de
la mise en page (imbrication et ordre des <div> - très important
pour les "float" -, etc.) ; faire plusieurs mises en page très différentes
pour le même HTML, c'est pas évident et ça limite les possibilités
pour un vrai site, il est difficile
de maintenir plusieurs mises en pages distinctes qui collent toutes à la
structure du site.
C'est là effectivement le dilemme de tout le projet. Aucun jeu unique de
squelette couplé à un réservoir de feuilles de styles ne peut convenir à
toutes les situations. Notamment, comme tu le signales, le flux
d'information doit être adaptée à la sémantique du site.
Mais, une fois cette sémantique établie et le code HTML qui la structure
développé (donc le jeu de squelette adapté), la constitution d'un réservoir
de feuilles de styles pour ce jeu de squelettes pourrait s'avérer
intéressant:
À la base, SPIP impose déjà une certaine sémantique, souple, mais présente
tout de même: ce n'est pas un portail de commerce en ligne.
Plusieurs types de sites partagent sensiblement la même sémantique et
souvent même, la même taxonomie: ONG internationales multilingues,
périodiques en lignes, sites de militants ou d'activistes, sites
pédagogiques, sites catalogues ou bibliographiques, carnets personnels (type
weblog), "open publishing", etc... Il y aurait toujours des adaptations
nécessaires, mais au moins ça fournirait à plusieurs un bassin pour partir
avec diverses options de présentation.
- une mise en page doit être adaptée à la structure du site ; pour
Zen Garden ce n'est pas compliqué, y a trois textes qui se battent
en duel (et tu vois que déjà certaines CSS utilisent des images à la place de
certains titres de "rubriques"...) ;
Bonne remarque. Mais ce site est un exercice de style. En passant, les
images sont tout à fait optionnelles, le texte et là dans le HTML, caché par
la feuille de style, si tu vires la feuille de style, il apparaît soudain.
Je pense qu'il serait carrément plus utile de faire différents jeux
de feuilles de style, ou de squelettes, indépendant(e)s.
L'un n'empêche pas l'autre. En fait, les ccs (et les quelques images
associées) pourraient se constituer en branches d'un même jeu de squelettes.
Je songe ici, par exemple, à se qui se développe autour d'EVA et SPIP-EDU.
Mais bon, c'est assez, je vais m'en coder et complèter tout au moins la
démonstration de la chose.
Et merci pour les remarques, ça replace les choses en perspective et ça
pointe très justement les limites d'un tel projet.
En attendant, si vous désirez suivre le projet:
http://speca.lautre.net
http://edu.ca.edu
Le même jeu de squelettes et des feuilles de styles sur 2 sites différents
(et 2 serveurs différents). Un seul mot dans un seul fichier est différent:
entete.html ainsi que 2 images différentes en haut, mais portant le même nom
sur les 2 sites. En fait, je songe à placer les feuilles de styles et les
images des gabarits sur un troisième serveur, question d'illustrer la
souplesse de la chose. Le design est moche et les css mal structuré et
redondant, mais ça marche et c'est en développement. Après ça le tutoriel.
La clef de l'affaire repose sur le remplacement dans les squelette de base
des deux lignes </head> et <body> par <INCLURE (entete.php3)> et 4 fichiers
- entete.php3 - n'a rien de particulier, c'est un simple appel de squelette
- entete-dist.php3 - il reprend seulement les lignes que nous avons enlevé
des squelettes, au cas où...
- entete.html - c'est là en fait que tout se passe, c'est aussi en
développement. En fait, j'aimerais bien éviter d'ajouter une division
d'entête (après le <BODY> et m"en tenir aux squelettes de base. Ou
carrément, comme le suggérait Fil, développer un nouveau jeu de squelettes.
- /js/styleswitcher.js - c'est le moteur de bascule des feuilles de style,
on n'y touche pas; j'en ai choisi un qui ne fonctionne pas dans Netscape 4
et c'est bien ainsi...
André Vincent
Le site CLX, http://clx.anet.fr/spip , propose un tel "style switcher"
pour SPIP. Comment ? Tout simplement en utilisant les "alternate
stylesheet" définis par la norme HTML 4.0. Détail amusant, il utilise en
partie des styles d'autres sites....
Bien sûr, c'est juste fait pour jouer. Ce n'est pas encore opérationnel
en tant qu'alternative sérieuse.
Bien sûr, il faut avoir un navigateur compatible, comme mozilla ou
firebird.
Si un graphiste souhaîte jouer avec des CSS, ce qui semble être le but,
autant ne pas réinventer un système jaja qui sera de toutes façons
périmé rapidement, dans la mesure où la fonctionnalité existe déjà, et
est normalisée. Antant jouer avec un navigateur respectueux des nores
(et non standards), et ensuite le passer à la validation sur d'autre
bouzins... Firebird, ce n'est pas lourd, hein. Et ça existe sur toutes
les plateformes mozilla (*nix, *nux, *bsd, *dows, MacOS*)
Par contre, pour le "repository", bien sûr, c'est une idée
intéressante...
A+
Le site CLX, http://clx.anet.fr/spip , propose un tel "style switcher"
pour SPIP. Comment ? Tout simplement en utilisant les "alternate
stylesheet" définis par la norme HTML 4.0. Détail amusant, il utilise en
partie des styles d'autres sites....
Oui, mais vas-y pour trouver l'option correspondante dans le navigateur.
Avec Firebird, je cherche toujours...
a+
Antoine.
C'est vrai. C'est un plugin,
"link toolbar", qui devrait être obligatoire.
si, regarde dans le code du cadre, il y a bien :
$<span class="spip_surligne">auteur_session au lieu de $auteur_session.
Bon, ce petit bug est réglé (un peu salement) dans la version CVS.
-- Fil
Comme j'ai eu un peu de mal à le trouver, je mets le lien qui va bien à
:
http://clx.anet.fr/spip/article.php3?id_article=165#forum4554
soit pour les impatients :
http://texturizer.net/firebird/extensions.html#Link%20Toolbar
Bien vu Gaétan :-))
Bonjour je tombe sur la discussion au hasard de recherches...
Salut,
Objectif: dans la même veine que "CSS Zen Garden", à partir d'un jeu
unique
de squelettes SPIP, constituer un réservoir de feuilles de styles
alternatives parmi lesquelles un webmestre pourrait puiser ou qu'il
pourrait
offrir comme choix aux visiteurs (à la manière openweb.eu.org).
Bravo je trouve cette idée géniale ! Si besoin je peux essayer de fournir de
l'aide sur ce projet.
Je suis aussi en train de m'y essayer (disons que j'ai eu la même idée),
mais je commence lentement en reprenant le jeu de squelette de la
distribution
- pour enlever toutes références de style dedans
- pour y ajouter toutes les balises SPIP possibles afin d'en faire un super
exemple complet
Comme je suis pas spécialement pro XHTML/CSS je vais pas aller vite.
Je ne suis pas convaincu de l'utilité du "style switcher" en soi.
Pour plusieurs raisons :- un site Web cherche à avoir une mise en page, pas plusieurs
... quel rapport ? il s'agit d'une démonstration de ce qu'on peut faire, ce
n'est pas pour appliquer a un même site (quoique certains font des sites
persos melting-pot qui vivraient très bien avec de multiples combinaisons de
design)
- même avec une feuille de style, le HTML n'est pas indépendant de
la mise en page (imbrication et ordre des <div> - très important
pour les "float" -, etc.) ; faire plusieurs mises en page très différentes
pour le même HTML, c'est pas évident et ça limite les possibilités
On peut s'en libérer je pense, c'est justement ma problématique actuelle,
l'ordre des div, leur imbrication (surtout non imbrication en fait), ainsi
que la séparation du squelette en différents fichiers pour inclusion.
- une mise en page doit être adaptée à la structure du site ; pour
Zen Garden ce n'est pas compliqué, y a trois textes qui se battent
en duel (et tu vois que déjà certaines CSS utilisent des images àplace de
certains titres de "rubriques"...) ;
C'est justement ça qui est bien ! si tu veux des images à la place des
titres pas de problèmes, et ça reste lisible, et comme on peut pas coller
directement une balise #LOGO_RUBRIQUE qui fasse tout ça ...
Ensuite un article spip c'est pas tellement plus que 3 textes qui se battent
en duel, c'est 5 groupes distinct pour moi :
#TITRE et ses amis
#DATE & #AUTEUR
#CHAPO
#TEXTE
#NOTES et #PS
une rubrique c'est du même acabit
le reste c'est des listes de liens (menu des rubriques, sites référencés,
autres articles dans cette rubrique...)
pour un vrai site, il est difficile
de maintenir plusieurs mises en pages distinctes qui collent toutes à la
structure du site.
Je ne suis pas aussi catégorique que toi, je crois qu'on peut s'en sortir
avec 2 ou 3 grandes structure :
- les sites associatifs / militants
- les fanzines
- les sites persos ou weblogs (celle là j'suis pas sur qu'elle soit très
développée)
en jonglant avec des squelettes spécifiques supplémentaires, voir par
sélection via mot clé comme le propose eva, on doit pouvoir couvrir tous les
besoins
Je pense qu'il serait carrément plus utile de faire différents jeux
de feuilles de style, ou de squelettes, indépendant(e)s.
De toute façon, au final, c'est ce que ça donneras ; des nouveaux squelettes
avec de nouvelles feuilles de styles !
Dorian
------------oO0o0Oo----------
::: http://www.3studio.org :::
"L'ennui est la seule excuse du travail" Jules Renard