5139 sujets

Le Bar du forum

Pages :
Modérateur
(reprise du message précédent)

Bonjour,
PapyJP a écrit :

Je constate que j'ai de plus en plus besoin d'interactions, notamment pour la gestion des petits écrans: je mets un bouton avec le titre de l'objet, et je l'affiche quand on clique dessus.
Si je voulais faire ça sans JS, il faudrait ouvrir une nouvelle fenêtre, ce qui n'est pas très ergonomique.

Mhhh ! T'es sûr d'avoir besoin de JS pour ça ? On parie ? Smiley cligne

Amicalement,
parsimonhi a écrit :
Bonjour,

Mhhh ! T'es sûr d'avoir besoin de JS pour ça ? On parie ? Smiley cligne

Amicalement,

Je ne parie jamais, surtout que je suis sûr de perdre!
Mais ça m'intéresse de savoir comment, rien que pour le fun Smiley cligne
Modérateur
Bonjour,

Je n'ai pas exactement en magasin ce que tu veux faire, mais j'ai des trucs qui y ressemblent.

Par exemple ce que j'appelle des pseudo popups : voir https://jsfiddle.net/obuc5s4j/

En changeant quelques lignes, tu devrais pouvoir afficher ton titre (et aussi le faire disparaitre).

Note : oui, je sais que j'exagère de donner un lien jsfiddle ou il n'y a pas de js du tout ! Smiley lol

Amicalement,
Modérateur
Vous l'aurez sûrement remarqué de part mes divers discours sur le sujet, je suis partisan de l'application du JS à la nano-pipette (un zeptolitre de code par ci par là) et c'est un positionnement que j'assume dans mes développements.

Certes cela implique de faire fonctionner ses méninges à une intensité maximale et ce n'est pas toujours évident lorsqu'on a "la tête dans le guidon". Il faut savoir prendre du recul et revoir les éléments dans leur ensemble, voire même, revoir l'ensemble des ensemble.

D'expérience, très souvent lorsque je me trouve dans une impasse qui oblige l'utilisation de JS, j'arrive à m'en sortir en changeant de point de vue. Ce qui conduit à un changement du concept que j'avais en tête (dans la mesure ou ce changement apporte une plus-value au projet et non en réduisant le champs des fonctionnalités).

Par exemple, pour reprendre ceux de PapyJP.
Lorsque j'aborde le sujet de l'orientation du périphérique, ses dimensions et plus généralement les différents designs sur les différents support, systématiquement je planche sur les media-queries. Jusque là je suis toujours parvenus à mes fins que ce soit pour une disposition générale des éléments d'une page, un tableau, des images etc.
Même chose quand je veux éviter une nouvelle fenêtre/onglet. Je m'oriente alors soit vers les fenêtres modales ou vers les listes genre "summary" (le nom m'échappe sic).
Au final, après revu ainsi de chaque point qui aurait nécessité du JS, je me retrouve à ne coder que ce petit zeste qui, en restant superflus, améliorera l'expérience utilisateur.

Bien entendu je conviens que dans des cas précis il reste un langage indispensable que nul autre langage et concept ne peut remplacer. Par exemple des listes déroulantes reliées comme en parlait Jencal ou, comme j'y ait été confronté, la suppression de l'affichage de la barre de scroll de la page alors que l'affichage est porté sur une modale en premier plan qui couvre tout le viewport et qui possède elle-même sa propre barre de scroll (c'est moche deux barres côte à côte, hein ?)

Notez tout de même que jusque lors, je ne fais référence qu'à la partie émergée, celle côté utilisateur pour lequel ma priorité est l'accessibilité à l'information suivie de son confort.

En back-office je perçois la chose autrement parce que je centre mes priorités non plus sur les points évoqués auparavant mais plutôt sur l'efficacité (d'un point de vue général). Le back-office s'adresse essentiellement à des utilisateurs avertis qu'il est possible - dans une certaine mesure - de se faire conformer aux exigence d'un tel espace.
Par exemple, je déconsidère IE8 ou encore j'utilise des tableaux à rallonge qui nécessitent des écran d'ordinateur et restent inapprochables via un téléphone. Pas pour l'embêter, mais simplement car ses besoins sont tels que faire autrement serait une hérésie - voire même impossible - qui le pousserait, au meilleur des cas, à devoir y passer plus de temps, donc à réduire son efficacité/productivité.

