ARNO*

Geek dilettante habitant une belle et grande propriété sur la Côte d’améthyste

  • Évolution de mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Nouvelle fonction : background_responsive() (mêmes variables que image_responsive(), sauf l’option « vertical »). À installer par exemple dans un div, pour fabriquer une image de background, en mode « cover », chargée de manière responsive évidemment.

    <div class="interieur"[(#IMG_FOND|background_responsive{320/600/1280/1920, 1})]>

    Bien noter que ça ne fabrique pas, pour le coup, une <img>, mais un style="background" (et tout le tralala pour que ça tourne en responsive et en lazyload). Il faut donc l’intégrer à l’intérieur d’une balise (ici un div) pour que ça fonctionne. C’est d’ailleurs pour cela que ce n’est pas une fonction image_…, puisque ça ne donne pas un fichier image en sortie.

    Je croyais ne pas avoir trop besoin de gérer les images en background en responsive, puisque je m’en sors très bien d’habitude en utilisant une véritable image (responsive, donc) et son positionnement (voir mon petit remplir_image) :
    http://seenthis.net/messages/264068

    Mais on a obligatoirement besoin de background si on veut pouvoir passer des images en position:fixed réellement par rapport au viewport, pour les effets de parallax (tenter de faire la même chose avec des décalages verticaux lors du scroll, ça donne des animations qui sautent et qui collent mal à la tête).

    Sinon, par la suite, il faudrait uniformiser l’insertion de data-lazy et data-responsive dans le code de image_responsive (ici je ne peux pas ajouter de classe, parce que je suis déjà dans un div que je ne fabrique pas, contrairement au img).

    • Nouvel ajout : dans background-responsive, j’utilise deux images – une horizontale et une verticale (l’une étant calculée automatiquement à partir de l’autre) – que je stocke dans data-portrait-src et data-italien-src. De cette façon, au moment du choix de l’image en javascript, selon la taille d’affichage du conteneur (idéalement, ici, l’écran), ça va donc utiliser l’image qui a le moins de pertes.

      L’idée, c’est que si je prends une image horizontale, et que j’affichage ça pour « remplir » un écran vertical, j’étais obligé d’expédier une image faisant quasiment deux fois la taille de l’écran, avec la droite et la gauche de l’image en dehors de l’écran. Là, je limite beaucoup le problème. (Je pense que ça devient d’autant pertinent qu’on utilise ici de grandes images, potentiellement en double définition.)