Recherche avancée

Médias (1)

Mot : - Tags -/ticket

Autres articles (35)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

Sur d’autres sites (4089)

  • Anomalie #3978 : Reload ajax et contexte au retour d’un URL_ACTION_AUTEUR

    29 septembre 2018, par cedric -

    Pas de bug ici, juste une erreur de conception dans les 2 squelettes :)

    Dans le cas 1 les arguments reloada=1 et reloadb=1 sont passés en argument du href et viennent dans l’URL après un reload ajax d’un bloc
    Du coup quand on passe un {args:{reloadb:''}} et {args:{reloada:''}} dans le refresh ajax ça annule bien l’argument de l’URL et évite la boucle infinie

    Dans le cas 2 les reloada et reloadb ne sont pas en arguments de l’URL mais en argument de l’URL de retour passée à l’action
    Du coup les arguments {args:{reloadb:''}} et {args:{reloada:''}} ne viennent rien faire car ils s’appliquent sur l’URL de l’action, pas sur l’URL de retour.

    Consequence sans doute pas vue : au second coup le refresh de A se fait via l’URL action, c’est a dire en faisant une action indésirable au lieu de simplement rafraichir

    Solution : indiquer dans le refresh ajax qu’il faut utiliser l’URL de départ et pas l’URL action :

    Bloc A (#REM


    Reload A => Declenchera ensuite le Reload de B

    [(#ENVreloada|oui)

    &lt;script type=&quot;text/javascript&quot;&gt;<br />
       ajaxReload('blocb', {args:{reloadb:''},href:'#SELF'});<br />
    &lt;/script&gt;

    ]

    Bloc B (#REM


    Reload B => Declenchera ensuite le Reload de A

    [(#ENVreloadb|oui)

    &lt;script type=&quot;text/javascript&quot;&gt;<br />
       ajaxReload('bloca', {args:{reloadb:''},href:'#SELF'});<br />
    &lt;/script&gt;

    ]

    A noter qu’ici j’ai aussi ajouté une class nohistory sur les liens pour ne pas modifier l’URL de la page web et éviter qu’elle ne devienne celle de l’action

  • Evolution #4080 : Raccourci puce : se débarasser de l’image

    28 septembre 2018, par cedric -

    Je note que la demande initiale simple était "ne plus avoir une image sur cette puce parce qu’on ne peut pas la personaliser" et qu’à la fin il s’agit de tout revoir le fonctionnement des raccourcis SPIP et donc qu’on ne fera rien :)

    Pour revenir au point de départ :

    1/ peut-être ça manque de documentation mais la puce est totalement personnalisable via le mes_options.php :

    $GLOBALS[’puce’] = ’’ ;
    $GLOBALS[’puce_rtl’] = ’’ ;
    $GLOBALS[’puce_prive’] = ’’ ;
    $GLOBALS[’puce_prive_rtl’] = ’’ ;
    

    2/ ça paraitrait moderne de passer à une puce unicode par défaut décorée en CSS avec un fallback texte pour les sites qui upgraderont sans avoir la CSS qui va bien

    
    

    avec les styles suivants :

    .spip-puce b display:none ;
    .spip-puce
    position : relative ;
    top : 1px ;
    display : inline-block ;
    font-style : normal ;
    font-weight : normal ;
    line-height : 1 ;
    -webkit-font-smoothing : antialiased ;
    -moz-osx-font-smoothing : grayscale ;

    .spip-puce:before
    content : "\2023" ;

    Avec puce à choisir parmi
    https://unicode-table.com/fr/2023/
    https://unicode-table.com/fr/25B8/
    https://unicode-table.com/fr/25B6/

    Du coup sans ces styles spécifiques, la puce est un simple tiret typographique, et avec les styles c’est un caractère qui s’affiche dans la couleur et taille de texte courante, et stylable

    2b/
    Voire si on veut faire une transition vraiment smoothly on garde le img actuel en fallback dans le span (au lieu du simple tiret), et il ne s’affichera plus que sur les anciens sites qui n’ont pas ajoutés la nouvelle CSS
    (et on prévient que dans une prochaine version cette puce image disparaitra complètement)

    3/ à partir du moment où on a un plugin qui permet de transformer ces puces en liste je pense que garder le comportement actuel par défaut dans SPIP est pertinent et le plus logique

  • Revision 92613 : Reparer la prise en compte des pnderation des titres. Attention cela ...

    2 novembre 2015, par cedric@… — Log

    Reparer la prise en compte des pnderation des titres. Attention cela change les resultats, car l’index titre se retrouve pondere x8 au lieu de x3.1 sur spip_articles