Bien sûr, il ne s'agit là que de grandes lignes, reflets d'un état d'esprit qui tente autant que faire se peut de suivre un chemin prêt établi menant vers un idéal qui ne peut, parfois, être touché du doigt ; s'en trouver au plus proche devenant alors une réussite.
Mais comme beaucoup de choses dans cette activité, il va de soi qu'en dehors de ces préceptes généraux il existe nombre de cas où il faille s'y pencher individuellement et dont les solutions retenues dépendront de facteurs propres à leur milieu.


A parte. Je ne souhaite pas remettre en question le bien fondé de vos diverses utilisations de JS. J'exprime ici un point de vue qui n'a nullement la prétention de vouloir vous convaincre mais dont l'unique objectif est de porter à vos yeux une vue peut-être différente de la votre. Gardons à l'esprit que personne n'a fondamentalement tord ou raison sur l'usage du JS et assimilés.
Se donner des contraintes est effectivement un bon moyen de faire fonctionner ses petites cellules grises, et on découvre plein de choses en réfléchissant à la façon de faire en se donnant ces contraintes.
Je pense en particulier au livre "La disparition" de Georges Perec, livre qui ne comporte pas la lettre "E", même dans le nom de l'auteur sur la couverture qu'il écrit "G.org.s P.r.c".

Pour des raisons historiques, je ne me suis jamais donné comme contrainte de ne pas utiliser JS, mais c'est un choix que je comprends parfaitement.
Je me suis donné d'autres contraintes, et de temps à autre j'en change, ce qui me permet de m'améliorer dans de nouveaux domaines.
La contrainte serait plutôt d'avoir un site accessible sans JS. Ne pas utiliser JS pour remplacer les scripts par différents hack n'est pas une très bonne idée.

Aussi ne pas oublier que comme pour les css on peut tout à fait "dégrader" l'aspect d'un site sans javascript. C'est ce qu'il faut avoir en tête si on veut rendre son contenu accessible (ainsi que pour la partie le SEO).
Je suis d'accord avec tout ceux qui recommande une utilisation minimale du JS. Je signale juste que les frameworks comme Angular, React et Vue ont la cote et c'est pas prêt de se calmer à mon avis. D'où la remarque "il faut vivre dans son époque".

Pour le reste, je reste d'avis que désactiver le JS c'est pas forcément pratique. Comme l'a bien signalé parsimonhi, sous quel critère tu décides de réactiver ? Personnellement, j'ai autre chose à faire que inspecter les URL ou le code de chaque fichier JS sur les sites que je consulte. Bongota l'a bien expliqué, tu accordes ta confiance aux sites officiels ou dont la réputation n'est plus à prouver. Pour le reste, c'est le loto.

Sinon juste pour rigoler, on en parle de ça ?

upload/1547042920-37407-photo2018-07-1313-30-36.jpg
Modérateur
Bonjour,
Depassage a écrit :
La contrainte serait plutôt d'avoir un site accessible sans JS. Ne pas utiliser JS pour remplacer les scripts par différents hack n'est pas une très bonne idée.

Aussi ne pas oublier que comme pour les css on peut tout à fait "dégrader" l'aspect d'un site sans javascript. C'est ce qu'il faut avoir en tête si on veut rendre son contenu accessible (ainsi que pour la partie le SEO).

Je n'arrête pas de penser à ces deux remarques depuis hier. Dans un premier temps, je me suis dit qu'effectivement, les solutions html+css sans JS pourraient être une "très mauvaise idée".

Mais bon, c'était assez intuitif comme jugement. Et j'ai voulu en avoir confirmation en reprenant l'exemple de papyJP : un input (bouton dans son cas) qui montre ou cache un texte (un titre dans son cas).

J'ai donc fait 2 versions, une avec et une sans javascript, en essayant d'être impartial . Si vous êtes pressé, voir :
https://jsfiddle.net/h35urodz/ pour la version sans JS,
https://jsfiddle.net/jbcfwxqo/ pour la version avec JS.

Dans les deux cas, j'ai considéré un html simple. J'aurais pu rajouté un <label> ou des attributs variés pour rendre la navigation plus claire pour les utilisateurs ayant des problèmes d'accessibilité, mais quelque soit ces ajouts, ils sont en gros les mêmes avec et sans JS.

Premier constat : on voit que le code est ultra simple dans les deux cas, voire un peu plus complexe avec JS, car il faut rajouter un attribut "onclick".

