[SPIP Zone] Prive Fluide : et même encore un peu mieux ?

Hello,

à la faveur de la doc proposée sur contrib, je découvre et teste
https://zone.spip.net/trac/spip-zone/browser/plugins/prive_fluide/trunk

Super, et merci, ça rend le back-office un minimum responsive et on en a bien besoin !

J’ai cependant plusieurs remarques :

-* il me semble qu’il faudrait fixer une largeur maxi du conteneur principal autour de 1400px, car au delà ça devient un peu contre-productif, tout devient beaucoup trop large par rapport à l’usage (mais là si je bloque un max-width sur .page, les blocs continuent à changer de taille quand j’élargis l’écran…)

-* dans le wysiwyg il est bien de fixer une largeur maxi pour eviter des lignes trops longues, mais là tel que c’est fait ça flotte au milieu, c’est un peu bizarre, surtout quand on a des blocs avec un background comme le descriptif. je pense que fixer le max-width sur .champs>div et laisser en fer à gauche serait mieux

-* je reste assez frileux sur l’usage des font-face, surtout pour du back-office : c’est quand même assez pénible dès qu’on a une connexion un peu lente et pas les fonts en cache d’avoir des pages blanches (sans aucun texte) pendant que ça charge. Je trouve que le désagrément est souvent cher payé pour le bénéfice, et là dans un back-office on cherche l’efficacité et la lisibilité avant tout.

Est-ce que vous êtes ouverts à une évolution dans ce sens ?
Ou vous êtes très attaché à ces choix et préférez qu’on y touche pas ?

Je pense que moyennant ces modifs on pourrait même ajouter ce gros patch CSS dans la dev 3.3 qui aurait au moins le mérite d’avoir un back-office un peu plus utilisable avec les petits écrans…
(et cela dit ensuite votre plugin pourrait compléter pour garder vos choix initiaux tels quels pour votre usage)

--
Cédric

Le 04/11/2019 à 12:17, Cerdic a écrit :

à la faveur de la doc proposée sur contrib, je découvre et teste
https://zone.spip.net/trac/spip-zone/browser/plugins/prive_fluide/trunk

-* il me semble qu’il faudrait fixer une largeur maxi du conteneur principal autour de 1400px, car au delà ça devient un peu contre-productif, tout devient beaucoup trop large par rapport à l’usage (mais là si je bloque un max-width sur .page, les blocs continuent à changer de taille quand j’élargis l’écran…)

