Nouvelle version de ma codebase front

Bonjour à tous,

Ça fait longtemps que je n'ai pas proposé un site à critiquer : Scriptura.

Mon intérêt ici est de partager et bien sûr de trouver des axes d'amélioration.

En fait ce n'est pas vraiment un site, il s'agit d'un ensemble de pages statiques à visée documentaire - pour moi-même ! - c'est un recueil de templates et d'exemples de composants de mon cru. On y retrouvera donc les onglets, accordéons et autres lecteurs HTML5 que j'ai élaboré avec vos conseils éclairés. Tout est accessible à partir de la page d'accueil.

L'aspect le plus aboutit du site ce sont les composants, les templates, eux, seront réévalués lorsque je serais au point côté backend (en préparation sous Fastify).

À part les cartes Leaflet et Prism.js pour souligner la syntaxe des blocks de codes, tout est de mon cru (et même dans ces deux derniers cas j'ai opéré des personnalisations). Donc le site est potentiellement critiquable dans tous les domaines.

À oui, un dernier point : le site est PWA ready (Progressive Web App). Vous pouvez donc l'ouvrir sur votre smartphone comme une application, ou sur votre ordinateur de bureau comme un logiciel. Pour l'instant tout n'est pas disponible hors ligne, le service worker ne met en cache que les ressources principales.

Lâchez-vous.
Modifié par Olivier C (27 Feb 2024 - 14:16)

Bonjour,

C'est bien.

Mais est-ce qu'on peut tailler dans le vif ou bien faut-il rester soft ?

Amicalement,
Modifié par parsimonhi (27 Feb 2024 - 14:07)

"Olivier C" a écrit :
Lâchez-vous.

Vas-y, fais-toi plaisir

Salut Olivier,

J'aime bien l'apparence globale, c'est soigné et on sent une certaine maitrise du sujet. Voilà quelques points à noter après ma visite :

- Le bouton pour personnaliser les cookies ne fonctionne pas
- En refusant les cookies, la fenêtre réapparait à chaque chargement de page
- Le :hover des liens vers les composants déclenche une animation sur tous les éléments suivants dans la liste

D'une manière générale c'est propre, mais personnellement je vois pas comment profiter / réutiliser / s'inspirer de ton travail. Y'a des classes / sélecteurs qui sont indiqués mais à quoi bon sans l'implémentation ? C'est pas très sexy non plus de devoir fouiller toute l'arborescence de ton dépôt. Dans ce sens, ce dernier mérite un README un peu plus détaillé.

Voilà voilà ! Good job !

Salut,

La banque d'images que tu proposes, elle est sous quelle licence ? Les images sont réutilisables ?
Une très bonne ressource en tout cas, tout en prenant garde aux fonctions très récentes et pas encore implémentées sur tous les navigateurs.
Idem pour le bandeau RGPD, il m'a expédié quand j'ai refusé (mais tu as déjà répondu).
Par contre, tu n'as pas mis sur les lecteurs vidéos le petit script JS pour faire taire un lecteur quand on lance un autre. Sur les lecteurs audio, il est présent (ou dans ton code). J'ai même pu en lancer trois ensembles.
Pour rappel :

documentstener('play', e => { // Un seul lecteur actif sur la page
  [..('audio, video')]((media) => media !== e && mediase())
}, true);

Ce code fait coup double, il agit aussi bien sur un lecteur vidéo qu'audio. D'une vidéo en lecture, tu peux activer une autre vidéo ou un autre lecteur audio. Ils s'arrêteront de même.
Modifié par Bongota (27 Feb 2024 - 14:53)

Bongota a écrit :
La banque d'images que tu proposes, elle est sous quelle licence ? Les images sont réutilisables ?

Oui, pour le site il s'agit de Unsplash. Le crédit photo n'est pas requis, alors je me suis contenté du nom des auteurs des photos.

Par contre je ne vois pas ce que tu veux dire pour les players HTML5 : en effet ils sont configurés pour fonctionner un seul à la fois (sur ta suggestion d'il y a quelques mois qui, effectivement, était pertinente)... excepté le lecteur dédié à YouTube et qui est présent sur la même page, mais là il s'agit encore d'un autre script. Je devrais peut-être le préciser dans la page.

Pour Youtube, je me suis appuyé sur une demande de lionel_css3 sur Alsa (je ne retrouve plus le post), pris au jeu, j'avais répondu à sa question. Il n'avait pas donné suite mais au final j'ai intégré mon travail dans ma propre codebase. L'idée est que le lecteur Youtube n'est chargé que si clique sur l'image poster. Sinon on s'en tient au poster.
Modifié par Olivier C (27 Feb 2024 - 15:14)

Bonjour,

Bon, alors je commence avec les svgs sprites, vu qu'on avait évoqué cette technique y a pas très longtemps dans un autre post.

L'intérêt principal d'un svg sprite est de réunir plusieurs svgs en un seul fichier afin de n'avoir qu'un seul fichier téléchargé plutôt que plusieurs. Car à tailles de codes cumulées égales, il est sensiblement plus efficace de ne télécharger qu'un seul fichier plutôt que plusieurs.

J'ai pris au hasard une page : https://scriptura.github.io/page/articles.html

Dedans, il y a plusieurs svgs sprites, sauf qu'il n'y a qu'un seul svg par fichier svg (j'entends ici par un seul svg le fait qu'il n'y a qu'une seule balise <symbol> dans le fichier svg). Un peu dommage de ne pas les avoir réuni en un seul fichier, puisque c'est surtout pour ça qu'on utilise des svgs sprites en théorie.

J'imagine assez bien que tu n'utilises pas des svgs sprites dans le (seul ?) but d'optimiser la taille du code téléchargé, mais probablement aussi voire surtout pour pouvoir les styler plus ou moins depuis la page où tu les insères tout en n'ayant pas à les inclure (côté serveur) inline dans ton html (ce qui aurait certes conduit à des duplications de code importantes dans ledit code html si tu as de nombreuses fois les mêmes svgs qui y sont inclus). Admettons ! Mais ça fait quand même un peu bricolage. Et si c'est ça le but principal, autant inclure (côté serveur) inline en début de page l'ensemble des svgs sprites que tu utilises dans la page. Tes possibilités de styler les svg depuis la page où tu les insères seront encore plus souples, tout en minimisant au mieux la taille du code téléchargé.

Amicalement,

Bonjour,

Je prends une page au hasard : https://scriptura.github.io/page/components.html

Bon, OK, c'est pas la plus petite !

1) Je regarde le nombre de "<div>" dans la page : 648. J'ai failli faire une attaque.
2) Je regarde dans la console : y a du rouge !
3) Je fais un petit coup de lighthouse : 83% pour l'accessibilité. Sans être catastrophique, c'est tout de même perfectible  !

