Author: marcimat-GANU6spQydw@public.gmane.org
Date: 2008-06-25 01:03:29 +0200 (mer, 25 jun 2008)
New Revision: 11871
Log:
2 choses :
- ajout du formulaire_ecrire_auteur en CVT
- modification de la structure et de la présentation des formulaires d'édition
* Le formulaire ecrire auteur a une petite différence avec ce qu'il y avait précédemment : on ne peut pas changer le statut dans l'édition, mais simplement après la validation (les 2 étaient possible avant), et cela car le javascript qui gère le statut ne permet de gérer dans la page qu'un seul bloc de changement de statut, or, ces changements impliquent qu'il en faudrait 2 en même temps (l'un est hidden quand l'autre est actif)
* La modification de la structure (surtout du nom des classes) et de la présentation des formulaires vise 2 choses : - alléger visuellement l'interface
- fournir des classes css permettant de styler indépendament chaque champ
Cet essai de nouvelle structure n'a plus besoin du javascript pour le inline-block, peut ne pas avoir de premier fieldset, conserve le chainage ul/li, et chaque li possède une classe indiquant le type de champ de formulaire (exemple : li.editer_titre)
On essaie au maximum de ne pas donner de styles graphiques aux champs de formulaires pour qu'ils gardent l'apparence de celle donnée par le navigateur par défaut, dont les utilisateurs sont habitués.
Par ailleurs, voici une ébauche d'explication de la structure; remarques bienvenues...
---- Proposition de formulaires ----
Un formulaire commence par une div expliquant ce qu'il est.
Il comporte une classe avec le nom de l'objet, et une autre avec
l'id de l'objet en plus de son nom :
Par ailleurs, voici une ébauche d'explication de la structure; remarques bienvenues...
Je trouve ça vraiment super tout ce qui a été fait.
Sauf... je ne suis toujours pas d'accord sur le nom des classes : pourquoi diable faire des noms à rallonge "editer_titre", etc, alors que CSS permet de faire "editer titre", ce qui permet dans les styles de mettre "li.editer.titre" d'une part, mais qui permet d'autre part de pouvoir mutualiser certains styles pour "tous les editer" ou "tous les titre", etc.
C'est quand même plus propre et plus clair ensuite dans la CSS, non ?
Non ca n'est pas pertinent si on prend la peine d'y réfléchir 2secondes
Dans la pratique
.titre sert a styler le rendu d'un titre, et porte donc nombre d'enrichissements stylistiques dont on n'a que faire dans un formulaire d'édition.
Dans ce que vous proposez, on ecrira deux fois plus de css pour annuler les styles de rendu dans les formulaires de saisie, puisque li.editer.titre heritera d'abord de li.titre
Au lieu de simplifier, on ne fera que complexifier les css.
Cédric
On ne parle pas CSS comme on parle français. En l'occurrence, les appellations simples constituée d'un seul mot, sont à l'usage bien plus confusionnantes. Des appellations complètes limitent les erreurs.
Euh... j'ai réfléchi déjà plus de 2 secondes lors de la discussion précédente, je te rassure, mais il semble que je n'ai pas été limpide dans mes explications.
Avec notre méthode, il suffit d'avoir un div englobant avec une classe "editer" ou "visualiser", et on pourra différencier très simplement ".editer .titre" et ".visualiser .titre", tout en pouvant donner des caractéristiques communes avec seulement ".titre".
Avec votre méthode, ce sera beaucoup plus pénible, notamment pour éviter les coquilles dans les noms de classes vu que le nom de l'une inclue les noms de toutes ses "mères" en cascade.
Bon, après, du moment que ça nous laisse toujours libre sur le front, peu importe, faites comme vous voulez.
Ouais, c'est ce que j'ai longtemps fait et c'est nettement plus difficile à maintenir sur la durée. Une foultitude de petites class hyper polysémiques (chacun y comprend ce qu'il veut, les associe en tout sens, s'étonnant que le CSS ne suive pas, oh, comme c'est étrange), c'est le meilleur moyen d'aboutir un beau bordel reprisé de partout et incompréhensible d'ici un an.
Personnellement, ce n'est pas comme cela que je conçois un projet logiciel en équipe.
Avec notre méthode, il suffit d'avoir un div englobant avec une classe "editer" ou "visualiser", et on pourra différencier très simplement ".editer .titre" et ".visualiser .titre", tout en pouvant donner des caractéristiques communes avec seulement ".titre".
Ouais, c'est ce que j'ai longtemps fait et c'est nettement plus difficile à maintenir sur la durée. Une foultitude de petites class hyper polysémiques (chacun y comprend ce qu'il veut, les associe en tout sens, s'étonnant que le CSS ne suive pas, oh, comme c'est étrange), c'est le meilleur moyen d'aboutir un beau bordel reprisé de partout et incompréhensible d'ici un an.
Il n'y a pas franchement beaucoup de monde qui bosse sur le core de SPIP, donc j'ai du mal à voir comment ça pourrait être plus compliqué que votre méthode, mais une fois de plus « faites comme vous voulez », je ne vais pas me battre.
oui mais la ce sont des formulaires utilisables dans le public
tout le monde peut mettre #FORMULAIRE_EDITER_ARTICLE dans son squelette public
et heritera alors de sa css qui est, a n'en pas douter, trufée de styles sur les .titre, .chapo, .texte, .ps etc ... dont il serait *vraiment* malvenu d'hériter ici
Cédric
Sauf que ".editer .titre { }" étant plus spécifique que ".titre { }", il n'y a pas ce risque sur les propriétés identiques. Il y a certes d'éventuels soucis sur les propriétés définies dans le ".titre { }" de la dist et celui de l'utilisateur, et cela selon l'ordre de chargement des CSS, mais je pense qu'il y a moyen de limiter les propriétés de ce type.
Je trouve dommage de montrer un usage des CSS n'en exploitant pas pleinement les riches possibilités, et incitant à reproduire dans le HTML et les CSS une soupe de classes.
Une foultitude de petites class hyper polysémiques
c'est vrai ça.
C'est pas évident de faire simple et "toujours valable".
ça se baserait sur des "conventions"
mais seraient elles toujours reliées à des caractéristiques objectives
facilement délimitables ?
editer_titre, c'est plus lourd apparament,
mais c'est plus difficile de se leurrer avec.
oui mais ca ne veut pas dire que p.toto.titi n'est pas compris par IE6, juste que le p.titi qui arrive apres le surcharge.
Les doubles classes marchent sous IE, a la seule condition que bien les utiliser dans le meme sens que dans leur declaration dans l'attribut class, et en faisant attention aux priorités des surcharges?
Non, pas sous IE6...
Je te donne un autre exemple plus compréhensible :
