A priori, sur le site donné en exemple, il n’y a que sur la navigation du haut que l’état « :active » a été travaillé. Puis après quelques clics, je me suis rendu compte que l’image enfoncée de « next client » par exemple, n’était pas chargée.

Le 13 Sep. 2009 à 21h35 par raphaël

l’état :active pour ma part je ne l’utilise pas via les CSS justement pour une raison, un clic relâché en dehors du bouton laisse l’état enfoncé du bouton (:active).

Je lui préfères le javascript onmousedown et onmouseup pour gérer ces états. Néanmoins il est aussi possible d’utiliser l’événement de déplacement de la souris afin de replacer le bouton dans son état normal en cas d’événement onreleaseoutside (qui n’existe pas en javascript certes mais c’est pour l’analogie avec l’événement en flash). Mais je trouves l’effet moins convaincant.

Cela dit je concède l’aspect rapide de cette méthode pour gérer les 3 états d’un bouton html.

Le 15 Sep. 2009 à 06h42 par bertrand germain

Un effet qui ne prend pas beaucoup de temps à mettre en place (pas d’image à préparer) avec :active est :

p.lienenformedebouton a:active {
position:relative;
top: 1px;
left: 1px;
}

Ça décale d’1px le « bouton » au clic et donne l’illusion qu’on enfonce celui-ci. J’ai oublié la source de cette astuce (CSS-Tricks peut-être) ; elle est visible en ligne sur http://www.alsace.com (boutons verts « About us » et « Read more » sous les deux colonnes de texte)

Le 15 Sep. 2009 à 09h50 par Felipe

C’est vrai ça je ne m’étais jamais fait la remarque mais c’est un peu con de mettre un effet « enfoncé » sur un bouton au survol de la souris et rien au clic en lui-même. Cet article tombe bien je refait la home de mon site. J’en prends bonne note merci !

Le 17 Sep. 2009 à 20h48 par moins52

Il faut dire que très peut de graphistes déclinent leurs maquettes avec cet état (ou avec un état :hover) Il est donc difficile de remédier au problème rapidement mais j’approuve ta démarche en affirmant que la mise en avant de cet « effet » est important pour l’utilisateur.

Pour appuyer ton article tu as un excellente utilisation du :active dans la partie administration de la galerie Picsengine.

Le 20 Sep. 2009 à 19h51 par Xavier

En effet c’est au graphiste à penser à ce genre de chose. Il serait d’ailleurs intéressant de penser à implémenter les états des boutons dans Photoshop… ou Gimp :)

Le 16 Oct. 2009 à 14h20 par Raphaël

A voir: gog.com, un site qui est d’ailleurs tres classe au cote dez effets GUI.

La reponse tactile du bouton , c’est bein quelquechose de sacre, mais la pluspart de temps on l’a deja — soit du clavier, ou de la souri. Avec l’iPod Touch, on commence a voir des problemes, surtout que la vitesse de la connection peut bien etre en doubte, de plus que les effects :hover/:focus ne vallent plus rien.

Mais sur ordi, je trouve beaucoup plus important de montrer que l’on peut cliquer — la confirmation devrait etre evidente dans le resultat de l’action…

Le 11 Nov. 2009 à 16h17 par Barney

[…] a récemment abordé le cas des boutons activés, je prends le relais et je m’interroge cette fois sur le survol des […]

Le 14 Nov. 2009 à 20h08 par Survol des hyperliens — HTML Zen Garden

Une fois n’est pas coutume, je ne suis pas d’accord.

On insiste sur l’importance de cet effet (ou tout bêtement son caractère positif) en faisant l’analogie avec un bouton pressoir physique. Or, un lien ou bouton sur un site ou une application web n’est pas un élément physique, et les caractéristiques de l’un se prêtent mal à l’autre.

Pour commencer, il faut bien comprendre que si le bouton pressoir s’abaisse, c’est parce que ce mouvement est nécessaire pour que l’action de l’utilisateur soit enregistrée. C’est une contrainte mécanique avant tout. On remarquera qu’elle n’existe pas, cette contrainte, pour les interfaces tactiles. La métaphore du bouton pressoir physique n’est pas négligeable, mais c’est aller un peu vite en besogne que de dire qu’elle est adaptée pour les interfaces informatiques en général, ou pour un menu de navigation de site web en particulier.

