Recherche avancée

Sur d’autres sites (7024)

• Préférence donnée à mp4 sur webm quand le fichier mp4 est chargé en tant que conversion d’un fichier webm

  21 janvier 2016

  Bonjour,
  le site AlterInfos - América latina (www.alterinfos.org) utilise depuis un an le plugin "Lecteur multimédia HTML5 pour MediaSPIP" qui marche super bien. Merci.
  Jusqu’à présent, les vidéos étaient surtout au format mp4. Mais dans un article récent, les vidéos ont été téléversés au format webm (VP9+Opus), puis, à partir de ces vidéos de référence, une conversion en mp4 a aussi été téléversée. Quand on visualise les vidéos dans Firefox (43, Debian Jessie 64) ou dans Chromium, c’est toujours le fichier mp4 qui est visualisé. Si on met la vidéo au format webm seulement, la vidéo est visualisée dans ce format.
  Ce n’est donc pas un problème de compatibilité du navigateur, mais plutôt peut-être que le fichier "conversion" (mp4) est traité avant le fichier "original" (webm). Si on regarde le code source de la page, le lien vers le mp4 apparaît avant celui en webm.
  Téléverser d’abord le fichier en mp4 puis charger ensuite en tant que "conversion du document" le fichier en webm règle le problème : c’est désormais le fichier en webm qui est joué "par défaut" quand on visualise la vidéo.
  Mais il me semble que ce serait plus logique que ce soit le document de référence et non sa conversion qui soit joué par défaut quand on visualise une vidéo.
  Ça permettrait aussi de choisir la vidéo qu’on souhaite diffuser "par défaut" (dans notre cas, la vidéo webm est beaucoup plus légère [car VP9 et opus], donc c’est assez logique de vouloir que ce soit la vidéo par défaut…
  Cordialement,
  Nicolas

• Anomalie #3645 (Nouveau) : Plusieurs bugs avec le bouton plein écran

  10 janvier 2016, par RastaPopoulos ♥

  Impossible d’avoir plusieurs champs textarea avec le bouton "plein écran" sur la même page. Au moins trois bugs avec ça.

  J’ai par exemple un objet qui a 5 champs textarea, dont au moins 2 ou 3 peuvent être des textes un peu longs. Donc déjà moi j’ai bien envie que les rédacs puissent mettre en plein écran sur ces champs. MAIS de toute façon j’ai pas le choix : j’ai activé la barre d’édition du porte plume sur tous ces champs (SANS demander explicitement le bouton plein écran) et SANS rien demander de spécial : ça m’ajoute de toute façon le bouton plein écran partout sur toutes les barres.

  Donc ce bouton est maintenant là 5 fois sur les 5 champs. Mais quand on clique sur n’importe lequel :

  1) ça fait le plein écran TOUJOURS pour le même champ : le dernier de la liste
  2) quand on clique ensuite sur le bouton "réduire" : ça fait tourner plusieurs plein-écran différents pour ceux des 5 champs qui sont non vides + celui sur lequel on a cliqué au départ (si c’était un qui était vide)
  3) quand on sort du plein écran, le champ sur lequel on était a changé de taille pour être de la hauteur de l’écran (la hauteur qu’il avait pendant le plein écran donc) ! Alors que dans le HTML j’ai par exemple un champ qui est de "rows=4", j’ai absolument PAS envie que tout d’un coup il fasse la hauteur d’un écran. Sauf si son contenu est déjà long, auquel cas le porte plume le met déjà à une taille correct il me semble. Mais en tout cas le fait même de sortir du plein écran ne doit absolument pas changer la taille, c’est seulement la longueur du contenu qui peut éventuellement être une cause.

• Anomalie #4111 (Nouveau) : Quand un formulaire est posté, donner accès aux retours dans l’environn...

  12 mars 2018, par RastaPopoulos ♥

  Un problème d’accessibilité des formulaires signalé par Julich sur le forum de Formidable :
  https://contrib.spip.net/Formidable-le-generateur-de-formulaires?debut_comments-list=@493531#forum493531

  Une norme d’accessibilité est de modifier notamment le