/star-trek-musical-tribute-50th-annivers

Et des vidéos:

▻https://www.youtube.com/watch?v=l94v4YOqxOc

▻https://vimeo.com/128757503

@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.

Bon, du coup pour moi c’est OK pour l’instant.

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…

https://dl.dropbox.com/s/wijfku31jnwdl8i/20180122_Image_ST.png

en abyme :-)

https://dl.dropbox.com/s/oxbiny3jgoexonu/20180122_Image_ST2.png

^v^

@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…

https://dl.dropbox.com/s/ao0mc8daomcuyxu/20180122_Image_ST4.png

… après avoir posté le commentaire précédent

https://dl.dropbox.com/s/g2lktu4qej23oeh/20180122_Image_ST3.png

(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 :

https://i.pinimg.com/originals/6f/6b/fb/6f6bfbfb9948b94ed8dc893ec74a246b.jpg

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.

@arno c’est up :)

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 :

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 :

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 ?