Recherche avancée

Sur d’autres sites (11623)

• 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 (???)

• Anomalie #3861 : Tri et caractères accentués dans boucle DATA

  7 février 2017

  Pour le pourquoi :

  • Les boucles articles, rubriques, etc, utilisent le moteur de base de données pour trier (ie ORDER BY titre) qui s’occupe brillamment de trier dans un ordre logique pour l’encodage utilisé
  • les boucles DATA utilisent PHP avec un tri sur un tableau de données.

  Actuellement {par x} dans une boucle DATA utilise un algorithme de tri assez classique qui fonctionne bien pour tout ce qui est numérique, mais effectivement ça peut poser des problèmes dès lors qu’on souhaite un tri naturel ou alphabétique sur des chaines non ascii.

  On pourrait peut être étendre pour la boucle DATA le critère par, de sorte que

  • {par alpha x} utiliserait une comparaison de texte en utilisant l’encodage (fonctions strcoll(), strcmp() ou strcasecmp() peut être)
  • {par naturel x} utiliserait une comparaison naturelle des nombres (fonction natsort()) (mais ne semble pas par contre trier correctement les accents)

  - http://php.net/manual/en/function.strcmp.php
  - http://php.net/manual/en/function.strcasecmp.php
  - http://php.net/manual/en/function.natsort.php

  Après un court test, les fonctions strcmp() ne prennent pas en compte les accents. Ça ne suffira pas. Une solution proposée convertie la chaine avec iconv() : http://stackoverflow.com/questions/14655092/comparing-utf-8-string mais suggère de préférer la classe Collatior (mais il faut l’extension Intl qui ne sera peut être pas installée partout)…
  Au sein de SPIP, si on suit cette technique, on peut peut être utiliser translitteration() pour enlever les accents, puis trier sur le résultat avec strcmp() ou strnatcmp() ou simplement avec < > d’ailleurs.

• avutil/libm : correct isnan, isinf compat hacks

  15 novembre 2015, par Ganesh Ajjanagadde

  avutil/libm : correct isnan, isinf compat hacks
  isnan and isinf are actually macros as per the standard. In particular,
  
  the existing implementation has incorrect signature. Furthermore, this
  
  results in undefined behavior for e.g double values outside float range
  
  as per the standard.
  This patch corrects the undefined behavior for all usage within FFmpeg.
  Note that long double is not handled as it is not used in FFmpeg.
  
  Furthermore, even if at some point long double gets used, it is likely
  
  not needed to modify the macro in practice for usage in FFmpeg. See
  
  below for analysis.
  Getting long double to work strictly per the spec is significantly harder
  
  since a long double may be an IEEE 128 bit quad (very rare), 80 bit
  
  extended precision value (on GCC/Clang), or simply double (on recent Microsoft).
  
  On the other hand, any potential future usage of long double is likely
  
  for precision (when a platform offers extra precision) and not for range, since
  
  the range anyway varies and is not as portable as IEEE 754 single/double
  
  precision. In such cases, the implicit cast to a double is well defined
  
  and isinf and isnan should work as intended.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavutil/libm.h