Il y a une version parallèle de nicod «Remix», (svn://zone.spip.org/spip-zone/_plugins_/prive_fluide/branches/remix)
  qui a un
`max-width: 1100px;`, peut être à tester aussi :slight_smile:

MM.

Merci pour les retours.

Une proposition : n’intégrer que la partie « largeur étendue + responsive + police plus grande » à la 3.3dev, et laisser le reste dans ces plugins (les fontface, la largeur du wysiwyg etc).
Dans le plugin j’ai fait le choix de rendre l’option « écran étroit/large » inopérante, mais peut-être qu’elle peut être conservée de la sorte (?) :

  • écran étroit = largeur fixe autour de 1400px
  • écran large = largeur fluide

Le 04/11/2019 à 13:58, Charles Razack a écrit :

Merci pour les retours.

Une proposition : n'intégrer que la partie « largeur étendue + responsive + police plus grande » à la 3.3dev, et laisser le reste dans ces plugins (les fontface, la largeur du wysiwyg etc).
Dans le plugin j'ai fait le choix de rendre l'option « écran étroit/large » inopérante, mais peut-être qu'elle peut être conservée de la sorte (?) :

- écran étroit = largeur fixe autour de 1400px
- écran large = largeur fluide

Ça serait peut être bien en fait.
Et d'en faire une nouvelle branche qui contiendrait juste le patch minimal pour la 3.3, qu'on pourrait tester et sur lequel on pourrait se mettre d'accord avant de l'intégrer.

--
nicod_

Du coup je commence des tests en ce sens dans une branche perso ici (branche prive_responsive) : https://git.spip.net/tcharlss/spip/commits/branch/prive_responsive

Le 04/11/2019 à 14:03, nicod_ a écrit :

Ça serait peut être bien en fait.
Et d'en faire une nouvelle branche qui contiendrait juste le patch minimal pour la 3.3, qu'on pourrait tester et sur lequel on pourrait se mettre d'accord avant de l'intégrer.

Oui alors je réponds à tes suggestions :

* je pense pas que détourner écran large/étroit en max-width=100%/max-width=1400px soit une bonne idée, ça va être incompréhensible et ça ne correspond pas à la même chose
* à partir du moment où on fait responsive, il me semble que ce réglage écran large/écran étroit disparait et n’a plus de raison d’être car c’était un pis-aller historique

Par ailleurs :

* si on utilises css grid qui n’est pas supporté par les vieux navigateurs, je pense qu’il faut garder un layout standard et qui fonctionne pour les vieux navigateurs, et mettre les nouvelles directives dans un @support() {} comme tu l’as fait dans le plugin pour que même si c’est pas responsive sur les vieux nav ça s’affiche au moins correctement (pas plus mal qu’avant). Même si c’est chiant à gérer je pense pas qu’on puisse envoyer paitre les utilisateurs qui ont du vieux matos, ça a jamais été notre politique. Donc j’aurai tendance à dire de poser un layout de base sans max-width ni media queries, qui reste peu ou prou celui qu’on avait en 2 colonnes par exemple

* si on touche body.html attention : les vieilles pages en exec php (pas en skel donc) qui utilisent les inc_commencer_page_dist() et les fonctions de inc/presentation_mini.php ne passent pas par body.html et ont une structure implicite gérée dans le php, qu’il faudra résoudre aussi

* je pense vraiment que dans le core il faut limiter à une largeur maxi genre 1400px, et pas aller à 100%, et tu pourras mettre l’option du 100% dans un plugin pour les vrais fans
* j’ai pas vérifié comment ça marche avec bigup et les zones étendues de drop ? il faut qu’on soit bon là dessus aussi

--
Cédric
Le 5 nov. 2019 à 01:31 +0100, Charles Razack <tcharlss@bravecassine.com>, a écrit :

Du coup je commence des tests en ce sens dans une branche perso ici
(branche prive_responsive) :
https://git.spip.net/tcharlss/spip/commits/branch/prive_responsive

Le 04/11/2019 à 14:03, nicod_ a écrit :
>
> Ça serait peut être bien en fait.
> Et d'en faire une nouvelle branche qui contiendrait juste le patch
> minimal pour la 3.3, qu'on pourrait tester et sur lequel on pourrait
> se mettre d'accord avant de l'intégrer.
>
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Le 05/11/2019 à 10:14, Cerdic a écrit :

Oui alors je réponds à tes suggestions :

* je pense pas que détourner écran large/étroit en max-width=100%/max-width=1400px soit une bonne idée, ça va être incompréhensible et ça ne correspond pas à la même chose
* à partir du moment où on fait responsive, il me semble que ce réglage écran large/écran étroit disparait et n’a plus de raison d’être car c’était un pis-aller historique

Oui le plus simple serait de supprimer cette option qui n'a plus trop d'utilité.

Après je ne vois pas pourquoi tu parles de « détourner » l'option, c'est son comportement actuel que je trouve confus et contre-intuitif : l'écran « large » fait apparaître une colonne supplémentaire qui est vide sur beaucoup pages, tout en réduisant au final la largeur disponible pour le contenu principal (~540px contre ~550px).
Là ben ça ferait exactement ce que ça dit, et uniquement ça : changer la largeur d'ensemble de la page.

Mais bref, oui, la même largeur responsive pour tout le monde, c'est plus simple.

Par ailleurs :

* si on utilises css grid qui n’est pas supporté par les vieux navigateurs, je pense qu’il faut garder un layout standard et qui fonctionne pour les vieux navigateurs, et mettre les nouvelles directives dans un @support() {} comme tu l’as fait dans le plugin pour que même si c’est pas responsive sur les vieux nav ça s’affiche au moins correctement (pas plus mal qu’avant). Même si c’est chiant à gérer je pense pas qu’on puisse envoyer paitre les utilisateurs qui ont du vieux matos, ça a jamais été notre politique. Donc j’aurai tendance à dire de poser un layout de base sans max-width ni media queries, qui reste peu ou prou celui qu’on avait en 2 colonnes par exemple

Oui support pour les vieux navigateurs, bien sûr.
Après faut voir jusqu'à quels navigateurs il faut remonter, il faudrait aussi prendre en compte ceux qui ne supportent même pas les media-queries ? Parceque c'est un peu plus compliqué que ça du coup, ça voudrait dire faire 2 bases différentes :

- layout de base à l'ancienne en 2 colonnes pour les vieux coucous
- layout pour mobiles en 1 seule colonne pour ceux qui supportent les medias queries (mobile-first).

* si on touche body.html attention : les vieilles pages en exec php (pas en skel donc) qui utilisent les inc_commencer_page_dist() et les fonctions de inc/presentation_mini.php ne passent pas par body.html et ont une structure implicite gérée dans le php, qu’il faudra résoudre aussi

Pour ces pages j'aurais besoin d'exemples afin de pouvoir faire des tests. On en trouve où ?

Actuellement la modif du body.html avait 2 principaux objectifs :

- 1) mettre #contenu avant #navigation et #extra, afin d'avoir l'ordre naturel dans le HTML. En CSS grid, l'ordre n'a pas trop d'importance mais pour le layout en fallback pour les vieux navigateurs, à voir, ça peut être problématique oui.

