Webshims lib - The capability-based polyfill-loading JS library

/demos

  • Webshims lib - The capability-based #polyfill-loading JS library
    http://afarkas.github.io/webshim/demos/index.html

    “Webshims Lib is a modular capability-based polyfill-loading library, which focuses on accurate implementations of stable #HTML5 features, so that developers can write modern, interoperable and robust code in all browsers. It is built on top of #jQuery and #Modernizr.” Tags: #JavaScript polyfill HTML5 #plugin jQuery Modernizr #IE8

    • Je suis en train de le mettre progressivement en prod sur un gros site (essentiellement pour la validation des formulaires). Parmi les solutions de ce genre, c’est celle qui m’a paru la plus propre et la plus « future-proof » (et avec un support polyfillé de :user-error !). Par contre la doc est assez difficile à digérer (mais l’auteur travaille sur ce point).

      Je suis preneur de retours, j’en ferais également, s’il y a des gens intéressés ou si vous avez des questions précises.

      #webdesign

  • Un petit #shameless_autopromo : je viens d’ouvrir les formulaires des inscriptions aux concours de la Fémis :
    http://www.femis.fr/concours-general-25

    C’est évidemment, comme le reste du site, du #SPIP #HTML5.

    Tu vas me dire : ben c’est des formulaires… Oui, c’est des formulaires, donc le CVT de SPIP, et le #plugin #SAISIES que tu peux pas vivre sans si tu fais des formulaires.

    Les choses rigolotes ici (parce que sinon, hein, « formulaires Web » et « rigolo », ça ne va pas ensemble dans la même phrase)…

    – c’est un formulaire à onglets ; pour le coup, le passage en affichage à onglets et le passage d’un onglet à l’autre se fait directement en Javascript, et pas via le serveur (je l’ai fait une fois, il y a longtemps, avec déjà CVT, mais c’est super-relou à gérer ; en javascript, c’est tout de même beaucoup plus simple – normalement si pas javascript on se retrouve avec un formulaire sans onglets).

    – l’aspect le plus sympa, c’est l’utilisation de Polyfiller.js (webshim) pour gérer les formulaires HTML5 directement du côté client :
    http://afarkas.github.io/webshim/demos

    Mais pas que : ici je valide chaque champ au fur et à mesure de la saisie, avec des codes couleur (vert c’est OK…). C’est pas bien compliqué à faire, mais je ne crois pas que ce soit un fonctionnement de base de webshims, et ça rend bien.

    Ce qui ajoute un peu de complexité, évidemment, ce sont les onglets : je colorie la onglets également au fur et à mesure mais, surtout, au moment de la validation finale, je dois détecter le champ de la première erreur bloquante et activer l’onglet qui le contient.

    Encore une fois, le code n’est pas compliqué (le javascript qui fait ça est directement dans la page HTML, alors tu peux aller regarder). La seule astuce, réellement, c’est de faire remonter le statut du champ (input, select en statut "error" ou "ok") dans une classe appliquée au <li> qui contient le truc.

    – petites difficultés avec #SAISIES : je n’arrive pas à faire passer les valeurs max et min (pour les champs de type number), ça semble se perdre en route. Pour ceux-là, j’ai dû faire le HTML à la main. Et surtout, pas de "required" quand obligatoire=oui ; je corrige donc en javascript au chargement (j’ajoute « required » dans le <input> quand il est enfant de <li.obligatoire>).

    À la fin de la saisie, on arrive sur une page qui fabrique un PDF récapitulatif, expédie un email, et (super-important) affiche un bouton de paiement en ligne vers la banque.

    Alors du côté du paiement en ligne, un bug détecté ce matin : je balance le #NOM (enregistré dans la base de données) pour fabriquer le formulaire qui va vers la banque et – si si, c’est possible – le plugin « orthotypo » le corrige. Le cas qui a planté : ces gens qui saisissent leur nom en majuscules, du coup Orthotype ajoute un <span> pour signaler que c’est tout en majuscules. Évidemment, le système de la banque refuse de répondre quand il y a du HTML dans le champ « nom du client ». (Solution facile : une étoile et |textebrut)

    • @arno, il n’y a pas de saisie de type « number », donc je suppute que tu utilises la saisie « input » à laquelle tu passes le type « number » ? Chaque saisie a son HTML/squelette qui lui est propre et qui ne continent que les attributs qui lui sont dédiés. Or « input » ne gère que les attributs basiques, pas les ajouts des nouveaux types.

      http://zone.spip.org/trac/spip-zone/browser/_plugins_/saisies/saisies/input.html

      Deux solutions :
      – Soit tu ajoutes les trucs non prévus dans le paramètre « attributs », en chaîne de caractères complète (attributs=’truc="machin" bidule="chouette"’) qui va s’ajouter avant la fermeture de balise.
      – Soit, plus propre sûrement, il faudrait ajouter (toi ?) une nouvelle saisie « saisies/number.html » qui gère les attributs propres à ce nouveau type. Peut-être en faisant une inclusion de la saisie « input » mais avec le paramètre « attributs » modifié en amont, un truc comme ça, pour ne pas doublonner du code (comme ça toute amélioration à « input » est prise en compte par les autres).

      Pour le « required », il est présent dans « input » déjà. Il faut avoir HTML5 d’activé dans la configuration de SPIP.

      [(#ENV{obligatoire}|et{#ENV{obligatoire} !={non}}|et{#HTML5}|oui) required="required"]