3246 sujets
Critiques de vos sites: code et design
Bonjour,
En fait c'est la règle numéro 15 qui dit ceci :
"Toutes les <div> sont inutiles."
C'est un poil exagéré. Mais bon, c'est un peu ça quand même.
Voici les autres règles :
Règle n°1 : "Simplifie !"
Règle n°2 : "C'est promis, demain, j'arrête de coder !"
Règle n°3 : "Tu testeras toujours tes solutions avant de les publier !"
Règle n°4 : "Plus tu mets de balises html dans ta page, moins tu risques d'arriver à faire ce que tu veux."
Règle n°5 : "Tu ne devrais pas avoir à faire de version spécifique pour mobile. Par contre, tu dois prévoir un affichage de tes pages dans une fenêtre étroite, en gros caractères, et si l'utilisateur zoome."
Règle n°6 : "Tu ne devrais utiliser :hover qu'une fois que tout marche déjà sans :hover."
Règle n°7 : "Tu ne mettras pas de <br> pour ajouter des espaces entre les lignes. Tu utiliseras plutôt des margin et padding appropriés."
Règle n°8 : "Quand tu penses avoir besoin d'un float, essaie d'abord autre chose."
Règle n°9 : "Tu dois pouvoir tout faire dans ta page avec la navigation clavier."
Règle n°10 : "Si tu es développeur, n'oublie jamais que les administrateurs système ont plus d'un tour dans leur sac."
Règle n°11 : "Quand tu t'apprêtes à demander à la Terre entière si quelque chose marche ou pas, essaie de regarder avant si ça marche ou pas."
Règle n°12 : "Plus tu as de classes, moins elles servent (variante : tu utiliseras les classes avec parcimonie)."
Règle n°13 : "Si tu te demandes si tu as besoin de faire du scss ou pas, c'est que tu ne devrais pas faire du scss."
Règle n°14 : "Bootstrap ? On a plus vite fait d'écrire un code à partir de rien pour ses propres besoins que d'essayer de comprendre comment marche Bootstrap."
Règle n°15 : "Toutes les <div> sont inutiles."
Règle n°16 : "Tu n'utiliseras pas jquery quand tu n'as qu'une ligne de code à faire, ou même dix d'ailleurs."
Règle n°17 : "Si ta page est longue à charger, c'est que t'en as trop mis dedans."
Règle n°18 : "Ie n'est plus un navigateur. Et on se demande même d'ailleurs s'il l'a vraiment été."
Règle n°19 : "Quand on met un !important quelque part, c'est qu'on est en train de faire une erreur."
Règle n°20 : "L'utilisateur devrait le plus rarement possible avoir besoin de scroller latéralement l'ensemble de la page."
Règle n°21 : "Les scrollbars sont une espèce en voie de disparition continue."
Règle n°22 : "Teste au moins une fois tes pages sans css, ou sans js, ou ni l'un ni l'autre. Si ta page continue d'être utilisable, c'est que tu es sur le bon chemin."
Règle n°23 : "Vérifie toujours tout ce que t'envoient les utilisateurs côté serveur, même si tu l'as déjà fait côté client."
Règle n°24 : "Si une fonction n'est pas visible entièrement à l'écran dans l'éditeur de code, il est temps de la découper en plusieurs fonctions plus petites."
Règle n°25 : "Il reste toujours quelque chose à optimiser."
Règle n°26 : "Tout le monde a été débutant."
Règle n°27 : "Évite les px, sauf pour les bordures, et éventuellement pour les images."
Règle N°28 : "C'est l'utilisateur qui décide de la taille des caractères, pas le développeur."
Règle N°29 : "Les CMS ou les frameworks, c'est comme les hirondelles, ça va, ça vient."
Règle N°30 : "Quelque soit le problème que tu peux avoir, quelqu'un d'autre l'a déjà eu."
Règle N°31 : "Tu utilises peut-être document.write() dans ton javascript, mais c'est une erreur."
Règle N°32 : "Si tu as besoin de beaucoup d'attributs aria, pose-toi des questions sur le choix de tes balises HTML."
Règle N°33 : "Un code, c'est comme une maison, il faut y faire le ménage régulièrement."
Règle N°34 : "Si tu arrives à te servir de la propriété css position:sticky dans une page où il y a plus que 2 balises html, cours demander une augmentation à ton patron."
Règle N°35 : "Quand tu utilises plusieurs opérateurs dans une expression, tu ne feras jamais confiance à ta maitrise des règles de priorité et tu mettras toujours des () autour de chaque opération."
Règle N°36 : "Quand on a une erreur dans un code, on fait le diagnostic avant de faire des corrections, et non pas après ou jamais."
Règle N°37 : "Tu ne mettras pas de style inline dans ton HTML, même quand tu ne peux pas faire autrement."
Règle N°38 : "Si tu penses maitriser la sécurité informatique, c'est que tu ne la maitrises pas."
Règle N°39 : "Mieux vaut utiliser comme ancre n'importe quelle balise HTML ayant un id plutôt qu'une balise <a> qui ne servirait qu'à ça."
Règle N°40 : "Les @media queries, c'est comme les antibiotiques, elles sont utiles mais il ne faut pas en abuser."
Règle N°41 : "Les éditeurs de navigateurs font beaucoup d'efforts pour qu'on ne puisse pas cibler une version particulière de leur produit. Ne les déçois pas et ignore les versions anciennes."
Règle N°42 : "Tu testeras tes pages en local avec un serveur, et non pas en utilisant le protocole file://."
Règle N°43 : "Tu mettras des points-virgules en fin d'instruction, même quand tu penses que ce n'est qu'optionnel !"
Règle N°44 : "Presque toute bidouille en javascript cache une erreur de conception !"
Amicalement,
Bongota a écrit :
Règle de parsimonhi n° 43 : parsimonhi n'aime pas du tout les <div>, mais alors pas du tout. Smiley biggrin
Il m'en a fait enlever plusieurs sur mon code, au plus grand bénéfice de la clarté de ce code Smiley lol
Je dois l'avouer.
En fait c'est la règle numéro 15 qui dit ceci :
"Toutes les <div> sont inutiles."
C'est un poil exagéré. Mais bon, c'est un peu ça quand même.
Voici les autres règles :
Règle n°1 : "Simplifie !"
Règle n°2 : "C'est promis, demain, j'arrête de coder !"
Règle n°3 : "Tu testeras toujours tes solutions avant de les publier !"
Règle n°4 : "Plus tu mets de balises html dans ta page, moins tu risques d'arriver à faire ce que tu veux."
Règle n°5 : "Tu ne devrais pas avoir à faire de version spécifique pour mobile. Par contre, tu dois prévoir un affichage de tes pages dans une fenêtre étroite, en gros caractères, et si l'utilisateur zoome."
Règle n°6 : "Tu ne devrais utiliser :hover qu'une fois que tout marche déjà sans :hover."
Règle n°7 : "Tu ne mettras pas de <br> pour ajouter des espaces entre les lignes. Tu utiliseras plutôt des margin et padding appropriés."
Règle n°8 : "Quand tu penses avoir besoin d'un float, essaie d'abord autre chose."
Règle n°9 : "Tu dois pouvoir tout faire dans ta page avec la navigation clavier."
Règle n°10 : "Si tu es développeur, n'oublie jamais que les administrateurs système ont plus d'un tour dans leur sac."
Règle n°11 : "Quand tu t'apprêtes à demander à la Terre entière si quelque chose marche ou pas, essaie de regarder avant si ça marche ou pas."
Règle n°12 : "Plus tu as de classes, moins elles servent (variante : tu utiliseras les classes avec parcimonie)."
Règle n°13 : "Si tu te demandes si tu as besoin de faire du scss ou pas, c'est que tu ne devrais pas faire du scss."
Règle n°14 : "Bootstrap ? On a plus vite fait d'écrire un code à partir de rien pour ses propres besoins que d'essayer de comprendre comment marche Bootstrap."
Règle n°15 : "Toutes les <div> sont inutiles."
Règle n°16 : "Tu n'utiliseras pas jquery quand tu n'as qu'une ligne de code à faire, ou même dix d'ailleurs."
Règle n°17 : "Si ta page est longue à charger, c'est que t'en as trop mis dedans."
Règle n°18 : "Ie n'est plus un navigateur. Et on se demande même d'ailleurs s'il l'a vraiment été."
Règle n°19 : "Quand on met un !important quelque part, c'est qu'on est en train de faire une erreur."
Règle n°20 : "L'utilisateur devrait le plus rarement possible avoir besoin de scroller latéralement l'ensemble de la page."
Règle n°21 : "Les scrollbars sont une espèce en voie de disparition continue."
Règle n°22 : "Teste au moins une fois tes pages sans css, ou sans js, ou ni l'un ni l'autre. Si ta page continue d'être utilisable, c'est que tu es sur le bon chemin."
Règle n°23 : "Vérifie toujours tout ce que t'envoient les utilisateurs côté serveur, même si tu l'as déjà fait côté client."
Règle n°24 : "Si une fonction n'est pas visible entièrement à l'écran dans l'éditeur de code, il est temps de la découper en plusieurs fonctions plus petites."
Règle n°25 : "Il reste toujours quelque chose à optimiser."
Règle n°26 : "Tout le monde a été débutant."
Règle n°27 : "Évite les px, sauf pour les bordures, et éventuellement pour les images."
Règle N°28 : "C'est l'utilisateur qui décide de la taille des caractères, pas le développeur."
Règle N°29 : "Les CMS ou les frameworks, c'est comme les hirondelles, ça va, ça vient."
Règle N°30 : "Quelque soit le problème que tu peux avoir, quelqu'un d'autre l'a déjà eu."
Règle N°31 : "Tu utilises peut-être document.write() dans ton javascript, mais c'est une erreur."
Règle N°32 : "Si tu as besoin de beaucoup d'attributs aria, pose-toi des questions sur le choix de tes balises HTML."
Règle N°33 : "Un code, c'est comme une maison, il faut y faire le ménage régulièrement."
Règle N°34 : "Si tu arrives à te servir de la propriété css position:sticky dans une page où il y a plus que 2 balises html, cours demander une augmentation à ton patron."
Règle N°35 : "Quand tu utilises plusieurs opérateurs dans une expression, tu ne feras jamais confiance à ta maitrise des règles de priorité et tu mettras toujours des () autour de chaque opération."
Règle N°36 : "Quand on a une erreur dans un code, on fait le diagnostic avant de faire des corrections, et non pas après ou jamais."
Règle N°37 : "Tu ne mettras pas de style inline dans ton HTML, même quand tu ne peux pas faire autrement."
Règle N°38 : "Si tu penses maitriser la sécurité informatique, c'est que tu ne la maitrises pas."
Règle N°39 : "Mieux vaut utiliser comme ancre n'importe quelle balise HTML ayant un id plutôt qu'une balise <a> qui ne servirait qu'à ça."
Règle N°40 : "Les @media queries, c'est comme les antibiotiques, elles sont utiles mais il ne faut pas en abuser."
Règle N°41 : "Les éditeurs de navigateurs font beaucoup d'efforts pour qu'on ne puisse pas cibler une version particulière de leur produit. Ne les déçois pas et ignore les versions anciennes."
Règle N°42 : "Tu testeras tes pages en local avec un serveur, et non pas en utilisant le protocole file://."
Règle N°43 : "Tu mettras des points-virgules en fin d'instruction, même quand tu penses que ce n'est qu'optionnel !"
Règle N°44 : "Presque toute bidouille en javascript cache une erreur de conception !"
Amicalement,
Ouh là là... toi, t'as trop traîné sur Alsacréations...
Ça c'est très vrai. Ça me rappelle ces menus aux profondeurs abyssales des années 2005+.
Ça m'arrive de le faire lorsque je prototype. À la fin du dev' il ne doit plus en rester... en principe...
Je tiens beaucoup à cette règle.
parcimonie > parsimonhi > parcimonie > parsimonhi... ah, ah, ah, euh...
Ça tombe bien, avec cette version j'ai arrêté définitivement (j'étais sous Stylus mais bon). Merci à l'année 2023 qui nous a arrosée de ses bienfaits.
Et voilà comment j'en suis arrivé à produire mon propre framework front qu'au bout d'un moment j'utilise à la manière de... Bootstrap.
jQuery oui...
Attention React : tu es au sommet de ta gloire, mais écoute les trompettes qui sonnent de toute part ton hallali, c'est bientôt ton tour !
Ça aussi j'y tiens beaucoup.
Pour le coup, je suis bien content de dev' sous Node.js parce que c'est le même code de vérification, sans changer une ligne. Confortable.
Tiens, ça c'est pour moi. Il faut que j'en prenne de la graine...
+1. À ce propos mon site est entièrement zoomable.
À nouveau je concède de le faire parfois pour prototyper, ensuite j'analyse ce qui est redondant, donc pertinent pour être ensuite ajouté à la codebase. Le résidu non intégrable est bien souvent un mauvais pattern.
Media queries ???... ah oui !!! : c'est les trucs qu'on utilisait avant l'avènement de @container.
Yes !!!
Krom ! Ben euh... on m'attend à l'auberge...***
___
*** Celui qui me trouve la référence, je lui paierais à boire un jour à la Chaise-Dieu !
Modifié par Olivier C (28 Feb 2024 - 13:33)
parsimonhi a écrit :
Règle n°6 : "Tu ne devrais utiliser :hover qu'une fois que tout marche déjà sans :hover."
Ça c'est très vrai. Ça me rappelle ces menus aux profondeurs abyssales des années 2005+.
parsimonhi a écrit :
Règle n°7 : "Tu ne mettras pas de <br> pour ajouter des espaces entre les lignes. Tu utiliseras plutôt des margin et padding appropriés."
Ça m'arrive de le faire lorsque je prototype. À la fin du dev' il ne doit plus en rester... en principe...
parsimonhi a écrit :
Règle n°9 : "Tu dois pouvoir tout faire dans ta page avec la navigation clavier."
Je tiens beaucoup à cette règle.
parsimonhi a écrit :
Règle n°12 : "Plus tu as de classes, moins elles servent (variante : tu utiliseras les classes avec parcimonie)."
parcimonie > parsimonhi > parcimonie > parsimonhi... ah, ah, ah, euh...
parsimonhi a écrit :
Règle n°13 : "Si tu te demandes si tu as besoin de faire du scss ou pas, c'est que tu ne devrais pas faire du scss."
Ça tombe bien, avec cette version j'ai arrêté définitivement (j'étais sous Stylus mais bon). Merci à l'année 2023 qui nous a arrosée de ses bienfaits.
parsimonhi a écrit :
Règle n°14 : "Bootstrap ? On a plus vite fait d'écrire un code à partir de rien pour ses propres besoins que d'essayer de comprendre comment marche Bootstrap."
Et voilà comment j'en suis arrivé à produire mon propre framework front qu'au bout d'un moment j'utilise à la manière de... Bootstrap.
parsimonhi a écrit :
Règle n°16 : "Tu n'utiliseras pas jquery quand tu n'as qu'une ligne de code à faire, ou même dix d'ailleurs."
jQuery oui...
Attention React : tu es au sommet de ta gloire, mais écoute les trompettes qui sonnent de toute part ton hallali, c'est bientôt ton tour !
parsimonhi a écrit :
Règle n°22 : "Teste au moins une fois tes pages sans css, ou sans js, ou ni l'un ni l'autre. Si ta page continue d'être utilisable, c'est que tu es sur le bon chemin."
Ça aussi j'y tiens beaucoup.
parsimonhi a écrit :
Règle n°23 : "Vérifie toujours tout ce que t'envoient les utilisateurs côté serveur, même si tu l'as déjà fait côté client."
Pour le coup, je suis bien content de dev' sous Node.js parce que c'est le même code de vérification, sans changer une ligne. Confortable.
parsimonhi a écrit :
Règle n°24 : "Si une fonction n'est pas visible entièrement à l'écran dans l'éditeur de code, il est temps de la découper en plusieurs fonctions plus petites."
Tiens, ça c'est pour moi. Il faut que j'en prenne de la graine...
parsimonhi a écrit :
Règle N°28 : "C'est l'utilisateur qui décide de la taille des caractères, pas le développeur."
+1. À ce propos mon site est entièrement zoomable.
parsimonhi a écrit :
Règle N°37 : "Tu ne mettras pas de style inline dans ton HTML, même quand tu ne peux pas faire autrement."
À nouveau je concède de le faire parfois pour prototyper, ensuite j'analyse ce qui est redondant, donc pertinent pour être ensuite ajouté à la codebase. Le résidu non intégrable est bien souvent un mauvais pattern.
parsimonhi a écrit :
Règle N°40 : "Les @media queries, c'est comme les antibiotiques, elles sont utiles mais il ne faut pas en abuser."
Media queries ???... ah oui !!! : c'est les trucs qu'on utilisait avant l'avènement de @container.
parsimonhi a écrit :
Règle N°41 : "Les éditeurs de navigateurs font beaucoup d'efforts pour qu'on ne puisse pas cibler une version particulière de leur produit. Ne les déçois pas et ignore les versions anciennes."
Yes !!!
parsimonhi a écrit :
Règle N°43 : "Tu mettras des points-virgules en fin d'instruction, même quand tu penses que ce n'est qu'optionnel !"
Krom ! Ben euh... on m'attend à l'auberge...***
___
*** Celui qui me trouve la référence, je lui paierais à boire un jour à la Chaise-Dieu !
Modifié par Olivier C (28 Feb 2024 - 13:33)
Bonjour,
Pour les boutons pour agrandir et rétrécir les images, pourquoi mets-tu aria-label="enlarge" et aria-label="shrink" en anglais alors que ta page est en français ?
Les lecteurs d'écran vont fatalement choisir la mauvaise voix (c'est à dire qu'il vont choisir une voix française et non anglaise) pour prononcer ça (je n'ai pas regardé s'il y avait d'autres cas du même genre ailleurs dans tes pages : à vérifier). Il faut a minima ajouter un attribut lang="en", ou changer les valeurs de ces attributs aria-label et les mettre en français.
D'une manière générale il faut faire attention à la langue du contenu, et on doit s'assurer qu'il y a le bon attribut lang sur l'élément ou ses parents.
Note : en 2024, les lecteurs d'écran et les OS sont encore selon moi fortement bogués en la matière car dès qu'un contenu n'est pas dans la même langue que l'OS, ils ne choisissent pas toujours la bonne voix même si l'attribut lang correspond bien à la langue du contenu. Dans certaines situations, ils le font, dans d'autres ils ne le font pas et c'est une vraie prise de tête pour vérifier tout ça. Lorsque qu'on reste dans un contexte de langues latines, on n'aura certes au pire qu'un problème d'accent sur les bras. Mais si on a par exemple du japonais (ou n'importe quelle langue ne s'écrivant pas en caractères latins) dans une page en français (ou une autre langue s'écrivant en caractères latins), le lecteur d'écran ne prononcera parfois rien du tout, ce qui sera un peu plus fâcheux.
Amicalement,
Modifié par parsimonhi (28 Feb 2024 - 10:46)
Pour les boutons pour agrandir et rétrécir les images, pourquoi mets-tu aria-label="enlarge" et aria-label="shrink" en anglais alors que ta page est en français ?
Les lecteurs d'écran vont fatalement choisir la mauvaise voix (c'est à dire qu'il vont choisir une voix française et non anglaise) pour prononcer ça (je n'ai pas regardé s'il y avait d'autres cas du même genre ailleurs dans tes pages : à vérifier). Il faut a minima ajouter un attribut lang="en", ou changer les valeurs de ces attributs aria-label et les mettre en français.
D'une manière générale il faut faire attention à la langue du contenu, et on doit s'assurer qu'il y a le bon attribut lang sur l'élément ou ses parents.
Note : en 2024, les lecteurs d'écran et les OS sont encore selon moi fortement bogués en la matière car dès qu'un contenu n'est pas dans la même langue que l'OS, ils ne choisissent pas toujours la bonne voix même si l'attribut lang correspond bien à la langue du contenu. Dans certaines situations, ils le font, dans d'autres ils ne le font pas et c'est une vraie prise de tête pour vérifier tout ça. Lorsque qu'on reste dans un contexte de langues latines, on n'aura certes au pire qu'un problème d'accent sur les bras. Mais si on a par exemple du japonais (ou n'importe quelle langue ne s'écrivant pas en caractères latins) dans une page en français (ou une autre langue s'écrivant en caractères latins), le lecteur d'écran ne prononcera parfois rien du tout, ce qui sera un peu plus fâcheux.
Amicalement,
Modifié par parsimonhi (28 Feb 2024 - 10:46)
Bonjour,
J'ai essayé de vérifier la règle de Parsimonhi N°5 sur la page https://scriptura.github.io : "Tu ne devrais pas avoir à faire de version spécifique pour mobile. Par contre, tu dois prévoir un affichage de tes pages dans une fenêtre étroite, en gros caractères, et si l'utilisateur zoome."
On prend chrome, on rétrécit la fenêtre à son minimum de largeur (500px), et on zoome à 500%. Bon, j'avoue que ce test effraierait n'importe quel développeur même les plus confirmés. C'est mon préféré !
Le résultat, c'est que c'est perfectible, bien que Scriptura résiste assez bien. Dans ces largeurs (si 1em = 16px, on n'a que 100px de largeur de viewport) le scroll horizontal est acceptable. Encore faut-il qu'il soit prévu. Ce n'est pas le cas pour scriptura, et certains éléments de la page dont par exemple le menu dans le header en haut ne sont plus accessibles.
EDIT: en attendant un peu, finalement ce menu devient accessible, mais par moment seulement (je n'ai pas chercher à comprendre). Bidouilles en js ?
EDIT2 : ça s'éclaircit. Le hover sur l'icône ne fonctionne pas à tous les coups. Ce n'est pas dû à scriptura. Ça le fait sur ma machine pour tous les sites (et je ne sais pas pourquoi). Par contre, j'ai beau cliquer sur l'icône dans les moments où le hover ne fonctionne pas, rien ne se passe. Ceci semble ne pas respecter la règle de Parsimonhi N°6 : "Tu ne devrais utiliser :hover qu'une fois que tout marche déjà sans :hover."
EDIT3 : reste qu'ailleurs dans la page, d'autres éléments ne sont pas accessibles ou difficilement accessibles en fenêtre très étroite comme par exemple les onglets "Présentation", "Version", etc.
EDIT4 : je viens d'essayer la page https://scriptura.github.io/page/components.html et là, on ne voit pas du tout l'icône du menu en haut à droite en fenêtre très étroite.
Amicalement,
Modifié par parsimonhi (04 Mar 2024 - 10:15)
J'ai essayé de vérifier la règle de Parsimonhi N°5 sur la page https://scriptura.github.io : "Tu ne devrais pas avoir à faire de version spécifique pour mobile. Par contre, tu dois prévoir un affichage de tes pages dans une fenêtre étroite, en gros caractères, et si l'utilisateur zoome."
On prend chrome, on rétrécit la fenêtre à son minimum de largeur (500px), et on zoome à 500%. Bon, j'avoue que ce test effraierait n'importe quel développeur même les plus confirmés. C'est mon préféré !
Le résultat, c'est que c'est perfectible, bien que Scriptura résiste assez bien. Dans ces largeurs (si 1em = 16px, on n'a que 100px de largeur de viewport) le scroll horizontal est acceptable. Encore faut-il qu'il soit prévu. Ce n'est pas le cas pour scriptura, et certains éléments de la page dont par exemple le menu dans le header en haut ne sont plus accessibles.
EDIT: en attendant un peu, finalement ce menu devient accessible, mais par moment seulement (je n'ai pas chercher à comprendre). Bidouilles en js ?
EDIT2 : ça s'éclaircit. Le hover sur l'icône ne fonctionne pas à tous les coups. Ce n'est pas dû à scriptura. Ça le fait sur ma machine pour tous les sites (et je ne sais pas pourquoi). Par contre, j'ai beau cliquer sur l'icône dans les moments où le hover ne fonctionne pas, rien ne se passe. Ceci semble ne pas respecter la règle de Parsimonhi N°6 : "Tu ne devrais utiliser :hover qu'une fois que tout marche déjà sans :hover."
EDIT3 : reste qu'ailleurs dans la page, d'autres éléments ne sont pas accessibles ou difficilement accessibles en fenêtre très étroite comme par exemple les onglets "Présentation", "Version", etc.
EDIT4 : je viens d'essayer la page https://scriptura.github.io/page/components.html et là, on ne voit pas du tout l'icône du menu en haut à droite en fenêtre très étroite.
Amicalement,
Modifié par parsimonhi (04 Mar 2024 - 10:15)
Bonjour,
Si, moi je sais pourquoi : une div du .breadcrumb passe au-dessus du bouton du menu et la recouvre à moitié. Je peux éventuellement régler le problème en faisant un :
Pourquoi pas. Mais, est-ce que cela aurait du sens ?
500% de zoom sur une fenêtre de 500px de large on se retrouve avec 4 caractères max. par ligne pour les titres, éventuellement un mot complet pour les paragraphes... C'est vraiment pour tester !
Si je fais la même chose pour Alsacréations, j'explose littéralement le forum (et tous les sites avec autre chose que du contenu composé de balises <p>).
Il me semble qu'à une époque on ne pouvait pas zoomer au-delà de 400% sur Chrome. En tout les cas, les chartes "sévères" que j'ai pu lire sur les sites des pires ayatollahs de accessibilité ne s'engagent pas au-delà de ces 400%. Je trouve cela acceptable.
Surtout qu'en plus, chez moi on peut quand même pousser à 500% avec une fenêtre raisonnablement large : 1100-1120px pour 500% ça passe tranquille.
Si, moi je sais pourquoi : une div du .breadcrumb passe au-dessus du bouton du menu et la recouvre à moitié. Je peux éventuellement régler le problème en faisant un :
.cmd-nav {
position: relative;
z-index:10;
}Pourquoi pas. Mais, est-ce que cela aurait du sens ?
500% de zoom sur une fenêtre de 500px de large on se retrouve avec 4 caractères max. par ligne pour les titres, éventuellement un mot complet pour les paragraphes... C'est vraiment pour tester !
Si je fais la même chose pour Alsacréations, j'explose littéralement le forum (et tous les sites avec autre chose que du contenu composé de balises <p>).
Il me semble qu'à une époque on ne pouvait pas zoomer au-delà de 400% sur Chrome. En tout les cas, les chartes "sévères" que j'ai pu lire sur les sites des pires ayatollahs de accessibilité ne s'engagent pas au-delà de ces 400%. Je trouve cela acceptable.
Surtout qu'en plus, chez moi on peut quand même pousser à 500% avec une fenêtre raisonnablement large : 1100-1120px pour 500% ça passe tranquille.
Bonjour,
Ton site est plutôt très bon sur cette question. Là n'est pas le problème !
C'est en fait une question plus générale qu'il y a derrière (et je vais peut-être ouvrir un autre post sur ce sujet). Jusqu'à quelle taille un site doit fonctionner sans scroll horizontal, et on prévoit quoi si d'aventure il y a des dépassements qui nécessitent quand même de scroller ?
Pour ton site, en dessous d'une certaine taille, ça ne tient plus en largeur (certains des éléments en tout cas deviennent inutilisables). Dans ce cas, pourquoi ne pas faire en sorte qu'en dessous d'une certaine taille (que tu auras testée au préalable), on puisse scroller horizontalement, au lieu de laisser le body se contracter sans fin ?
Dans ton site, tu as prévu des word-breaks et autres dispositions du même genre pour éviter les dépassements. C'est bien, mais ça devient quand même difficilement utilisable en dessous d'une certaine largeur du viewport.
Selon moi, quelque soit le site, il faut tester le comportement en fenêtre très étroite, et si le design explose en dessous d'une certaine taille (ça peut très bien être 20em comme 10em voire moins, peu importe en fait), rajouter sur le body un min-width à cette taille et un overflow:auto sur les éventuels éléments pour lesquels ça ne passe vraiment pas sinon. Mais ce n'est que mon avis bien entendu.
Amicalement,
Modifié par parsimonhi (04 Mar 2024 - 11:14)
Ton site est plutôt très bon sur cette question. Là n'est pas le problème !
C'est en fait une question plus générale qu'il y a derrière (et je vais peut-être ouvrir un autre post sur ce sujet). Jusqu'à quelle taille un site doit fonctionner sans scroll horizontal, et on prévoit quoi si d'aventure il y a des dépassements qui nécessitent quand même de scroller ?
Pour ton site, en dessous d'une certaine taille, ça ne tient plus en largeur (certains des éléments en tout cas deviennent inutilisables). Dans ce cas, pourquoi ne pas faire en sorte qu'en dessous d'une certaine taille (que tu auras testée au préalable), on puisse scroller horizontalement, au lieu de laisser le body se contracter sans fin ?
Dans ton site, tu as prévu des word-breaks et autres dispositions du même genre pour éviter les dépassements. C'est bien, mais ça devient quand même difficilement utilisable en dessous d'une certaine largeur du viewport.
Selon moi, quelque soit le site, il faut tester le comportement en fenêtre très étroite, et si le design explose en dessous d'une certaine taille (ça peut très bien être 20em comme 10em voire moins, peu importe en fait), rajouter sur le body un min-width à cette taille et un overflow:auto sur les éventuels éléments pour lesquels ça ne passe vraiment pas sinon. Mais ce n'est que mon avis bien entendu.
Amicalement,
Modifié par parsimonhi (04 Mar 2024 - 11:14)
parsimonhi a écrit :
Dans ce cas, pourquoi ne pas faire en sorte qu'en dessous d'une certaine taille (que tu auras testée au préalable), on puisse scroller horizontalement, au lieu de laisser le body se contracter sans fin ?
C'est lié a certains choix de design, des choix pas si nombreux au final (peut-être des antipatterns ?).
Par exemple, mes ribbons bénéficient d'un déplacement transfom + rotate dont le conteneur dépasserait par défaut du cadre du site si je n’opérais pas un traitement `overflow-x: clip` sur le html et le body (j'avais tenté à un niveau plus granulaire il me semble, mais ça ne marchait pas sur tous les navigateurs). De même pour mon menu de navigation principale en version mobile, j'ai un peu oublié mais il me semble qu'il a besoin de ce type de règle. Quelques animations encore, qui dépassent du cadre, comme les marqueurs des cartes que j'ai reproduis sur le modèle de Google Maps (enfin il me semble, là aussi j'ai un peu oublié avec le temps).
Quoi qu'il en soit n'hésite pas à me titiller. Je trouve qu'il est aussi important de pouvoir justifier ses choix que de corriger du code.
Bien amicalement.
Bonjour,
@Olivier C
À propos du bouton scroll-top en bas à droite, c'est amusant, ce bottom: env(safe-area-inset-bottom, 0). Je ne connaissais pas.
Trois remarques :
1) c'est bien (je ne peux pas dire autrement, je fais quasi le même chose depuis des années),
2) cependant, ne vaudrait-il pas mieux afficher le bouton par défaut, et le cacher via JS quand on arrive en haut de page, plutôt que l'inverse (c'est quasi le même code) ? Tel que tu le fais, le bouton n'est pas utilisable sans JS. Dans le monde de 2024, c'est certes un détail, mais ça reste un principe général : quand tu fais du JS pour modifier le comportement d'une fonctionnalité, tu essaies quand c'est possible (et là, c'est possible facilement) que la fonctionnalité soit quand même utilisable sans JS,
3) ce matin, je me suis dit "bon, on est en 2024, et faire du JS pour cacher (ou afficher) ce bouton, c'est abusé. En fait, ça fait même des années que je me dis ça, mais j'ai procrastiné. Et donc, j'ai fait le code ci-dessous aujourd'hui qui fait le même effet, mais en css uniquement. Ton avis m'intéresse.
Amicalement,
@Olivier C
À propos du bouton scroll-top en bas à droite, c'est amusant, ce bottom: env(safe-area-inset-bottom, 0). Je ne connaissais pas.
Trois remarques :
1) c'est bien (je ne peux pas dire autrement, je fais quasi le même chose depuis des années),
2) cependant, ne vaudrait-il pas mieux afficher le bouton par défaut, et le cacher via JS quand on arrive en haut de page, plutôt que l'inverse (c'est quasi le même code) ? Tel que tu le fais, le bouton n'est pas utilisable sans JS. Dans le monde de 2024, c'est certes un détail, mais ça reste un principe général : quand tu fais du JS pour modifier le comportement d'une fonctionnalité, tu essaies quand c'est possible (et là, c'est possible facilement) que la fonctionnalité soit quand même utilisable sans JS,
3) ce matin, je me suis dit "bon, on est en 2024, et faire du JS pour cacher (ou afficher) ce bouton, c'est abusé. En fait, ça fait même des années que je me dis ça, mais j'ai procrastiné. Et donc, j'ai fait le code ci-dessous aujourd'hui qui fait le même effet, mais en css uniquement. Ton avis m'intéresse.
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Sticky to top button</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
html {scroll-behavior:smooth;}
body
{
position:relative;
margin:0;
padding:0;
}
main {font-size:10rem;}
div
{
position:absolute;
top:100vh;
height:calc(100% - 100vh);
width:100%;
}
a
{
--d:4rem;
--m:1rem;
position:sticky;
top:calc(100vh - var(--d) - var(--m));
margin:0 1rem 0 auto;
display:flex;
justify-content:center;
align-items:center;
height:var(--d);
width:var(--d);
border-radius:50%;
background-color:#0007;
color:#fff;
}
</style>
</head>
<body>
<main>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</main>
<div>
<a href="#">Haut</a>
</div>
</body>
</html>Amicalement,
Bonsoir Parsimonhi,
La règle bizarroïde en CSS c'est sensé prendre en compte les boutons de navigateurs surajoutés au-dessus d'une page web, en bas de page (comme avec Safari pour iPhone) et passer l'icône au-dessus de ces boutons le cas échéant. J'ai codé ça en pure théorie à un moment donné où ce truc était encore très prototype (il semble que le code soit supporté maintenant), mais depuis je n'ai pas encore vérifié concrètement le comportement de cette règle sur iPhone. J'ai oublié ! et comme je n'ai pas d'iPhone sous la main...
.
La plupart des dev' ne s'embêtent pas : ils ajoutent une énorme marge en bas et on se retrouve ainsi avec des flèches positionnées au 2/5ème de hauteur de l'écran. Pas beau !
Pour le point n°2 : oui, tout a fait. Après, comme ce n'est pas une fonctionnalité essentielle du site cela ne me dérangeait pas plus que ça qu'elle ne soit pas disponible sans JS. A contrario je n'aime pas trop l'idée que, par défaut, l'élément puisse "disparaître" aux yeux de l’utilisateur à la fin du chargement total de la page. C'est pour cela que j'avais fait ce compromis.
Mais ne perdons pas trop de temps à débattre là dessus car au final c'est bel et bien ton point n°3 qui m'intéresse et, oui, tu as raison sur toute la ligne : on doit peut-être pouvoir faire mieux aujourd'hui en CSS... et moi aussi j'ai procrastiné à ce sujet et j'en ai eu conscience ! La dernière fois que j'en ai eu conscience c'est lorsque j'ai inspecté la nouvelle refonte du blog de Raphaël.
Alors lui, il utilise une animation avec opacity qu'il déclenche avec un ensemble de nouveautés :
Pas mal, mais la flèche reste bel et bien à sa place et je trouve cela rédhibitoire. L'élément est invisible mais bel et bien présent (le passage de la souris le détecte), il gênera éventuellement la sélection de la souris ou l'activation d'un bouton. À défaut de pouvoir utiliser display:none avec une animation, ne pourrait-on pas améliorer la solution avec un transform:scale(0) ? À voir, ce sont des idées en l'air, il faudrait que je teste.
Autre problème avec sa solution ces règles ne fonctionnent pas avec Safari ou Firefox pour l'instant.
Et ta solution ? Je viens de tester sur un CodePen et je trouve l'astuce de l'escamotage pas mal du tout. Mais je viens de m’apercevoir qu'il y a un hic : pour utiliser ton sticky tu fais appel à une div conteneur qui empêche l’interaction de la souris sur les éléments de la page dès que l'on scrolle plus de 100vh. Regarde, j'ai mis en évidence la div : CodePen.
Maintenant que tu as relancé mon intérêt pour cette question, et que j'ai ta solution et celle de Raphaël en tête, je tenterais quelque chose ce WE. Si c'est concluant je vous en ferais part.
Ce soir je retourne côté backend (et je vais en baver un bon coup)...
La règle bizarroïde en CSS c'est sensé prendre en compte les boutons de navigateurs surajoutés au-dessus d'une page web, en bas de page (comme avec Safari pour iPhone) et passer l'icône au-dessus de ces boutons le cas échéant. J'ai codé ça en pure théorie à un moment donné où ce truc était encore très prototype (il semble que le code soit supporté maintenant), mais depuis je n'ai pas encore vérifié concrètement le comportement de cette règle sur iPhone. J'ai oublié ! et comme je n'ai pas d'iPhone sous la main...
.La plupart des dev' ne s'embêtent pas : ils ajoutent une énorme marge en bas et on se retrouve ainsi avec des flèches positionnées au 2/5ème de hauteur de l'écran. Pas beau !
Pour le point n°2 : oui, tout a fait. Après, comme ce n'est pas une fonctionnalité essentielle du site cela ne me dérangeait pas plus que ça qu'elle ne soit pas disponible sans JS. A contrario je n'aime pas trop l'idée que, par défaut, l'élément puisse "disparaître" aux yeux de l’utilisateur à la fin du chargement total de la page. C'est pour cela que j'avais fait ce compromis.
Mais ne perdons pas trop de temps à débattre là dessus car au final c'est bel et bien ton point n°3 qui m'intéresse et, oui, tu as raison sur toute la ligne : on doit peut-être pouvoir faire mieux aujourd'hui en CSS... et moi aussi j'ai procrastiné à ce sujet et j'en ai eu conscience ! La dernière fois que j'en ai eu conscience c'est lorsque j'ai inspecté la nouvelle refonte du blog de Raphaël.
Alors lui, il utilise une animation avec opacity qu'il déclenche avec un ensemble de nouveautés :
animation: scroll-top auto linear forwards;
animation-timeline: scroll(root); /* là */
animation-range: 0 150dvh; /* et là */Pas mal, mais la flèche reste bel et bien à sa place et je trouve cela rédhibitoire. L'élément est invisible mais bel et bien présent (le passage de la souris le détecte), il gênera éventuellement la sélection de la souris ou l'activation d'un bouton. À défaut de pouvoir utiliser display:none avec une animation, ne pourrait-on pas améliorer la solution avec un transform:scale(0) ? À voir, ce sont des idées en l'air, il faudrait que je teste.
Autre problème avec sa solution ces règles ne fonctionnent pas avec Safari ou Firefox pour l'instant.
Et ta solution ? Je viens de tester sur un CodePen et je trouve l'astuce de l'escamotage pas mal du tout. Mais je viens de m’apercevoir qu'il y a un hic : pour utiliser ton sticky tu fais appel à une div conteneur qui empêche l’interaction de la souris sur les éléments de la page dès que l'on scrolle plus de 100vh. Regarde, j'ai mis en évidence la div : CodePen.
Maintenant que tu as relancé mon intérêt pour cette question, et que j'ai ta solution et celle de Raphaël en tête, je tenterais quelque chose ce WE. Si c'est concluant je vous en ferais part.
Ce soir je retourne côté backend (et je vais en baver un bon coup)...
@Olivier,
voici une version en css qui n’interfère pas grâce a grid: https://codepen.io/gc-nomade/pen/abxdROq et avec la seconde colonne en 0 de largeur : https://codepen.io/gc-nomade/pen/dyLGgYg
no joking, it clearly floats!
Modifié par gcyrillus (08 Mar 2024 - 23:27)
voici une version en css qui n’interfère pas grâce a grid: https://codepen.io/gc-nomade/pen/abxdROq et avec la seconde colonne en 0 de largeur : https://codepen.io/gc-nomade/pen/dyLGgYg
no joking, it clearly floats!
Modifié par gcyrillus (08 Mar 2024 - 23:27)
@gcyrillus : l'astuce est excellente mais - à moins que j'ai manqué un truc - il me semble que le float ainsi utilisé n'est optimisé que pour une hauteur de 100vh :
Que se passerait-il si l'on décidait - comme bien souvent - de ne faire apparaître la flèche qu'à partir d'une page et demi (150vh, ou même 200vh) ?
J'ai l'impression que ce n'est pas possible. Mais bon, je ne suis pas bien concentré car je me penche actuellement sur un autre problème (côté backend avec Fastify ; rien à voir donc).
Que se passerait-il si l'on décidait - comme bien souvent - de ne faire apparaître la flèche qu'à partir d'une page et demi (150vh, ou même 200vh) ?
J'ai l'impression que ce n'est pas possible. Mais bon, je ne suis pas bien concentré car je me penche actuellement sur un autre problème (côté backend avec Fastify ; rien à voir donc).
Olivier C a écrit :
@gcyrillus : l'astuce est excellente mais - à moins que j'ai manqué un truc - il me semble que le float ainsi utilisé n'est optimisé que pour une hauteur de 100vh :
Que se passerait-il si l'on décidait - comme bien souvent - de ne faire apparaître la flèche qu'à partir d'une page et demi (150vh, ou même 200vh) ?
J'ai l'impression que ce n'est pas possible. Mais bon, je ne suis pas bien concentré car je me penche actuellement sur un autre problème (côté backend avec Fastify ; rien à voir donc).
c'est la hauteur du float qui va décider à quel moment l’élément sticky va apparaitre et être scotcher . 100vh n'est qu'une valeur minimale et arbitraire dans l'exemple
À moins de 100vh, il n'y a plus d’intérêt, un position:fixed sans grid ferait l'affaire.
codepen modifier avec une valeur à 150vh https://codepen.io/gc-nomade/pen/dyLGgYg (peut-être configurer en amont via CSS var()
Modifié par gcyrillus (09 Mar 2024 - 00:36)
Oui, sitôt que tu veut garder l’élément sous l'horizon, il y aura une barre de scroll.
Tu peut tester les container queries pour réduire le défaut :
extrait :
Tu peut tester les container queries pour réduire le défaut :
extrait :
div {
container-type:size;
--d: 4rem;
--m: 1rem;
grid-column: 2;
}
div::before {
content: "";
float: left;
height:150vh;
max-height:calc(100cqh + var(--d));
}Bonjour,
Si c'est bien ça, il suffit de rajouter :
EDIT: une autre possibilité serait d'utiliser des z-index (mais ça dépend alors de ce qu'il y a d'autre dans la page). Par exemple ici :
Quoi qu'il en soit, bien vu d'avoir détecté ça. J'étais passé à côté (en fait j'ai mis en place la solution hier sur un site en production, mais je n'avais pas vu ce problème parce qu'il y avait des z-index un peu partout qui involontairement l'empêchaient de se manifester : un coup de bol).
Amicalement,
Modifié par parsimonhi (09 Mar 2024 - 07:08)
Olivier C a écrit :Oui, je m'étais renseigné dans la foulée. C'est très intéressant.
La règle bizarroïde en CSS c'est sensé prendre en compte les boutons de navigateurs surajoutés au-dessus d'une page web, en bas de page (comme avec Safari pour iPhone) et passer l'icône au-dessus de ces boutons le cas échéant.
Olivier C a écrit :Quelles interactions ? Je ne suis pas sûr d'avoir bien compris. Tu veux dire par exemple qu'on ne peut plus sélectionner le texte avec la souris ?
Et ta solution ? Je viens de tester sur un CodePen et je trouve l'astuce de l'escamotage pas mal du tout. Mais je viens de m’apercevoir qu'il y a un hic : pour utiliser ton sticky tu fais appel à une div conteneur qui empêche l’interaction de la souris sur les éléments de la page dès que l'on scrolle plus de 100vh. Regarde, j'ai mis en évidence la div : CodePen.
Si c'est bien ça, il suffit de rajouter :
div {pointer-events:none;}
div a {pointer-events:auto;}EDIT: une autre possibilité serait d'utiliser des z-index (mais ça dépend alors de ce qu'il y a d'autre dans la page). Par exemple ici :
main {position:relative;z-index:1;}
div a {z-index:2;}Quoi qu'il en soit, bien vu d'avoir détecté ça. J'étais passé à côté (en fait j'ai mis en place la solution hier sur un site en production, mais je n'avais pas vu ce problème parce qu'il y avait des z-index un peu partout qui involontairement l'empêchaient de se manifester : un coup de bol).
Amicalement,
Modifié par parsimonhi (09 Mar 2024 - 07:08)
Bonjour,
Amicalement,
gcyrillus a écrit :Ça a l'air pas mal aussi. Bien joué.
Codepen modifier avec une valeur à 150vh https://codepen.io/gc-nomade/pen/dyLGgYg (peut-être configurer en amont via CSS var()
Amicalement,
parsimonhi a écrit :
Quelles interactions ? Je ne suis pas sûr d'avoir bien compris. Tu veux dire par exemple qu'on ne peut plus sélectionner le texte avec la souris ?
Si c'est bien ça, il suffit de rajouter :
div {pointer-events:none;} div a {pointer-events:auto;}
Oui mais c'est bien sûr, tu as raison ! Hou là là, je fatigue...
Du coup ta solution est pas mal du tout je trouve.
Je vais regarder cela plus en profondeur ce matin si j'arrive à trouver le temps.
Bonjour,
Je viens de faire quelques améliorations pour que la solution passe le test "500px de large, zoom de 500%, police par défaut de 72px". Toute ressemblance avec un autre sujet ne serait que purement fortuite !
Note : j'ai aussi essayé d'utiliser la fonction css env() sur les variables --mb et --mr du code ci-dessus, mais ça n'a rien donné de concluant (je ne sais pas si j'ai bien utilisé la fonction ou pas, et si j'avais le bon matériel de test ou pas (iphone Xs max, safari 17.3.1)) :
Amicalement,
Modifié par parsimonhi (09 Mar 2024 - 13:27)
Je viens de faire quelques améliorations pour que la solution passe le test "500px de large, zoom de 500%, police par défaut de 72px". Toute ressemblance avec un autre sujet ne serait que purement fortuite !
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Sticky to top button</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
html {scroll-behavior:smooth;}
body
{
position:relative;
margin:0;
overflow-wrap:anywhere;
}
main
{
font-size:5rem;
}
div
{
position:absolute;
top:100vh;
left:0;
right:0;
height:calc(100% - 100vh);
}
a
{
--f:min(10vmin,1rem);
--d:calc(4 * var(--f));
--mb:var(--f);
--mr:var(--f);
font-size:var(--f);
position:sticky;
top:calc(100vh - var(--d) - var(--mb));
margin:0 var(--mr) 0 auto;
display:flex;
justify-content:center;
align-items:center;
height:var(--d);
width:var(--d);
border-radius:50%;
background-color:#0007;
color:#fff;
}
div
{
position:absolute;
top:100vh;
left:0;
right:0;
height:calc(100% - 100vh);
}
div {pointer-events:none;}
div a {pointer-events:auto;}
</style>
</head>
<body>
<main>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</main>
<div>
<a href="#">Haut</a>
</div>
</body>
</html>Note : j'ai aussi essayé d'utiliser la fonction css env() sur les variables --mb et --mr du code ci-dessus, mais ça n'a rien donné de concluant (je ne sais pas si j'ai bien utilisé la fonction ou pas, et si j'avais le bon matériel de test ou pas (iphone Xs max, safari 17.3.1)) :
--mb:calc(var(--f) + env(safe-area-inset-bottom,0));
--mr:calc(var(--f) + env(safe-area-inset-right,0));
Amicalement,
Modifié par parsimonhi (09 Mar 2024 - 13:27)