Hello 
J’ai bien lu https://git.spip.net/spip/spip/pulls/17
Par contre, je me pose la question de savoir pourquoi avoir fait le choix de 1440px ?
Cela ne serait pas mieux de mettre 1920 ? Surtout que les écrans 4k vont devenir de plus en plus abordable et sans doute bien avant la sortie de spip 3.4…
Franck
Parce qu’au dela de ~1400 de large il faut tout casser et refaire si on veut conserver de la lisibilité.
Si on élargit les blocs au delà de ce qu’on a en 1440 actuellement, tout devient beaucoup trop large/long à lire.
Clairement on prétends pas avoir une « nouvelle » version d’interface super responsive, c’est vraiment un patch qui améliore l’existant, mais qui a des limites.
Mes deux balles (je bosse dans l'accessibilité toute la journée) :
4K != 1920.
La définition de ton écran n'est pas la définition en pixels d'une interface.
Ainsi, mon navigateur me dit ça : Window: 1366px x 704px Viewport: 1366px x 607px (sur un PC qui a 10 ans).
En vérité ce ne sont pas des "vrais" pixels.
Petite explication pour comprendre :
* dans une page web tu dis : body { font-size:100% }
* tout le monde te dira "ça fait 16px la plupart du temps"
* en vrai ça faisait 16px physiques sur un écran CRT (les tubes en 640*480 de notre jeunesse)
* quand on est passé aux écrans plats, on est passé de 72dpi (points par pouces) à 96dpi : nos navigateurs ont commencé, en sous-main, à transformer ces 16px en 16*96/72=22px (j'arrondis) : 22 pixels physiques.
* maintenant les Retina et les trucs comme ça, avec leurs 150dpi ou leurs 300dpi, font la même règle de 3.
Donc bref, 4k ou Retina ou écran plat tout bête, ce n'est pas le nombre de pixels réels marqués sur l'emballage qui conditionne la définition qu'on doit donner dans un navigateur, ni celle que le navigateur offre à l'utilisateur.
Il est plus respectueux, je pense, de dire 1440px de large et de permettre aux gens de zoomer s'ils ont un grand écran (et là encore c'est le navigateur qui fera un calcul interne et rendra des pixels "virtuels" si je puis dire), que de pousser pour du 1920, d'autant que la démarche de spip (usage pour le plus grand nombre) est plutôt à l'inverse et prend en compte des gens avec des configurations un peu anciennes, et j'espère bien que ça durera longtemps.
Mais bon c'est mes deux balles, hein. 
Et d'autre part, sans oublier la taille croissante des ecrans... en largeur !
La facilité de lecture est inversement proportionnel à la longueur de la ligne.....
Or SPIP -en particulier dans le privé- utilise souvent des affichages à rallonge vers le bas
(s'ils sont naturellement utilisables sur smartphone, c'est bien moins pratique à l'écran,
(car il faut alterner la souris pour descendre/remonter avec le clavier
( et sur mon portable : 1600x900 les boites popup du privé sont toujours tronquées
Par contre j'ai utilisé aussi les thèmes privés Fluide et autres....
Bon, cela améliore la largeur utile, ce qui facilite la mise-à-jour en privé
mais je reprendrai l'expression de 'moins fini'....
Finalement le seul cas ou je me plains de la largeur restreinte, c'est sur Skeleditor
(quand on veut corriger vite fait une pedzouille de squelette, ou améliorer ponctuellement
( je n'ai pas réussi à agrandir le textarea à la souris... => lame Grande largeur du CS )
Alors j'avoue que la bonne utilisation consisterait peut-etre à :
proposer une option basculant le menu principal en quatrieme colonne à gauche
(comme WordPress : son menu Admin est tres pratique /c'est bien la seule....
Et cela permettrait meme d'aller jusqu'au bout de la logique Minibando,
en le proposant automatiquement à gauche, que ce soit en privé ou en public,
/* troll : oui, je sais, la communauté préfere les menus qui guident à droite.. */
avec cette 'petite' facilité de WP, qui le réduit en colonne fine ou l'elargit à l'usage...
PS il y a eu un patch proposé par Luis autrefois.... peut-on l'intégrer ?
YannX SPIP(hot) a écrit le 22/03/2020 à 14:40 :
Finalement le seul cas ou je me plains de la largeur restreinte, c'est sur Skeleditor
(quand on veut corriger vite fait une pedzouille de squelette, ou améliorer ponctuellement
( je n'ai pas réussi à agrandir le textarea à la souris... => lame Grande largeur du CS )
Un commit vieux de plusieurs mois permet d'utiliser F11 dans SkelEditor pour passer la zone d'édition en plein écran (et inversement).
YannX SPIP(hot) a écrit le 22/03/2020 à 14:40 :
Finalement le seul cas ou je me plains de la largeur restreinte, c'est sur Skeleditor
(quand on veut corriger vite fait une pedzouille de squelette, ou améliorer ponctuellement
( je n'ai pas réussi à agrandir le textarea à la souris... => lame Grande largeur du CS )Un commit vieux de plusieurs mois permet d'utiliser F11 dans SkelEditor pour passer la zone d'édition en plein écran (et inversement).
pas sur MacOS en cout cas 
Claude