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 :p


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

Répondre à