28172 sujets
CSS et mise en forme, CSS3
Bonjour,
Tu peux tenter ceci:
Le problème (outre le fait que ça n'est pas supporté pour IE), c'est que de nombreux navigateurs ne te laisseront pas modifier la couleur de fond d'un select. La seule technique fiable pour styler un select est de... ne pas utiliser les éléments SELECT et OPTION, mais de les simuler avec des éléments HTML génériques (DIV, SPAN, etc.), du CSS, et pas mal de JavaScript. Ce qui est un peu lourd, pose des problèmes d'accessibilité, etc.
Tu peux tenter ceci:
option[selected=selected] {background-color: red;}
Le problème (outre le fait que ça n'est pas supporté pour IE), c'est que de nombreux navigateurs ne te laisseront pas modifier la couleur de fond d'un select. La seule technique fiable pour styler un select est de... ne pas utiliser les éléments SELECT et OPTION, mais de les simuler avec des éléments HTML génériques (DIV, SPAN, etc.), du CSS, et pas mal de JavaScript. Ce qui est un peu lourd, pose des problèmes d'accessibilité, etc.
Bonjour,
Le style de l'élément SELECT [selected=selected]est sans effet sur MAC pour firefox et safari....
Je suis assez curieux de savoir en quoi les <input> datent d'un autre âge juste parce que tu ne peux pas les styler ?
Comme le disais Florent tu peux aussi faire ça avec des div, des span , du javascript, de l'ajax et pourquoi pas le faire clignoter avec une video de Youtube qui passe en arrière mais....le propre de SELECT est de "sélectionner "et il fait parfaitement son travail .
Le style de l'élément SELECT [selected=selected]est sans effet sur MAC pour firefox et safari....
Je suis assez curieux de savoir en quoi les <input> datent d'un autre âge juste parce que tu ne peux pas les styler ?
Comme le disais Florent tu peux aussi faire ça avec des div, des span , du javascript, de l'ajax et pourquoi pas le faire clignoter avec une video de Youtube qui passe en arrière mais....le propre de SELECT est de "sélectionner "et il fait parfaitement son travail .
pourquoi faire un tel boulot et en plus utiliser du javascript qui peut être désactivé ? il est bien evident que le vieil html a besoin d'un coup de plumeau
il suffirait tout simplement que ces elements qui marchent très bien puissent se modifier en css
je ne suis pas sous mac mais sous windows et je n'obtiens pas de fond rouge avec ce code
il suffirait tout simplement que ces elements qui marchent très bien puissent se modifier en css
je ne suis pas sous mac mais sous windows et je n'obtiens pas de fond rouge avec ce code
rufus_ a écrit :
pourquoi faire un tel boulot et en plus utiliser du javascript qui peut être désactivé ? il est bien evident que le vieil html a besoin d'un coup de plumeau
La la la...
http://xulfr.org/wiki/XForms
rufus_ a écrit :
il suffirait tout simplement que ces elements qui marchent très bien puissent se modifier en css
Sauf que «se modifier» (c'est-à-dire, ici, modifier l'apparence), lorsqu'on parle d'éléments qui sont avant tout des widgets système aux formes complexes, c'est loin d'être une évidence! Quelles propriétés doivent s'appliquer, de quelle manières? Est-ce qu'un background-color sur un SELECT doit supprimer toute mise en forme de type image du SELECT, ou bien doit conserver l'aspect du widget et en colorer certaines parties et pas d'autres (ce qui peut être très chaud à gérer...)? Et faut-il appliquer ce même style du SELECT pour un SELECT à lignes multiples?
L'option retenue par les éditeurs de navigateurs est la suivante:
- certains contrôles de formulaire sont des widgets graphiques qui ne peuvent pas être modifiés, ou alors que de manière marginale;
- d'autres sont des widgets graphiques qui, lorsqu'on utilise certaines propriétés CSS, sont transformées en boites CSS classiques (à quelques nuances près ).
Le deuxième mécanisme, c'est celui des champs texte notamment. L'appliquer à des éléments plus complexes comme des SELECT ou des boutons radio n'est pas une mince affaire, et serait plutôt inutile en l'absence de spécification permettant d'harmoniser tout ça.
rufus_ a écrit :
il faut bien sur des spécifications , mais ce n'est pas si complique que ça
Si, élaborer des spécifications EST compliqué. Et demande un travail énorme: conception d'un premier jet, appel à commentaire, deuxième jet, appel à commentaire, écriture de tests (plusieurs milliers pour certaines spécifications), premières implémentations, corrections éventuelles de la spécification...
rufus_ a écrit :
pour les XForms quels navigateur les reconnait ? on verra dans 10 ans
Il y a des applications possibles aujourd'hui de XForms, même si ça n'est pas sous la forme «code HTML lu directement par le navigateur», mais plutôt des applications côté serveur, des conversions automatiques XForms -> HTML+JS, et des clients passant par des plugins (Flash, notamment).
Ma réponse visait surtout à montrer qu'il y a un travail effectué dans ce domaine depuis plusieurs années. Quoique XForms vise plus la modélisation des formulaires que leur mise en forme (à l'exception de l'attribut appearance, utilisé par Mozilla -- via une implémentation de test avec -moz-appearance -- pour l'affichage de certains éléments de formulaires dans Firefox 3).
Côté mise en forme pure, il y a bien quelques nouvelles pseudo-classes en CSS3 qui apportent plus de possibilités (modulo les implémentations):
http://www.css3.info/styling-forms-with-css3/
Mais je ne crois pas que ça corresponde à ton besoin.
Dans l'essentiel, les éditeurs de navigateur ont tendance à viser des éléments de formulaire qui utilisent l'apparence des widgets système. Ce qui n'est pas idiot d'un point de vue ergonomique. J'ai peur que la capacité de styler précisément (ou tout court) les éléments SELECT ne soit pas dans leurs priorités.
Modifié par Florent V. (01 Nov 2008 - 18:42)
rufus_ a écrit :
quel manuel ?
La spécification XForms 1.1 ou les différentes pages publiées par le groupe de travail Forms du W3C.
rufus_ a écrit :
pourquoi perdre du temps avec des trucs a venir
Je ne vais pas perdre de temps à répondre à cette question.
Bon allez, si, rapidement: pour se coucher moins bête et avoir une vue d'ensemble des possibilités actuelles et futures. Parce que si on se fout de ce qui est à venir on risque fort de louper en même temps des choses tout à fait utilisables dans le présent, ou utilisables dans certains contextes précis. Parce que la compétence demande de la connaissance. Parce qu'IE6 disparait progressivement et qu'il devient possible d'utiliser certaines techniques considérées par beaucoup comme «à venir» jusqu'ici... ceux qui se sont intéressés aux techniques futures les maitrisent déjà, et sont donc plus compétents (ou du moins plus experts) que leurs collègues qui ont reporté leur attention dès que ça ne marchait pas sous IE6.
Bien entendu, le temps à investir dans le «futur» dépend du niveau d'expertise que l'on souhaite atteindre.
Modifié par Florent V. (01 Nov 2008 - 18:50)