Amicalement,

Bonjour,

Je prends une page au hasard (ou plutôt devrais-je dire une url) : https://scriptura.github.io/page/components.html#section-maps

Je vois un rectangle gris à la place de la première map. Je ne sais pas si c'est voulu ou pas.

Edit: je viens de tester avec d'autres navigateurs et c'est pire (plusieurs cartes ne s'affichent pas). Mais on voit quand même les repères. Il est probable que ce soit dû à ma connexion (qui est "exotique" en ce moment) donc on oublie ma remarque.

Et hasard ou pas, ça me fait penser que j'ai passé 2 très bonnes semaines à la Chaise-Dieu l'été dernier.

Amicalement,
Modifié par parsimonhi (27 Feb 2024 - 18:30)

En fait le site dispose de deux fichiers de sprites SVG, "utils" et "player", qui servent l'UI du site. On peut voir l'ensemble de leurs icônes sur cette page : Icons.

Les autres "sprites", a contenu uniques, ont été pensés dans une philosophie différente : il s'agit de pouvoir intégrer des SVG, parfois lourds, à l'aide d'un simple `use`, comme on le ferait pour l'URL d'une image, pour donner une comparaison. Là encore, pour les contenus des articles, je pourrais faire appel à eux à partir... d'un simple shortcode.

Pour la page "composants", il s'agit de mettre ensemble tous les composants à disposition pour vérifier leurs effets de bord éventuels. Mais, oui, il serait bien d'optimiser son chargement. Une piste ? (Ajax ?)

Bonjour,

Olivier C a écrit :
Pour la page "composants", il s'agit de mettre ensemble tous les composants à disposition pour vérifier leurs effets de bord éventuels. Mais, oui, il serait bien d'optimiser son chargement.

Il ne semble pas y avoir de problème de perf sur cette page. Elle charge remarquablement vite vu la quantité de données qu'elle contient. En tout cas, je déconseille d'éventuelles bidouilles en js pour améliorer ça ("Presque toute bidouille en js cache une erreur de conception", règle de parsimonhi n°44).

Par contre, cette page a le défaut de toutes les pages "one-page", c'est qu'elle est ... "one-page". Quoique tu fasses, ça prendra du temps pour tout afficher et pour la visiter.

Amicalement,

parsimonhi a écrit :
Je vois un rectangle gris à la place de la première map. Je ne sais pas si c'est voulu ou pas. Edit: je viens de tester avec d'autres navigateurs et c'est pire (plusieurs cartes ne s'affichent pas). Mais on voit quand même les repères. Il est probable que ce soit dû à ma connexion (qui est "exotique" en ce moment) donc on oublie ma remarque.

