Recherche avancée

Médias (91)

Autres articles (65)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • MediaSPIP Core : La Configuration

    9 novembre 2010, par

    MediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
    Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

Sur d’autres sites (10751)

  • Evolution #4768 : Sus aux préfixes navigateurs

    5 mai 2021, par cedric -

    je suis pas fan du prefixeur JS :(

    Dans le plugin BS4 j’ai fait un mini-prefixeur utilisable en filtre, soit dans le squelette lui même en ajoutant le filtre à la fin, soit dans le head en l’utilisant en filtre sur le nom du fichier.

    Je dis "mini-prefixeur" car il a pas la prétention de traiter tous les cas, je me suis concentré sur "tous les cas utilisés dans BS4", ce qui couvre quand même les cas les plus courants... (mais pas les css grids par exemple donc)

    J’avais fait une recherche sur les prefixeurs PHP, mais rien trouvé de super convaincant. Cela dit, si quelqu’un a une lib propre et à peu près à jour sous la main, on peut facilement l’intégrer au lieu du truc à la main, et ainsi avoir donc un prefixeur PHP facile à utiliser...

  • Evolution #4727 (Nouveau) : Des pictos / icônes symboliques pour tout le monde

    12 avril 2021

    Je fais un ticket pour la future PR et poser le plan d’action.
    C’est la suite de https://core.spip.net/issues/4562#Des-ic%C3%B4nes

    Proposition pour intégrer un jeu complet d’icônes symboliques.

    Les besoins sont multiples pour pleins d’éléments d’interface, dans le core et les plugins : des barres d’outils, des boutons d’actions, etc.
    Et chacun doit réimplémenter ça un peu à sa sauce, notamment dans le privé.

    C’est un besoin bien distinct des icônes svg de couleur dont on dispose actuellement dans le privé : on veut des pictos symboliques qui héritent de taille et de la couleur du texte, et issus d’un même set afin d’avoir un style unifié.
    Cela vient donc en complément.

    Il s’agit donc de reprendre un jeu d’icônes existant, qu’on n’aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes. Cf. plus bas pour une comparaison initiale des candidats possibles.

    Utilisation

    Ces icônes seraient utilisables de 2 façons :

    1) Des classes .spicon

    Des classes à ajouter à n’importe quel élément inline quand il s’agit d’icônes purement décoratives.
    Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose la contraption de spip + icon = spicon. Il y a aussi spip-icon mais c’est un peu plus verbeux.

    Exemples :

    <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_menu</span><span class="delimiter">"</span></span><span class="tag">></span>Ouvrir le menu<span class="tag"></span>
    
<span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_truc</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Du texte
    
<span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">titrem spicon_machin</span><span class="delimiter">"</span></span><span class="tag">></span>Mon titre<span class="tag"></span>
    
</span></span></span></span>

    2) Une balise #ICON

    En complément, on peut vouloir embarquer une icône svg dans le HTML.

    On propose de reprendre et d’adapter la balise #ICON du plugin Zcore, qui fait ça très bien.
    Cette balise permet d’embarquer une icône du set par défaut, mais également n’importe quelle autre (je rentre pas dans les détails).

    Un modèle correspondant permettra aussi d’inclure des icônes svg dans les textes : 

    <span class="CodeRay">
    
#ICONE{identifiant}
    
#ICONE{chemin/vers/mon_icone.svg}
    
#ICONE{#identifiant_autre_set}
    
</span>

    Identifiants sémantiques

    Les identifiants des icônes seront directement ceux du jeu d’icônes choisi.
    Mais ils peuvent avoir des noms un peu barbares : chevron-double-right, eye-slash, grip-vertical, etc.

    Dans tous les cas on pourra les utiliser tels quels, mais en plus de ça, on propose de faire une correspondance sémantique pour les icônes correspondants aux actions les plus courantes. Par exemple au lieu de faire #ICONE{chevron-double-down} on pourra faire #ICONE{deplier}.
    Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins.

    La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both

    Ressources privé / public

    Cela veut dire 2 ressources à charger :

    • Une font-face pour les classes
    • Un sprite svg pour la balise

    Dans le privé, il faut charger les 2.
    Dans le public, cela pourrait se faire optionnellement, à la demande.

    Candidats

    Pour finir un tableau comparatif des jeux d’icônes possibles (à licences libres), avec mes commentaires initiaux.
    Petite préférence pour Feather actuellement.

    Lib Nb sprite fontface Commentaire
    Bootstrap 1300+ 693ko 85ko Clés en main, beaucoup d’icônes (trop ?)
    Feather 286 ( 100ko) - Styles rounded. Bonne balance nb icônes / poids.
    Octicon (Github) 433 ( 240ko) - Styles rounded. Bonne balance nb icônes / poids. Beaucoup de manips à faire pour créer sprite et cie.
    Material (Google)  ? (?ko) 44ko Style rounded / épaisseur variable. Beaucoup de manips à faire pour créer sprite et cie. Google !
    Core-ui 554 418ko 63ko Clés en main. Sets inutiles non pris en compte dans ce tableau (brands, flags, …)
    Bytesize 101 11ko - Style rounded / épaisseur variable. Léger : le minimum syndical.

    Sprite entre parenthèses = non fourni dans le dépôt ou la dist → poids théorique.

  • Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

    30 avril 2021

    Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
    Je pense que logiquement les listes d’objets devraient suivre.
    En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.

    Pour les listes on peut séparer la question en 2 aspects :

    1) L’emballage extérieur

    Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
    Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)

    Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.

    2) L’intérieur

    Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
    Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.

    Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
    Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.

    Je retiens quelques règles simples :

    • Des espacements suffisants et consistants (le padding quoi)
    • Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
    • À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.

    Donc voilà, c’est pas grand chose à ajuster non plus.
    Les colonnes des tables ont des classes .importante et .secondaire.
    À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.

    Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :

    3) Détails

    Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
    Cette classe serait automatiquement appliquée dans les colonnes.

    Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?

Navigation