Voila, en ce moment je fait des boutons pour interface mobile sur une page web, et je me retrouve face à un problème tout bête.
La délimitation des zones cliquables sous les navigateurs. Je m'explique, je vais prendre comme exemple chrome.
Quand on pose le doigt sur un bouton sous chrome on vois apparaitre la zone cliquable en bleu, et je cherche à faire disparaitre cette fameuse zone bleu.
Par exemple voici une page :
Quand on clique dessus voila ce que ça donne:
Ce que je cherche à faire, c'est faire disparaitre cette fameuse Zone qui apparait, je l'ai entouré en rouge.
Je ne cherche pas à reproduire cette effet, mon but est de supprimer ce carré bleu, j'en viens même à me demander si ça ne viens pas d'android.
Les seules choses que j'ai vu se comporter sans produire cette effet à l'heure d'aujourd'hui, ce sont les les gestures en javascript que m'a passé Lucky13 .
hammerjs et Jquery.finger.
Mais le problème est que je ne sais pas m'en servir, je suis une truffe en JS (honte à moi je le sais bien).
Ce qui me surprend d'autant plus c'est que je sois l'un des rares à qui ça ai posé un problème.
Oui, même si je savait que certaines ne changeraient rien, je l'ai fait. Même pour les plus étranges que l'on m'a conseillé, je passe les idées de survole, hier j'en ai même un qui m'a soutenu que le :hover fonctionnait sur mobile et que le doigt était le pointeur et qu'en glissant le doit sur l'url le hover se déclenchait et bien sachant ce que je sais j'ai quand même pris le temps de faire le test par acquis de conscience.
Je le redis c'est un problème récurant à tout les navigateurs mobile en tout cas sous lollipop.
Pour faire simple, si le test est effectué depuis un ordi qui simule le comportement d'un mobile, on ne verras rien.
Je n'ai rien contre donner un code vu que le plus basic des code pose ce problème.
J'aimerais te demander un service, pourrais tu avec ton smartphone ouvrir chrome et aller sur le site Openclassrooms et appuyer sur un lien voir si tu a le même cadre bleu qui apparait, si tu reste appuyé sur le lien une demi seconde tu devrais le voir. Au pire même injecter mon code en offline dans ton smartphone ou en faire un basic avec un href:"#", ça permet de bien voir le problème.
De mon coté ça va me permettre de voir si c'est un comportement récurant lier à toutes les build Android ou juste à la mienne.
Au passage merci pour le cours, il est dans ma liste, c'est certain il va falloir que je m'y colle.
Après c'est peut être simplement une feature d’accessibilité du système sur de la sélection de contenu cliquable qui ne peut être court-circuité en html/css
a tu essayé de remplacé tes <a href="#"> par des <span onclick="window.location = '#'"> pour voire ce que ça donne ?
Comme précisé plus haut ce genre de mise en évidence de l'interface sont généralement intégré pour des besoins d'accessibilités par exemple pour des personnes malvoyante ou qui ne pourrais utiliser le doigt/ la souris, je ne saurais te répondre précisément pourquoi cette bordure bleu autour d'un élément interactible car je n'ai que des hypothèses et aucune certitude actuellement (navigation au clavier ou vocal par exemple), mais cela dépend probablement de la spec la plus connu et utilisé dans ce domaine à ma connaisance, Aria: https://developer.mozilla.org/fr/docs/Accessibilit%C3%A9/ARIA bien que chaque constructeur puisse la personnaliser à sa guise en pratique, cela reste un standard donc c'est vraiment une bonne pratique de la suivre à la lettre pour avoir aussi bien un impacte positif sur le confort utilisateur que sur le référencement de les respecter autant que possible.
Mais pour ce projet aucunes règles accessibilités ne va être appliquées dans un premier temps. Vu qu'il s’agit d'un panel personnel que je vais utilisé pour accéder plus rapidement aux sites que j'utilise pour le css, le html, UI/UX, et la veille.
@exen même si ton sujet est résolu, j'ai fait le test sur mon téléphone et je n'ai pas de cadre bleu sur openclassrooms, ni sur aucun des sites que je consulte régulièrement.
Quelques remarque sur ton code :
il n'y a pas la propriété outline que je t'avais indiquée, alors impossible de savoir si tu l'as bien utilisée...
tu devrais plutôt utiliser une liste (<ul> avec des <li>). Tu as d'ailleurs choisi des noms de classes CSS (item1, item2...) qui le confirment
l'intérêt des classes CSS est que tu peux les réutiliser sur plusieurs éléments, alors il serait plus logique d'avoir une seule classe "item". Si tu as un besoin d'un identifiant unique pour du JS, il est conseillé d'utiliser un id
Même si c'est pour un projet personnel, il est toujours bon de prendre des bonnes habitudes dès le début
Je vais laisser répondre TryAndShare pour cette suggestion mais j'en rajoute deux autres au passage, plutôt que de faire item1 item2....
tu peut utiliser le pseudo selecteur css :nth-child(1) :nth-child(2) ... (voire aussi :nth-of-type(1) ... selon les cas) ça évite de polluer le code html avec des class quand elles ne sont pas utiles et ça te permet d'être plus flexible
voire même idéalement .grid-container > div si tu applique le même style à tous tes items
Les balises HTML ont une sémantique et bien la respecter permet notamment d'améliorer le référencement, l'accessibilité et la lisibilité du code.
Tu peux bien sûr n'utiliser que des <div>, ça fonctionnera, mais si tu fais une liste d'items (présentée en ligne, en colonne ou en grille), autant utiliser la balise qui sert à ça
Quand je veux personnaliser le comportement du navigateur, en général j'utilise "outline: 0;" dans mon reset.css
- Edité par TryAndShare 5 septembre 2018 à 10:00:33
Quitte à citer un cours sur la sémantique tu n'a vraiment pas trouvé moins à jours ou moins complet ? (dernier maj 2013 et c'est dans le cadre du xhtml n'hésite pas à utiliser le lien plus haut sur le même sujet qui est à jours en html5 de cette année )
Alors, le outline comme je te l'ai dit je l'ai testé et cela n'a eu aucune incidence sur le comportement de ma build.
Coté sémantique je suis tout à fait d’accord avec toi.
Mais comme je l'ai dit dans mon premier post on est sur "un panel de boutons sur une page web". Ce que j'ai montré c'est le maquettage de cette partie, il y a un menu indépendant, tout comme il y aura un footer.
Si j'utilise des noms basic pour Grid c'est dans un souci de simplicité et de rapidité dans la mise en place de cette partie pendant que j'opère divers changements dessus. Un indice le montre, comme je te l'ai dit plus haut, la ligne de rafraichissement dans le <head>.
Si je suis passé poser cette question c'est parce que ce comportement sur mon smartphone me dérangeait, je cherchais une façon simple de le contourner. Et peut être aussi parce que je peut être légèrement psychorigide quand un truc me démange.
De plus là ce n'est que la partie mobile de ce panel, je n'ai même pas encore attaqué son design général ou son comportement à proprement parlé. Comme c'est pour une utilisation personnel pas de seo, je vais même exclure les bots un max sur cette partie du serveur.
Donc sachant qu'un menu va venir se greffer à la page, et que ce que tu à vu n'est qu'un simple panel de boutons qui va être injecté dans une page, est t'il toujours utile d'envisager <ul> et <li> ?
Concernant les cadres bleus, si tu les vois sur d'autres sites, alors c'est peut-être effectivement ta version d'android/chrome. Si tu ne les vois pas sur un site en particulier, essaie d'analyser le CSS de ce site pour voir ce qu'il y a de différent.
Concernant la sémantique, même si tu n'as pas de problématique de SEO ou d'accessibilité, rien ne t'empêche d'utiliser les bonnes balises pour représenter une liste, ne serait-ce que pour la lisibilité du code. Ce qu'il y a autour de tes boutons (header, nav, footer...) n'a pas d'importance, tu peux avoir plusieurs listes dans une page.
Après c'est ton projet personnel et privé en plus, alors tu es libre d'utiliser ce que tu veux
c'est très certainement çà, vu que ca le fait sur tout les navigateur de ma build android.
Concernant la sémantique tu pense que je ne l'utilise pas, mais si, sur le reste elle y est, par contre je ne suis pas pour utiliser une liste sur ce panel de boutons, parce qu'en faite ce sont des cards.
Pas de soucie pour le lien je précise juste au cas où quelqu'un déterre le post car je pense qu'en dehors de l'aspect référencement la sémentique permet surtout d'avoir un code css html moins redondant et donc plus simple à manipuler, je m'explique:
- Déjà en découpant le code par catégorie d'usage nav/section/caption... tu peut plus facilement sélectionner tel ou tel partie du site en css sans avoir à mettre des id / class à tous va car généralement tu na qu'un voir deux menu de navigation et une section qui est le contenu propre à la page, de plus ça rend le css plus lisible et réutilisable
- Pour ce qui est du ul je l'ai effectivement beaucoup vue dans des exemple de menu sur internet et je peut comprendre ça pour des raison historique, par exemple sans css c'est ce qui ressemble le plus à un menu et cela permet de faire facilement un agencement vertical découpé pour un exemple, (c'est d'ailleurs aussi dans l'exemple du cours que j'ai posté).
Mais en pratique je trouve personnellement que avec les nouvelle balises structurantes html5 comme nav cela perd totalement de son intérêt surtout au vue du designe moderne ou tu va facilement avec flex passer d'un menu horizontal / wrapped / vertical pour le responsive car en générale ton menu ressemble rarement à une liste à puce statique ce qui oblige généralement à réinitialiser le css pour en faire un truc jolie.
Ce qui me fait poser donc me poser la question des potentielles ressources gaspillées et de l’intérêt final de l'utiliser encore aujourd'hui pour cette usage d’autant plus que comparé à un nav > a | nav > button | nav > * qui est relativement unique dans une page, tu peut avoir plein de liste dans le contenu de ta page.
Qu'ont ce comprenne bien c'est pas une reproche ou une recommandation mais je me pose moi aussi vraiment la question de l’intérêt et donc j'en profite au passage pour te demander si tu a des arguments positif en cette faveurs autres que sémantiques qui pourrais améliorer ma compréhension de cette pratique répandue
Sinon pour en revenir au sujet, question bête mais on sait jamais: tu a regardé du coup dans les options d'accessibilités de ton portable configuration > accessibilité si y a pas une case à cocher pour ça ?
Je ne le prends pas du tout comme un reproche, c'est une discussion intéressante et une question légitime. Je ne prétends pas connaître la bonne réponse (s'il y a en bien une), mais je peux toujours donner mon avis
Je suis d'accord avec toi concernant la découpe du code mais d'un point de vue de la lisibilité du HTML.
Dans mes projets (pro et perso) j'utilise presque tout le temps la méthodologie BEM, donc je ne cible jamais des balises HTML en CSS (sauf dans le reset CSS) et utilise toujours des classes. Cela permet notamment :
de découpler (un peu) HTML et CSS (par ex : si tu changes une <div> en <p> dans ton HTML, tu n'as pas besoin de modifier ton CSS)
d'avoir la même spécifitié pour tous les éléments et d'éviter les risques de surcharge avec !important
de ne pas avoir des sélecteurs à rallonge (nav > ul > li > a...)
et donc d'améliorer les performances de rendu
...(et certainement plein d'autres choses que j'ai oubliées)
Il y a bien sûr d'autres méthodologies CSS (modules CSS...) qui sont très bien et qui sont aussi basées sur les classes.
Concernant le menu de navigation, en général j'utilise cette structure : nav > ul > li > a
Je pense qu'il faut bien différencier la sémantique (une liste d'élément de même nature) de la représentation par défaut (une liste à puce verticale). Un menu est une liste de liens qui permet de naviguer sur un site, donc l'utilisation d'une liste non ordonnée <ul> me semble naturelle, même avec les nouvelles balises HTML5 et pas forcément pour des raisons historiques.
Effectivement ça nécessite un peu plus de CSS pour cacher les puces, supprimer le padding par défaut... mais je ne trouve pas ça dérangeant.
PS : j'ai édité mon précédent message pour supprimer le mauvais lien
- Edité par TryAndShare 6 septembre 2018 à 4:19:35
Ok, merci beaucoup pour l'explication, je ne connaissais pas la méthodologie BEM j'en ai profité pour en lire un peut plus au passage et en effet bien qu'elle ne me charme pas du tout l’œil je suis bien obligé de reconnaître qu'il y a de très bon arguments en sa faveurs pour de gros projets à maintenir sur le long terme, c'est d'ailleurs à peut près ce que j'utilise déjà quand j'inclue boostrap dans un projet, un sujet fort intéressant en effet, qui me permettra de pester un peut moins la prochaine fois que je voie un projet avec des class à tous les niveau ^^'
J'ai pris le temps, de lire ce que vous avez écrit, et c'est très intéressent, même si pour le moment je n'ai fait que le survoler.
Alors l'accessibilité, les option DEV, la gesture sensing, ce sont les premières chose que j'ai vérifié avant de poser mes question et faire le tour des forums. Mais plus j'y pense et plus je me dit que ça viens de la build constructeur, c'est l'un des rare tel que je n'ai pas passé sous build xda, il est brut de pomme et c'est un speed7+.
Je pense que tu auras compris que le morceau de code que tu as vu, est la partie central de la version mobile, sur la version desktop je ne suis pas encore trop sure de ce que je vais faire, mais je pense que ce serras proche d'un ensemble de crad ou de mosaïques. Donc on auras bien un header, nav, block central, et peut-être un footer. C'est aussi pour çà que je n'ai pas encore déterminé de noms concrets pour mes objets ca va dépendre aussi de la direction que je vais prendre sur la version desktop. Mais bon ce n'est pas non plus le sujet de ce post.
Au passage j'aurais autre question si ça ne vous dérange pas.
J'ai un menu latéral qui va se déclencher via une image, du moins pour le moment.
Désoler par avance pour cette réponse qui n'aide pas beaucoup mais je ne suis vraiment pas fan des questions du type quelle serais la manière façon de faire tel ou chose spécifiquement alors que l'ont a pas du tout le contexte ni la finalité du code et que je n'ai pas la prétention de connaitre la meilleur façon de faire quoi que ce soit, je m'explique:
La meilleur vis à vis de quoi ? Les performances ? La simplicité du code ? La portabilité ? La ré utilisabilité ? L'architecture ?
Qu'est ce qui ne te convient pas actuellement dans la façon de faire comme ça ? Est ce que tu passe par un parseur de code pour faire un build de production ? Quel est le temps que tu souhaite consacrer à ce projet ? Va tu travailler en équipe ? Est ce une maquette que tu va potentiellement rouvrir plusieurs mois après ? Va tu faire beaucoup de redirection de ce type ? quel sont les librairies que tu compte inclure ? Besoin d'intercepter des requête pour un mode offline ou de les gérer de façon générique ? ...
Enfin tu le comprendra que c'est en fait pour quelque chose qui parait très simple une très vague et vaste question il me semble et que ça va surtout dépendre de tes préférences et objectifs sur un projet perso.
Quand je suis intervenu hier sur le sujet je venais de lire un ou deux articles sur la façons d’intégrer plusieurs fonction sur onclick.
j'ai donc vu des personnes parler de &&
onclick="fonc1('xx','xx') && fonc2('xx')"
d'autres de ;
<p onclick="Fonc1();Fonc2();">
D'autres encore de doubler onclick
onclick="fonc1('xxx')" onclick="fonc2('xxx')"
Donc j'en ai profité pour poser la question, le but étant pour moi de toujours masquer ce fameux cadre, mais cette fois-ci sur l'image qui va servir de déclencheur pour le volet de navigation. Qui aujourd'hui ce présente comme ceci :
Voila ce qu'il en était de ma question "Quelle serrait la meilleur façon de procéder pour l'intégrer ?"
Pour le temps que je vais passer sur ce projet à mon avis pas plus de 6h, et j'y ai déjà consacré environ 2h le temps de définir sa charte graphique, faire la maquette, et échanger sur le forum.
C'est un projet tout simple, ce sont juste quelques url et 5 ou 6 mémos.
En générale si tu compte mapper un événement sur plusieurs élément, de manière conditionnel ou en faire un code réutilisable on préférera utiliser addEventListener et ne pas mettre de code inline.
Le code inline a le mérite d'être plus rapide et intuitif à écrire et peut tout à fait convenir pour un événement précis sur un élément précis.
Ensuite les trois exemples de js inline que tu donne ne sont pas des codes équivalent entre lequel choisir mais 3 code bien distinct qui font des choses différentes.
Le premier execute f1 et si vrais execute f2, le deuxième execute f1 et f2, le 3eme... hum sérieux ai je bien besoin d'expliquer pourquoi ce code est invalide ? ^^'
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.
Compos sui.