Qu’est-ce qui importe vraiment dans ces interfaces? Simplement: fournir un feedback à l’utilisateur pour qu’il comprenne que son action a été prise en compte (et ne cherche pas soit à la répéter inutilement, soit à trouver un autre moyen d’effectuer une action). C’est pourquoi certaines interfaces tactiles rajoutent un son ou un tremblement de l’appareil lorsque certains «boutons» sont «pressés». Mais ce type de feedback n’est pas un passage obligé; il s’agit en général de cas particuliers (claviers virtuels sur mobile tactile…).

Quid d’un site web, et notamment d’un menu de navigation sur un site classique avec des pages HTML séparées? La réaction principale, c’est le changement de page. On peut découper cette réaction en trois éléments:
1. indicateur de chargement dans l’interface du navigateur (barre de progression ou visuel tournant dans l’onglet, voire les deux);
2. possible chamboulement visuel de la page (passage au blanc, phase d’affichage progressif d’un contenu);
3. au final, présence d’un contenu différent, avec éventuellement variation de la mise en page.

Ça fait déjà pas mal de choses. À cela, on peut rajouter la pression du doigt sur la touche Entrée (navigation au clavier), ou sur la souris ou le pavé tactile, avec éventuellement un clic (son) en réaction. Il se peut aussi que le système d’exploitation rajoute un son au clic (il me semble que certaines versions de Windows font ça, non?).

À cette profusion de signaux, on voudrait rajouter un effet graphique sur le bouton. On obtiendrait donc, de manière détaillée:
0. Action physique de l’utilisateur.
1. Éventuel retour physique et/ou sonore du périphérique de saisi (souris, clavier, pavé tactile).
2. Éventuel retour sonore du système d’exploitation.
3. Changement graphique du bouton.
4. Indicateurs de chargement du navigateur.
5. (Latence.)
6. Dessin du nouveau contenu (de instantané à plusieurs secondes).
7. Chargement d’un nouveau contenu.

Je ne suis pas sûr qu’on ait besoin de ce numéro 3.

Et je ne reviens pas sur les incohérences d’implémentation de :active dans IE 6 et 7, le fait que l’état :active persiste dans plusieurs navigateurs si on relâche la pression en dehors du lien, ou encore qu’il persiste lorsque l’on revient à la page précédente. Diverses petites choses qui font que le signal donné peut être contre-productif, en plus d’être superflu.

(La prochaine fois, on parle de l’inutilité de :visited?)

Le 22 Déc. 2009 à 12h38 par Florent V.

Le point 3 représente pour moi la couche applicative, entre le système d’exploitation et le navigateur.

Pourquoi n’aurait-elle pas le droit à son propre retour pour indiquer qu’elle fonctionne bien, comme le peuvent les périphérique, système d’exploitation et navigateur ?

J’ai hâte de débattre sur le :visited qui est utile très souvent, mais ça tout le monde est d’accord.

Le 22 Déc. 2009 à 13h58 par Corentin

Je me sers d’active et hover de la même manière car la navigation au clavier par la touche tabulation rend le lien sélectionné actif et donc, cela permet d’avoir un hover pour les personnes qui n’ont pas de souris.

En fat, active signifie : si tu appuie sur entrée, tu suivra le lien sélectionné.

Bref, je pense que ton interprétation du sélecteur est mauvaise. Mais bon, tu as ouvert le débat, peut-être qu’il manque certains sélecteurs CSS, vous avez vu qqchose dans CSS 3 qui comblerai la lacune actuelle ?

Le 28 Déc. 2009 à 11h35 par Nicolas Froidure

Re,

En fait, ton interprétation est probablement bonne, j’ai fait un raccourci un peu hâtif. Focus est plus approprié effectivement pour afficher le focus même si IE se comporte différemment.

Du coup, :active reste un mystère car il ne fonctionne qu’avec la souris, pas quand on navigue au clavier et qu’on tape entrée (du moins sur mon Firefox 3.5) ce qui devrait être le cas si ton interprétation de sa destination est correcte.

En fait, en regardant les specs, on s’aperçoit que le comportement cité en exemple est implémenté, sans vraiment aller plus loin et le transposer à la navigation clavier. En fait, il serait mieux que le parcours d’un lien avec la touche entrée ne se fasse qu’au relâchement de la touche, et non à l’enfoncement de celle-ci (onKeyPress). Ca permettrai d’appliquer ce sélecteur à la navigation clavier.

