On continue notre petit bonhomme de chemin dans le développement de ce petit plugin — qui est d’ores et déjà fonctionnel et utilisable en pratique. Avant de s’attaquer à la balise de template promise il y a quelques jours, j’ai choisi de m’intéresser un peu à l’aspect du bouton mis en place par la bibliothèque.
Pour l’instant, on a le choix du libellé, mais rien d’autre, ce qui peut (éventuellement) poser des problèmes de design sur certains thèmes. C’est pourquoi j’ai eu envie — et on en a discuté récemment — de proposer une forme iconique, à base d’image SVG, pour le bouton.
Pendant un temps j’avais l’idée de faire un script javascript qui remplacerait le bouton par un champ input de type image, mais ça complique les choses puisqu’il faudrait aussi prévoir tout l’aspect accessibilité de sa mécanique.
Finalement j’ai juste prévu d’afficher une icône SVG en fond du bouton, tout en masquant (mais pas pour les lecteurs d’écran) le texte choisi.
Ça donne ça, une fois en place :
Côté code, j’ai opté pour des boutons radio sur la page de réglage du plugin avec comme possibilités :
- Le texte seul (option par défaut)
- Une icône de chaise roulante
- Une icône de déficience visuelle
Je ne vais pas détailler tout le code supplémentaire, c’est visible dans le commit associé.
Côté widget, j’ai choisi une liste déroulante, afin de gagner un peu de place, mais avec les mêmes options :
Pour finir, quelques explications sur le code CSS ajouté :
#accessconfig.a11yc-vd button, #accessconfig.a11yc-wc button {
border: none;
width: 2.5em;
height: 2.5em;
background-size: 2.5em 2.5em;
margin: .5em;
overflow: hidden;
color: transparent;
}
#accessconfig.a11yc-vd button {
background-image: url(index.php?pf=a11yConfig/img/visual-deficiency.svg), none;
}
#accessconfig.a11yc-wc button {
background-image: url(index.php?pf=a11yConfig/img/wheelchair.svg), none;
}
#accessconfig.a11yc-vd button:hover, #accessconfig.a11yc-wc button:hover,
#accessconfig.a11yc-vd button:active, #accessconfig.a11yc-wc button:active {
cursor: pointer;
}
Tout d’abord, lignes 1 à 9, ce qu’il faut pour dimensionner suffisamment le bouton — j’ai opté pour 2,5em de côté, ce qui correspond à une zone de 40 pixels avec un navigateur réglé sur une police de caractères de 16 pixels, ce qui est le plus fréquent ; et je rend transparent le texte (il reste lisible par les lecteurs d’écran).
Ensuite, lignes 11 à 17, le chargement de l’image SVG idoine en fond de bouton.
Enfin, lignes 19 à 22, je transforme le curseur de la souris en pointeur au survol et à l’activation (nécessaire pour indiquer qu’une action est possible).
Voilà, c’est tout pour aujourd’hui.
1 De Bernard -
J’ai eu un petit problème quant au suivi des modifications.
En effet dans le commit associé indiqué dans ce billet, j’ai noté des différences dans le code de la page
_public
- proposé dans le billet précédant , notamment avec l’insertion de la méthodeinject
- qui n’apparait pas en “ajout” dans le commit cité.En cherchant un peu dans l’historique j’ai remarqué que cela se passe dans le commit Code cleaning and refactoring.
Ceci dit, j’avais déjà remarqué que les codes des fonctions
publicTopAfterContent
etpublicFooterContent
se ressemblaient…Je ne sais pas si j’ai loupé une information, mais, du coup, je me permets de signaler que la lecture de ce commit là -“cleaning…” pourrait permettre de mieux assimiler le code final résultant des modifications signalées dans ce billet.
2 De Franck -
Effectivement Bernard, j’ai légèrement factorisé le code pour éviter les doublons et comme tu l’as remarqué les deux fonctions appelées sur les behaviours ne diffèrent que par l’un des paramètres (qui indique la position, haute ou basse) fourni à la fonction de rendu.
Il y a d’ailleurs surement d’autres « petits » commits dont je n’ai pas parlé et qui concernent des petits « oups » ou des petites « améliorations ».
Quoi qu’il en soit tout ça ne remet pas en cause les principes que j’évoque dans ma série de billets.