[Résolu]Retirer bordure au clic sur firefox

Salut tout le monde,

Voilà mon problème :
J'ai des boutons de la forme suivante : côté HTML :

<a href"" class="bouton"></a>

et côté CSS :

a.bouton{
  float:left;
  display:inline;
  width:20px;
  height:20px;
  background-image:url(../images/image.gif);
  background-repeat:no-repeat;
  background-position:0px 0px;
}

sous IE, Safari, pas de problème.. Mais sous Firefox, lorsque je clique sur ce lien, je vais voir un espèce d'encadré en pointillé qui donne un effet plutôt moche...
pensez-vous qu'il est possible de faire qqc pour ne plus voir cela avec firefox ? (j'ai essayé des border:none; border:0; etc.. histoire de voir, mais ça me semble plutôt lié au navigateur qu'aux styles.. ?)

Merci...
Modifié par pdup (27 Nov 2008 - 01:04)

Bonsoir,

Il faut utiliser la propriété outline-style, dans ton cas :

a.bouton:active {outline-style:none;}

Merci !! ça marche !
dans mon cas, j'ai du mettre outline-style:none; directement dans le style a (pas dans a:active) sinon le problème persistait

Super ! comme ça les gens qui naviguent au clavier ne sauront plus du tout où ils sont
Si le gros cadre bleu FF te dérange à ce point remplace-le par quelque chose de plus discret si tu veux (1px dotted #eee...) mais qu'au moins on sache que quelque chose se passe. Faut-il rappeler l'hypertextualité est une fonctionnalité (un outil) et que supprimer sa visibilité en tant qu'outil (son affordance diraient certains experts) est aberrant ? Faut-il rappeler que les finasseries genre "oui mais ça bouge au survol" n'ont guère cours sur des mobiles et sur les nouveaux grands écrans tactiles ? Faut-il rappeler que réduire les contenus à la "cohérence de leur couche graphique" est réduire le média lui-même ?

C'est une question de choix en fonction de la cible, si on va par là, il y a du javascript et du flash sur le site, je dois le retirer car tout le monde n'y a pas accès ? idem pour la résolution d'écran, le visiteur sur un EEEPC en 800*600 aura des scrollbars de tout côté... faut-il alors sacrifier les 90% des visiteurs présent et à venir qui ont une résolution supérieure (et qui auront un timbre poste qui se balade au milieu de l'écran)...
Je suis le premier à défendre tout ce qui est respect des standards mais parfois il faut aussi développer en fonction de la cible, je suis ok, la navigation au clavier va peut-être déranger 0,1% des visiteurs, mais je pense les sacrifier pour les dizaines de % qui viennent avec Firefox et qui vont avoir une expérience visuelle désagréable* (ce qui va à l'encontre de ce qui est prôné sur le site).
Quand aux gens avec écran tactile, je ne peux rien pour eux s'ils n'arrivent pas distinguer les boutons ici, c'est très visible, pas besoin d'image qui bouge (et d'ailleurs, même avec le cadre gris, ça ne changerait rien pour eux, puisque le cadre n'apparaîtrait qu'au clic)

*c'est déjà un cadre de 1px en petits points gris par défaut et c'est tout simplement moche, ça casse tout simplement l'expérience visuelle, alors si je trouve la solution pour ne l'avoir qu'au clavier, je veux bien le mettre en place, sinon, je l'abandonnerais...

Je plussoie complètement Arsene.

pdup a écrit :
C'est une question de choix en fonction de la cible, si on va par là, il y a du javascript et du flash sur le site, je dois le retirer car tout le monde n'y a pas accès ? idem pour la résolution d'écran, le visiteur sur un EEEPC en 800*600 aura des scrollbars de tout côté... faut-il alors sacrifier les 90% des visiteurs présent et à venir qui ont une résolution supérieure (et qui auront un timbre poste qui se balade au milieu de l'écran)...
Je suis le premier à défendre tout ce qui est respect des standards mais parfois il faut aussi développer en fonction de la cible, je suis ok, la navigation au clavier va peut-être déranger 0,1% des visiteurs, mais je pense les sacrifier pour les dizaines de % qui viennent avec Firefox et qui vont avoir une expérience visuelle désagréable* (ce qui va à l'encontre de ce qui est prôné sur le site).
Quand aux gens avec écran tactile, je ne peux rien pour eux s'ils n'arrivent pas distinguer les boutons ici, c'est très visible, pas besoin d'image qui bouge (et d'ailleurs, même avec le cadre gris, ça ne changerait rien pour eux, puisque le cadre n'apparaîtrait qu'au clic)

*c'est déjà un cadre de 1px en petits points gris par défaut et c'est tout simplement moche, ça casse tout simplement l'expérience visuelle, alors si je trouve la solution pour ne l'avoir qu'au clavier, je veux bien le mettre en place, sinon, je l'abandonnerais...

Il ne s'agit pas de sacrifier certains utilisateurs ... il s'agit d'avoir une démarche constructive (tes propos indiquent le contraire) permettant à chacun d'avoir la possibilité d'utiliser ce que tu leur proposes. Alors, oui tu fais bien ce que tu veux mais si ce concept ne te plaît pas je ne peux que te recommander de changer de domaine ...

On va pas relancer ce débat, hein ? La question est qu'il y a des milliers de forums pour webmasters et que celui-ci a pour particularité de réunir des gens plus ou moins concernés par une certaine approche de la production de contenus web. On peut ne pas aimer cette approche, juger qu'elle est ceci ou cela, ok. Rien à redire.
Mais si tu viens poser des questions ici, sur alsa, et que tu n'as pas envie d'entendre les réponses qui vont t'être données, alors pourquoi poster ici sachant qu'inévitablement la question des standards, de l'accessibilité, de l'ergonomie, de l'intéropérabilité, etc. sera abordée si ta question soulève un problème ?
J'avoue que je ne comprends pas bien la démarche consistant à venir sur un forum dédié aux standards si c'est pour refuser d'en tenir compte ?

relisez mon premier message avant de partir en cacahuète...
je n'avais pas fait le lien entre la navigation au clavier et ce cadre qui n'apparaît qu'au clic sur firefox et pas sur les autres navigateurs et je souhaitais le retirer en croyant à un bug.
Il se trouve que la solution proposée ne facilite pas la navigation au clavier et de là vous avez commencé des laïus sur l'accessibilité.

Il faudrait être un peu ouvert et accepter qu'on peut respecter les standards, les validations et cie mais qu'il est parfois nécessaire de faire une entorse à la règle pour coller à la réalité, sinon on développerait des pages blanches avec du texte noir, des liens bleus et sans aucune mise en page, après tout, il faut penser à la personne sur terre qui utilise encore lynx...

Cette réalité dans le cas présent est que 0% des visiteurs utiliseront le clavier pour le lien qui pose problème, je le sais car je connais le projet, vous non, alors ne commencez pas à juger sans savoir et surtout pas en me suggérant de changer de profession... (cf. yodaswii)... j'ai quand même pas ch*é sur le W3C ou dit que je faisais un site en table...

Je viens poser ma question sur ce forum, car je sais qu'ici, j'aurais une réponse adéquat (et j'en suis pleinement satisfait), et que sur un autre forum, j'aurais eu droit à une réponse du style "ta ka metr border:0 lol".. soyez donc flattés

Bonjour,

J'avais proposé une solution utilisant la pseudo-classe "active" car bêtement je croyais que celle-ci s'appliquait lorsque l'on 'clickait' sur l'élément (je ne l'utilise jamais) et que ça ne générait pas la prise de focus lors d'une navigation au clavier.
Pour l'accessibilité je pense que l'on pourrait envisager une solution javascript utilisant l'évènement "onclick" qui isolerait bien le problème et ne gênerait pas la navigation au clavier.
Avec une page en ligne on pourrait réfléchir à une solution alliant esthétisme et accessibilité.

pdup a écrit :
Il faudrait être un peu ouvert et accepter qu'on peut respecter les standards, les validations et cie mais qu'il est parfois nécessaire de faire une entorse à la règle pour coller à la réalité ...

Quelle réalité ? Ta demande est du même ordre que celle de vouloir personnaliser les barres de défilement. Et tout ça juste pour une histoire que c'est pas beau ... soyons sérieux.

pdup a écrit :
Cette réalité dans le cas présent est que 0% des visiteurs utiliseront le clavier pour le lien qui pose problème, je le sais car je connais le projet ...

Tu n'en sais rien du tout (tout comme nous). Chacun à ses préférences de navigation ; certains aiment la couleur noire d'autre pas ça ne s'explique pas.

pdup a écrit :
soyez donc flattés

Il n'y a pas de quoi ... l'objectif affiché de ce forum est d'aller plus loin que le simple schéma : problème -> réponse.

<edit>Correction de l'auteur des citations </edit>
Modifié par yodaswii (27 Nov 2008 - 14:02)

Hum. Tout doux les gens, on reste zen

Pourquoi ne pas compenser la perte de l'outline par une réaction des liens au focus (avec la pseudo-classe correspondante) ? ça supprime la bordure "disgracieuse" et ça donne la main sur l'effet à appliquer, tout en permettant la navigation au clavier ...

a écrit :
Pour l'accessibilité je pense que l'on pourrait envisager une solution javascript utilisant l'évènement "onclick" qui isolerait bien le problème et ne gênerait pas la navigation au clavier.

Par exemple ? je suis un peu sceptique sur ce coup-là... je demande à voir

yodaswii : pourquoi je ne le saurais pas ? si la destination est une borne tactile, sans clavier par exemple ?

sinon, quand je parle de "réalité", je parle des désirs d'un client, de l'attente des visiteurs, qui, eux, se tamponnent des standards et qui préfèrent un site "joli" et fonctionnel. Je fais toujours tout mon possible pour mettre en avant des solutions accessibles, respectant tous les standards possibles quand il y a lieu.

Après, on parle de "recommandations" W3C, pas de "loi" ou je ne sais quoi, ce n'est pas pour rien, c'est pour cela aussi qu'on a le choix entre du strict, du transitionnel et cie : pour s'adapter aux différents cas de figure.

Pour revenir au sujet, merci Shunkin, ça peut effectivement être une idée, à tester... dans mon cas, ça serait un peu "lourd" mais on peut imaginer un onclick appelant une fonction qui ajouterait le style outline-style:none; au lien cliqué (et encore mieux : en ne faisant ça que sous firefox).

Hello,

pdup a écrit :
Après, on parle de "recommandations" W3C, pas de "loi" ou je ne sais quoi, ce n'est pas pour rien, c'est pour cela aussi qu'on a le choix entre du strict, du transitionnel et cie : pour s'adapter aux différents cas de figure.

Il ne s'agit pas ici de standards ni de recommandations, mais d'ergonomie.

pdup a écrit :
Pour revenir au sujet, merci Shunkin, ça peut effectivement être une idée, à tester... dans mon cas, ça serait un peu "lourd" mais on peut imaginer un onclick appelant une fonction qui ajouterait le style outline-style:none; au lien cliqué (et encore mieux : en ne faisant ça que sous firefox).

Je pense que la solution proposée par Thomas est bien plus robuste et bien moins lourde.

Mais de toute façon, s'il s'agit en effet de bornes sans clavier, la question ne se pose même pas.
Modifié par Julien Royer (27 Nov 2008 - 14:57)

pdup a écrit :
yodaswii : pourquoi je ne le saurais pas ? si la destination est une borne tactile, sans clavier par exemple ?

Est-ce que ce site / outil est uniquement consultable depuis un périphérique / UA spécifique (excluant certaines contraintes) ?
Si c'est le cas oui tu peux le savoir sinon aucune chance (mais cela ne justifie pas tout) !

pdup a écrit :
sinon, quand je parle de "réalité", je parle des désirs d'un client, de l'attente des visiteurs, qui, eux, se tamponnent des standards et qui préfèrent un site "joli" et fonctionnel.

Oui (ils ont raison de s'en tamponner), d'où la nécessité d'avoir une démarche de conseil forte (c'est ton métier, ton savoir-faire pas celui de ton client). Alors certes on peut se dire que c'est un détail mais ce n'en est pas un.

Thomas D. a écrit :


Pour l'accessibilité je pense que l'on pourrait envisager une solution javascript utilisant l'évènement "onclick" qui isolerait bien le problème et ne gênerait pas la navigation au clavier.

Par exemple ? je suis un peu sceptique sur ce coup-là... je demande à voir

J'utilise juste les données du problème. Pdup nous dit qu'il veut supprimer un comportement lorsque l'on 'click' sur un élément. Il me semble logique d'utiliser l'évènement "onclick" pour y remédier. Seuls les visiteurs utilisant la souris pour naviguer seront soumis à cette règle. S'ils n'ont pas le javascript activé ou naviguent au clavier ils auront le comportement par défaut du navigateur et comme ça ne concerne qu'un faible nombre de personne, la majorité ne sera pas lésée de "l'expérience visuelle".
Comme le dit Pdup, on n'a aucune idée du site en question et si ça se trouve le comportement par défaut du navigateur ne permet de mettre correctement en valeur l'élément prenant le focus. Sans page en ligne (et il ne peut peut-être pas nous la proposer pour des raisons de confidentialité), difficile de donner une solution parfaite. Tout ce que l'on peut faire c'est de proposer des options avec leurs avantages et inconvénients et lui faire confiance pour choisir celle qui satisfera son client et prendra au mieux en compte les recommandations sur l'accessibilité.

Hello,

Pour le focus, ça peut marcher mais il faut faire ça dans les règles de l'art. Dans Firefox, un lien cliqué aura simultanément les états :focus et :active. Pour que le style :focus ne s'applique pas, il faudra quelque chose comme ceci:

a:focus {outline: solid red;}
a:active {outline: none;}

Si on inverse les deux lignes, ça ne marche plus comme souhaité.

Il faudrait maintenant voir ce que ça peut donner avec les autres navigateurs. Vu qu'IE 6-7 implémente mal :focus et :active, je crains le pire.

Shunkin a écrit :
Il me semble logique d'utiliser l'évènement "onclick" pour y remédier.

Utiliser la touche Entrer du clavier lorsque le focus est sur un lien déclenche l'évènement onclick, il me semble.

Florent V. a écrit :

Utiliser la touche Entrer du clavier lorsque le focus est sur un lien déclenche l'évènement onclick, il me semble.

Oui, peut-être.
Mais lorsqu'on navigue au clavier, l'important est de savoir où l'on se trouve (donc repérer l'élément ayant le focus) et non de savoir pendant un temps infime que l'on active un lien (a priori si on enfonce la touche Entrer lorsqu'on est positionné sur un lien on sait qu'on va redirigé vers la destination de se lien).

Dans le même ordre d'idée, si on click sur un lien, celui-ci va prendre le focus. Donc agir directement sur le comportement du focus ne changera rien si on ne réfléchit pas à la façon dont l'élément prend le focus.

Pour info, les réactions des navigateurs face au focus des liens sont très variées. En testant avec la page suivante, avec les dernières versions (stables) de Firefox, Opera et Safari, on constate que:

1. Opera impose un halo bleuté et une couleur de fond et couleur de texte (noir sur fond jaune pâle). Il applique à la fois les styles au focus et ceux du :hover (soulignement du texte dans le cas présent), et rajoute donc ses deux styles: halo bleu qui n'est pas un outline, fond jaune, texte noir.

2. Safari utilise un halo bleuté qui passe en fait par la propriété outline (propriétés CSS3 pour les bordures/outline ou mécanisme interne? en tout cas le outline:none le désactive).

3. Firefox utilise un outline en dotted 1px red. Au clic, Firefox applique à la fois :active et :focus. Avec le bon ordre, le style :focus se voit peu, mais si le lien est un bouton JS plutôt qu'un lien changeant de page l'élément risque de garder le style focus, ce qui peut être gênant. Sur Opera et Safari, ce problème ne se pose pas.

Pas testé avec IE pour l'instant.
Modifié par Florent V. (27 Nov 2008 - 16:33)