
Recherche avancée
Autres articles (89)
-
Creating farms of unique websites
13 avril 2011, parMediaSPIP 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" (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (6934)
-
Evolution #4727 : Des pictos / icônes symboliques pour tout le monde
12 avril 2021Les fontes d’icônes c’est pas top, c’est un peu déprécié aujourd’hui, ça pose pas mal de problèmes.
Pour la partie « icônes purement en CSS », c’est à dire sans rien de plus dans le HTML, je crois qu’on n’a pas trop le choix.
Dans ce cas ce sont des pseudos-éléments CSS:before
ou:after
, si on veut que l’icône hérite de la couleur et de la taille du texte, rien d’autre ne marche à ma connaissance. Pas les svg en background-image en tout cas.D’ailleurs au passage mon 2ème exemple était mauvais :
<i class="spicon_truc"></i> Du texte
→ dans ce cas c’est la balise#ICONE
qu’il faut utiliser.
Pour les icônes CSS, la proposition était bien de n’avoir à qu’à ajouter une classe sur un élément existant, sans<span></span>
ou<i></i>
supplémentaire à l’intérieur.Mais du coup oui, on tombe plein pot sur le problème soulevé par ces icônes à base de fontface : à priori les lecteurs d’écran vont lire ces caractères abscons, et sans moyen de les cacher puisque c’est purement du CSS.
Moi au départ je pensais que la balise #ICONE suffirait : des icônes présentes dans le HTML, ce qui permet de gérer tout les attributs d’accessibilité finement.
Et les gros fichiers de sprites svg, ça diminue le nombre de hits, c’est sûr, mais charger plusieurs centaines de Ko de Sprites pour afficher 3 icônes, c’est peut être beaucoup.
C’est bien pour ça qu’il faut trouver une balance entre le poids et le nombre d’icônes dispos.
La proposition à moyen et long terme c’est de généraliser l’usage de ces icônes dans le privé de Spip, donc ça sera pas chargé pour rien.Et c’est la misère à mettre à jour sans outil spécialisé qui regénère tout le code, et vérifier que ça ne casse pas des choses...
C’est bien l’idée :)
Un outil à piori dans un dépôt à part qui genère tout seul le sprite et le reste.moi j’ai du mal avec "spipcon". Ca fait "petit con", et c’est pas compréhensible si on a pas l’historique derrière. Pour gagner 5 caractères...
On se disait qu’on partirait plutôt sur
sp-icone
du coup. -
Evolution #3103 (Nouveau) : Découpage des fichiers de langue du core en groupes logiques
27 novembre 2013, par Suske -Les fichiers de langue de SPIP-core sont au nombre de 3 : ecrire_xx.php, public_xx.php et spip_xx.php
Ce découpage historique n’est plus très pertinent ni le plus efficace pour les traducteurs (et dans une perspective de réemploi des chaînes).
Un exemple de "groupement logique" serait de créer un fichier dates_xx.php qui permettrait de gérer spécifiquement le casse-tête des traductions de dates...
Voir http://thread.gmane.org/gmane.comp.web.spip.devel/64720
-
Anomalie #4849 (Nouveau) : Lisibilité du tableau des statistiques
12 juillet 2021, par JLuc -#2693 a été fermé suite à la correction du code, mais la présentation du tableau de résultat n’a pas évolué et pour le comprendre, il a fallu que j’étudie le code. Du coup j’ai compris qu’il y a un petit problème de conception que je signale ici, ainsi que le manque de clarté dans un énoncé.
La colonne de gauche présente 2 listes à la suite.
Ces 2 listes sont séparées par un intertitre centré "..." qui indique qu’il y a une forme d’interruption dans la continuité d’une même liste.
Or ce n’est pas le cas puisque l’analyse du code révèle que :
- la première liste présente les 30 articles les plus populaires
- la 2eme liste présente la popularité des 10 articles les plus récents (classés du plus récent au plus ancien)
L’ordonnancement étant totalement différent, il s’agit bien de 2 listes qui devraient être perçues comme totalement différentes...
MAIS
- il y a quand même une interférence entre ces 2 listes puisque les articles présents dans la première (les articles populaires) sont exclus de la seconde.
- il n’y a qu’un seul titre pour ces 2 listes, qui reflète l’ambigüité du mélange (malheureusement sans l’éclairer) : « Afficher les visites pour les articles les plus populaires et pour les derniers articles publiés : « Afficher les visites pour les articles les plus populaires et pour les derniers articles publiés : »
Mais ce n’est pas possible, de même qu’il n’est pas possible de lister dans une même liste des voitures triées par vitesse maximale et des pommes triées par teneur en sucre.Donc il faudrait
- avoir un titre différent pour chacune de ces listes
- à mon avis aussi retirer le doublon qui rend difficile la lecture de la 2eme liste car autant il est simple de dire "c’est la popularité des articles les plus récents" (et intéressant d’avoir une telle liste), autant il est complexe d’expliquer et de comprendre "C’est la popularité des articles les plus récents sauf s’ils font partie des 30 plus populaires du site" (et difficile à utiliser une telle information circonluée).
- ne pas avoir de séparateur "[...]" entre ces 2 listes. Ce ne sera pas utile avec le 2eme intertitre.Par ailleurs le texte explicatif "Comment lire ce tableau" en bas de la colonne de droite contient une explication de ce qu’est la "popularité de l’article : (une estimation du nombre de visites quotidiennes qu’il recevra si le rythme actuel de consultation se maintient)". L’emploi du futur + l’hypothèse "si le rythme actuel de consultation se maintient" donnent des pistes incomplètes et ne permettent pas de comprendre ce que c’est.
- Spontanément j’avais retenu le futur et compris que c’était le nombre total final de visite de cet article, à supposer que sa fréquentation s’épuise mais sur quelle durée ? ça ne voulait rien dire.
- Maintenant je comprend que c’est une estimation du nombre de visite quotidienne à partir d’une "moyenne instantannée" de fréquentation. Mais sur quelle durée se fait cette moyenne instantanée ? La fréquentation estimée se fait elle aussi sur la base d’une moyenne instantanée pour les articles ayant plus d’une journée d’âge ou bien c’est la fréquentation de la veille qui est prise dans ce cas ? Ça ne veut pas dire grand chose encore...
En bref : ça en dit trop ou pas assez. On peut en dire moins avec simplement "une estimation du nombre de visites quotidiennes". Mais pour en dire plus et être plus précis... faudrait donner les infos manquantes.