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 <tchar...@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
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à