Recherche avancée

Sur d’autres sites (10373)

• Evolution #3692 (Nouveau) : Suivre les évolution de MediaJS

  11 février 2016, par realet RealET

  Discussion initiée sur http://thread.gmane.org/gmane.comp.web.spip.zone/39560

  SPIP 3.1 inclus : http://mediaelementjs.com en version 2.15.1.
  La dernière version est la 2.19.0 (10 releases de différence)

  Le changelog
  https://github.com/johndyer/mediaelement/blob/master/changelog.md
  montre qu’il y a eu plein de nouveautés depuis, en particulier pour
  l’accessibilité.
  Est-ce que ça ne vaudrait pas le coup de mettre à jour la lib avant la
  sortie ?

  Pour tester, j’ai donc fait une installation d’un SPIP 3.1 svn vierge.
  Créé une rubrique.
  Créé un article.

  Joint un .mp3 et un .mp4 à l’article.
  Mis dans le texte de l’article :
  

  Publié.

  Résultat avant mise à jour de mejs :
  - les 2 players de son s’affichent et fonctionnent (testé avec Opera)
  - les 2 players de vidéo s’affichent et fonctionnent

  Mais ça m’a aussi permis de tomber sur 2 bugs :
  La liste des documents joints en dessous de l’article (site public)
  affiche le lien le .mp4, mais pas vers le .mp3
  > pas très cohérent.

  Le premier .mp4 que j’ai voulu mettre dépassait les limites d’upload du
  serveur.
  J’ai donc eu en ajax un message d’erreur.
  J’ai supprimé de la liste d’upload le gros fichier, mis un plus petit
  fichier, cliqué sur téléverser et je me suis retrouvé sur la page d’accueil.
  Pourtant, le fichier avait bien été rajouté à l’article.

  J’ai ensuite :
  - mis à jour la lib
  - vidé le cache de SPIP
  - vidé le cache du navigateur

  > ça marche !

  Voir : http://zone.spip.org/trac/spip-zone/changeset/94466 (3.1 qui a été reverté)
  Et http://zone.spip.org/trac/spip-zone/changeset/95088 (3.2)

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

  12 avril 2021

  Les 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 #4559 : Découpage et rangement des CSS de l’espace privé

  29 avril 2021

  Bon, les divers ajustements des css du privé ont fait mettre le pied dans l’engrenage.

  J’en profite pour faire un tour d’horizon et noter ce qu’il resterait à faire.
  J’ajoute au cahier des charges le reformatage de css, si le but du rangement est de faciliter les interventions, la lisibilité du code en fait partie.

  Pour éviter les malentendus : la proposition est de rester en gros sur les bases du rangement actuel, en complétant et en ajustant un peu.
  Et plus loin dans le futur, en cas de tabula rasa je pousserais à adopter un rangement à la Integraal, pour ma part.

  Composant	Rangement	Formatage	Commentaire
  alertes	ok	ok
  bando	ok*	ok	Contient aussi les menus de navigation, à déplacer dans un composant dédié
  boutons	ok	ok
  box_skins	ok*	ok	À renommer en « box » tout court (le vieux box.css a été supprimé)
  clear	-	-	Contient quelques resets et des styles utilitaires (pour masquer, etc.). Doublon avec utils.css, fusionner les 2 ? Pour le reset, il y a déjà celui de meyer, par ailleurs.
  content	-	-	Contient beaucoup de choses. Les styles correspondant aux sections pourraient être rangées ailleurs (#pied, #chemin). Le #wysiwyg également sans doute.
  exceptions	-	-	S’il s’agit vraiment de règles spécifiques à des pages précises, renommer en « pages » ? Contient la liste des plugins → à déplacer ?
  forms	ok	ok
  grids	-	-	Encore utilisé ?
  icons	ok*	ok	Contient aussi les onglets, à déplacer dans un composant onglet.css
  layout	ok	-
  lists	ok*	-	Contient des composants qui pourraient être déplacés ailleurs : pagination, plan du site, menu-item + divers (.en-edition, ...)
  minipres	ok	-
  picker	ok	-
  reset	ok	-
  table	ok	-
  theme	-	-	Tout le contenu devrait être dispatché dans les composants adéquats. Ne laisser que des choses spéciales ne pouvant être rangées ailleurs.
  typo	ok*	-	Quelques styles pour les documents qui devraient être dans medias plutôt
  utils	ok	ok	Cf. commentaire sur clear.css
  vieilles_def	-	-	Vide (???)