Des affiches pour tester les nouvelles insertions d’images…
Suivi du reboute :
Des affiches pour tester les nouvelles insertions d’images…
Suivi du reboute :
@arno je viens d’up avec ta dernière modif, c’est bon pour les images :)
Génial, j’avais pas vu (je te causais dans le vide sur IRC :-))
Maintenant il faut aussi installer la correction du Autoembed, il manque un </div>.
@arno tu n’est plus connecté sur IRC :p Je viens d’up autoembed.
Bonjour à tous les deux et merci pour SeenThis ! Mais comment fait-on s’il vous plaît pour poster une image ?
@cjldx Il faut copier directement l’URL de l’image dans ton message à l’endroit où tu veux qu’elle apparaisse. Le système se chargera de fabriquer l’affichage qui va bien.
#merci ! ça a l’air super.
Apparemment, il y a quelques bugs d’affichage…
@simplicissimus pas de bug chez moi, essaye de vider le cache de ton navigateur, ou tente avec une fenêtre de navigation privée ;)
Sur smartphone, c’est pas aussi évident de vider le cache. (Sur iOS, aller dans les Réglages du système, trouver Safari dans la liste, et dans le panneau de droite, vers le bas, trouver « Effacer historique, données de site »).
Vivement qu’on passe sur #SPIP-3.1, on récupérera le timestamp automatique sur les CSS et les JS, ça nous simplifiera les mises à jour…
ah oui @b_b, les deux méthodes suggérées font disparaître la surimpression. Merci !
En revanche, il y a quand même des trucs bizarres…
Lorsque je rafraichis la page…
… après avoir posté le commentaire précédent
(reproductible l’un et l’autre, sans que j’aie fermé ou redimensionné la fenêtre)
Oui, quand on poste un message, le script qui effectue le calcul ne se redéclenche pas, et donc on a le rendu « standard » (l’image fait 1/3 de la largeur par défaut). C’est un aspect à affiner.
Super chouette, bravo !
Visiblement, les petites images sont agrandies de force à la largeur du texte, ce n’est pas forcément très heureux :
▻https://seenthis.net/messages/661811
On devrait donc pouvoir intégrer du Dailymotion :
▻https://www.dailymotion.com/video/x5umyjr
Et l’insertion asynchrone des images, aussi :
Cooooool, DailyMotion, merci !
(et tout le reste aussi, d’ailleurs)
Sinon, @b_b, je viens de faire une mise à jour d’Autoembed pour mieux gérer MixCloud.
Et donc l’intégration Mixcloud :
▻https://www.mixcloud.com/bluenote71/star-trek-musical-tribute-50th-anniversary
(Note : ça ne fonctionne pas avec l’URL mobile.)
@arno, à priori depuis ces modifications sur les images, les flux de seenthis (atom donc) font des trucs bizarres quand il y a des images, ai-je l’impression. Dès qu’il y a une image ça fait un gros blanc en dessous du texte, et en fait c’est parce qu’il y a un conteneur, le lien de l’image qui prendre plein de place, alors que l’image elle-même reste à une taille normale là où elle est insérée.
Et donc je viens de voir dans le code du flux, et il y a des styles insérés dans dur dans le HTML du genre :
<span class='image' style='padding-bottom:146.52014652015%'>
Du coup forcément…
Ah oui, du coup y’a pas de feuille de style externe dans les flux… Il faudrait peut-être insérer en dur dans le style le height:0
(éventuellement un display:block
).
Sinon, pour expliquer le principe : auparavant, pour placer une image dans une page, il fallait indiquer (en dur dans le HTML) ses dimensions (height
) et (width
), de façon à « réserver » son emplacement avant même le chargement de l’image. De cette façon, la page s’affiche sans attendre que les images soient chargées, et on n’a pas de décalage du texte une fois que les images sont chargées.
À partir du moment où la maquette est « responsive », on veut que les images s’affichent en proportion de la taille de la colonne de texte (qui varient, évidemment, selon la taille de l’écran). Du coup, si on a affiché « en dur » les dimensions hauteur et largeur de l’image, elle ne se redimensionnera pas. On a donc besoin de réserver l’emplacement de l’image, mais sans indiquer des dimensions « fixes ». Le principe, alors, c’est d’indiquer sa proportion : l’image verticale a une hauteur qui fait 146% de la largeur (en gros : une fois et demi plus haute que large). Si on affiche l’image sur une largeur de 300 pixels (smartphone), la hauteur « réservée » sera de 438 pixels ; si on affiche l’image sur une largeur de 550 pixels (écran d’ordinateur), la hauteur réservée sera de 803 pixels. Je dis « hauteur réservée », puisque le principe est d’indiquer l’emplacement qu’occupera l’image dès l’affiche initial de la page, c’est-à-dire avant même qu’elle soit téléchargée. Pour indiquer le proportion (hauteur divisée par largeur) d’un bloc, en HTML, il n’y a qu’une solution : donner un padding-bottom
(qui est la valeur exacte de cette proportion), en forçant la « hauteur » à 0.
Oui je fais ce genre de calculs aussi mais pas pour le même besoin (pas pour pré-réserver de l’espace avant chargement), pour avoir des blocs ayant tels proportions (16/9, 4/3, etc) même lorsque ce ne sont pas des images, n’importe quel bloc HTML. J’ai même une mixin pour ça :
/* Garde la proportion d'un bloc en permanence */
@mixin aspect-ratio($width, $height, $selector:'.inner') {
position: relative;
&:before {
display: block;
content: "";
width: 100%;
padding-top: ($height / $width) * 100%;
}
> #{$selector} {
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
}
}
Mais du coup c’est pas en dur dans le HTML puisque ce n’est pas pour réserver une place avant chargement. Je ne sais pas si les flux doivent vraiment bénéficier de tout ça… C’est obligé que ce soit le même code ? Ou bien on peut nettoyer après coup en enlevant les attributs styles ?
#seenthis_fonctionnalités Les #hashtags, hiérarchisés
Bon, les hashtags sont désormais omniprésent, je ne pense pas que ce soit particulièrement une caractéristique de Seenthis.
En revanche, il y a l’aspect hiérarchisé qui est marrant : les messages avec le hashtag #seenthis_fonctionnalités apparaissent aussi dans la page du hashtag #seenthis_fonctionnalité, et du hashtag #seenthis, et #seen… On peut par exemple préciser #spip-3.1, ou #spip-3 ou juste #spip, et ça fera une hiérarchie. On a une série avec #ghost et autres endroits abandonnés…
Et par ailleurs on a un système de thématisation automatique, qui tourne avec l’API Reuters (OpenCalais), qui produit des hashtags automatiquement.
Et enfin on peut s’abonner (« suivre ») des hashtags (pas seulement des @auteurs). Si on suit un hashtag, dans la logique des hashtags hiérarchisés, on voit aussi passer les enfants de son hashtag. Ça me semble particulièrement intéressant, parce qu’on peut taguer de manière précise (#spip-3.1), mais suivre de manière plus générale (#spip tout court).
Commentaire : j’aime bien l’idée des hashtags hiérarchisés, et je trouve particulièrement élégant le principe de taguer précisément et de suivre plus largement. Mais après, dans la pratique, je ne suis pas certain que ce soit très important. En dehors de #spip, je n’ai pas vu autre chose qui tourne comme ça.
Sur le fait de pouvoir s’abonner à un hashtag, très bien. Mais notre communauté étant très petite, là encore dans la pratique, ce n’est pas forcément indispensable. Si on avait le nombre de participants de Mastodon, ça deviendrait sans doute plus pertinent, du coup :-))
Quant à la thématisation automatique, ça fonctionne surtout bien en anglais (c’est censé fonctionner aussi en français, mais ça ne semble pas donner des résultats très spectaculaires), sur certains sujets. Genre dans le flux de @nidal, c’est fonctionne très bien parce qu’on y parle de pays, de villes, de mouvements politiques… qu’OpenCalais identifie plutôt bien.
L’autre aspect problématique, c’est qu’on dépend là d’une API propriétaire, et qu’on n’a pas franchement de concurrent même propriétaire. Je me souviens que @fil avait évoqué des choses libres, mais est-ce que ça fonctionne bien ?
Moi je trouve ça très bien la hiérarchie, ne serait-ce que pour les problèmes de pluriels ou autres tags pas tout à fait écrits pareil.
C’est une des méthodes pour organiser l’énorme bordel que sont les tags libres. Dans d’autres systèmes (Stackoverflow il me semble par ex), il y a des fonctionnalités de fusion des tags, administrable par des admins et par celleux qui ont beaucoup de points. C’est une autre méthode. Mais si on laisse tout libre, alors ce système de hiérarchie limite les dégâts de l’éparpillement.
Et je m’abonne à quelques tags (dont « ghost », pour avoir toutes les variantes).
À signaler : il y a un #hashtag consacré aux hashtags specifiques en usage sur Seenthis : #seenthis_lexique
Inauguré par @intempestive en 2013 ?
▻https://seenthis.net/messages/185096#message185961
Oui, suivre un tag c’est bien, mais comme je le signalais ici ▻https://github.com/seenthis/seenthis_squelettes/issues/151 il serait vraiment sympa de proposer aux personnes de pouvoir être notifiées par email quand un tag qu’on suit est utilisé.
Perso, je n’ai aucun usage des tags automatiques, je pourrais très bien m’en passer.
Pouvoir construire son propre flux (ou sa newsletter) serait vraiment bien. La page « Thèmes », c’est ce qui m’a permis de garder le contact avec Seenthis (@7h36 est vraiment précieux aussi pour ça) et de me motiver à venir éplucher une fois par mois la 20aine de tags que j’essaie de suivre.
Par contre c’est pas évident de savoir quoi suivre parce qu’il n’y a pas de page qui permettrait d’explorer tous les tags et de capter leur hiérarchie, ou encore de voir les articles les plus « favorisés » sur tel ou tel tag (dans l’esprit de Delicious), ou « favorisés » par celles et ceux qu’on suit uniquement. Ou encore une bête liste des « tags » les plus utilisés en ce moment.
Quand ne on suit pas Seenthis au jour le jour, c’est compliqué de saisir les nouveaux usages qui pourrait peut-être nous intéresser.
Merci en tout cas pour ces #seenthis_fonctionnalités, c’est vraiment super classe de capter la richesse de cet outil et sa conception.
J’ai un gros soucis avec #SPIP-3.1 : il ajoute un timestamp aux fichiers, que ce soient les CSS et les Javascript, mais aussi les images passées par les filtres.
C’est certes épatant pour être certain de bien utiliser la dernière version de chaque fichier, mais en revanche, ça me plante complètement l’aspiration des sites en local (parce qu’en local, le fichier monimage.jpg?1436899191
, ça ne marche pas du tout).
Est-ce qu’il y a un moyen prévu (genre une variable) pour pouvoir désactiver cet automatisme ?
J’ai l’impression d’avoir plus de timestamps avec le 3.1, par exemple sur des images passées par image_reduire, qui n’en avaient pas en 3.0.
Ce que je veux, c’est aspirer le site en local, pour en avoir une copie totalement statique. Avec les timestamp, ça ne fonctionne pas.
Pour l’instant, ce que je fais, c’est d’avoir un #FILTRE{mini_html}
dans tous mes squelettes, qui me sert déjà à faire différentes bidouilles (essentiellement, supprimer les tabulations et les espaces surnuméraires dans le code source), et donc là-dedans j’ajoute la suppression des timestamp un peu à la hache (chaque fois que je trouve (jpg|gif|png)\?[0-9]+[\'\"]
, je vire le timestamp).
C’est dans image_graver()
visiblement et il n’y a pas d’option pour le virer (option à ajouter, problablement). Cela dit il n’y a pas de raison fondamentale que les timestamp fassent foirer ta copie locale. Peut-être le fait qu’ils sont avec un ?xxx
et ne finissent donc plus par .jpg
— mais ça aussi ça pourrait se changer.
@b_b, oui j’ai vu |supprimer_timestamp
, mais ça m’oblige à reprendre tous mes squelettes, alors que l’idée est plus dans le sens de ce que remarque @fil. Ou, plus largement, dans le sens de ce qu’ai fait pour image_responsive
:
►http://seenthis.net/messages/374212
Là quand j’ajoute :
define("_SPIP_LIER_RESSOURCES", true);
mes_options
, le même site se met à me fabriquer des squelettes plus verbeux contenant les liens <link href…>
pour permettre l’aspiration du site et des ressources.Là c’est pareil, idéalement on définirait une variable dans mes_options
, et hop terminés les vilains timestamps le temps de faire l’aspiration.
@speciale : le but du timestamp est juste d’éviter que, quand tu fais les mises à jour de ton site (soit en div, soit pendant que tu mets en ligne des articles) tu sois gêné par le cache de ton navigateur. Un logo arton1.jpg
, remplacé par une nouvelle version, est toujours le logo arton1.jpg
; le timestamp ajoute la date de mise en ligne du fichier, et donc ton navigateur ne réutilisera pas la vieille image. Donc c’est bien dans le src
de l’image que ça doit se trouver, pas dans un data-
, qui n’invaliderait pas le cache.
@arno puisque tu as un #FILTRE{truc}
dans tes squelettes, tu peux y ajouter le filtre supprimer_timestamp non ?
@b_b : oui c’est ce que j’ai fait (expliqué plus haut), mais pas directement supprimer_timestamp, qui prend un URL en entrée, et pas l’ensemble de la page.
Mais à nouveau, ça oblige à modifier ses squelettes si on n’a pas l’habitude comme moi de mettre un #FILTRE{mini_html}
absolument partout…
Le problème se pose aussi sur les js et css compactés et agrégés par SPIP qui ont aussi ce timestamp, mais sur lesquels il n’est pas possible de passer le filtre de suppression de ce timestamp.
Sauf erreur de ma part, le nom des fichiers créés dans local/ dépend déjà de la date des fichiers. Le timestamp est alors inutile et contre productif.
Et si le nom du fichier ne dépend pas pas de la date, il suffirait de la rajouter dans le calcul du nom, non ?
Salut @arno*. Il est bien possible que ▻https://zone.spip.org/trac/spip-zone/changeset/104022 t’intéresse comme réponse à ton problème, d’autant plus que ça se greffe sur #FILTRE{mini_html}