http://zone.spip.org

  • « Mozilla under fire » : leçons de la tourmente et défis à relever » MozillaZine-fr
    http://mozillazine-fr.org/mozilla-under-fire-lecons-de-la-tourmente-et-defis-a-relever

    Le paysage est aujourd’hui radicalement différent qu’en 2004. Google revendiquait en 2013 750 millions d’utilisateurs de Chrome (contre 400-450 pour Mozilla). Les concurrents – des géants – de #Firefox et de #Firefox_OS intègrent leurs produits et services enfermant leurs utilisateurs dans leurs écosystèmes extrêmement contrôlés. Les clients s’y enferment en nombre : en 2013, ils ont acheté plus d’un milliard de smartphones… la plupart propulsés par Android et iOS des mêmes Google et Apple.

    Pour #Mozilla et Firefox, Internet Explorer a peut-être été la victoire la plus facile.

    10 #défis pour le prochain directeur général

  • Nouvelle version du plugin GIS pour SPIP

    Version 4.20.0 : refactoring de l’API js + maj vers leaflet 0.7.3

    Refonte de l’API javascript sous forme de plugin Leaflet, L.Map.Gis étend L.Map
    – les options sont passées à l’objet lors de son initialisation, renommage de certaines options pour se caler sur celles de Leaflet
    – les variables de configuration default_layer, gis_layers et affiche_layers sont regroupées dans l’objet L.gisConfig située dans le squelette gis.js.html, ainsi le script leaflet.gis.js n’a plus besoin d’être un squelette
    – du coup on peut ajouter deux paramètres au modèle : default_layer permet de définir ponctuellement le fond de carte affiché par défaut, affiche_layers permet de définir la liste des fonds proposées par la carte
    – on en profite pour regrouper les variables de config du geocoder dans un objet L.geocoderConfig
    – toutes les méthodes l’ancienne API sont attachées à l’objet L.Map.Gis
    – l’objet de la carte est toujours attaché à une variable globale de type mapID_MAP

    Dans le mode de la carte :
    – utiliser ajax au lieu de getScript pour permettre la mise en cache
    – toujours inclure la lib de clustering sinon l’eval du script peut poser problème losqu’on utilise une carte avec clustering sur une page qui comporte une autre carte sans clustering

    Maj des libs : on passe en leaflet 0.7.3 et maj des plugins
    – permet de régler le bug des cartes qui se figent au chargement losqu’on affiche un kml/gpx/json en overlay

    http://zone.spip.org/trac/spip-zone/changeset/82811

    #spip_blog

  • Un nouveau moteur de recherche pour seenthis

    Nous avons travaillé ces deux dernières semaines, avec @marcimat et @rastapopoulos, à la programmation d’un #moteur_de_recherche générique pour #SPIP, basé sur #Sphinx, et très adaptable à différents types de sites. En l’appliquant à #seenthis, on obtient un outil dont les caractéristiques sont assez intéressantes :

    – opérateurs logiques (et, ou, non)
    – recherche de mots parmi une liste
    #proximité
    – des #facettes permettent par ailleurs d’affiner la recherche, en proposant des #hashtags et des @people liés aux mots demandés
    – une facette de date permet de filtrer par année (2014, 2013, etc).
    – enfin, on propose plusieurs tris (par pertinence, date, ou en mettant en tête de liste les messages les plus partagés)

    Je vous laisse découvrir tout cela :
    – le moteur lui-même : http://seenthis.net/recherche
    – la documentation : http://seenthis.net/fran%C3%A7ais/article/moteur-de-recherche
    – le code d’#indexer, le plugin générique pour SPIP : http://zone.spip.org/trac/spip-zone/browser/_plugins_/indexer/trunk
    – le code du plugin qui l’adapte à seenthis : https://github.com/seenthis/seenthis_sphinx

    Commentaires et relevés de bugs sont très bienvenus.

    #seenthis_nouveautés

    • La recherche est sur le message ou sur le fil ?

      Ça peut être intéressant de chercher des messages qui contiennent une image ou une vidéo ou qui a reçu des commentaires (dans le cas où on cherche un de nos messages et que ce sont des infos qui se retiennent bien).

      Sinon une recherche sur le fil entier pour des messages qu’on recherche sur un sujet, par exemple si on cherche sur poutine et ukraine, ça peut rapporter pas mal de sujets en plus (surtout que souvent les billets sont taggés a posteriori par les autres membres)

      Rechercher des fils dans lesquels des membres de seenthis ont participé ?

      Bon c’est des idées en l’air, je sais pas s’il y a un réel besoin pour ça ?

    • La colonne de droite « follow » elle se base sur la recherche / les résultats ? Ça me met des comptes que je suis déjà en tout cas

      Edit : ha non ça permet d’affiner la recherche en spécifiant un auteur, mais si j’ai fais ma recherche avec déjà un auteur, ça va sortir aucun résultat

    • Pas compris. J’ai essayé les # et je ne sais pas si je dois affiner les recherches parce que je me suis retrouvée dans un flux sans queue ni tête...bigre ! Je crois que je suis complètement crevée !

    • #Merci

      Je n’ai fait que quelques essais de recherche. Sans problème. L’interface est super claire et les affinages très bien venus.

      Mais surtout, je vois des comptages. Alors, je n’ai pas pu m’empêcher…

      Sur une entrée vide, on compte tout. Du coup, ça fait une super façon d’entrer dans les stats…

      On a des unités statistiques différentes :
      – pour les années, apparemment, il s’agit des billets (messages initiaux). Si tu implémentes un dépliement hiérarchique par mois, outre que ça permet de préciser le filtre chronologique (surtout utile pour l’année en cours), ça permettrait d’avoir l’activité mensuelle.
      – pour les comptes (follow) et les tags, il me semble qu’il s’agit de toute l’activité (billet, commentaire, étoile)
      Là aussi, peut-être un niveau hiérarchique inférieur permettrait de ventiler entre ces 3 types d’activités (ce qui permettrait de préciser quand on cherche une réponse dans une discussion)

      Du coup, les totaux n’ont pas de raison de coïncider. Si mon interprétation est bonne, il y a eu (et il subsiste après effacement des comptes) 120000 billets (ça change tout le temps…) et comme le numéro du dernier est autour de 260400, cela fait de l’ordre de 1,2 « activité complémentaire » (commentaire ou étoile) par billet.

      Juste pour voir, j’ai fait le suivi du nombre de billets par année.

      Et l’activité des top 20 (en % du nombre de billets)
      (pour 2010, la somme des 20 follows fait 3548, alors que le nombre de billets est de 3520)

      2013

      2014

      Éventuellement, un nouveau bloc par nombre « d’activité complémentaire » pour classer les billets par intensité de la discussion ou des étoiles (souhait qui a été exprimé, me semble-t-il).

      Encore merci. Et bravo pour l’interface « naturelle » ou « invisible ».

    • Jolies déductions :)

      La facette « follow » est établie sur la base de l’attribut multivalué {auteur initial + partageurs}. Les intervenants dans la discussion ne sont donc pas comptés en tant que tels (ils sont indexés dans un autre attribut, mais pas utilisés dans l’interface : l’idée est que si je ne partage pas un billet, mes suiveurs n’ont pas forcément vocation à être alertés que je suis en train d’y discuter).

      Chacune des facettes, comme tu l’as constaté, est limitée aux 20 éléments ayant le plus fort effectif, et à condition qu’il soit > 1.

      Le système recense à cet instant 156548 billets publiés. Il existe des billets effacés (11197 dont une trace reste dans le système, sans compter ceux de quelques tests, ou du compte machin, qui ont carrément été supprimés).

      Pour ce qui est de fouiller plus avant dans les données, je pense qu’il sera plus efficace de créer des requêtes ad hoc. Le langage d’interrogation, très proche du SQL, est assez parlant.

      Par exemple pour avoir le nombre de billets publiés mois par mois :
      SELECT COUNT(*), YEARMONTH(date) as m FROM seenthis where properties.published=1 GROUP BY m ORDER BY m ASC LIMIT 1000;

      La même chose pour les billets qui répondent à un critère fulltext :
      SELECT COUNT(*), YEARMONTH(date) as m FROM seenthis where MATCH('spip') AND properties.published=1 GROUP BY m ORDER BY m ASC LIMIT 1000;

      etc.

      Concernant la suggestion de trier selon l’intensité des discussions : il n’y aurait aucun obstacle technique, sachant que les éléments nécessaires (liste des participants à chaque discussion) sont déjà indexés. En revanche, il me semble qu’il s’agit d’une fausse bonne idée : j’ai comme un doute en effet sur l’intérêt de mettre en valeur des discussions qui impliqueraient de nombreuses personnes, mais qu’aucune ne souhaiterait partager…

      La vocation du moteur de recherche est de permettre de trouver aussi rapidement que possible une information précise, les décisions doivent se baser uniquement là-dessus, pour cette page en tout cas. Mais l’outil permet d’imaginer d’autres « vues » sur les données, qui pourront servir à l’administration du serveur, à créer des pages annexes, à repérer des « corrélations » entre les sujets, des proximités entre auteurs, une analyse du « dictionnaire » global, et que sais-je encore. Tout un champ à explorer !

      PS : la doc de SphinxQL : http://sphinxsearch.com/docs/current.html#expressions

    • Tu sais que l’utilisateur est d’abord et avant tout pervers : il utilise les outils qu’on lui donne pour faire tout autre chose avec… Et, donc, oui je sais qu’il s’agit de recherche, pas de stats. Tavaikapa mettre des comptages.

      Blague à part, en fait, je ne sais pas comment faire pour rentrer dans les tables de ST à des fins statistiques. À l’occasion (R ?), je jetterais bien un œil…

    • Oui @fil, pour la mise en avant des discussions « chaudes » (celles ayant le plus de participants et/ou celles ayant le plus de messages), je ne voyais pas ça spécialement dans la page de recherche. Mais dans une autre vue à part ce serait bien oui.

      (Dans le même thème, un truc qui pourrait être bien, hors interface, ce serait aussi un flux Atom des commentaires postés par les gens qu’on suit.)

    • @intempestive à priori ça semble compliqué d’utiliser le raccourci @truc à la fois pour du fulltext et pour spécifier un auteur ; mais sinon, la recherche de « commentaires seenthis », triée par pertinence, te donne bien la loi de nicolasm comme deuxième résultat.

    • (une loi qui porte mon nom la classe .. ah mince c’est moi qui l’ai créée...)

      Le menu pour affiner la recherche par facette semble avoir des bugs :

      http://seenthis.net/recherche?recherche=%23permaculture+%40nicolasm+%23agriculture

      – le tag agriculture n’est pas déjà coché dans le menu
      – si je clique sur le tag alimentation ça me met cette url = http://seenthis.net/recherche?recherche=%23agriculture&tag=%23alimentation (ça vire mon pseudo et le tag permaculture) alors que j’imaginais que ça rajoutais le tag alimentation en contrainte supplémentaire ? Même souci avec les facettes par auteur pour http://seenthis.net/recherche?recherche=%23agriculture+

    • @homlett le moteur est accessible en RSS et en JSON :
      http://seenthis.net/?page=sphinx.rss&recherche=sphinx
      http://seenthis.net/?page=sphinx.json&recherche=sphinx
      Attention c’est de la version alpha, je changerai probablement les URLs une fois que ce sera testé et stabilisé.

      À noter les deux flux proposent des données complémentaires : uri, title, date, @login de l’auteur, tags et « snippet », c’est-à-dire l’extrait du contenu avec les mots repérés mis entre <b> (à styler comme tu veux, le gras rendant assez moche).

      Ce qui manque je pense, à ce stade, c’est de pouvoir personnaliser (faire « mes messages » ou « messages de mon réseau » plutôt que « Tous les messages »).

    • @speciale le système n’affiche pas de facette s’il n’y en a pas d’intéressantes (si la facette contient 1 seul élément, ou si l’élément ne correspond qu’à un seul message) ; je pense que c’est le cas de ta requête.

    • En fait, j’ai beaucoup utilisé le moteur hier pour écrire mon dernier papier et je suis ravie de la facilité avec laquelle j’ai pu retrouver toutes les sources dont j’avais besoin. Souvent, j’associe deux termes pour mieux cibler ma recherche, et sans avoir besoin de me prendre la tête avec les opérateurs booléens, j’exhume très rapidement ce que je mettais des heures à chercher jusque là (et que je ne retrouvais généralement pas !). J’aime beaucoup le surlignage des termes recherchés et la possibilité de trier les résultats par date ou pertinence, de limiter par année, auteur, me ravit littéralement.
      Je n’ai pas eu de bugs, pas de problème et mes requêtes ont toutes abouti.

      Donc désolée de ne pas aider plus que cela, mais je suis juste la ravie de la crèche qui pensait depuis un bon moment que le gros défaut de Seenthis, c’était de ne jamais rien y retrouver !

    • <b> c’est le choix de sphinx, sans doute historique ; je le conserve par souci de simplicité (et puis c’est économique en bytes)

    • Peut-être puis-je émettre un bidule qui serait bien pratique mais je ne sais pas si c’est le sujet de cette discussion. Serait-il imaginable de mettre une étoile à côté d’une réponse. Car parfois, il y a des réponses qui mériteraient d’être mentionnées dans les recherches. Voir des possibilités d’y répondre....

    • en effet c’est hors-sujet :)

      pour gérer le développement de seenthis, on vient tout juste de mettre en place un compte github où vous pouvez envoyer des issues (problèmes ou demandes de fonctionnalités) et des pull-requests (des modifications du code source).
      https://github.com/seenthis

    • Une petite amélioration du moteur : la recherche se fait désormais à partir de la racine des mots (lemmatisation) ; ainsi le moteur trouvera les messages contenant aussi bien le pluriel que le singulier, ou bien diverses formes des verbes conjugués (c’est censé fonctionner pour l’anglais et pour le français).

      Si, à l’occasion, vous souhaitez rechercher la forme exacte d’un mot, utilisez l’opérateur = ; par exemple, une recherche de =terres évitera les messages contenant le mot terre au singulier seulement.

      (Et pour répondre à @nhoizey : il me semble probable que les plugins seenthis fonctionnent déjà pour la plupart avec SPIP 3, je n’ai pas essayé mais je ne vois pas ce qui pourrait bloquer. Si dans tes tests tu vois des bugs, n’hésite pas à les signaler ou à envoyer une pull-request sur https://github.com/seenthis )

    • Bonjour

      On m’a dit de m’adresser ici si je ne comprenais pas quelque chose.

      Comme par exemple : comment faire pour afficher sur sa page personnelle un billet d’un autre utilisateur ? Il faut le mettre en favori, c’est tout ?

      Je n’ai pas trouvé le bookmarklet en page d’accueil qui, paraît-il (dixit la page « le minimum à savoir »), transforme complètement le confort d’utilisation.

      Merci d’avance !

    • Bon, OK.
      Autre question :
      Pour suivre un thème, je n’ai pas trouvé d’autre moyen qu’utiliser le moteur de recherche, chercher le thème avec le # dans la page et cliquer dessus, puis ensuite faire « suivre le thème ».
      Il n’y a pas moyen de faire plus simple ?

    • Fondamentalement plus simple, je vois pas comment. Mais il y a un lien « thèmes » dans le bandeau du haut, vers http://seenthis.net/tags avec la liste des thèmes/tags suivis.
      Tu peux aussi directement taper l’url http://seenthis.net/tag/THEME_EN_QUESTION

      À savoir : si par exemple tu suis le thème #seenthis, tu suis avec ses sous-thèmes : #seenthis_doc, #seenthis_todo, etc. Mais bien sûr, pas l’inverse.

      Autre chose : devant chaque liens partagés, il y a un triangle. S’il est blanc, l’url n’a été partagée qu’une fois. S’il est noir, l’url a été partagée plusieurs fois. Et un clic sur le triangle renvoi vers la liste de tous les posts où elle apparait.

      Last but not least, la mise en forme :
      – du gras en encadrant avec le signe *
      – de l’italique avec le signe _
      – du code avec le signe `
      – des citations avec Shift+Tab

    • c’est embêtant ça signifie péter tous les svn up ; cette règle est-elle absolue ? s’il faut vraiment en passer par là je crois que ça vaut le coup, mais j’aimerais comprendre pourquoi, pourquoi, pourquoi on se met tout le temps des bâtons dans les roues

    • On peut supposer que c’est lié à l’utilisation de l’outil de migration #git-svn qui peut faire des choses très sympa en récupération de l’historique avec l’une des options ’’’—stdlayout’’’ ou ’’’-T’’’ mais bon, ça peut être aussi autre chose, je fais que supposer... c’est souvent long à procéder, et le résultat n’est pas toujours à la hauteur, surtout quand les dev n’ont pas utilisé svn « comme il faut » pour gérer tags et branches ...

      ô toi qui aime l’anglais, lis donc ça : https://www.kernel.org/pub/software/scm/git/docs/git-svn.html

    • Yop

      @fil tout #VCS recommande à minima la logique trunk/branches/tags, certains plugins suivent cette recommandation, d’autres non.
      Il est parfois bon d’être rationnel et si possible de suivre les bonnes pratiques.
      Autre point où copierons nous la branches créée depuis git dans la version svn ?

      @james #git-svn n’est pas utilisé car ne fait pas le boulot voulu. Le « layout » utilisé permet d’être bijectif :
      on peut contribuer indifféremment sur la copie git ou svn c’est pareil.

      Question piège : à quoi ressemblerait le « layout » pour les plugins core ? :)

      Est ce qu’on doit vraiment en passer par là, je dirais oui car il nous faut être cohérent pour ne pas se mettre des traverses dans les pieds, on a assez de bâtons pour le moment.

      Je regarde pour que ce soit le plus transparent possible même pour ces plugins, mais ce n’est pas trivial.

  • Logiciels
    http://visionscarto.net/logiciels

    Le site Visionscarto fonctionne avec des logiciels libres. Le socle en est SPIP, le système de publication sur Internet auquel nous contribuons depuis 2001. De nombreux plugins sont utilisés, certains bien connus, d’autres plus obscurs : ZPIP (z-core + zpip_html5) pour organiser le code des pages ; adaptive_images, pour télécharger les images adaptées à la taille de l’écran ; ancres_douces, bellespuces, orthotypo, pour certaines finitions ; les crayons, pour faciliter les corrections des (...)

    #Ressources_libres

    « http://www.spip.net »
    « http://zone.spip.org/trac/spip-zone/browser/_plugins_/z-core »
    « http://zone.spip.org/trac/spip-zone/browser/_plugins_/zpip_html5 »
    « http://contrib.spip.net/4458 »
    « http://contrib.spip.net/Ancres-douces »
    « http://contrib.spip.net/Belles-puces »
    « http://contrib.spip.net/Ortho-typographie »
    « http://contrib.spip.net/Les-crayons »
    « http://tinytypo.tetue.net »
    « http://seenthis.net/messages/250985 »
    « http://zone.spip.org/trac/spip-zone/browser/_plugins_/ressource »
    « https://bitbucket.org/recifs/tuile »
    « https://bitbucket.org/recifs/squelettes-visionscarto »
    « http://scholarsfonts.net/cardofnt.html »
    « http://www.boldmonday.com/fr/nittigrotesk »

  • Nous venons de lancer le nouveau site de l’Adresse, Musée de la Poste réalisé avec Mosquito :
    http://www.ladressemuseedelaposte.fr

    C’est comme toujours du #SPIP, #HTML5, #responsive.

    – Le site utilise les nouvelles fonctionnalités que j’ai développées pour le #plugin image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
    En particulier la définition de valeurs de largeur prédéfinies, pour éviter de fabriquer quelques centaines d’images. Le site a, à plusieurs endroits, des images qui occupent toute la largeur de l’écran ; donc il faut éviter de fabriquer avec le plugin autant de versions de l’image que de largeurs de la fenêtre d’affichage.

    J’avais documenté ça là :
    http://seenthis.net/messages/223187

    – L’une des originalités du site est la possibilité de présenter le contenu d’une rubrique sous forme dite de « longform » ou de parallaxe. C’est-à-dire une de ces longues pages regroupant toute l’information sur page unique, avec un long scroll, tout en essayant graphiquement de rendre la consultation d’une longue page aussi attractive que plusieurs pages normales. Par exemple, les « 10 objects phares du musée » :
    http://www.ladressemuseedelaposte.fr/Les-10-objets-phares-16
    Les grandes images qui rythment la page, avec l’effet de parallaxe, ce sont les logos des articles de cette rubrique.

    Les images de la page se chargent au fur et à mesure du scroll, simplement en utilisant l’option « lazy load » du plugin image_responsive. C’est bien pratique…

    Pour la gestion du parallaxe, j’utilise le plugin jquery skrollr. J’avais indiqué il y a quelques temps comment rendre skrollr compatible avec le lazy load de image_responsive :
    http://seenthis.net/messages/204550

    – Enfin, comme c’est du SPIP, je peux intégrer facilement dans les pages longform les éléments que j’inclus habituellement dans un tel site. Voir par exemple ici :
    http://www.ladressemuseedelaposte.fr/La-tete-dans-les-nuages
    Il y a donc une colonne principe « à gauche » et une colonne d’informations spécifiques « à droite », on peut intégrer un calendrier, et évidemment un portfolio.

    – Sinon, on a fait une présentation plutôt spectaculaire des vidéos embeddées :
    http://www.ladressemuseedelaposte.fr/Pilatre-du-Rozier
    et aussi une grande carte d’accès bien maousse :
    http://www.ladressemuseedelaposte.fr/Travaux-Acces-Tarifs

    – Enfin, j’ai récupéré le contenu d’un Wordpress préexistant pour réaliser la rubrique « Le Blog » (qui se gère désormais dans SPIP) :
    http://www.ladressemuseedelaposte.fr/Le-Blog-48
    J’avais fait un squelette dans SPIP permettant de récupérer le contenu d’un site Wordpress, livré ici :
    http://seenthis.net/messages/213240

    #shameless_autopromo

    • Chez moi aussi le menu boutique n’est visible qu’en partie sur la page d’accueil même en écran large. Autrement chapeau, c’est très réussi :-)
      Merci pour les explications sur les plugins SPIP utilisés.
      (FF 27.0.1 sous Linux)

    • Ah oui, c’est corrigé. C’était à cause du changement de nom de domaine, alors que les CSS étaient encore calculées depuis l’ancienne URL. Et Firefox n’accepte pas de charger les webfonts depuis un autre domaine.

  • Amélioration de mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Il s’agit ici de limiter l’effet de « redraw » au chargement de la page. Le plugin, en effet, fait que la page se charge et s’affiche une première fois, avant de charger les images. Et pendant ce temps, la page est calculée et affichée en supposant que les images sont carrées. Du coup, après ce premier affichage de la page sans les images responsives, on se retrouve avec un « redraw » (la page est redessinée) durant lequel on « voit » nettement qu’il se passe quelque chose, puisque les éléments de texte (tout ce qui est hors images responsive, en fait) se déplacent. Le redessin de la page est donc très visible. Par ailleurs, dans le cas où il y a une vignette de prévisualisation avant le chargement de l’image complète, du fait des différences d’arrondi entre les trailles d’images, il n’est pas rare d’avoir alors un petit effet de bougé sur… 1 pixel.

    De plus, cet effet de redraw visible se produit même quand on revient sur la page (dont l’ensemble est déjà en cache), puisque le principe même du plugin est qu’on redessinne la page forcément après l’avoir dessinée une première fois.

    Dans le cas où l’on avait pas de vignette de prévisualisation (on charge le carré « rien.gif »), le javascript du plugin limitait les dégâts en « forçant » les dimensions des images contenant rien.gif, mais on avait quand même un effet de « bougé » après le premier affichage.

    Pour moi, c’était le principal défaut de cette façon de réaliser des images responsives.

    L’amélioration du jour s’applique de manière transparente pour le webmestre (il suffit de faire la mise à jour du plugin et de recalculer les pages - attention, recalculer aussi les CSS). Pour les images_responsive classiques (pas les nouvelles, verticales, que j’ai introduites dans la précédente mise à jour), la balise <img> est désormais intégrée à l’intérieur d’un <span>. L’image, elle, passe alors en position absolue à l’intérieur du spam, qui définit les dimensions de l’image.

    Et comme on fait pour qu’un <span> adopte les proportions de l’image tout en restant responsive ? Avec la technique tirée de « Fluid Width Video » :
    http://css-tricks.com/NetMag/FluidWidthVideo/Article-FluidWidthVideo.php
    Le span a une largeur de 100%, une hauteur de 0. Sa hauteur est définie précisément par un padding-bottom, qui est la proportion (par exemple 50% pour une image qui serait deux fois plus large que haute).

    De cette façon, on a bien les dimensions de l’emplacement de l’image qui sont connues, dès le chargement de la page, par les CSS et le HTML, sans attendre le chargement des images et/ou du Javascript.

    Il n’y a plus d’effet visible de bougé lors du redraw, puisque tout est déjà correctement positionné dans la page avant même le démarrage du javascript de chargement des images. Ce qui est épatant, c’est que la différence est également sensible lorsqu’on revient sur la page déjà en cache. On a désormais un effet de « surgissement » des images sans redessiner visiblement la page.

    Un peu comme si on avait définit dans le code HTML les dimensions (width et height) des images, comme c’est préconisé, mais en restant en responsive.

  • Encore du nouveau sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, il s’agit de pouvoir calculer la taille de l’image en fonction de la hauteur, et non plus de la largeur, de la boîte qu’elle occupe. (Et il y avait un bug dans la version précédente, qui faisait qu’il n’y avait jamais d’image de prévisualisation.)

    Pour cela, introduction d’une troisième variable :

    [(#LOGO_ARTICLE|image_responsive{0,0,1})]

    Ici, pas de vignette de prévisualisation au chargement de la page (première variable à 0). Puis pas de « lazy load » (deuxième variable à 0 ; l’image responsive est chargée au document.ready, même si elle est en dehors de l’écran). Et le troisième argument, qui est nouveau, lorsqu’il est à 1, indique qu’on ne va pas calculer l’image selon la largeur de sa boîte, mais selon sa hauteur.

    Je pense que c’est d’un usage très spécifique, parce que concevoir une interface (qui plus est responsive) en définissant les hauteurs de boîtes plutôt que les largeurs, c’est assez coton.

    Au passage, il faut re-modifier le .htaccess.

    Exemple minimal : on place les logos des articles les uns à côté des autres, et ils auront la même hauteur (celle de la boîte contenante : 120 pixels ; ou, automatiquement, 240 pixels en écran haute définition) :

    <div style="height: 120px;">
    <BOUCLE_articles(ARTICLES){par date}{inverse}{0,5}>
    [(#LOGO_ARTICLE|image_responsive{0,0,1})]
    </BOUCLE_articles>
    </div>
    • Bonjour ARNO et un grand merci pour ce plugin.

      Puisque le but ici est d’optimiser les images envoyées en fonction de la taille nécessaire, ne serait-il pas judicieux de passer en plus par le plugin smush pour réduire encorela taille de ces images ?

      Pour l’instant |image_responsive|image_smush ne fonctionne pas je suppose que ce serait au javascript de permettre ce détour.

      Qu’en penses-tu ?

  • Une nouveauté sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée est de pouvoir désormais fixer arbitrairement quelles largeurs d’image on autorise.

    Le principe initial d’image_responsive, c’est de charger l’image une fois qu’on a calculé la page, donc on connaît déjà la largeur réelle d’affichage de l’image. De cette façon, on charge exactement l’image à la taille à laquelle on l’affiche.

    Du coup, il devient totalement inutile même de gérer la largeur réelle de l’image en amont. Ça fonctionnait bien dans mes maquettes précédentes, avec au final un nombre limité de tailles d’images différentes. En laissant faire le plugin, je fabrique certes beaucoup de tailles de la même image, mais pas de façon excessive.

    Le hic, c’est lorsque j’affiche l’image carrément en pleine largeur de l’écran (habituellement, j’étais plutôt dans des largeurs d’affichage fixées). Là, je me retrouve avec la possibilité de calculer des centaines de versions d’une même image, en fonction de la taille de la fenêtre d’affichage.

    Du coup, j’introduis la possibilité de fixer les tailles autorisées pour charger les images :

    [(#LOGO_ARTICLE
        |image_proportions{3,2}
        |image_responsive{320/600/1024}
    )]

    Ici, je fabrique une image de proportions 3/2 (de largeur indéterminée dans ces proportions, je m’en fiche), puisque j’insère une vignette de prévisualisation de 320 (la première valeur). Le javascript qui charge l’image définitive, lui, ne chargera des images que de 320, 600 ou 1024 (en fait : plus les versions haute définition, donc potentiellement six versions de l’image). Exemple : si j’affiche l’image sur une largeur de 479 points, alors je charge l’image de largeur 600 (que je réduis donc à l’affichage).

    On perd évidemment un peu de l’efficacité du plugin, puisqu’on charge une image un peu plus grande que celle qu’on affiche, mais cela évite d’avoir des centaines d’images différentes calculées dans certains cas.

    Si on ne veut pas de vignette de prévisualisation mais les mêmes tailles autorisées au chargement a posteriori, la première valeur à indiquer est 0 :

    |image_responsive{0/320/600/1024}

    Je l’utilise sur la page d’accueil de ce site (#shameless_autopromo) :
    http://festival-scenaristes.com

  • Nouvelle version du plugin #Crayons pour #SPIP

    – Nombreuses notices PHP en moins
    – Changement de stratégie dans la fonction valeur_colonne_table_dist() : on ne calcule la partie where de la requête SQL que si c’est réellement utile, et pour ce faire, on sépare en 2 fonctions le calcul :
    –- du nom de la table d’application et de sa/ses clés primaires
    –- du where SQL

    De la sorte, si un contrôleur calcule lui-même les valeurs de tous ses champs, aucune tentative erronée de créer un where adapté n’est réalisé, ce qui évite des notices PHP lorsque le controleur utilise des noms de champs ne correspondant pas à des colonne SQL.

    Ceci permet entre autres de passer des #EDIT{mots_article-128} dans une boucle GROUPES_MOTS et en gérant un contrôleur adapté permettant de sélectionner les mots d’un certain groupe, liés/à lier à l’article 128.

    http://zone.spip.org/trac/spip-zone/changeset/80169

    #spip_blog et merci @marcimat :)

  • 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"]

  • Voici un squelette que je viens de me bidouiller pour récupérer le contenu d’un blog #Wordpress dans #SPIP. Pas envie d’y passer ma vie, accès limités aux serveurs… bref j’ai fait ça rapidement et ça m’a suffit. Je viens de récupérer 800 billets d’un Wordpress (hébergé chez Wordpress, d’ailleurs) à partir de l’export en XML, aspiré le logo de chacun et ça fonctionne.

    Comme je n’ai rigoureusement aucune expérience de Wordpress, je ne sais pas si c’est générique, je sais que ça ne reprend aucune structure (ni mots-clés, ni « rubriques ») mais bon : #çamsuffit et je te file le code si ça peut te servir.

    Le mode d’emploi est dans le début du code. Principalement : il faut installer le plugin « sale » de SPIP :
    http://plugins.spip.net/sale.html
    dans lequel il faut modifier le fichier plugin.xml pour lui dire qu’il fonctionne avec SPIP 3. Et dans le fichier « wordpress.date.xml », il faut faire deux chercher-remplacer rudimentaires, parce que je ne sais pas comment accéder à des nœuds XML nommés avec des deux-points.

    #CACHE{0}
    [(#REM)
      # Convertir une sauvegarde Wordpress vers SPIP
      #
      # activer le plugin «sale» de SPIP (si nécessaire, modifier les limites dans plugin.xml pour l'activer)
      #
      # dans "wordpress.xml"
      # remplacer "content:encoded" par "contentencoded"
      # et "wp:post_date" par "wp_post_date"
      #
      # renseigner #SET{fichier}
      # renseigner #SET{id_rubrique} (la rubrique SPIP qui accueille les billets Wordpress)
      #
      # parcourir une première fois (via les liens de pagination)
      # ce qui provoque le chargement des images distantes
      # puis passer #SET{mysql,oui}
      # et reparcourir la pagination - cette fois tout est en base et les images sont copiées
    ]


    #SET{fichier,wordpress.2013-12-28.xml}
    #SET{id_rubrique,48}
    #SET{mysql,non}



    #SET{reg_img, src=\"(.*)(\?w=[0-9]+)?\"}
    #SET{reg_caption, caption=\"(.*)(\?w=[0-9]+)?\"}
    #SET{reg_vides,\\[\-\>.*\\]}


    <B_cite>
    #PAGINATION

    <ul>
    <BOUCLE_cite(DATA)
    {source xml, #GET{fichier}}
    {datapath channel/0}
    {cle==item}
    {pagination 50}
    >
            <li>
                    <h2>[(#VALEUR{0/title/0}|typo)]</h2>
                    <h4>[(#VALEUR{0/wp_post_date/0}|affdate)]</h4>

                    [(#SET{logo,[(#VALEUR{0/contentencoded/0}|sale|match{#GET{reg_img}, Uims, 1}|copie_locale)]})]
                    [(#SET{term,[(#GET{logo}|match{(jpg|png|gif)$, "",1}]})]
                   
                   
                    <br>
                    [(#VALEUR{0/contentencoded/0}|sale|match{#GET{reg_caption}, Uims, 1})]



                    [(#VALEUR{0/contentencoded/0}
                            |replace{"<span .*>", "", Uims}
                            |replace{"</span>", "", Uims}
                            |replace{"<(strong|em)><(strong|em)>","<\1> <\2>"}
                            |replace{"<(strong|em)><(strong|em)>","<\1> <\2>"}
                            |replace{"</(strong|em)></(strong|em)>","</\1> </\2>"}
                            |replace{"</(strong|em)></(strong|em)>","</\1> </\2>"}
                            |sale
                            |replace{"<img.*>","", Uims}|strip_tags
                            |replace{#GET{reg_vides},""}
                            |replace{\\[caption.*\\],"",Uims}
                            |replace{\\[\/caption\\],""}
                            |propre
                            )]

                    [(#GET{mysql}|=={oui}|oui)
                    <?php
                            $id_article = sql_insertq("spip_articles",
                                    array(
                                            "titre" => "[(#VALEUR{0/title/0}|replace{'"','\"'})]",
                                            "id_rubrique" => #GET{id_rubrique},
                                            "texte" => "[(#VALEUR{0/contentencoded/0}
                                                    |replace{"<span .*>", "", Uims}
                                                    |replace{"</span>", "", Uims}
                                                    |replace{"<(strong|em)><(strong|em)>","<\1> <\2>"}
                                                    |replace{"<(strong|em)><(strong|em)>","<\1> <\2>"}
                                                    |replace{"</(strong|em)></(strong|em)>","</\1> </\2>"}
                                                    |replace{"</(strong|em)></(strong|em)>","</\1> </\2>"}
                                                    |sale
                                                    |replace{"<img.*>","", Uims}|strip_tags
                                                    |replace{#GET{reg_vides},""}
                                                    |replace{\\[caption.*\\],"",Uims}
                                                    |replace{\\[\/caption\\],""}
                                                    |replace{'"','\"'}
                                                    )]",
                                    "statut" => "publie",
                                    "date" => "[(#VALEUR{0/wp_post_date/0})]"
                                    )
                            );
                           
                            copy("#GET{logo}", "IMG/arton$id_article.#GET{term}");
                           
                    ?>               
                    ]               
            </li>

    </BOUCLE_cite>
    </ul>
  • Avec Mosquito, on vient de livrer le nouveau site de la Fémis :
    http://www.femis.fr

    C’est du #SPIP_3, #responsive, #HTML5 (et du #shameless_autopromo évidemment).

    Parmi les points originaux…

    – Le menu de navigation principal avec son animation « gauche-droite » au survol. Le javascript est très simple, et l’animation est directement en transition CSS. Dans chaque menu, les colonnes des rubriques/sous-rubriques sont aussi équilibrées que possible, et c’est fait directement avec Masonry.

    – Les images passent par mon plugin « image_responsive », ce qui permet de gérer différentes tailles, ainsi que le chargement d’images deux fois plus grandes pour les écrans haute définition.

    – Il y a réellement très peu d’images pour réaliser l’interface graphique. C’est essentiellement des CSS avec des dégradés discrets, des ombres portées… Comme d’habitude, mon plugin « CSS imbriqués » est très utile pour faciliter le codage (CSS avec gestion des préfixes et des variantes de navigateurs, code hiérarchisé, inversion des #media_queries…).

    – La moteur de recherche (c’est du pur SPIP/Fulltext) bénéficie de petites améliorations dans les squelettes. (C’est accessible via la loupe en haut à gauche de la page.) La première consiste à faire des suggestions lorsqu’on commence à taper un mot. Tu tapes « réali », et ça te déplie des suggestions : « réalisation, réalisateurs, réalisateur, réalisé, réaliser… » classées en fonction de la présence de ces mots dans le site. Une fois que tu as validé ta recherche, la page de résultats est classique, mais avec un détail : le texte « descriptif » de chaque article est calculé pour afficher le terme recherché, surligné dans son contexte (habituellement on affiche simplement le début du texte comme partout dans le site ; là il y a un calcul amusant).

    – Une grosse partie du boulot a consisté à refondre la base de donnée des anciens élèves. D’abord créer des moulinettes pour réorganiser l’ancienne base de données dans ma nouvelle structure. Ensuite évidemment gérer l’affichage sur le site (avec SPIP, cette partie, c’est assez finger in ze noze). Et surtout : des formulaires pour que chaque ancien étudiant gère lui-même sa fiche, ses infos personnelles, sa filmographie, son CV structuré… Le tout en essayant de proposer des interfaces aussi intuitives que possible, ce qui est toujours une gageure quand on a des formulaires un peu complexes.

    – Ça faisait carrément longtemps : on utilise les brèves de SPIP ! (Pour l’« Actualité des diplômés »).

    – Comme à mon habitude, la page d’accueil et le footer sont construits avec une « rubrique technique » invisible, laquelle contient des sous-rubriques pour structurer, et il faut donc publier des « articles virtuels » qui redirigent vers ce qu’on veut. C’est un peu plus contraignant que d’autres techniques, mais c’est ce qui donne la plus grande souplesse (on peut « référencer » des articles, des rubriques, des pages distantes…, forcer le classement qu’on veut en page d’accueil, utiliser des titres et des descriptifs plus adaptés…).

    • Comme à mon habitude, la page d’accueil et le rooter sont construits avec une « rubrique technique » invisible, laquelle contient des sous-rubriques pour structurer, et il faut donc publier des « articles virtuels » qui redirigent vers ce qu’on veut. C’est un peu plus contraignant que d’autres techniques, mais c’est ce qui donne la plus grande souplesse (on peut « référencer » des articles, des rubriques, des pages distantes…, forcer le classement qu’on veut en page d’accueil, utiliser des titres et des descriptifs plus adaptés…).

      Héhé, par deux fois déjà, j’ai opté pour exactement la même technique, afin de sélectionner les contenus listés dans un carrousel d’accueil. Cela permet d’avoir une image différente, pas forcément intégrée au contenu final qui est lié, pareil pour le titre et le descriptif, qui peuvent être propres à l’accroche, et ça permet effectivement aussi de rediriger vers un autre contenu externe.

      Pour ne pas faire de bidouille, ça pourrait mériter un plugin dédié, du genre « Sélections de contenus », où on pourrait en créer autant qu’on veut, avec un identifiant textuel non lié à la base (ce qui permet de l’utiliser dans les squelettes génériquement), et qui permettrait alors de sortir :
      <BOUCLE_news_accueil(SELECTIONS){identifiant=news_accueil}>
      LOGO_SELECTION
      TITRE
      DESCRIPTIF
      LIEN (celui ci pouvant gérer à la fois une URL classique, ou un identifiant de contenu SPIP du genre : « evenement1234 »)
      </BOUCLE_news_accueil>

      Avec une interface bien fichue pour les administrer. Ça sera plus facile et plus facilement compréhensible (car pas un détournement).

    • Salut @arno,
      j’ai enfin pris le temps de commencer ce plugin de sélections éditoriales.

      Voici le premier commit :
      http://zone.spip.org/trac/spip-zone/changeset/83884

      Tu peux donc te faire une sélection « accueil », une autre « footer », etc. Et les récupérer facilement dans tes squelettes :

      <BOUCLE_une(SELECTIONS){identifiant=accueil}>
         <BOUCLE_contenus(SELECTIONS_CONTENUS){id_selection}>
             <a href="#URL">
             #LOGO_SELECTIONS_CONTENU
             #TITRE
             #DESCRIPTIF
             </a>
         </BOUCLE_contenus>
      </BOUCLE_une>

      Et dans le champ « url », tu peux y mettre :
      – soit un URL complet quelconque
      – soit un objet SPIP sous la forme « article123 », « evenement456 », « rubrique789 ».

      Dis moi ce que tu en penses.

      (Et comme le dit le commit, viendra ensuite l’ajout de sélections en-dessous d’un objet SPIP. Lorsqu’on le veut.)

    • Oublié de le dire :
      1) j’ai ajouté la création d’une sélection sous un contenu SPIP (un article par exemple), et
      2) j’ai modifié le formulaire d’ajout d’un contenu sélectionné pour le rendre plus pratique : seule l’URL est obligatoire, et si on ne met que ça, la magie va chercher le titre du contenu SPIP (si on a mis « article1234 » par exemple) ou le titre de la page HTML (si on a mis un URL http).

  • #Plugin_SPIP #scssphp
    téléchargeable sur http://plugins.spip.net/scssphp.html
    compile en CSS et mets en cache les fichiers .scss
    grace à http://leafo.net/scssphp

    Permet d’utiliser #SASS, un #préprocesseur_CSS et ses diverses possibilités dans #SPIP,
    voir les discussions poursuivies sur seenthis à ce propos
    http://seenthis.net/messages/199765
    http://seenthis.net/messages/204846

    Les @import sont surchargeables dans les squelettes sans avoir à toucher aux originaux des éventuels #frameworks qui disposeraient de fichiers sass, par exemple #knacss
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/knacsss

    Le code de ce plugin a été pompé de celui déjà existant pour less
    http://plugins.spip.net/lesscss.html

    • Merci @rastapopoulos et @nicod_, car nos diverses discussions m’ont permis de concrétiser un peu les choses avec scss.
      Le but après avoir tenté de comprendre les imbrications actuelles entre html5/elasticité/grille/css/jsforIE, est de pouvoir simplifier la méthode de fabrication d’un site mais aussi, tenter d’échapper à Bootstrap, et faire que dans tout ce joyeux bordel l’#artisan-web (que je suis) ne se retrouve pas juste bouton pressoir ou assembleur de cascades à la chaine ;)
      Pas sûr cependant que SASS permette de faire du simple, facile pour tous, dont la relecture soit aisée, sans attaches à un framework lourd, et entre autres rêves d’indépendance, autorise à se passer des class le plus possible.
      J’ai aussi très envie d’une optimisation en légèreté avec une css de maximum… 25ko, ce qui devrait être suffisant pour : faire un beau site, alléger le poids des fichiers envoyés au serveur/client et faciliter la prise en main et la maintenance.
      Avec des structures HTML adéquates, et ta piste d’échafaudage @rastapopoulos http://seenthis.net/messages/204846#message205077 que tu nous expliqueras hein ! ça risque d’être bien sympa.

  • Modif sur mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Cette fois, c’est très spécifique : on peut appeler la fonction charger_image_lazy, qui se charge de décider s’il faut charger les images (en mode « lazy load »), en lui passant la valeur du scrollTop.

    Ça sert dans le cas où l’on a un script qui intercepte le scroll pour le gérer à la main. C’est le cas, uniquement sur interface touch, avec Skrollr. Dans ce cas, je déclenche skrollr en lui indiquant de faire ceci lors du « render ».

    var sk = skrollr.init({
       render: function(data) {
           charger_image_lazy(data.curTop);
       }
    });

    Oui, c’est un peu spécial, mais je prépare un site avec de très longues pages en mode « long form » (ou « parallax »), chargement des images en responsive et lazy load, et du coup, viili voilou.

  • Grosse modif de mon #plugin #SPIP image_responsive : il permet désormais de choisir de charger les images en lazyload
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    L’idée, c’est de transformer un des inconvénients de ce système (lancer le chargement des images après un premier rendu de la page) en avantage, et d’intégrer directement un système de lazyload : c’est-à-dire ne charger que les images qui sont réellement affichées dans les limites visibles de l’écran.

    Le plugin change de syntaxe : la deuxième variable permettait de désactiver le chargement des images haute définition, je décide de l’éliminer parce que ça ne sert à rien avec les modifs récentes (calculs et compression plus efficaces), et à la place, la seconde variable permet d’activer (si elle est mise à la valeur « 1 ») le lazyload sur cette image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_proportions{16,9}
            |image_responsive{0,1})
    ]

    Ici, |image_proportions va recadrer l’image selon les proportions 16/9e, sans réduire cependant la taille de l’image.

    Et |image_responsive va fabriquer les éléments permettant le chargement d’une image responsive. Ici, la première variable (« 0 ») est la taille de la vignette chargée par défaut (avec la valeur 0, je décide de ne pas intégrer de vignette : je charge « rien.gif » à la place). La seconde variable (« 1 ») indique donc qu’il ne faut charger cette image que si elle se situe dans la fenêtre visible.

    Au passage, le javascript de lazyload est assez marrant, j’ai privilégié l’efficacité des calculs, du coup la « position » verticale de l’image dans la page est calculé une seule fois (au chargement et au redimensionnement) et stocké dans un « data-top », puis effacé. Ça évite de faire des calculs à chaque fois qu’on scrolle. En revanche, on perd potentiellement en précision (images qui se déplaceraient dans la page, ou blocs affichés/masqués).

    À noter qu’il y a évidemment une tolérance : ça charge un peu plus que l’écran visible, c’est pas la peine que les gens voient trop que les images n’ont pas été chargées.

    Enfin, il y a désormais un calcul en javascript de la hauteur des images tant qu’elles sont en "rien.gif", ça permet de calculer plus précisément le lazyload.

    Comme d’habitude, je l’utilise sur Orient XXI :
    http://orientxxi.info

    • Je me posais la question au sujet du Lazyload, si y’avait pas une autre approche envisageable (c’est peut-être la tienne et j’ai pas compris) :
      – afficher en priorité les images visibles
      – puis aller chercher et « afficher » les autres images (sans attendre que la personne scroll, donc « en-dessous » de la ligne de flottaison)

      J’ai l’impression qu’en terme de rapidité d’affichage c’est équivalent quand on arrive sur le site, mais que cette solution est plus agréable quand on scroll parce qu’on donne une chance pour que les images aient le temps de s’afficher avant (en tous cas forcément plus qu’avec le lazyload).

      C’est peut-être au niveau de la consommation de la bande passante que la solution lazyload est plus avantageuse, mais je ne sais pas quand elle situation elle est vraiment utile.

      Après je dis tout ça un peu comme ça, je sais pas précisément comment ça marche en javascript, peut-être que ce que je propose n’est tout simplement pas possible.

      Une dernière remarque : y’a déjà un plugin LazyLoad dans SPIP.
      http://contrib.spip.net/jQuery-Lazy-Load-pour-SPIP

      Il ne fonctionne pas sur les mêmes principes, mais peut-être pourrait-il être amélioré, en lui donnant des options et tout ? Ou peut-être autonomiser cette fonction si des gens veulent l’utiliser sans le reste du plugin (là encore, tout ça est peut-être trop imbriqué...) ?

      En tous cas merci pour toutes ces contributions autour des images et du #RWD.

    • En gros, ce que fait LazyLoad, c’est de lancer le script jquery Lazy Load, très connu. Mon script est très différent, et son principe de fonctionnement est également très différent, j’ai essayé d’optimiser (limiter les recalculs de positionnement) et ça doit fonctionner en responsive (donc je ne fixe pas les dimensions des images a priori).

      Ensuite, le principe du lazy load n’est pas idéal non plus dans l’absolu (notamment parce qu’il bloque le pré-chargement des images). En tout cas, le fait de charger des images progressivement avant de les afficher, c’est l’assurance de ne pas afficher toutes les images en même temps. Si on a de grosses images, ce n’est pas grave (il y a une image par « écran », plus ou moins), mais si c’est une multitude de petites vignettes (c’est le cas de Flip-Zone), la page est redessinée plusieurs fois (à chaque vignette) et c’est pénible ; en changeant d’un coup toute une série complète de « img src », j’ai bien l’impression que les navigateurs sont optimisés et assez souvent, toute une série de vignettes s’affichent d’un seul coup. Avec un preloading individuel, ça n’a pas l’air de faire pareil (une de mes versions faisait ça : préloading puis affichage). Le preloading avant d’afficher, c’est pas mal sur tout petit écran, mais ça m’a semblé au contraire très pénible sur écran normal.

      Sinon, un preloader de toutes les images, c’est une idée, mais c’est encore un autre principe à mon avis. Je n’y suis pas favorable pour l’instant : charger des trucs « en trop », c’est justement ce qu’il s’agit d’éviter avec les image_responsive (parce qu’on est sans la 3G, parce que le smartphone n’est pas très vaillant…), alors pour le coup, ne charger que si les gens scrollent réellement. Et si tu veux faire ça, à mon avis, le mieux est encore de ne pas utiliser l’option « lazyload » de mon plugin : tu laisses le comportement normal, et je suspecte que c’est plus ou moins le principe de base d’un navigateur a qui on indique tous les « img src » d’une page – il commence par les premiers et/ou les éléments visibles.