Le 28 Déc. 2009 à 13h45 par Nicolas Froidure

Il est parfaitement exact qu’il faudrait prévoir les enfoncements de boutons dans les interfaces. Une excellente raison pour cela est que les IHM des window managers le font très souvent et que donc, que cela soit mal ou bien, les usagers sont habitués à un tel comportement.

Maintenant, il est absolument nécessaire de se rendre compte que ce comportement « par défaut » des window managers dépend de la plate-forme. Par exemple sur Mac OS X, certains boutons ont un comportement en mode :active mais pas en mode :hover (les + et – des listes par exemple). On règlera ce genre de choses (dans une page Web) par exemple en mettant programmatiquement une classe dépendant du système à l’élément body et en utilisant un body.telleClasse dans les sélecteurs appropriés des feuilles de style. On peut aussi utiliser des « hacks » CSS sélectionnant la plateforme mais personnellement je trouve cela très cracra…

Globalement, il faut utiliser les sélecteurs :hover pour le survol et :hover:active (les deux à la fois) pour l’action. J’ai lu plus haut que quelqu’un se plaint qu’un navigateur ne « relacherait » pas l’état si la souris est relachée hors du bouton. Face à ces sélecteurs, un tel comportement doit être traité comme un bug. Utiliser des event handlers sur la souris, ça marche aussi mais pourquoi faire du programmatique quand on peut faire du déclaratif ?

Voila, en hopant que ça helpe.

Daniel Glazman, W3C CSS WG Co-Chairman

Le 28 Déc. 2009 à 14h11 par Daniel Glazman

Re,

Ca sert d’avoir un frenchy dans le working group CSS3 ;). Le coup du :hover:active est simple, mais fallait y penser.

Sinon, je me permet de retourner encore plus ma veste en appuyant le discours sur la nécessité ou du moins, l’utilité d’implémenter un comportement :active sur un bouton.

En effet, la représentation visuelle du bouton enfoncé pourrait correspondre à l’enfoncement de la touche entrée si :active était également implémenté pour la navigation au clavier. Reste à savoir si ça le sera et si c’est justifié que ça le soit.

Peut-être qu’il faudrait créer un ticket pour Firefox sur ce thème ?

Le 28 Déc. 2009 à 14h21 par Nicolas Froidure

> Peut-être qu’il faudrait créer un ticket pour Firefox sur ce thème ?

Oui probablement. La spec Selectors Level 3 dit explicitement « The :active pseudo-class applies while an element is being activated by the user ». Ce qui tendrait à signifier que keydown avec la bonne touche clavier devrait basculer l’élément en mode :active.

Le 28 Déc. 2009 à 14h38 par Daniel Glazman

Il resterait alors trois bugs à signaler pour Firefox:

1. Lors d’un retour à la page précédente (bouton back du navigateur), le dernier lien cliqué a l’état :active, qu’il ne devrait pas conserver.

2. Lors d’un clic sur un lien pointant dans la page en cours, le lien cliqué conserve l’état :active jusqu’au clic sur un autre élément de la page. Il devrait perdre cet état dès le moment où le bouton d’action (bouton de la souris ou touche du clavier) est relâché.

3. Dans le cas où le bouton d’action (bouton de la souris ou touche du clavier) serait conservé appuyé par l’utilisateur, le lien devrait perdre l’état :active si le pointeur quitte la zone du lien. Ou dès que le lien perd le focus. C’est ce que fait Gnome, par exemple. (Et la solution du :focus:active est intéressante, mais du coup il faut renoncer à déclarer un comportement valable également en navigation au clavier…)

Le 28 Déc. 2009 à 19h15 par Florent V.

« Il serait d’ailleurs intéressant de penser à implémenter les états des boutons dans Photoshop… ou Gimp :) »
Le 16 oct. 2009 à 14h20 par Raphaël

Pour Gimp, lors de la création d’un bouton il crée automatiquement 3 images, pour les 3 positions ! Ça fait longtemps maintenant. On peut même personnaliser ces états.

Le 30 Avr. 2010 à 10h21 par Damien

[…] ayant des difficultés à manipuler la souris. Je vous invite d’ailleurs à lire l’article :hover vs :active écrit par Eric Le Bihan, et publié sur Les Intégristes en […]

Le 23 Juil. 2013 à 13h37 par Signalétique des hyperliens | Édition Nº43 | le train de 13h37