Recherche avancée

Médias (0)

Mot : - Tags -/utilisateurs

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (46)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

Sur d’autres sites (8700)

  • lavc : remove libfaac wrapper

    29 septembre 2016, par Josh de Kock
    lavc : remove libfaac wrapper

    There is really no need for two aac wrappers, we already have
    
libfdk-aac which is better. Not to mention that faac doesn’t
    
even support HEv1, or HEv2. It’s also under a license which is
    
unusable for distribution, so it would only be useful to people
    
who will compile their own ffmpeg, only use it themselves (which
    
at that point should just use fdk-aac).
    

    Signed-off-by : Josh de Kock <josh@itanimul.li>
    • [DH] Changelog
    • [DH] LICENSE.md
    • [DH] configure
    • [DH] doc/encoders.texi
    • [DH] doc/ffserver.conf
    • [DH] doc/general.texi
    • [DH] doc/muxers.texi
    • [DH] doc/platform.texi
    • [DH] libavcodec/Makefile
    • [DH] libavcodec/allcodecs.c
    • [DH] libavcodec/libfaac.c

  • Anomalie #2367 : Transmettre #ENV à propre() et aux modèles

    12 octobre 2011, par cedric -

    Je comprends bien que du point de vue c’est un bug. Il pourrait se résoudre en patchant le balise/formulaires_ecrire_auteur pour choisir un destinataire par défaut si pas de contexte. Mais si on se ramène au problème général de l’environnement qui n’est pas transmis aux modèles insérés dans le (...)

  • Evolution #4468 : Unification des CSS pour les boutons et les icônes

    14 septembre 2020

    Ah et dernière question pour les sachant⋅e⋅s : est-ce que quelqu’un⋅e peut m’expliquer vite fait la logique du découpage des squelettes css du privé ?

    Je vois qu’il y a un fichier général theme.css.html un peu fourre-tout, et quelques fichiers pour des modules précis : forms.css.html, icons.css.html, etc.
    Donc la logique semble être : les trucs qui correspondent à un module précis sont dans un fichier css.html à part, et tout le reste en vrac dans theme.css.html.
    Sauf que parfois un module a des règles à la fois dans le fichier général et dans le fichier dédié. Et parfois les mêmes règles. Par exemple pour les formulaires, il y en a un bout dans theme.css.html et aussi dans forms.css.html.
    En l’état, quand il y a des modifs à faire c’est le doutage, on les fait où ?

    Là comme il s’agit de mutualiser les styles de plusieurs choses, dont les boutons de formulaire, le mieux serait de déplacer tout ce qui concerne les boutons dans un nouveau module boutons.css.html tout simplement, depuis forms.css.html et theme.css.html.
    Des objections ?

Navigation