Le problème (depuis toujours), c'est que pour les rédacteurs c'est left, center ou right, point barre.
Et qu'on se retrouve à devoir expliquer aux utilisateurs pourquoi ça pète quand on insère plusieurs photos en left avec des textes courts à côté, à cause du float.
Ou qu'il faut ajouter des <div class="nettoyeur">
Ce que je propose c'est qu'on ait un raccourci <doc123> par défaut, en premier, quitte à avoir d'autres options (dans la boite des documents, ou par inserer_modele).
Je ne propose pas, évidemment, de ne plus gérer les .spip_document_left et right.
Et je maintiens que l'usage le plus courant aujourd'hui, c'est quand même d'insérer une image dans le texte, sous forme d'illustration, qui dispose de toute sa largeur, un peu comme un embed de vidéo ou autre.
le fait qu'en mobile first, petite colonne, on force tout en pleine largeur par défaut, n'empêche en rien qu'en grand écran, les rédacteurices puissent alterner des choses à gauche et à droite pour animer les contenus et rendre la chose imprévue, pas tout carré monotone
Je partage l'avis de Rasta sur ce point, et puis évitons de trop en ajouter dans la 3.3 elle est déjà pas mal chargée en nouveautés (et changements qui peuvent "casser").
l'insertion en grande image, pleine largeur là bien sûr ça n'a pas de sens, mais l'insertion en mode miniature cliaquable, que si
Attention, le nouveau modèle de doc n'affiche plus de vignette, c'est plein pot par défaut, même si c'est encore possible en jouant avec <doc|left|largeur=300>
Je ne propose pas, évidemment, de ne plus gérer les .spip_document_left et right.
Comme dit plus haut il faut les garder, mais aussi les adapter au nouveau modèle de doc car à ce jour on limite la largeur des doc let/right à 66% du conteneur cf :
Amha, ça n'a aucun intérêt de laisser les gens afficher une image qui prend 2/3 de large et ne laisse que 1/3 au texte. 33% de large d'une ligne de texte c'est foireux, quelle que soit la largeur de celle-ci, car "normalement" une ligne de texte affiche le "bon nombre" de caractères pour être lisible (sauf si le webmestre a décidé de faire de la merde :p).
Exemple concret sur demo.spip où j'ai fait exprès de coller une image plus large que 230px pour illustrer :
Je propose donc de changer la largeur max des doc en left/right à 33% de large afin de garder suffisamment d'espace pour le texte qui "habille" l'image, voir cette capture pour démo :
Et je maintiens que l'usage le plus courant aujourd'hui, c'est quand même d'insérer une image dans le texte, sous forme d'illustration, qui dispose de toute sa largeur, un peu comme un embed de vidéo ou autre.
Pour conclure sur ce point, il ne faut pas oublier que le chantier en question annonçait dès le départ qu'il serait basé sur une reprise de medoc pour la partie usage d'un raccourci unique, mais aussi sur le plugin insertions images avancées qui permet bien d'utiliser les variantes left/right.
Je propose donc de changer la largeur max des doc en left/right à 33% de large afin de garder suffisamment d'espace pour le texte qui "habille" l'image, voir cette capture pour démo :
+1, quand on demande à flotter à gauche ou droite, ça doit forcément être une version "petite", qui a alors un intérêt à être flottant
J'ai fait quelques essais et ça fonctionne bien quand on insère une image avec <doc|left> comme sur la capture d'écran. Par contre, le max-width garde la main si jamais on tente de faire un <doc|left|largeur=300>.
On obtient donc un comportement "sympa" pour les gens qui tentent de jouer simplement avec left/right, mais cela peut être contre-productif ou frustrant pour les personnes qui tenteraient de faire des choses plus fines en spécifiant la largeur de l'image en plus, ce qui me fait hésiter...
je trouve pourtant très bien, ça évite des problèmes de lecture et ça rend possible malgré tout des largeurs précises dans des conditions idéales… quand est-ce que ça devient contre productif ? Même si on donne une largeur précise, on veut pas non plus que ça coince le texte dans une largeur trop faible, donc c’est bien…
