Bonsoir
Je constat que le nombre de colonne n’est pas pris en compte et que le nombre de ligne oui.
Pierre
Le 20/04/2010 19:00, Pierre KUHN a écrit :
Bonsoir
Je constat que le nombre de colonne n'est pas pris en compte et que le
nombre de ligne oui.Pierre
Mais encore ?
Si je lis l'explication de l'option, je trouve : "Cette option n'est pas toujours appliquée car les styles CSS de votre site peuvent l'annuler."
C'est peut-être tout simplement le cas.
© chez-moi-ça-marche.
--
RastaPopoulos
Bonsoir
Regarde en bas de http://dev.festivaldepaques.org/Offres-pour-groupes , chez moi le champs prend toutes la page mais si c’est une option pas toujours appliquer ça devais ennuyant alors
Pierre
Le 20 avril 2010 20:53, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 20/04/2010 19:00, Pierre KUHN a écrit :
Bonsoir
Je constat que le nombre de colonne n’est pas pris en compte et que le
nombre de ligne oui.Pierre
Mais encore ?
Si je lis l’explication de l’option, je trouve : « Cette option n’est pas toujours appliquée car les styles CSS de votre site peuvent l’annuler. »
C’est peut-être tout simplement le cas.© chez-moi-ça-marche.
–
RastaPopoulos
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 20/04/2010 20:59, Pierre KUHN a écrit :
Bonsoir
Regarde en bas de http://dev.festivaldepaques.org/Offres-pour-groupes ,
chez moi le champs prend toutes la page mais si c'est une option pas
toujours appliquer ça devais ennuyant alors
Ben je vois pas trop ce qu'il y a d'ennuyant :
1) Ça n'a rien de spécifique à ce plugin, c'est juste la propriété cols="40" de la balise HTML textarea
2) Les propriétés rows et cols des textareas ont toujours été surchargées par les propriétés venant des CSS
3) Enfin, dans l'explication de l'option, il est indiqué clairement par avance que ça pourra ne pas être appliqué suivant les styles CSS du site
Sur ton site, moi je vois immédiatement :
.formulaire_spip textarea{
width:99%;
}
Ça fait bien ce que tu demandes.
--
RastaPopoulos
Ba justement moi je l’ai mis a 40 et non à 99% donc je conclu que le 40 est pas pris en compte.
Désolé du dérangement
Pierre
Le 20 avril 2010 21:36, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 20/04/2010 20:59, Pierre KUHN a écrit :
Bonsoir
Regarde en bas de http://dev.festivaldepaques.org/Offres-pour-groupes ,
chez moi le champs prend toutes la page mais si c’est une option pas
toujours appliquer ça devais ennuyant alorsBen je vois pas trop ce qu’il y a d’ennuyant :
- Ça n’a rien de spécifique à ce plugin, c’est juste la propriété cols=« 40 » de la balise HTML textarea
- Les propriétés rows et cols des textareas ont toujours été surchargées par les propriétés venant des CSS
- Enfin, dans l’explication de l’option, il est indiqué clairement par avance que ça pourra ne pas être appliqué suivant les styles CSS du site
Sur ton site, moi je vois immédiatement :
.formulaire_spip textarea{
width:99%;
}Ça fait bien ce que tu demandes.
–
RastaPopoulos
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 20/04/2010 21:41, Pierre KUHN a écrit :
Ba justement moi je l'ai mis a 40 et non à 99% donc je conclu que le 40
est pas pris en compte.Désolé du dérangement
Tu as lu ma réponse ?
Tu as mis 40 dans cols *ET* 99% dans ta feuille de style. Si tu ne connais pas les styles que tu utilises sur ton propre site, tu peux utiliser par exemple l'extension Firebug pour les visualiser.
Et je t'ai expliqué que la feuille de style prend *toujours* le dessus sur la propriété écrite dans le HTML.
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
Si tu veux que ça prenne en compte ta valeur :
- soit tu supprimes .formulaire_spip textarea{ width:99%; }
- soit tu mets width:auto; dedans (mais dans ce cas ça vaudra pour tous les formulaires spip)
- soit tu ajoutes .formulaire_formidable textarea{ width:auto; }
Enfin bref : c'est du travail de CSS, exactement comme l'explique déjà la phrase décrivant l'option dans l'interface.
--
RastaPopoulos
Le 20 avr. 2010 à 23:11, RastaPopoulos a écrit :
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
-Nicolas
--
Nicolas HOIZEY
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Pas du tout ; c'est plutôt le contraire puisqu'on ne fatigue ni ne
perd ses visiteurs !
Mais encore une fois, on peut désactiver ces CSS si on préfère faire à
l'ancienne.
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Il y a plein de sites où les champs ont la même longueur sans que ça
paraisse inergonomique. C'est tout aussi vrai pour des formulaires en
ligne ou papiers où on a une ligne pour chaque renseignement, que ce
soit l'e-mail ou le code postal... L'usage de l'attribut "size" n'a de
toute façon pas de sens que tu crois : ce n'est pas parce-que tu
mettra à 10 par exemple que ton e-mail ne pourra pas y rentrer (à part
que les usagers auront du mal à se relire) et ce n'est pas parce-que
tu mettra du 5 que ce sera limité aux codes postaux français : ce
pouvoir est réservé à l'attribut "maxmaxlength"...
Le 21/04/2010 07:41, Nicolas Hoizey a écrit :
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Ben oui mais ça n'a rien à voir avec ce plugin ou avec le HTML : si *toi* tu penses que la taille des champs à un sens pour ton site, bah tu modifies pas l'attribut "width" en CSS, ou bien tu le mets explicitement à "width:auto;".
--
RastaPopoulos
Le 21 avr. 2010 à 08:22, Gildas Cotomale a écrit :
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Pas du tout ; c'est plutôt le contraire puisqu'on ne fatigue ni ne
perd ses visiteurs !
Avec un champ qui fait visuellement toute la largeur, alors que tu as prévu de la place pour 5 chiffres, tu donnes une mauvaise indication à l'utilisateur, c'est une erreur ergonomique.
Mais encore une fois, on peut désactiver ces CSS si on préfère faire à
l'ancienne.Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Il y a plein de sites où les champs ont la même longueur sans que ça
paraisse inergonomique. C'est tout aussi vrai pour des formulaires en
ligne ou papiers où on a une ligne pour chaque renseignement, que ce
soit l'e-mail ou le code postal... L'usage de l'attribut "size" n'a de
toute façon pas de sens que tu crois : ce n'est pas parce-que tu
mettra à 10 par exemple que ton e-mail ne pourra pas y rentrer (à part
que les usagers auront du mal à se relire) et ce n'est pas parce-que
tu mettra du 5 que ce sera limité aux codes postaux français : ce
pouvoir est réservé à l'attribut "maxmaxlength"...
Euh... je connais HTML, merci. Je parle bien de taille d'affichage, définie par l'attribut "size".
-Nicolas
--
Nicolas HOIZEY
Le 21 avr. 2010 à 07:41, Nicolas Hoizey a écrit :
Le 20 avr. 2010 à 23:11, RastaPopoulos a écrit :
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Faux problème, puisque ça se fait en CSS 
Et en matière de rendu graphique des formulaires, moins on en fait en amont (dans les plugins notamment) mieux ce sera pour l'intégrateur (à condition qu'il dispose de sélecteurs CSS distinctifs suffisamment nombreux, ce qui est normalement le cas depuis SPIP 2, dans les formulaires générés par le système du moins : tout manquement est à signaler).
-- Romy
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Pas du tout ; c'est plutôt le contraire puisqu'on ne fatigue ni ne
perd ses visiteurs !Avec un champ qui fait visuellement toute la largeur, alors que tu as prévu de la place pour 5 chiffres, tu donnes une mauvaise indication à l'utilisateur, c'est une erreur ergonomique.
"visuellement ... indication ... ergonomique" : pour moi le problème
est mal posé car l'ergonomie n'est pas de faire du visuel et que
d'autre part la meilleure indication qu'on puisse donner est un label
parlant (éventuellement accompagné d'un paragraphe explicatif si le
label ne se suffit pas). mais bon, tout le monde veut utiliser le mot
ergonomie à sa sauce...
maintenant, cet exemple précis est plutôt mal choisi pour démontrer
quelque chose car c'est un peu absurde (à moins que tes visiteurs ne
viennent que de France ?) de prévoir de la place pour cinq chiffres en
guise de code postal (celui-ci peut comporter des lettres et peut
avoir plus de cinq caractères !)
Mais encore une fois, on peut désactiver ces CSS si on préfère faire à
l'ancienne.
Chacun sa problématique et RastaPopoulos a indiqué les façons de
traiter ce cas.
(nota : on peut tout aussi bien jouer de la taille en CSS et ciblant
précisément un élément par son identifiant)
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Il y a plein de sites où les champs ont la même longueur sans que ça
paraisse inergonomique. C'est tout aussi vrai pour des formulaires en
ligne ou papiers où on a une ligne pour chaque renseignement, que ce
soit l'e-mail ou le code postal... L'usage de l'attribut "size" n'a de
toute façon pas de sens que tu crois : ce n'est pas parce-que tu
mettra à 10 par exemple que ton e-mail ne pourra pas y rentrer (à part
que les usagers auront du mal à se relire) et ce n'est pas parce-que
tu mettra du 5 que ce sera limité aux codes postaux français : ce
pouvoir est réservé à l'attribut "maxmaxlength"...Euh... je connais HTML, merci. Je parle bien de taille d'affichage, définie par l'attribut "size".
j'entends et vois beaucoup limiter la taille des champs en pensant
restreindre ainsi la quantité de caractères saisis... si tu es
d'accord avec moi (et c'était un rappel et non un cours de HTML), tu
conviendras donc que ce n'est pas pratique de limiter un champ à cinq
caractère quand il peut en contenir plus : celui qui comme moi aime à
se relire avant de valider est emmerdé de voir sa saisie affichée de
façon tronquée surtout pour un truc court.
Le 21 avr. 2010 à 11:26, romy@rezo.net a écrit :
Le 21 avr. 2010 à 07:41, Nicolas Hoizey a écrit :
Le 20 avr. 2010 à 23:11, RastaPopoulos a écrit :
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Faux problème, puisque ça se fait en CSS
Non, justement, la discussion parle du constat que le "size" du champ n'est pas respecté à cause de la CSS...
Et en matière de rendu graphique des formulaires, moins on en fait en amont (dans les plugins notamment) mieux ce sera pour l'intégrateur (à condition qu'il dispose de sélecteurs CSS distinctifs suffisamment nombreux, ce qui est normalement le cas depuis SPIP 2, dans les formulaires générés par le système du moins : tout manquement est à signaler).
Sauf que le "size" doit bien être défini selon le type de contenu (sans non plus tomber dans le travers inverse avec que des champs de tailles différentes), donc pas de manière unique dans la CSS pour tous les champs.
-Nicolas
--
Nicolas HOIZEY
Le 21 avr. 2010 à 11:47, Gildas Cotomale a écrit :
Encore heureux d'ailleurs : quand on écrit un thème, on aime bien qu'il soit cohérent et que le premier créateur de contenu venu ne puisse pas casser toute la mise en page en mettant des tailles farfelues.
En l'occurence, décider une fois pour toutes en CSS de la taille des champs d'un formulaire, ça me semble inadapté.
Pas du tout ; c'est plutôt le contraire puisqu'on ne fatigue ni ne
perd ses visiteurs !Avec un champ qui fait visuellement toute la largeur, alors que tu as prévu de la place pour 5 chiffres, tu donnes une mauvaise indication à l'utilisateur, c'est une erreur ergonomique.
"visuellement ... indication ... ergonomique" : pour moi le problème
est mal posé car l'ergonomie n'est pas de faire du visuel
Je parle du visuel comme indication de la nature du contenu attendu.
J'avoue que je ne sais pas si les synthèses vocales et terminaux braille tirent parti de l'attribut "size".
et que
d'autre part la meilleure indication qu'on puisse donner est un label
parlant (éventuellement accompagné d'un paragraphe explicatif si le
label ne se suffit pas).
Evidemment.
mais bon, tout le monde veut utiliser le mot
ergonomie à sa sauce...
Euh...
maintenant, cet exemple précis est plutôt mal choisi pour démontrer
quelque chose car c'est un peu absurde (à moins que tes visiteurs ne
viennent que de France ?) de prévoir de la place pour cinq chiffres en
guise de code postal (celui-ci peut comporter des lettres et peut
avoir plus de cinq caractères !)
La plupart des développements de formulaires Web que j'ai fait depuis de nombreuses années ont été faits pour un public exclusivement français, oui.
Il est naturel (et donc intuitif, et ergonomique) dans ce cas de demander un code postal en prévoyant une limite de 5 caractères (attribut "maxlength", qui n'évite pas de contrôler ensuite côté serveur), et un affichage de 6 caractères (attribut "size"), pour que l'affichage du curseur en fin de ligne ne décale/masque pas le premier caractère.
Mais encore une fois, on peut désactiver ces CSS si on préfère faire à
l'ancienne.Chacun sa problématique et RastaPopoulos a indiqué les façons de
traiter ce cas.
(nota : on peut tout aussi bien jouer de la taille en CSS et ciblant
précisément un élément par son identifiant)
Mais pourquoi vouloir absolument définir une taille en CSS alors que la taille calculée par le navigateur tient compte de l'attribut "size" ???
Un champ où tu dois saisir un code postal aura la même taille qu'un champ où tu dois saisir une adresse e-mail par exemple, c'est une erreur ergonomique. Sinon, on ne s' « embêterait » pas à utiliser l'attribut "size" des input...
Il y a plein de sites où les champs ont la même longueur sans que ça
paraisse inergonomique. C'est tout aussi vrai pour des formulaires en
ligne ou papiers où on a une ligne pour chaque renseignement, que ce
soit l'e-mail ou le code postal... L'usage de l'attribut "size" n'a de
toute façon pas de sens que tu crois : ce n'est pas parce-que tu
mettra à 10 par exemple que ton e-mail ne pourra pas y rentrer (à part
que les usagers auront du mal à se relire) et ce n'est pas parce-que
tu mettra du 5 que ce sera limité aux codes postaux français : ce
pouvoir est réservé à l'attribut "maxmaxlength"...Euh... je connais HTML, merci. Je parle bien de taille d'affichage, définie par l'attribut "size".
j'entends et vois beaucoup limiter la taille des champs en pensant
restreindre ainsi la quantité de caractères saisis... si tu es
d'accord avec moi (et c'était un rappel et non un cours de HTML), tu
conviendras donc que ce n'est pas pratique de limiter un champ à cinq
caractère quand il peut en contenir plus : celui qui comme moi aime à
se relire avant de valider est emmerdé de voir sa saisie affichée de
façon tronquée surtout pour un truc court.
Mais justement, je parle uniquement de champs de taille limitée.
Pour les champs input de type "text" qui acceptent un nombre indéfini de caractères, ou impossible de toute façon à afficher sur une seule ligne de texte même si la taille est restreinte, on définira quand même une valeur de l'attribut "size" pour ceux qui n'ont pas les CSS, on pourra contrôler l'affichage avec des CSS (avec un 100% en gros, classiquement), ou on envisagera plutôt un textarea pour que tout le texte soit lisible sans scroller dans le champ texte, ce qui est très pénible...
-Nicolas
--
Nicolas HOIZEY
Le 21 avr. 2010 à 12:33, Nicolas Hoizey a écrit :
donc pas de manière unique dans la CSS pour tous les champs.
Non, car rien n'oblige à ce que ce soit de manière unique !!! [*]
Le CSS permet heureusement des rendus différents, champ par champ, indépendamment des attribut size du HTML, ce qui devrait satisfaire toutes les approches ergonomiques.
Si, pour cela, il manque des sélecteurs dans les formulaires générés par SPIP, il faut le signaler afin que ce soit amélioré.
[*] Le widht à 99% ou 100% imposé sur tous les champs par certains plugins ou reset CSS (dont spip_formulaires.css je crois) est une mauvaise pratique, qu'il ne faut pas tenir pour exemplaire car c'est une vraie plaie à surcharger !
-- Romy
Chacun sa problématique et RastaPopoulos a indiqué les façons de
traiter ce cas.
(nota : on peut tout aussi bien jouer de la taille en CSS et ciblant
précisément un élément par son identifiant)Mais pourquoi vouloir absolument définir une taille en CSS alors que la taille calculée par le navigateur tient compte de l'attribut "size" ???
il ne s'agit pas de faire tout en css puisque tu as le choix.
soit tu fais tout en css (perso, je préfère car tout ce qui est
visuel/présentation doit pouvoir être travaillé par le designer qui
travaille sur les feuilles de style) ; soit tu fait chacun au cas par
cas (ça marche tout aussi bien).
maintenant, quand on mélange, il faut faire attention aux effets de
bord (dans le cas présent, le style par défaut donne une certaine
taille à tous les champs textes)... qui souvent sont rattrapable avec
les css (je sais, le serpent se mord la queue)
[...]
Pour les champs input de type "text" qui acceptent un nombre indéfini de caractères, ou impossible de toute façon à afficher sur une seule ligne de texte même si la taille est restreinte, on définira quand même une valeur de l'attribut "size" pour ceux qui n'ont pas les CSS, on pourra contrôler l'affichage avec des CSS (avec un 100% en gros, classiquement), ou on envisagera plutôt un textarea pour que tout le texte soit lisible sans scroller dans le champ texte, ce qui est très pénible...
ça c'est le vieux problème du conflit entre les attributs HTML et les
propriétés CSS car la norme ne disait rien là-dessus (ça a peut-être
changé entre temps) et donc les navigateurs pouvaient gérer
différemment ces priorités... mais en générale, ce sont les css qui
l'emportent (et même pour eux, le problème se posent à cause des
effets de cascade où c'est le dernier qui l'emporte selon la norme).
c'est ce que tu dis justement : l'attribut "size" ne s'appliquera
qu'aux navigateurs qui ne savent pas interpréter les propriétés CSS
qui contredisent (ou pas) cela...
d'où le conseil de RastaPopoulos : tu désactive la gestion des tailles
desINPUT dans le CSS et tu peux faire mumuse à ta guise en HTML ou
alors, tu gardes les CSS génériques et tu spécifie (via les classes
et/ou les identifiants) comme le dit Romy 
Le 21 avr. 2010 à 13:26, Nicolas Hoizey a écrit :
Si, pour cela, il manque des sélecteurs dans les formulaires générés par SPIP, il faut le signaler afin que ce soit amélioré.
Prenons l'exemple de CleverMail utilisé sur SPIP 2.2.0-dev SVN [15560], dans la page de configuration :
<Capture d’écran 2010-04-21 à 13.10.41.PNG>
Le champ « Nombre de messages par envoi » attend un entier, donc entre 1 et 4 caractères (soit au maximum 9999 messages envoyés chaque minute) si on veut rester raisonnable. Je viens de me rendre compte grâce à notre discussion que j'avais laissé par erreur size="50" et maxlength="255"—un copier/coller malencontreux—mais corriger avec size="5" et maxlength="4" ne change rien à l'affichage, forcé à 96% de la largeur du parent par la CSS de SPIP.
Arf ! Je pensais à toutes sortes de situations, sauf celle de l'espace privé de SPIP... où des style="" en dur à l'ancienne, directement dans le HTML, s'imposent, évidemment. Désolée pour le bruit, j'ai encore perdu une occasion de me taire.
-- Romy
Le 21 avr. 2010 à 13:01, romy@rezo.net a écrit :
Le 21 avr. 2010 à 12:33, Nicolas Hoizey a écrit :
donc pas de manière unique dans la CSS pour tous les champs.
Non, car rien n'oblige à ce que ce soit de manière unique !!! [*]
Le CSS permet heureusement des rendus différents, champ par champ, indépendamment des attribut size du HTML, ce qui devrait satisfaire toutes les approches ergonomiques.
Je suis rassuré.
Si, pour cela, il manque des sélecteurs dans les formulaires générés par SPIP, il faut le signaler afin que ce soit amélioré.
Prenons l'exemple de CleverMail utilisé sur SPIP 2.2.0-dev SVN [15560], dans la page de configuration :
Le 21 avr. 2010 à 13:40, romy@rezo.net a écrit :
Arf ! Je pensais à toutes sortes de situations, sauf celle de l'espace privé de SPIP... où des style="" en dur à l'ancienne, directement dans le HTML, s'imposent, évidemment. Désolée pour le bruit, j'ai encore perdu une occasion de me taire.
Non, non, je pense qu'on peut aussi discuter de cela pour que ça évolue dans le bon sens !
-Nicolas
--
Nicolas HOIZEY
Le 21 avr. 2010 à 13:33, Gildas Cotomale a écrit :
Chacun sa problématique et RastaPopoulos a indiqué les façons de
traiter ce cas.
(nota : on peut tout aussi bien jouer de la taille en CSS et ciblant
précisément un élément par son identifiant)Mais pourquoi vouloir absolument définir une taille en CSS alors que la taille calculée par le navigateur tient compte de l'attribut "size" ???
il ne s'agit pas de faire tout en css puisque tu as le choix.
Non, dans l'exemple que je cite, d'un formulaire CVT utilisé dans l'espace privé, je n'ai pas le choix, c'est bien le soucis !
Côté public, nous sommes d'accord, c'est à celui qui fait l'intégration de choisir s'il veut hériter ou non des styles de la dist.
-Nicolas
--
Nicolas HOIZEY