Arreter la dépendance de la saisie DATE à Jqueryui #43

Closed
opened 2 years ago by pierre.laszczak · 17 comments
Collaborator

Bonjour,

Je me permets de faire un ticket pour raler sans proposer de solution toute faite :D

La saisie date dépend intrésequement de JqueryUi à cause du #ENV{type} et certainnement d'autre mécanisme que je n'ai pas eu le temps de cerner.

En l'etat il n'est pas possible d'avoir un type=date en html5 sans que le datePicker jqueryUi se déclenche et charge TOUTES les libs JqueryUI.

Sur IRC on m'a conseillé de faire un champ text, mais ce n'est pas du tout la bonne solution ; je veux un champ de type date HTML5 sans me voir Imposer le picker JUI.
(C'est l'inverse qu'il faudrait faire le picker devrait etre sur un input type text avec une classe date pour ne pas venir interférer avec le htm5)

Je ne comprends pas pourquoi le markup de cette saisie est si bancal. Pourquoi ne pas avoir laissé a l'initiative de la personne qui utilise cette saisie le soin d'ajouter une class="datepicker" ou éventuellement prendre en compte la meta HTML5 de spip.

Cette saisie date est complexe et ne permet pas de faire les choses correctement.

Actuellement en HTML5 il existe 5 valeurs d'attribut type à coller sur les inputs pour gerer des dates:

date
https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/date

datetime-local
https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/datetime-local

month
https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/month

week
https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/week

time
https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/time

Pour la saisie date, ce que j'entrevoi est de creer un modèle de saisie date_html5 qui ne dépendrait pas du modèle input de base.

De plus elle pourrait éventuellement venir se charger dans la saisie date À condition que l'option HTML5 soit active il faudra certainnement mapper les diffèrentes options afin d'avoir un markup clair.

Voilà

Bonjour, Je me permets de faire un ticket pour raler sans proposer de solution toute faite :D La saisie date dépend intrésequement de JqueryUi à cause du [#ENV{type}](https://git.spip.net/spip-contrib-extensions/saisies/src/branch/master/saisies/input.html#L62) et certainnement d'autre mécanisme que je n'ai pas eu le temps de cerner. En l'etat il n'est pas possible d'avoir un type=date en html5 sans que le datePicker jqueryUi se déclenche et charge **TOUTES** les libs JqueryUI. Sur IRC on m'a conseillé de faire un champ text, mais ce n'est pas du tout la bonne solution ; je veux un champ de type date HTML5 sans me voir Imposer le picker JUI. (C'est l'inverse qu'il faudrait faire le picker devrait etre sur un input type text avec une classe date pour ne pas venir interférer avec le htm5) Je ne comprends pas pourquoi le markup de cette saisie est si bancal. Pourquoi ne pas avoir laissé a l'initiative de la personne qui utilise cette saisie le soin d'ajouter une class="datepicker" ou éventuellement prendre en compte la meta HTML5 de spip. Cette saisie date est complexe et ne permet pas de faire les choses correctement. Actuellement en HTML5 il existe 5 valeurs d'attribut type à coller sur les inputs pour gerer des dates: date https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/date datetime-local https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/datetime-local month https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/month week https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/week time https://developer.mozilla.org/fr/docs/Web/HTML/Element/input/time Pour la saisie date, ce que j'entrevoi est de creer un modèle de saisie date_html5 qui ne dépendrait pas du modèle input de base. De plus elle pourrait éventuellement venir se charger dans la saisie date À condition que l'option HTML5 soit active il faudra certainnement mapper les diffèrentes options afin d'avoir un markup clair. Voilà
Owner

Je crois que la saisie date combinée au dateur permet toujours des choses en plus par rapport à l'input date de base :

Cela dit on peut déjà utiliser directement la saisie input pour avoir un input date html5 brut de pomme :

[(#SAISIE{input, madate, type=date, label=Input de base})]

Mais sans doute qu'une option pour désactiver le dateur sur la saisie date aurait sa place.

Je crois que la saisie date combinée au dateur permet toujours des choses en plus par rapport à l'input date de base : * Saisie de l'horaire (pas l'impression que ce soit possible avec un input date, mais je peux me tromper) * Accepter plusieurs formats de date (spip, mysql, etc). L'input date accepte plusieurs formats aussi, mais faut lui donner un pattern, ça à l'air plus restreint et compliqué : https://developer.cdn.mozilla.net/en-US/docs/Web/HTML/Element/input/date#Handling_browser_support * Et support des vieux navigateurs Cela dit on peut déjà utiliser directement la saisie input pour avoir un input date html5 brut de pomme : ``` [(#SAISIE{input, madate, type=date, label=Input de base})] ``` Mais sans doute qu'une option pour désactiver le dateur sur la saisie date aurait sa place.
Owner

Fun fact : si j'affiche sur la même page une saisie date et une saisie input type=date, alors le dateur s'active sur les 2 :p

[(#SAISIE{input, madate, type=date, label=Input de base})]

[(#SAISIE{date, madate2, label=Input avec le dateur})]
Fun fact : si j'affiche sur la même page une saisie date et une saisie input type=date, alors le dateur s'active sur les 2 :p ``` [(#SAISIE{input, madate, type=date, label=Input de base})] [(#SAISIE{date, madate2, label=Input avec le dateur})] ```
Poster
Collaborator

Cela dit on peut déjà utiliser directement la saisie input pour avoir un input date html5 brut de pomme :

[(#SAISIE{input, madate, type=date, label=Input de base})]

Mais sans doute qu'une option pour désactiver le dateur sur la saisie date aurait sa place.

Non pas dans le privé ou la class date et généré via le #ENV{type} ce qui déclenche le dateur JUI.

> Cela dit on peut déjà utiliser directement la saisie input pour avoir un input date html5 brut de pomme : > > ``` > [(#SAISIE{input, madate, type=date, label=Input de base})] > ``` > > Mais sans doute qu'une option pour désactiver le dateur sur la saisie date aurait sa place. Non pas dans le privé ou la class date et généré via le #ENV{type} ce qui déclenche le dateur JUI.
Owner

Ah, donc c'est le bug que je signalais après alors : dès que le dateur est chargé il semble s'activer sur tous les inputs date.

Tu as vu s'il ciblait la classe input.date, ou alors plus généralement les input[type=date] ?

Ah, donc c'est le bug que je signalais après alors : dès que le dateur est chargé il semble s'activer sur tous les inputs date. Tu as vu s'il ciblait la classe `input.date`, ou alors plus généralement les `input[type=date]` ?

Avant tout il faut lister : que fait le picker du noyau en entier, que fait le picker navigateur html5, est-ce que ça fait réellement 100% pareil ?

Avant tout il faut lister : que fait le picker du noyau en entier, que fait le picker navigateur html5, est-ce que ça fait réellement 100% pareil ?
Poster
Collaborator

Avant tout il faut lister : que fait le picker du noyau en entier, que fait le picker navigateur html5, est-ce que ça fait réellement 100% pareil ?

non,non @rastapopoulos c'est pas la question.

Je ne souhaite pas supprimer ou remplacer le fonctionnement actuel mais avoir la possibilité de creer une saisie type=date sans avoir:

  • à charger obligatoirement tout le JqueryUi ; 500Ko (bordel!)
  • à Gérer les traitements associés (normaliser)

Ce que préconise @tcharlss
[(#SAISIE{input, madate, type=date, label=Input de base})] marche à moitié et n'est pas possible via l'interface cextra. de plus le comportement semble diffèrent entre le privé et le public.

Dans 99% des cas l'attribut type="date" sans le Jqury UI suffirait

  • c'est simple et leger,
  • Pas de langue ou traduction à gérer,
  • format standard en sortie (pas de conversion au post),
  • accessibilté

Mais, Je m'aperçois qu'en 2020, cette grosse daube de Safari™ sur Mac ne gère pas les input type date, alors que safari IOS™ le gère depuis 2012.

> Avant tout il faut lister : que fait le picker du noyau en entier, que fait le picker navigateur html5, est-ce que ça fait réellement 100% pareil ? non,non @rastapopoulos c'est pas la question. Je ne souhaite pas supprimer ou remplacer le fonctionnement actuel mais avoir la possibilité de creer une saisie type=date sans avoir: - à charger **obligatoirement tout le JqueryUi** ; 500Ko (bordel!) - à Gérer les traitements associés (normaliser) Ce que préconise @tcharlss `[(#SAISIE{input, madate, type=date, label=Input de base})]` marche à moitié et n'est pas possible via l'interface cextra. de plus le comportement semble diffèrent entre le privé et le public. Dans 99% des cas l'attribut type="date" **sans** le Jqury UI suffirait - c'est simple et leger, - Pas de langue ou traduction à gérer, - format standard en sortie (pas de conversion au post), - accessibilté **Mais**, Je m'aperçois qu'en 2020, cette grosse daube de Safari™ sur Mac ne gère pas les input type date, alors que safari IOS™ le gère depuis 2012.
pierre.laszczak added the
invalide
label 2 years ago
Collaborator

Les assistances des smartphones sur les input typés (number, date, ...) ne sont pas toujours au top.
Surtout pour les dates, ils sont souvent plus pénibles à utiliser qu'un date picker bien foutu.

Les assistances des smartphones sur les input typés (number, date, ...) ne sont pas toujours au top. Surtout pour les dates, ils sont souvent plus pénibles à utiliser qu'un date picker bien foutu.

bé si si car par défaut (dans saisies même) on va PAS fournir plusieurs saisies de date à la fois, différentes mais pas vraiment, et que les gens vont rien comprendre de la différence

Donc il faut bien arriver à développer/maintenir une seule saisie de date, qui contient tout ce qu'on veut avoir dedans, que ce soit uniquement avec un JS ou que ce soit intelligent avec le HTML5 en prio et un JS en fallback pour les navs où c'est pas top. D'où le fait qu'il faut bien être sûr de tout avoir.

Surtout si même le picker interne au nav est pas super, notamment en accessibilité.

Mais en plus c'est même pas un ticket propre à saisie, vu que "comment on rentre une date" c'est fourni par le core ça, donc ça devrait être un ticket du noyau pour améliorer ce point génériquement, partout, avec ou sans saisies.

En tout cas pour saisie, moi je suis plutôt contre avoir plusieurs saisies de date et le JS doit rester tant que (avec le listing dont je parle) on prouve pas que celui en HTML5 peut effecitvement le remplacer entièrement.

bé si si car par défaut (dans saisies même) on va PAS fournir plusieurs saisies de date à la fois, différentes mais pas vraiment, et que les gens vont rien comprendre de la différence Donc il faut bien arriver à développer/maintenir une seule saisie de date, qui contient tout ce qu'on veut avoir dedans, que ce soit uniquement avec un JS ou que ce soit intelligent avec le HTML5 en prio et un JS en fallback pour les navs où c'est pas top. D'où le fait qu'il faut bien être sûr de tout avoir. Surtout si même le picker interne au nav est pas super, notamment en accessibilité. Mais en plus c'est même pas un ticket propre à saisie, vu que "comment on rentre une date" c'est fourni par le core ça, donc ça devrait être un ticket du noyau pour améliorer ce point génériquement, partout, avec ou sans saisies. En tout cas pour saisie, moi je suis plutôt contre avoir plusieurs saisies de date et le JS doit rester tant que (avec le listing dont je parle) on prouve pas que celui en HTML5 peut effecitvement le remplacer entièrement.
Owner

Oui enfin, sans vouloir être désagréable :

  • dans le core on a un dateur dont l'intégration et les choix techniques ont été fait pour l'espace privé, dans lequel on avait choisit d'intégrer jQuery UI, et pour lequel on avait déjà des habitudes de saisie de dates
  • les développeurs de "Saisies" se sont dit : "ah tiens, il y a un dateur prêt à l'emploi dans le core, créons une saisie basée sur ça" sans de poser la question de la pertinence du picker, de provoquer le chargement de jQuery UI complet dans le site public pour un input etc.

Et maintenant vous repassez la patate chaude au core "ah mais c'est lourd, c'est compliqué, on peut pas avoir mieux ?".

BREF.

Oui enfin, sans vouloir être désagréable : - dans le core on a un dateur dont l'intégration et les choix techniques ont été fait **pour l'espace privé**, dans lequel on avait choisit d'intégrer jQuery UI, et pour lequel on avait déjà des habitudes de saisie de dates - les développeurs de "Saisies" se sont dit : "ah tiens, il y a un dateur prêt à l'emploi dans le core, créons une saisie basée sur ça" sans de poser la question de la pertinence du picker, de provoquer le chargement de jQuery UI complet dans le site public pour un input etc. Et maintenant vous repassez la patate chaude au core "ah mais c'est lourd, c'est compliqué, on peut pas avoir mieux ?". BREF.
Owner

Indépendamment de la remarque de cédric sur le lien avec le core (sur lequel je n'ai pas forcément d'avis en l'absence d'étude approfondie), je rejoint parfaitement Rastapoulos : évitons de multipler les saisies date qui varient à un pouième incomprénsible.

Il y a deja beaucoup de saisies, avec beaucoup de réglages, donc limitons les dégâts.

Indépendamment de la remarque de cédric sur le lien avec le core (sur lequel je n'ai pas forcément d'avis en l'absence d'étude approfondie), je rejoint parfaitement Rastapoulos : évitons de multipler les saisies date qui varient à un pouième incomprénsible. Il y a deja beaucoup de saisies, avec beaucoup de réglages, donc limitons les dégâts.

Et la saisie date "avec picker du core", vient deeeeee… Yffic (RIP)
ec9841e13a

Pas avec picker du core donc, à l'époque c'était fourni dans Bonux, donc pas juste pour le core.
Et "les devs de Saisies" ne se sont donc rien dit du tout vu qu'ils n'existaient pas à ce moment (je n'avais même pas fini totalement la refonte avec API, et Yffic a fait cet ajout quand les gens utilisaient que les #SAISIE à mettre en squelettes, au tout début du plugin)

Et la saisie date "avec picker du core", vient deeeeee… Yffic (RIP) https://git.spip.net/spip-contrib-extensions/saisies/commit/ec9841e13ae3b9fee7a9f76d64e7b8f0df769c75 Pas avec picker du core donc, à l'époque c'était fourni *dans Bonux*, donc pas juste pour le core. Et "les devs de Saisies" ne se sont donc rien dit du tout vu qu'ils n'existaient pas à ce moment (je n'avais même pas fini totalement la refonte avec API, et Yffic a fait cet ajout quand les gens utilisaient que les #SAISIE à mettre en squelettes, au tout début du plugin)
Collaborator

Ah tiens au fait, un date picker assez complet, léger (Weighs only ~10kb minified and Gzip’ed (this includes all styles and icons), développé avec l'accessibilité en tête (supporting WCAG 2.1 as well as we can).

https://duetds.github.io/date-picker/
https://github.com/duetds/date-picker

Voilà, c'est juste pour info, si quelqu'un a envie de se pencher là dessus.

Ah tiens au fait, un date picker assez complet, léger *(Weighs only ~10kb minified and Gzip’ed (this includes all styles and icons)*, développé avec l'accessibilité en tête *(supporting WCAG 2.1 as well as we can)*. https://duetds.github.io/date-picker/ https://github.com/duetds/date-picker Voilà, c'est juste pour info, si quelqu'un a envie de se pencher là dessus.

ça a l'air super oui

(et je maintiens aussi que jquery ui c'est vieux et pas forcément accessible et que peu importe les "habitudes de saisies", si on trouve une méthode plus clean, que ce soit HTML5 pur + JS fallback ou JS uniquement, et bien ça devrait être amélioré dès le core, pas juste dans Saisies)

ça a l'air super oui (et je maintiens aussi que jquery ui c'est vieux et pas forcément accessible et que peu importe les "habitudes de saisies", si on trouve une méthode plus clean, que ce soit HTML5 pur + JS fallback ou JS uniquement, et bien ça devrait être amélioré dès le core, pas juste dans Saisies)
Collaborator

@nicod_ Très bien, certes, mais il propose pas l’heure avec ? C’est préconisé d’avoir deux champs dans ce cas ? un pour la date et un pour l’heure (ou les heures) peut être ?

@nicod_ Très bien, certes, mais il propose pas l’heure avec ? C’est préconisé d’avoir deux champs dans ce cas ? un pour la date et un pour l’heure (ou les heures) peut être ?

@marcimat mais dans le noyau non plus on n'utilise pas l'heure dans le même picker qui s'ouvre, c'est un champ séparé à côté. Et pareil dans agenda, c'est aussi un champ à côté, donc c'est indépendant du picker qui s'ouvre spécifiquement sur le champ de date seul non ?

@marcimat mais dans le noyau non plus on n'utilise pas l'heure dans le même picker qui s'ouvre, c'est un champ séparé à côté. Et pareil dans agenda, c'est aussi un champ à côté, donc c'est indépendant du picker qui s'ouvre spécifiquement sur le champ de date seul non ?
Collaborator

Il faut de toute façon que chaque <input> ait son propre <label> (ou son attribut aria-labelledby), son propre message d'erreur etc...
Après, les aria-labelledby, aria-describedby peuvent pointer sur le même id pour plusieurs inputs (ce que j'ai fait sur le dateur).

Il faut de toute façon que chaque `<input>` ait son propre `<label>` (ou son attribut `aria-labelledby`), son propre message d'erreur etc... Après, les aria-labelledby, aria-describedby peuvent pointer sur le même id pour plusieurs inputs (ce que j'ai fait sur le dateur).
Owner

on ferme, en 4.0 la saisie date n'utilise plus jQueryUi

on ferme, en 4.0 la saisie date n'utilise plus jQueryUi
maieul closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.