- 2) Remanier légèrement afin de faire en sorte qu'il y ait un .largeur au bon endroit dans chaque section principale, et donc qu'il se comporte comme un bon vieux .container de base. Ainsi changer la largeur de la page devient super simple : il suffit de mettre un max-width sur ce .largeur (alors que maintenant il faut le faire 50 fois sur 50 sélecteurs différents).

* je pense vraiment que dans le core il faut limiter à une largeur maxi genre 1400px, et pas aller à 100%, et tu pourras mettre l’option du 100% dans un plugin pour les vrais fans
* j’ai pas vérifié comment ça marche avec bigup et les zones étendues de drop ? il faut qu’on soit bon là dessus aussi

Yep ok.
Je suis un vrai fan, donc je la garderai dans le plugin :stuck_out_tongue:

Le 04/11/2019 à 12:39, Matthieu Marcillaud a écrit :

Le 04/11/2019 à 12:17, Cerdic a écrit :

à la faveur de la doc proposée sur contrib, je découvre et teste
https://zone.spip.net/trac/spip-zone/browser/plugins/prive_fluide/trunk

-* il me semble qu’il faudrait fixer une largeur maxi du conteneur principal autour de 1400px, car au delà ça devient un peu contre-productif, tout devient beaucoup trop large par rapport à l’usage (mais là si je bloque un max-width sur .page, les blocs continuent à changer de taille quand j’élargis l’écran…)

Il y a une version parallèle de nicod «Remix», (svn://zone.spip.org/spip-zone/_plugins_/prive_fluide/branches/remix)
qui a un
`max-width: 1100px;`, peut être à tester aussi :slight_smile:

MM.
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Hello,

Ni voyez aucune animosité, mais moi je remarque que j'avais lancé un appel et lancé un projet similaire d'adaptation responsive et que on m'as mis un gros vent à l'époque sans essayer ni d'en discuter ni d'y participer, pour pas faire une issue ou une pull request, ou demander les sources scss. Bon il est vrai que à l'époque Github c'était le mal ^^ à croire que c'est devenu mieux depuis la rachat par crosoft …

https://github.com/mistergraphx/spip_admin_responsive

1er commit 2016

Et comme l'histoire à tendance a ce répéter, la première version d'un theme qui était fluide, elle était sur la zone dans le plugin mes_preferences, et date de 7ans : elastic layout

https://zone.spip.net/trac/spip-zone/changeset/63570/spip-zone

Une belle preuve de développement de projets participatifs et communautaires …

Bon WE

--

Bonne journée
Arnaud B. (Mist. GraphX)