Et oui, on veut tous se dégoogliser, malheureusement OpenStreetMap n'a pas les infrastructures de Google Maps, c'est là que l'on s'en rend compte. Si trop de gens switchent à l'avenir (et ce sera forcément le cas puisque Google Maps est devenu payant depuis déjà un moment, mais le temps que tout le monde s'y mette...) on aura des problèmes, parce que OSM c'est comme WIKI, ça peut pas entretenir son parc de serveurs sans argent...

parsimonhi a écrit :
Et hasard ou pas, ça me fait penser que j'ai passé 2 très bonnes semaines à la Chaise-Dieu l'été dernier.

Aaah ! le ponton...

Limite on aurait pu se croiser ! Mais - si je connais bien l'endroit pour y avoir souvent séjourné - cet été je n'y ai fait qu'une étape sur le lac en rentrant de vacances.

J'espère que tu es allé voir les fameuses tapisseries flamandes de l'abbaye (depuis leur restauration je ne sais pas où ils les ont exposées) ?

parsimonhi a écrit :
Je regarde dans la console : y a du rouge !

Figure toi que j'avais pressenti le coup et que l'idée m'avais traversée l'esprit de mettre un console.log() d'avertissement à l’intention de psychopathes comme vous ! Puis je me suis dit : "Bon, on va pas pousser le bouchon quand-même, soyons raisonnables !" En fait ces erreurs sont intentionnelles : si tu regarde bien se sont des erreurs 404 (ou 400) provoquées par un manque de ressources pour les players du site, ceci afin de voir comment ils se comportent en cas de ressources manquant à l'appel. Par exemple : la fonction "lecture à la suite" arriverait-t-elle à passer outre le fait qu'un lecteur d'une playliste n'a pu se charger ? (La réponse est oui).
Par contre il me reste réellement 2 erreurs non voulues que je n'ai pas encore corrigé :

main.js:1 Uncaught DOMException: Failed to execute 'end' on 'TimeRanges': The index provided (4294967295) is greater than the maximum bound (0).

Et là, j'ai vraiment du mal à débuger. Si quelqu'un a une idée je suis preneur (ça provient de mon script sur les players, au chargement de la page je crois).

Enfin, oui : il faut que j'améliore l'accessibilité. Je pense que je m'y collerais lorsque j'aurais peaufiné le côté backend, alors je reviendrais sur le front et je passerais le tout à la moulinette (avec aussi l'ajout de JSON-LD pour les micro-données).
Modifié par Olivier C (27 Feb 2024 - 23:26)

Bonjour,

Olivier C a écrit :
Figure toi que j'avais pressenti le coup et que l'idée m'a traversée de mettre un console.log() d'avertissement à l’intention de psychopathes comme vous !

Amicalement,

Bonjour,

Je n'ai pas vu de test de la balise <meter>. Y en-a-t-il un ?

Amicalement,

parsimonhi a écrit :
Je n'ai pas vu de test de la balise <meter>. Y en-a-t-il un ?

J'utilise une balise <meter> moi ? (je viens de faire une recherche globale : non). Par contre j'utilise des inputs de type "range" pour mes players et j'ai l'impression qu'il y a un couac au chargement, quelque part ici :

      // @note Le code récupère l'intégralité des plages téléchargées dans l'objet range et donne une indication de la quantité de médias réellement téléchargés, sans tenir compte de la localisation des plages.
      // @see  https://developer.mozilla.org/fr/docs/Web/Guide/Audio_and_video_delivery/buffering_seeking_time_ranges
 
      // @see  https://stackoverflow.com/questions/25651719
 
    ;['loadeddata', 'progress'].forEach(event => {
      media.addEventListener(event, () => {
        // @note 'media.onprogress' évite une erreur de lecture si execution avant l'événement 'loadeddata'.
        media.onprogress = () =>
          progressBar.style.setProperty(
            '--position-buffer',
            `${Math.floor((media.buffered.end(media.buffered.length - 1) / media.duration) * 100)}%`,
          ) // @note Un nombre entier suffit.
      })
    })

Sur GitHub : mediaPlayer.js#L338-L347

Je ne vois pas trop comment faire pour remédier au problème, je pensais avoir déjà traité le problème.

Quand au test... je ne sais même pas comment en faire un à ce niveau, mais je veux bien une petite explication (pour mon calendrier j'utilise déjà Jest).

PS : désolé pour le manque de réactivité, la petite dernière de la famille a eu besoin d'un peu d'attention (1 mois de vie !)...

Bongota a écrit :
Règle de parsimonhi n° 43 : parsimonhi n'aime pas du tout les &lt;div&gt;, mais alors pas du tout.

Oui, bien sûr, je suis tout a fait dans cette logique moi aussi.
Après il faut ce qu'il faut, si elles sont justifiées c'est autre chose.