Le code html sans JS :
<div id="a">
	<input type="checkbox">
	<span>Lorem ipsum</span>
</div>


Le code html avec JS :
<div id="a">
	<input type="checkbox" onclick="magic(this);">
	<span>Lorem ipsum</span>
</div>


Pour le css, j'ai séparé le code en deux parties, une partie "mécanisme de base" (core mecanism) et une partie "décoration" (decoration). J'ai fait à peu près la même chose pour la partie "decoration" dans les deux cas bien qu'il soit probable qu'on puisse faire plus court avec du JS (mais pas forcément plus clair).

Deuxième constat : on voit que le code avec ou sans JS a à peu près la même complexité. Le mécanisme de base est ultra simple dans les deux cas.

Le code css sans JS :
/* core mecanism */

#a span {
  display: none;
}

#a input:checked~span {
  display: inline-block;
}

/* decoration */

#a {
  box-sizing: border-box;
  position: relative;
  min-height: 2rem;
  line-height: 2rem;
  background: #eee;
}

#a input {
  width: 2rem;
  padding: 0;
  margin: 0;
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}

#a input::-ms-check {
  display: none;
}

#a input:before,
#a input:after {
  position: absolute;
  display: block;
  top: 0;
  left: 0;
  width: 2rem;
  height: 2rem;
  color: transparent;
  background-color: #ccc;
  background-size: 50% 50%;
  background-position: center;
  background-repeat: no-repeat;
}

#a input:before {
  content: "+";
  z-index: 1;
  background-image: linear-gradient(transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent), linear-gradient(to right, transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent);
}

#a input:checked:after {
  content: "-";
  z-index: 2;
  background-image: linear-gradient(transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent);
}


Le code css avec JS :
/* core mecanism */

#a span {
  display: none;
}

#a.checked span {
  display: inline-block;
}

/* decoration */

#a {
  box-sizing: border-box;
  position: relative;
  min-height: 2rem;
  line-height: 2rem;
  background: #eee;
}

#a input {
  width: 2rem;
  padding: 0;
  margin: 0;
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}

#a input::-ms-check {
  display: none;
}

#a input:before,
#a input:after {
  position: absolute;
  display: block;
  top: 0;
  left: 0;
  width: 2rem;
  height: 2rem;
  color: transparent;
  background-color: #ccc;
  background-size: 50% 50%;
  background-position: center;
  background-repeat: no-repeat;
}

#a input:before {
  content: "+";
  z-index: 1;
  background-image: linear-gradient(transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent), linear-gradient(to right, transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent);
}

#a.checked input:after {
  content: "-";
  z-index: 2;
  background-image: linear-gradient(transparent, transparent 45%, #000 45%, #000 55%, transparent 55%, transparent);
}


