Comment normalisons nous les formulaires. Je vois qu'ils restent
encore dans la dist/ les formulaires ne sont pas tous normalisé.
Mais avant de le faire faut il savoir quel normalisme utilisé. Nous
avons deja eu des échanges sur la listes mais rien de validé.
Il serait bon que nous mettions en place une normalisation que nous
publierons sur spip.net pour dire comment on doit faire et nous servir
de référence.
Par rapport à ces 2 sites, en plus des classes obligatoire et
erreur_message, j'ajouterai une classe "aide" ou "explication"
Que pensez vous qu'on initie un article sur spip.net qui nous servent
de référence ?
Ce document on le ferait bien sur évoluer en fonction de retours que
nous pourrions rencontrer à l'usage.
Comment normalisons nous les formulaires. Je vois qu'ils restent
encore dans la dist/ les formulaires ne sont pas tous normalisé.
Mais avant de le faire faut il savoir quel normalisme utilisé. Nous
avons deja eu des échanges sur la listes mais rien de validé.
Il serait bon que nous mettions en place une normalisation que nous
publierons sur spip.net pour dire comment on doit faire et nous servir
de référence.
Par rapport à ces 2 sites, en plus des classes obligatoire et
erreur_message, j'ajouterai une classe "aide" ou "explication"
Que pensez vous qu'on initie un article sur spip.net qui nous servent
de référence ?
Ce document on le ferait bien sur évoluer en fonction de retours que
nous pourrions rencontrer à l'usage.
Non, du tout !
- formfx est un fork de cmxform, utilisé différemment (et je pense que c'est une erreur, de renommer, comme de forker)
- pour ce que j'ai vu, la nomenclature actuellement utilisé pour les formulaires de l'espace privé ne suit pas la nomenclature que j'ai suggérée
Oui il y a des variantes entre ce que propose tetue, ce qui existe dans spip.
Du coup il est bien difficile de savoir dans quel sens aller d'où
cette suggestion d'article de références répondant au besoin de SPIP.
Le bazar n'est pas stable mais il faut bien qu'on est un point de
convergence et/ou de référence.
La documentation permettra de savoir :
-* où on en est
-* de structurer avec le temps ce bazar
Car comme ça on peut permettre à tout un chacun de se dire je prends
la recommandation SPIP pour les formulaires. çCa rebondit entre autre
aux remarques concernant les forms CFG qui n'ont pas le look spipiens.
Dans tous les cas pour juillet il faudra bien avoir une doc, donc
autant commencé maintenant.
La structure est celle ultra-classique d’un formulaire dans lequel on place bien des pour champ champ, et c’est grosso-modo tout. La différence avec ce qu’on a actuellement (“formfx”), c’est qu’il ajoutent un fieldset pour absolument chaque entrée. Fieldset qui ne nous sert à rien.
Là-dessus, il ajoutent un formfx.js, dont la seule utilité me semble-t-il est de ne pas insérer dans le CSS la simple ligne:
-moz-inline-box: block;
(genre pour faire du CSS compliant?). Bref, ça charge et ça déclenche un Javascript dont je ne pige pas l’utilité du tout.
Pour moi:
– la structure formfx est simple, c’est la même que cmxform, sauf qu’on n’ajoute pas un niveau de fieldset supplémentaire (niveau qui ne sert à rien: il y a le pour tout emballer, et les
pour chaque ligne; ça commence déjà à faire du monde).
– comme c’est pas cmxform, autant ne pas prendre le même nom.
– pas besoin du javascript, à moins qu’on en trouve l’utilité réelle. D’après list apart, j’ai bien l’impression qu’il s’agit de faire simuler -moz-inline-box en le balançant dans un long javascript plutôt qu’en une ligne de CSS.
=> Sinon, qu’on récupère des grosses bibliothèques toutes faites pour les gros trucs, genre jquery, bien sûr bonne idée. Mais là c’est pas le cas. C’est un bête formulaire tout con. Alors faire notre propre tambouille, ça n’est ni réinventer la roue, ni bien compliqué. Sinon c’est la première fois que j’entends parler de «forker» du code HTML :-))
Tout l'enjeu est d'avoir un html suffisamment générique pour permettre le stylage complet des formulaires en ne modifiant que les css là ou avant chacun forkait le squelette dans son coin pour des betes problemes de stylage
La structure est celle ultra-classique d'un formulaire dans lequel on
place bien des <label> pour champ champ, et c'est grosso-modo tout.
La structure d'un formulaire n'est pas ultra classique car nous
trouvons des propositions à base de listes, d'autre à base de
paragraphe, d'autre sans rien.
Sinon, qu'on récupère des grosses bibliothèques toutes faites pour les
gros trucs, genre jquery, bien sûr bonne idée. Mais là c'est pas le cas
L'intégration de formfx est pour le moment assez simple vu que c'est
une css restreinte et un bout de jquery.
(genre pour faire du CSS compliant?). Bref, ça charge et ça déclenche un
Javascript dont je ne pige pas l'utilité du tout.
Le jquery permet juste à Firefox d'afficher correctement le style
display: inline-block. Car de lui même, il est incapable de traiter
correctement le bouzin.
L'intérêt c'est de proposer une structure html cohérente pour
l'ensemble des formulaires. Il y a peu tu grognait contre CFG qui
gérait les formulaires sans standard SPIP. Or pour le moment nulle
part il y a de doc sur ce standard.
c'est qu'il ajoutent un fieldset pour absolument chaque entrée.
On n'ajoute pas à chaque entrée un fieldset. Il regroupe juste une ou
plusieurs entrées.
Après il faut savoir trier et prendre ce dont nous avons besoin, mais
nous avons besoin d'un standard sur la structure des formulaires entre
autre.
Cela améliorera la lisibilité du code html car une fois qu'on a
compris la logique on la retrouvera partout et limitera les surprises.
Actuellement ce n'est pas le cas.
OK, mais:
1. c'est bien ce que je dis,
2. c'est le cas des formulaires formfx que j'ai intégrés: ils sont normalisés selon cette méthode. Ensuite formfx ou cmxform, je dis qu'en gros c'est kif-kif, y'a pas à se prendre la tête bien longtemps pour du HTML à papa (tout le boulot pénible est dans les CSS). C'est rigoureusement le même principe.
=> En revanche, je répète que le javascript de cmxform n'a pour seule utilité que de faire bouffer inline-block à Firefox. Or, c'est ce que j'ai déjà fait, en indiquant directement dans la feuille de style:
display: -moz-inline-box;
display: inline-block;
Je suppose que le W3C n'aime pas (et encore, à vérifier). Mais ça fonctionne parfaitement, sans avoir à lancer un bout supplémentaire de jaja au chargement. Je pense qu'on s'en sortira beaucoup mieux pour la suite avec une ligne supplémentaire dans le CSS plutôt qu'avec le chargement d'un jaja qu'on ne saura plus ce qu'il fait dans 2 mois (parce que Firefox 3, lui, accepte le inline-block, je crois bien).
J'ai pas regardé si vous avez ajouté l'appel à cmxform.js dans l'espace privé. S'il y est, je n'y suis pour rien, et je pense que ça ne sert à rien.
=> C'est moi qui ait intégré formfx, suite au message de je ne sais plus qui; alors c'est pas la peine d'essayer de me convaincre là-dessus. Et formfx est peu différent de cmxform (que je trouve inutilement lourd), mais comme il l'est, j'ai changé de nom pour éviter les confuses.
OK, mais:[...]
=> En revanche, je répète que le javascript de cmxform n'a pour seule utilité que de faire bouffer inline-block à Firefox. Or, c'est ce que j'ai déjà fait, en indiquant directement dans la feuille de style:
display: -moz-inline-box;
display: inline-block;
J'ajoute mon petit grain de sel...
Ok avec Arnaud sur les faits que :
- le premier "fieldset" qui englobe tous les champs me semble inutile dans l'exemple de alistapart repris par Tetue.
- -moz-inline-box; dans une css ne me chagrine pas non plus, si le js ne servait effectivement qu'à ça.
Par contre 2 points :
- je suis pour éviter l'utilisation de 'gauche' et 'haut' dans les classes css qui indiquent un positionnement dans leur nom même qui pourrait être différent en css. Je crois que simplement avec un identifiant sur le li parent, on peut reproduire via CSS les gauche et haut pour ceux qui en auraient besoin.
- avec le temps, je trouve les graphismes proposés par Arnaud sont vraiment très chargés visuellement et pesants. J'aimerai bien que l'on essaie quelques temps ce que propose Romy pour se faire une idée (http://romy.tetue.net/interface/article_modifier.html)
Je rentre dans la danse un petit peu... Tetue, j'ai essayé ton formulaire (celui présenté ici : http://romy.tetue.net/interface/article_modifier.html) et j'ai rencontré des petits problèmes. Je suis reparti de ce que tu as fait, mais j'ai ajouté, en plus, une div après chaque label, qui entoure le contenu qui suit le label (explications, input, erreurs...) et cela me semble plus robuste.
Dans l'essai que j'ai réalisé, qui n'utilise pas de js mais simplement un float:left sur le label et une marge sur le div qui suit, les formulaires présentés (exception du premier sans les div) s'affichent correctement, quelque soit le navigateur (IE fait une exception en décalant la partie de droite vers le bas, mais c'est présentable)
Ici, les classes "obligatoire" et "erreur" (s'il y a une erreur sur ce champ) se positionnent sur le li, ce qui permet à la fois de styler le li, et le contenu du li différemment.
Je ne crois pas que ce soit une bonne idée car cela devient moins générique, meme si un peu plus facile à styler dans le cas de figure de présentation considéré.
Chaque element etant atteignable par un selecteur css, on peut arriver au meme résultat sans la div, sans alourdir la structure html.
Surtout, ici il manque des elements qui sont présents sur certains formulaires :
- aide
- mention 'obligatoire'
Si on commence à introduire une div parce que ca semble plus facile, chacun y ira de son fork parce qu'elle ne contient pas les elements souhaites (qui sortira l'erreur de la div, qui y ajoutera la mention 'obligatoire'), et cela va a l'encontre du résultat souhaité qui est d'avoir une structure html unique.
J'ai utilisé cmxforms sur plusieurs projets en dehors de Spip, et la structure proposée par tetue, qui enrichie la proposition initiale de cmxforms de quelques class permet vraiment de couvrir tous les cas de figures en css pure.
moi je rajouterai juste une remarque du point de vue de l'accessibilité, il serait mieux que le message indiquant qu'il y a une erreur sur le champ soit juste après le label et non après le champ lui même. Le sens de lecture de l'information en serait plus logique.
Ici, les classes "obligatoire" et "erreur" (s'il y a une
erreur sur ce
champ) se positionnent sur le li, ce qui permet à la fois de
styler le
li, et le contenu du li différemment.
le nouvel ajax de SPIP (dit CVT) positionne la fenêtre en haut du bloc rechargé en ajax, il suffit donc de mettre ce message en haut, je pense. Et en effet les formulaires de Barack Obama assurent
Ca serait sympa de faire un plugin qui offre un filtre permettant d’insérer les aux bons endroits (et c’est ça qui est délicat : il doit exister des librairies déjà, j’imagine, qui dépendent de la langue du contenu) ; pour ma part je l’utiliserais sur des colonnes très étroites, par exemple pour un sommaire en page d’accueil (mais évidemment pas sur un texte normal installé dans une grande largeur, où le fer à gauche est ce qu’il y a de plus lisible).
