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

    Cette fois, j’introduis la possibilité de fabriquer le code <picture><source> complet pour complètement gérer les images responsive nativement (pour l’instant, dans Chrome).

    L’idée, c’est l’introduction d’un quatrième paramètre dans ma fonction, ce qui permet de définir les media queries correspondant à chaque taille d’image.

    Par exemple :

    [(#LOGO_ARTICLE_NORMAL
            |image_responsive{
                    0/50/100/200,
                    0,
                    0,
                    (max-width:470px)/(max-width:1009px)/
            }
    )]

    La première variable (0/50/100/200) est la liste des tailles d’images autorisées :
    – 0 n’est pas une taille d’image, ça signifie simplement qu’au chargement de la page, le <img> se fera sur rien.gif
    – ensuite on autorise des images de 50 pixels, 100 pixels, 200 pixels (donc trois tailles).

    Si on n’indique rien d’autre, on a le fonctionnement habituel du plugin : une fois la page chargée, un javascript calcule la taille de l’endroit qui contient cette image, et en fonction va appeler l’image à la bonne taille (et éventuellement en haute définition si écran haute déf.)

    La seconde variable permettrait de forcer le chargement en « lazy load ». Comme la valeur est zéro (par défaut), ce mode est désactivé. Si on avait forcé la valeur à 1, alors l’image ne serait chargée que si elle visible à l’écran (ou bientôt visible en scrollant). Ça permet, si on a envie, de ne pas charger des images qui seraient bien plus loin en bas de page. Ici, il est important de laisser à zéro, parce qu’on veut un code complet qui se charge dès avant le lancement de la page (voir en préchargement).

    La troisième variable est à zéro (par défaut). Si on met à un, alors on indique qu’on veut que les calculs se fassent sur la hauteur du conteneur, et non sur la largeur. Ici il faut laisser à zéro, je n’ai pas encore adapté mon code pour qu’il fonctionne avec les images alignées verticalement.

    La quatrième variable est la nouvelle : si on décide de l’utiliser, alors on va permettre au plugin de fabriquer le code complet qui fait fonctionner les images responsive directement en HTML5. C’est alors bien plus rapide à l’affichage, et le pré-chargement fonctionne sur ces images.

    Le code généré est le suivant :

    <picture style='padding:0;padding-bottom:63.5593220339%' class='conteneur_image_responsive_h'>
            <source media='(max-width:470px)'
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=50 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=50&amp;dpr=2 2x
                    '>
            <source media='(max-width:1009px)'
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=100 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=100&amp;dpr=2 2x
                    '>
            <source
                    srcset='
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=200 1x,
                            index.php?action=image_responsive&amp;img=IMG/arton5.jpg&amp;taille=200&amp;dpr=2 2x
                    '>
            <img class='image_responsive' alt="" src='https://seenthis.net/rien.gif' data-src='IMG/arton5.jpg' data-l='2832' data-h='1800' data-tailles='[\&#034;50\&#034;,\&#034;100\&#034;,\&#034;200\&#034;]' />
    </picture>

    Le principe de cette variable est de contenir autant de mediaqueries qu’il y a de tailles autorisées dans la première variable, en les séparant par des slash (comme pour les tailles de la première variable). Pour rappel : le 0 ne compte pas comme une taille autorisée.

    Ici, on avait les tailles autorisées : 0/50/100/200. On a donc trois tailles autorisées. Dans les medias queries, il nous faut donc définir trois valeurs correspondant à ces tailles d’images autorisées :
    (max-width:470px)/(max-width:1009px)/

    Ce qui signifie :
    – utiliser l’image de largeur 50 dans le cas (max-width:470px)
    – utiliser celle de largeur 100 dans le cas (max-width:1009px)
    – utiliser l’image de largeur 200 dans les autres cas (par défaut donc).

    Noter le slash final, qui permet de voir qu’il y a bien une troisième valeur attendue (valeur vide).

    Le plugin fabrique donc les <source> correspondant à ces tailles, en indiquant à chaque fois l’image en définition 1x et l’image en haut définition (2x).

    Sur les navigateurs qui comprennent ça (Chrome), ça fonctionne très bien : les images sont chargées bien plus rapidement (puisqu’on n’attend plus le chargement de la page, des JS et des CSS avant de lancer le chargement des images), et le preloader est censé prendre en compte ces informations. (Et si on désactive Javascript : ça fonctionne parfaitement sur ces navigateurs…)

    Actuellement caniuse.com donne 40% des visiteurs compatibles (essentiellement : Chrome – donc c’est déjà pas rien) mais la prochaine version de Firefox va l’avoir, et vu que c’est Chrome c’est webkit, je ne vois pas pourquoi Safari traînerait encore longtemps. De toute façon, c’est un enrichissement progressif : si le navigateur ne pige pas, le plugin fonctionnera comme auparavant uniquement en Javascript. (Dommage quand même que ça ne fonctionne pas sur Safari mobile, quand même.)

  • Tutoriel sur l’URL Rewriting (réécriture d’URL)
    http://www.webrankinfo.com/dossiers/techniques/tutoriel-url-rewriting#reecriture

    Le format de l’URL à réécrire est basé sur les expressions régulières, dont la base devra être acquise pour pouvoir définir des règles de réécriture. Ne vous inquiétez pas, pour la plupart des cas c’est très simple.

    Voici la liste des éléments pris en considération dans les règles de réécriture :

    #url_rewriting #regexp #url

  • On dirait que certains ont trouvé une parade aux contenus de qualité variable sur leurs domaines : les sous-domaines !

    Les sous-domaines, une solution à Google Panda ?
    http://www.webrankinfo.com/dossiers/techniques/panda-sous-domaines
    C’est sans doute la première fois qu’on entend parler d’un gros site disant avoir trouvé une solution pour récupérer (une partie de) son trafic après avoir été impacté par Panda. En résumé, ce portail d’articles isole ses contenus dans des sous-domaines... Est-ce réellement la solution ?

    #seo #référencement #google #panda #qualité #fermes_de_contenu

    • @stephane, je n’entends pas te faire changer d’avis sur les conseils en référencement. Ton incrédulité dans ce domaine n’est pas nouvelle. Néanmoins, je te rejoins en cela que le coup des sous-domaines reste très superficiel et pas du tout pérenne.

      Ce qu’il faut, c’est bel et bien privilégier le contenu de qualité, ce que la plupart des responsables éditoriaux de sites refusent de comprendre, parce que ça coûte plus cher que de déplacer des dossiers vers des sous-domaines, ou encore importer un flux RSS et de changer le titre de la page.

      D’ailleurs, dès que je recommande à mes clients de rédiger du contenu sur leur site, parce qu’ils sont 100 (fréquent) à 100.000 (déjà vu) concurrents qui utilisent strictement le même flux XML fourni par le fournisseur, en leur expliquant qu’il faut bien une heure par fiche produit pour donner une description et des conseils pertinents (les gens ont besoin d’être rassurés, pas de lire une fiche produit réduite à « longue et puissante » pour — véridique, j’ai eu ce cas — décrire une balle de golf), ou encore qu’il faut fournir des guides de conseils d’achat à disposition des clients (quoi ? les dossiers fnac ? jamais entendu parler ?), il n’y a plus personne. :-D

      Les clients veulent une potion magique. Les sous-domaines en sont une composante. :-D