Enfin, pour la version avec JS, il faut un bout de code (on aurait pu imaginer plein d'autres solutions évidemment pour ce code) :
function magic(e) {
  var a = e.parentNode;
  if (e.checked) {
    a.className = "checked";
  } else {
    a.className = "";
  }
}


Ma conclusion sur tout ceci, c'est que dans pas mal de cas (même si je n'ai certes pris qu'un exemple ici), il est probable que les versions sans javascript ne seront pas plus tordues (plus "hackeuses") que les solutions avec JS, et donc de ce fait pas forcément moins accessibles.

Par ailleurs, il n'est pas clair que pour l'accessibilité en général, ainsi que pour le référencement, les versions avec JS soient meilleures. Dans le cas général, j'ai de gros doutes sur les solutions consistant à mettre du JS pour espérer tant une meilleure accessibilité qu'un meilleur référencement ! Le JS est selon moi dans les 2 cas une difficulté supplémentaire à surmonter plus qu'une aide.

Amicalement,
Je suis pas expert en accessibilité, loin de là, mais je pense qu'il manque pas mal de chose a mettre en place pour que l'une ou l'autre des versions soit accessible. Par exemple pour un menu :
https://medium.com/@heyoka/responsive-pure-css-off-canvas-hamburger-menu-aebc8d11d793

Et comme précisé à la fin de l'article
It is also worth noting that a decent level (and arguably the most important level) of accessibility can be achieved without JavaScript. However, it is difficult to provide a robust level of accessibility without JavaScript’s ability to manipulate the DOM (e.g. focus management, ARIA attribute updates, etc.).

Il y a aussi quelques inconvénients au fait d'utiliser une checkbox pour ce genre de chose comme précisé dans l'article. Et d'une manière générale je pense que c'est une bonne pratique d'éviter de détourner des éléments html pour faire ce genre de chose afin d'éviter tout comportement imprévus.
Modérateur
Bonjour,
Depassage a écrit :
Je suis pas expert en accessibilité, loin de là, mais je pense qu'il manque pas mal de chose a mettre en place pour que l'une ou l'autre des versions soit accessible.

J'ai bien précisé que je n'avais pas mis tout ce qu'il fallait. Le débat ici est "avec ou sans javascript". Surcharger les exemples avec des attributs qui auraient été les mêmes dans les deux cas n'avait pas beaucoup d'intérêt.

Depassage a écrit :
Par exemple pour un menu :
https://medium.com/@heyoka/responsive-pure-css-off-canvas-hamburger-menu-aebc8d11d793


Je connais cet article. Il est imparfait selon moi ! Smiley cligne

Amicalement,
L'exemple que tu donnes est certainement meilleur sans JS mais c'est un mauvais exemple. Il n'y a aucun intérêt a utiliser ce hack de checkbox avec js et le fait de devoir utiliser la barre d'espace pour activer le "bouton" est contre intuitif.

Je ne participe pas a un débat avec ou sans javascript car celui-ci n'a pas de sens vu la proportion de site a utiliser javascript plus la nécessité d'utiliser javascript pour certaines interactions. Je dis juste que c'est une erreur de toujours chercher a utiliser les solutions sans javascript.
Modérateur
Bonjour,
Depassage a écrit :
L'exemple que tu donnes est certainement meilleur sans JS mais c'est un mauvais exemple. Il n'y a aucun intérêt a utiliser ce hack de checkbox avec js et le fait de devoir utiliser la barre d'espace pour activer le "bouton" est contre intuitif.

Ha bon ? Smiley cligne Sauf que la barre d'espace sert aussi à déclencher un click sur un bouton.

EDIT: de plus, l'emploi de checkbox pour "déplier" des informations (comme des arborescences) me semble tout aussi indiqué que des boutons.

C'est de la tétracapillosectomie, et l'une des (nombreuses) raisons pour lesquelles je considère que l'article auquel tu te réfères est "imparfait".

Depassage a écrit :
Je dis juste que c'est une erreur de toujours chercher a utiliser les solutions sans javascript.

Je n'ai pas dit qu'il fallait forcément le supprimer. Je l'utilise d'ailleurs régulièrement. Je dis juste qu'on l'utilise trop, et notamment en ce qui concerne l'accessibilité. On croit améliorer les choses en bricolant avec du JS. On ne fait que les empirer.

Par exemple, dans l'article que tu citais, le gars écrit : "You can also utilize JavaScript to prevent scrolling on the page while the menu is open." Ça fait peur ¡

Amicalement,
Modifié par parsimonhi (11 Jan 2019 - 11:10)
Sauf que
- personne ne peut savoir que c'est une checkbox visuellement car celle-ci est totalement obfusqué donc c'est pas du tout évident que ton utilisateur appuie sur espace.
- il n'y a aucune indication sur ce à quoi sert / a quoi est reliée cette checkbox et même si ton code est incomplet tu vas devoir rajouter du code en plus pour rendre ta solution accessible relativement à l'utilisation d'un bouton.
- tu n'as aucune garantie que ce hack fonctionne à 100% et tu n'en auras jamais en utilisant des éléments de façon détournées.

Au final tu as juste quelque chose de moins bon.

Et globalement vu qu'il est impossible de connaître toutes les conséquences de ce genre de hack il vaut mieux utiliser les balises dans le cadre pour lequel elles ont été crées, comme énoncé la première règle d'ARIA :
If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Aussi il ne faut pas oublier qu'on parle de remplacer un toggle ce qui ne représente rien en terme d'optimisation. Et quand la seule justification technique c'est de faire sans javascript c'est généralement une mauvaise justification.
Modifié par Depassage (11 Jan 2019 - 15:47)
Modérateur
Bonjour,
Depassage a écrit :
Aussi il ne faut pas oublier qu'on parle de remplacer un toggle ce qui ne représente rien en terme d'optimisation. Et quand la seule justification technique c'est de faire sans javascript c'est généralement une mauvaise justification.


OK, pourquoi pas.
Mais ce serait quoi ton code html avec javascript ?

Amicalement,
Pages :