Après, je pense que les personnes pas habituées vont avoir tendance à effacer le texte « à la main » (genre le resélectionner, ou bien aller à la fin et faire backspace plein de fois, etc.). Mais j’ai trouvé néanmoins que c’était la meilleure solution si on voulait préremplir.

Pour plusieurs raisons : - un champs rempli donne implicitement comme information à notre cerveau que l’endroit où il doit faire saisir aux doigts qqc est déjà rempli ! pas besoin de le faire … - un champs rempli se vide au moment de la prise de contrôle : ce qui est une erreur ergonomique car cela force à mémoriser le champs (sur un fraction de secondes où sur qq minutes : le concepteur du site ne peut pas savoir comment l’utilisateur va utiliser l’interface dans le temps !) - un champs saisi attire moins l’attention de l’utilisateur : il est déjà rempli car l’internaute sait aujourd’hui qu’un temps de saisi est rectangulaire et vide (le champs attend un texte : cf mon 1er point)

Toutes ces raisons sont liées à l’affordance des champs de saisie (merci Amélie Boucher, à sa conférence ParisWeb et à son livre)

Un champs de saisie dit à notre cerveau « saisissez ici qqc ». Pré-saisir interfère donc sur cette interaction. Et sur le plan de l’accessibilité, mieux vaut mettre l’intitulé en dehors du champs !

Ton dernier exemple en jQuery est très utile pour la majorité des utilisateurs.

Néanmoins, les utilisateurs sans JS, n’aurons pas d’exemple vraiment visible… L’attribut title c’est bien joli, mais quel utilisateur lambda va attendre 2sec pour voir apparaitre une petite bulle jaune avec un exemple à peine lisible ? Sans parler des utilisateurs de lecteurs d’écrans qui n’auront pas configuré la lecture de ces tooltips …

Perso je prévois des exemples derrières les inputs, avec la balise em voir kbd … et on peut toujours envisager de les manipuler en DOM…

LukeW a écrit un joli pdf reprennant de bonnes et mauvaises pratiques pour la structure de formulaires : http://www.lukew.com/ff/entry.asp?502

D’un point de vue sémantique, l’attribut title semble plus intéressant, mais l’information est moins visible pour les navigateurs graphiques : il faut survoler un certain temps l’élément pour voir apparaître la valeur de title.

Corrigez-moi si je me trompe, mais en navigant à l’aide du clavier (sans JS, et sans aide vocale), l’information n’est plus du tout accessible avec un title, tandis qu’avec un value, le contenu est entièrement sélectionné lorsque le champ prend le focus. Dans ce cas, l’attribut value est clairement plus intéressant, puisqu’une simple pression sur une touche permet de remplacer la valeur pré-remplie par une autre.

Même chose pour les interfaces tactiles, sur lesquelles le survol n’existe évidemment pas.

Une des solutions pourrait être d’utiliser l’attribut placeholder combiné à l’attribut title en attendant, et de tester le support de placeholder pour appliquer ou non le script à l’élément. Cette méthode ne résout pas le problème de visibilité pour les navigateurs ne supportant pas encore l’attribut placeholder, c’est à dire tous les navigateurs en version stable.

Je crois que je vais rester au bon vieux value pour le moment, de manière à éviter tout comportement anxiogène.

(ceci est ma contribution hautement constructive au débat, mais je sais que Vincent validera mon commentaire parce que quand même, on ne peut pas négliger les joueurs de Scrabble® qui nous lisent)

Mis à jour : merci pour l’idée.

Je vais donc injecter via JS mon title dans chaque champ (laissé vide sans JS donc), ça a l’air de contenter tout le monde. Le coup de la couleur plus fade me plaît, je bidouillerai ça sans doute plus tard (passske là je prends du retaaaaaard).

Ca fait plaisir de revoir un peu d’activité par ici ! Ca y est ? Paris-web 2008 a fini de régner sur les blogs des geeks ? =D