Yep, on utilisera simplement les outils par défaut de JS.
C’est une très bonne nouvelle.
@SpaceFox merci, je ne connaissais pas Vanilla JS.
De rien, c’est un framework proposé par quelqu’un qui a de belles réalisations dans son CV. Et la blague me fait toujours rire (même si le site mériterait une petite mise à jour).
Bonsoir,
La bêta a été mise à jour avec toutes les corrections demandées :
N’hésitez pas à dire si vous voyez d’autres petites coquilles !
Je n’avais même pas fait attention de ce qu’au survol des dates de messages, quand elles sont suffisamment éloignées, on avait droit à l’attribut title pour donner la durée, exemple : « mercredi 01 octobre 2014 à 13h34 » affiche au survol « il y a 6 ans, 4 mois » avec une mise en forme spartiate. Mais quand le message a été modifié, on a justement le texte « Modifié (par …) » à côté, et là au survol on a droit à un tooltip… C’est vraiment pinailler, mais j’avoue que ça fait étrange d’avoir un "simple" title sur les dates et un tooltip JavaScript sur l’indication de modification, d’autant plus que la très jolie plume pour signaler l’auteur du sujet a elle aussi droit à un tooltip. J’imagine volontiers qu’il y a des histoires d’accessibilité là-dessous au vu des attributs utilisés pour les tooltips, mais je trouverais plus harmonieux que ce soit le même affichage pour les différents éléments. Après, title ou tooltips, si les premiers sont très probablement accessibles, les seconds s’accordent à la charte graphique.
C’est vraiment pinailler, mais j’avoue que ça fait étrange d’avoir un "simple"
titlesur les dates et un tooltip JavaScript sur l’indication de modification, d’autant plus que la très jolie plume pour signaler l’auteur du sujet a elle aussi droit à un tooltip. J’imagine volontiers qu’il y a des histoires d’accessibilité là-dessous au vu des attributs utilisés pour les tooltips, mais je trouverais plus harmonieux que ce soit le même affichage pour les différents éléments. Après,titleou tooltips, si les premiers sont très probablement accessibles, les seconds s’accordent à la charte graphique.
Alors vu que tu pinailles je vais aussi pinailler : les tooltips noires “construites” sont en CSS pur, pas de JS là dedans 
.
Sinon, c’est plus un non-changement qu’une volonté, et effectivement ça ferait sens de mettre une tooltip “propre” partout. Le raisonnement initial était que certaines des infos sont utiles immédiatement (la date de modification, on est susceptible de vouloir la connaître ; idem pour savoir ce que veut dire l’outil plume) ; quand d’autres moins (la version relative de la date est un peu moins utile). Mais en effet, ce serait cohérent de mettre la même infobulle partout, je suis d’accord.
En terme d’accessibilité ça ne change rien car les infobulles noires CSS sont conçues pour être accessible (car le texte affiché provient en réalité de l’attribut aria-describedby, ou aria-label pour la plume).
Alors vu que tu pinailles je vais aussi pinailler : les tooltips noires “construites” sont en CSS pur, pas de JS là dedans
Ah, ça peut se faire en CSS désormais ce genre de choses ? Fort pratique !
Je ne suis absolument pas intégrateur CSS, donc c’est le genre de technologie dont je n’ai pas connaissance des nouveautés/possibilités. Tout au plus je me suis amusé à regarder s’il y avait des événements sur le DOM, et n’en ai effectivement vu aucun, mais je n’ai pas creusé plus.
En réalité, le CSS est devenu très puissant, beaucoup de choses nécessitant JavaScript se font très bien sans aujourd’hui.
C’est le cas de ces infobulles (si tu es curieux, ça utilise un pseudo-élément correctement positionné et affiché lorsque l’élément parent est au survol ; code source), mais aussi de ces menus ouverts au clic et qui exploitent l’élément HTML5 details.
Bonjour,
J’ai mis en place sur la bêta une limitation du nombre de requêtes par seconde à la fois par IP et par URL, pour prévenir une éventuelle attaque par DDOS comme celle du 28 mars (deux petites attaques qui ont rendu le site inaccessible pendant quelques secondes). Néanmoins il ne faudrait pas qu’une telle limitation bloque des requêtes légitimes, donc je cherche à peaufiner les réglages de cette limitation.
Pouvez-vous aller sur la bêta naviguer normalement comme vous le feriez sur le serveur de production et me dire si vous rencontrez des erreurs ? Si vous rencontrez une erreur "429 Too Many Requests" c’est que vous avez été bloqué par ce nouveau dispositif.
Merci d’avance !
Édition 7 avril 17h59 : Je suis en train de faire des essais en ce moment même donc ne pas tester là tout de suite.
Édition 7 avril 19h07 : Fin de mes essais, j’ai augmenté la limite donc il ne devrait vraiment pas y avoir de soucis.
Bonsoir,
J’ai mis en bêta la prochaine version 30.1, n’hésitez donc pas à aller jeter un coup d’œil et nous remonter d’éventuels soucis !
Voici les changements principaux :
/@Pseudo au lieu de /membres/voir/Pseudo pour la page de profil du membre Pseudo
Bonsoir,
La prochaine version 30.2 est sur la bêta. La liste des commits qu’elle inclut est disponible ici. C’est principalement des changements qui seront invisibles pour les visiteurs du site (mise à jour de dépendances, correction de la doc, tests, refactorisation, etc).
Il y a tout de même quelques changements visibles, à tester un peu plus donc :
N’hésitez pas à tester tous ces points sur la bêta (les liens vers les PRs contiennent les instructions pour faire la QA, donc permettent de voir comment tester). Les bugs sont à rapporter sur le dépôt GitHub. S’il n’y a pas de problème rapporté, on peut envisager une mise en production dimanche 8 mai.
On fêtera la mise en prod pendant l’AG !
Merci pour votre travail 
Je verrai si j’ai le temps de tester des trucs ça et là
Bonsoir,
La prochaine version 30.3 est sur la bêta. La liste des commits qu’elle inclut est disponible ici.
Parmi les points particuliers à tester :
N’hésitez pas à tester tous ces points sur la bêta (les liens vers les PRs contiennent les instructions pour faire la QA, donc permettent de voir comment tester). Les bugs sont à rapporter sur le dépôt GitHub. S’il n’y a pas de problème rapporté, on peut envisager une mise en production dimanche 31 juillet.
Bonsoir,
La prochaine version 30.4 est sur la bêta. La liste des commits qu’elle inclut est disponible ici.
Parmi les points particuliers à tester :
N’hésitez pas à tester tous ces points sur la bêta (les liens vers les PRs contiennent les instructions pour faire la QA, donc permettent de voir comment tester) et tester aussi le fonctionnement correct du reste du site. Les bugs sont à rapporter sur le dépôt GitHub. S’il n’y a pas de problème rapporté, on peut envisager une mise en production dimanche 6 novembre, en même temps que la mise à jour mensuelle des serveurs.
Bonsoir,
La prochaine version 30.5 est sur la bêta. La liste des commits qu’elle inclut est disponible ici (seulement les commits à partir du 5 décembre 2022 sont à considérer en réalité, les précédents sont déjà dans la version actuelle 30.4a).
Parmi les points particuliers à tester :
N’hésitez pas à tester tous ces points sur la bêta (les liens vers les PRs contiennent les instructions pour faire la QA, donc permettent de voir comment tester) et tester aussi le fonctionnement correct du reste du site. Les bugs sont à rapporter sur le dépôt GitHub. S’il n’y a pas de problème rapporté, on peut envisager une mise en production dimanche 25 juin.
J’ai fait le tour des différents changements et nouvelles fonctionnalités, tout semble bien fonctionner. J’ai juste remarqué une incohérence entre la gestion des labels et des objectifs dans la zone d’administration, donc j’ai ouvert une PR pour corriger ça. Ce serait bien qu’elle soit dans la version 30.5, donc je vais attendre que quelqu’un fasse la QA.
Puisque ça devient un peu juste pour annoncer une maintenance pour aujourd’hui 18h, je ferai la mise en production à un autre moment, dès que la PR sera mergée, probablement la semaine prochaine.
Bonsoir,
La prochaine version 30.6 est sur la bêta. La liste des commits qu’elle inclut est disponible ici, la liste des PRs fusionnées dans cette version est dans la colonne Fusionnée.
Parmi les points particuliers à tester :
N’hésitez pas à tester tous ces points sur la bêta. Les bugs sont à rapporter sur le dépôt GitHub. S’il n’y a pas de problème rapporté, on peut envisager une mise en production dimanche prochain, 17 mars.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte