Stylez-moi ce formulaire !
Après avoir essayé à plusieurs reprises et par tous les moyens de styler les éléments d’un formulaire html pour donner vie aux créations des graphistes, il a bien fallu se rendre à l’évidence : ce n’est pas possible ! Déjà les styles ne sont pas appliqués de façon identique selon les navigateurs, mais en plus ces éléments diffèrent selon les systèmes d’exploitation et leurs versions successives, CQFD.
Après avoir tenu ce discours : «Non les formulaires, on ne peut pas les styler, désolé» pendant des années, les webdesigners les plus tenaces sont revenus avec des exemples de sites en nous disant : «Tu me dis que c’est pas possible, mais là sur tel site, ils l’ont fait.»”
Ok, reprenons : styler des éléments de fomulaire html, ça ne donne pas un résultat terrible, mais… avec javascript on arrive à voir un résultat plutôt satisfaisant. La question est : faut-il utiliser du JS pour faire de la cosmétique ? Parce que la seule chose qu’on fait avec JS ce n’est pas styler des éléments de formulaires, mais au mieux cacher des éléments de formulaires (ou les rendre invisibles) pour leur substituer des éléments graphiques, au pire remplacer des éléments de formulaires par d’autres balises html qui elles pourront être stylées avec CSS. Par exemple, remplacer un select par une liste non ordonnée. Est-ce que le jeu en vaut la chandelle ? Est-ce qu’on va alourdir les pages et retarder leur affichage pour quelques effets que l’utilisateur ne remarquera même pas ?
La question que tout le monde se pose (ou peut-être qu’il n’y a que moi qui me la pose), c’est pourquoi on ne peut pas styler les éléments de formulaire ? Ok pour les input de type texte (et encore pas avec tous les navigateurs), mais pourquoi pas les listes déroulantes de type select, les cases à cocher ou autres boutons radio ? Y-a-t-il une raison à ça ou les fabricants de navigateurs, se sont dit : «oups, on a oublié les formulaires !» «Laisse tomber on va dire que c’est fait exprès.»
Argumentons dans le sens où c’est fait exprès : les internautes ont l’habitude de leur système d’exploitation, du coup ils vont toujours identifier ces éléments quelque soit le navigateur dans lequel ils sont, et ça en terme d’utilisabilité c’est imbattable ! Mouais, pas vraiment convaincant tout ça…
Est-ce qu’on se posait la question avant ? «Fais moi ça en flash c’est plus joli». Ce serait de la faute de flash, alors ? Toujours est-il qu’on trouve de plus en plus de plugins qui permettent de faire ça facilement, tentant, non ? J’en ai essayé deux ou trois, je vous donne mon avis :
- jQuery UI selectmenu
- Pas des plus facile à manipuler, mais très complet, il couvre largement le spectre des utilisations de menus avec des listes déroulantes. Trop de styles inline qui complique le skinning des css externes. A noter que ce plugin utilise les attributs ARIA pour l’accessibilité.
- jQuery UI checkbox
- Simplissime. Par exemple pour une case à cocher il suffit d’initialiser le script de cette façon
$('input').checkBox();
Et la case à cocher est remplacée par un span avec la classe “ui-checkbox”, il ne reste plus qu’à appliquer les CSS. - jQuery Stylish select
- Je ne l’ai pas testé personnellement, mais ça a été utilisé sur un projet récent dans ma boîte. Complètement customisable en CSS et ultra light.
- Uniform
- Je suis tombé sur celui-ci il y a quelques jours, il me parait assez complet et facilement skinnable, une image sprite pour tous les éléments (vous pouvez créer des thèmes et les proposer sur le site), une fois les éléments stylés la navigation au clavier me parait correcte, reste juste à mettre plus en avant le focus sur les éléments.
Après c’est vous qui voyez… Personnellement, je ne trouve pas ça indispensable, mais pourquoi pas si les contraintes de conception ne sont pas trop draconiennes.
Bon je repose ma question aux concepteurs de navigateurs : Pourquoi les éléments de formulaire ne peuvent être stylés de la même façon que les autres balises html ?
Les commentaires sont fermés sur cet article.
15 commentaires
Flux RSS des commentaires de cet article
Il devient possible en effet de tricher en mettant un élément de formulaire caché derrière une liste ordonnée ou une … afin de le styler. Et les web designers s’en donnent à coeur joie.
Question performance cela fait du coup beaucoup de code pour « faire beau » et on sacrifice du coup cette contrainte en rajoutant du js et du css en plus.
Il, n’est pas sur qu’au final l’utilisateur comprennent que ce qui est stylé est un formulaire, mais on disait la même chose il y a quelques années à propos des liens hypertexte qui devaient rester bleu.
C’est donc encore une fois une équation compliquée à mettre en place entre la charte graphique, l’ergonomie et l’accessibilité… Mais à un web designer têtu on pourra dire désormais oui c’est possible.
Le 17 Août. 2010 à 16h11 par Nicolas G
Raaah, vade retro, tu as prononcé le nom des éléments-dont-on-ne-doit-pas-prononcer-le-nom-quand-on-style-une-page.
(multiples prises de tête pour une solution parfaite… qu’on cherche encore)
Franchement, je me pose la question : est-il bien utile de chercher à styler à tout va, alors que les éléments sont effectivement mieux reconnus quand ils sont dans le layout natif de l’OS ? (les Mac-eux ont des effets aqua, les WP-iens ont un bouton gris tout moche, etc… et chacun s’y retrouve)
Le 17 Août. 2010 à 16h22 par Nico
La vraie question que je me pose depuis 10 ans, c’est pourquoi les navigateurs ne permettent pas de styler ces éléments (principalement les boutons radio, checkbox et input file). On peut « tout » faire avec une textbox. On peut même styler les scrollbars système dans Webkit. Alors sérieusement, pourquoi les navigateurs empêchent encore en 2010 de styler certains contrôles ?
Pour moi, à défaut d’avoir des solutions propres en CSS, mieux vaut ne rien faire. Donc mesdames et messieurs les graphistes, arrêtez de nous pondre des maquettes avec des checkbox folkloriques !
Le 17 Août. 2010 à 17h03 par HTeuMeuLeu
Je suis en plein dans la même problématique (une fois de plus) mais n’ayant pas le temps de faire de réelles recherches j’ai développé quelque chose rapidement.
Du coup cet article tombe à pic et je pense m’orienter vers Uniform qui semble plutôt complet dans son genre.
Merci !
Le 17 Août. 2010 à 17h10 par Duael
Sinon, y a css3 … qui donne de très bon résultats !
Extrêmement simple.
Pas lourd du tout.
« Compatible » Chrome, Firefox, Opera et Safari.
Bon, après faut abandonner IE mais bon c’est pas grave les « utilisateurs » de ce « navigateur » restent avec les formulaires de leur système d’exploitation.
Le 17 Août. 2010 à 18h08 par Petitgnome
@Petitgnome
Si tu as des exemples de formulaires entièrement stylés avec CSS3 et sans Javascript et qui donne un rendu équivalent dans Chrome, Firefox, Opéra et Safari, je pense que ça nous intéresse tous. Pour ma part je n’ai rien vu de tel lors de mes recherches sur le sujet.
Après pour la question d’IE, encore une fois, on ne peut pas dire à nos clients, 50% des utilisateurs de votre site n’auront pas la version que vous avez validée…
Le 17 Août. 2010 à 18h12 par Eric Le Bihan
Oui, c’est vrai je me suis peut-être un peut emballé, mais j’obtient un résultat identique sous Chrome, Firefox et Safari, bon pour Opera c’est pas encore ça pas de support du border radius, ni du gradient.
Mais pour un projet non professionnel c’est une alternative très acceptable, je dirais que c’est mieux que rien du tout, si on hésite entre faire un formulaire standard et en faire un design et lourd, là certains des utilisateurs en aurons un normal et les autres un bien.
Le 17 Août. 2010 à 18h19 par Petitgnome
Coïncidence, je me faisais justement cette réflexion il y a quelques jours : CSS3 et les récentes (et nombreuses) paluchades expérimentales auto-congratulatoires des constructeurs passent systématiquement à côté de la principale plaie « design » historique du CSS : les formulaires.
La charrue, les bœufs, tout ça ?…
Le 17 Août. 2010 à 18h25 par STPo
@Eric Le Bihan
.. encore une fois le même souci : IE vs client vs utilisateurs …
En sachant que : HTML5 ne sera pas complet avant quelques années, que CSS3 il faut attendre IE9 pour être sûr alors qu’il n’est pas encore là de sortir … (en vis à vis on dispose des nouveaux navigateurs déjà suffisamment compatibles).
Franchement en gardant l’état d’esprit « Continuons à produire des choses qui fonctionnent absolument sous ie6 ie7 ie8 et tous les nouveaux navigateurs » et « oui Monsieur le client, ça marchera sur votre pc » .. sans prendre le temps d’expliquer quoi que ce soit .. beh forcement, même si ça va en diminuant, on en sera encore à 30% ou + d’utilisation d’IE6 en 2020 LOL :( …
Pourtant, si de plus en plus « d’applications » ou « services » requièrent un des autres navigateurs (firefox, chrome, safari, ..) pour une meilleure visibilité et utilisation (ou tout simplement pour être fonctionnel) et bien, il est clair que les chiffres autour d’IE en terme d’utilisation vont fortement chuter !
Imaginez facebook, ebay, etc. qui imposerait aux utilisateurs de changer de navigateur ça ferait un sacré effet ! On a vu avec Hotmail récemment : Microsoft est lui-même prêt à proposer d’utiliser un autre navigateur (en attendant les corrections) comme solution ! Alors pourquoi pas ?
Le 17 Août. 2010 à 23h39 par reddazz69
@reddazz69
Même si je suis d’accord avec le fond de ta pensée (dégradons gracieusement et avançons, que diable !), je vais me permettre de nuancer ton propos.
Par curiosité : as-tu déjà vendu un site de plusieurs dizaines de milliers d’euros à un gros client dont le parc tout entier est sous WinXP IE6 ? Je t’assure que ça ne se fait pas « sans prendre le temps d’expliquer quoi que ce soit », au contraire c’est un long et patient travail d’évangélisation qui doit placer le curseur de la façon la plus juste entre cible (statistiques des utilisateurs), respect des engagements (graphiques, notamment, souvent pris par d’autres bien en amont), contraintes techniques, humeurs et susceptibilités diverses.
Un éreintant travail de négociation qui demande du courage au prestataire et de la confiance au client.
Concernant les 30% d’IE6 en 2020, si tu prends le marché des pays émergents, tu te rendras compte qu’aujourd’hui une écrasante majorité de ses postes sont équipés d’IE6 (bien plus que 30%)… et peu d’agences cracheraient sur l’énorme source financière que cela représente. Tout est question de cible.
Sauf que tu fais tes applications et tes services pour une cible, et que si cette cible est sous IE6 par contrainte à cause d’une DSI récalcitrante ou Dieu sait quoi, tu t’adaptes à elle ou tu perds ton contrat.
Le 18 Août. 2010 à 00h40 par STPo
@STPo
Heureux de voir que, sur le principe, tu sois d’accord avec ma vision. Bien entendu celui-ci s’applique en premier lieu au ‘web consommateurs’ > étant donné que le sujet des formulaires vs design s’applique en particulier au internautes traditionnels :-)
Pour répondre à ta question, je n’ai pas eu de nombreux projets où un très grand parc informatique était lié à l’obligation de rendre le « produit final » fonctionnel sur une plateforme en particulier, mais j’ai quand-même eu l’occasion de réaliser une application ‘intranet’ pour une unité de +/- 150 personnes et là, forcement on doit s’aligner sur ‘le système’ utilisé; même travailler conjointement avec l’équipe de développement interne.
Ayant souvent été amené à produire des ‘applications’ ou projets nécessitant un plugin, dans cette situation on impose déjà une certaine configuration côté utilisateurs.
En ce qui concerne les ‘applications’ ou ‘services’ qui sont par définition lié à une cible, je ne peux nier l’évidence d’une perte plus que probable; mais pour reprendre ton expression (qui convient bien) « avançons, que diable ! » Pour moi, un intégrateur/développeur se doit d’apporter son grain de sel et renforcer l’ ‘éducation’ de/du la cible/public pour une adaptation plus facile des deux côtés.
Le 18 Août. 2010 à 01h40 par reddazz69
Bonjour,
Pour ma part, vu que tous les sites dont je m’occupe doivent être adaptés pour l’ensemble des navigateurs (toutes versions d’IE entre autres), j’ai recours au JS uniquement pour IE afin de styler les formulaires.
Il est vrai que cela ralentit le chargement de la page, mais vu les soucis du dom:ready sous ce navigateur (IE6 et 7), un petit onload devient indispensable.
Dès lors, styler un formulaire doit être, comme vous le précisez, mesuré en fonction du projet et des navigateurs ciblés.
NB : il n’y a pas que jQuery… :)
Le 18 Août. 2010 à 10h20 par DevIntact
@DevIntact
Bonne remarque pour jQuery :-)
Mais comme tu as pu t’en apercevoir, on est plutôt fan de cette bibliothèque ici.
Si tu as d’autres sources à nous indiquer (hors jQuery), tu es le bienvenu ;-)
Le 18 Août. 2010 à 10h31 par Eric Le Bihan
Pour Uniform il est effectivement complet par contre il y a quelque chose qui me dérange c’est au niveau du select. Un petit zoom text X6 sur Firefox et on perd l’intitulé du select… pas tip top
Le 25 Août. 2010 à 17h32 par Olivier
@olivier :
Si tu regardes c’est le conteneur de la colonne de gauche qui a un
overflow:hiddenet c’est ce qui coupe le select quand on est en zoom x6 … pas le mécanisme jquery ou les styles liés au mécanisme de remplacement.Le 06 Sep. 2010 à 14h05 par bertrand