Enrichissement du Markdown ?

Parce-que là, c'est pas pratique wesh!

a marqué ce sujet comme résolu.

Salut :)

Ayant un peu de temps je me suis repenché aujourd'hui sur un gros article que nous avons en projet depuis un bout de temps avec d'autres newsers (depuis la v3). Il a été transféré sur ZdS et je me rend compte aujourd'hui que certaines options de mise en page, disponibles à l'époque, sont vraiment manquantes ici.

Pour vous donner une idée notre article est en a peu près à 60% et fait déjà 8000 mots, c'est donc un sacré morceau, parfois avec de longs paragraphes théoriques. Nous essayons donc de le rendre le plus esthétique possible pour fatiguer au minimum le futur lecteur.

Voilà où le bât blesse, n'étant pas moi même habitué au markdown j'ai consulté le tuto de ShigeruM et j'ai été déçu du peu de fonctionnalité. En voici une liste non exhaustive des chose qui me manque T_T :

  • Le texte justifié
  • Les flottants sur les images
  • Les légendes sur les images dans les paragraphes
  • Les tableaux borderless
  • La définition de la largeur d'une grande image en px
  • Les titres de niveau 5
  • … je compléterais ici au fur et a mesure qu'une feature me manque :)

Alors je sais que certaines implémentation comme les flottants ont déjà été discutées, mais je n'ai pas trouvé si oui ou non vous pensez les intégrer un jour. Personnellement je pense que pour un site tel que ZdS, proposer des outils d'édition puissants ET complets (et j’espère bientôt un WYSIWYG pas trop lourd ? Le MDwn c'est quand même une régression si la politique est de s’ouvrir à plus qu'un public geek… regardez wikipédia ;) ) est plus qu'une nécessité !

Sinon, des bisous, vous êtes super et ce site est super même si je râle ^^" !

+0 -0

Alors la majorité on été discuté, je te met les arguments avancés à l'époque :

Le texte justifié

Si je me souvient bien, c'est une mauvais pratique pour le web/lecture sur écran. Dans tous les cas ce n'est normalement pas au texte de s'occuper de la mise en forme (ex: le centrage existe surtout pour pouvoir faire des poeme, l'alginement à droite ne devrait même pas être là)

Les flottants sur les images

En gros :

  • Très souvent mal utilisé
  • Ce n'est pas aux auteurs de s'occuper de la mise en page (toujours)

Les légendes sur les images dans les paragraphes

C'est à dire ? Il est possible de mettre des legendes pour les images mais je ne vois pas l'interet de mettre une légende pour une image qui est intégré à un paragraphes (images qui devraient rester petites puisques coupent la lecture et la mise en page).

Les tableaux borderless

Ça n'a jamais été abordé avant.

La définition de la largeur d'une grande image en px

Ça n'a jamais vraiment été abordé non plus.

Les titres de niveau 5

En fait c'est dût au fait qu'on a besoin de réserver les H1 et H2 pour afficher les titres et titres de chapitres dans les tutos et d'avoir le même rendus partout.

Voila quand à mes souvenir.

Pour le reste, maintenant, mon avis perso est que beaucoup de ces trucs ne me semblent pas beaucoup aider à la lecture (sauf peut être les images en flottantes qui pourraient être sympa). Mais pour moi, cela ne devrait pas être le job de la personne qui rédige. Toujours pour moi, l'auteur ne devrait s'attacher qu'à la sémantique de son contenu et c'est au site de faire une mise en page agréable. Cela simplifie les chose pour l'auteur, cela assure une cohérence sur tout le site et cela facilite les conversions de formats.

Par exemple le fait qu'on autorise a mettre des légendes sur figures, tableaux & co va dans ce sens : on s'assure qu'elles soient toutes rendues pareil et pas à la volonté de l'auteur.

Après comme tout, ça reste ouvert. Par contre actuellement il n'y a aucune de ces propositions qui sont prévu à court terme (si c'etait ça ta question)

+0 -0

Les tableaux borderless

Exemple d'utilisation ? Si c'est pour de la mise en page, c'est non.

Les titres de niveau 5

Si tu as besoin d'aller jusque là, globalement c'est que ce que tu rédige est mal construit. Déjà les titres de niveau 4 je trouve ça déjà abusé (car il faut rajouter deux niveaux pour avoir partie / sous-partie, en réalité avec un niveau 4 tu es à un niveau 6 et avec un 5 ème niveau on arriverait à un 7 ème niveau réel, impossible en HTML).

La définition de la largeur d'une grande image en px

Suffit de l'envoyer à la bonne dimension. Autoriser une telle chose encouragerait les auteurs à envoyer des poster pour faire une icône, pour moi c'est non.

TL;DR : En somme, en résumé résumons-nous : la personne qui rédige fait de la mise en forme, tandis que le site gère la mise en page.

Ah, il fallait pas attaquer Alex-D sur le design et la mise en page ;)

La définition de la largeur d'une grande image en px

Plus sérieusement, je suis d'accord avec Alex-D. On ne peux plus aujourd'hui rédiger un document en gérant la mise en page. Le choix de la taille en pixels est le meilleur exemple : on ne sais pas sur quel écran on va être affiché, et il n'y a aucun sens à afficher les images de la même taille sur un écran 640*480 de téléphone et un écran 1920*1200 de pc. Il faut faire confiance au CSS pour le rendu final, et ne pas chercher un truc précis au millimètre, parce qu'il ne peut pas être précis au millimètre sur tous les moyens d'accès au site.

+3 -0

Suffit de l'envoyer à la bonne dimension. Autoriser une telle chose encouragerait les auteurs à envoyer des poster pour faire une icône, pour moi c'est non.

En fait c'est même plus intelligent que ça : tu l'envoie en définition correcte, et le front va calculer les images redimensionnées en fonction du front du moment. Et comme ça, si jamais un jour on fait des modifications du front, il nous suffira de reprendre l'image d'origine (conservée) et de lui demander un autre redimensionnement !

Pour le reste il y a peut être une chose a noté, il manque peut être d'éléments pour spécifier une sémantiques complète. On pourrait par exemple imaginer quelque chose pour les images-figures (qui fonctionneraient comme actuellement quand il s'agit d'images isolés) et des images-illustrations (qui elles pourraient venir se placer en flottant sur un des cotés). Cette nuance peut exister et ne me choquerais pas. En tout cas ça me choque moins que les images "inlines" qui n'ont pas beaucoup de sens selon moi.

Alors la majorité on été discuté, je te met les arguments avancés à l'époque :

Le texte justifié

Si je me souvient bien, c'est une mauvais pratique pour le web/lecture sur écran. Dans tous les cas ce n'est normalement pas au texte de s'occuper de la mise en forme (ex: le centrage existe surtout pour pouvoir faire des poeme, l'alginement à droite ne devrait même pas être là)

Kje

Euh. D'accord…

Cela étant dit, c'est complètement idiot de ne pas laisser la possibilité aux gens de mettre leur texte en forme comme ils l'entendent. Just sayin.

Je n'ai fait que rapporté ce qui avait été dit quand discuté a l'époque. Pour autant c'est un bon exemple : si tu permet de justifier, tu va avoir la moitié des textes du site de justifié et l'autre moitié non. Ça va être totalement incohérent et moche. Donc si vous pensez qu'il est mieux de lire du texte justifié, proposez plutôt de tous les justifier de base.

Perso je suis un grand partisans de la séparation fond/forme. Et pour plus de cohérence, c'est au site et non a l'auteur de s'occuper de cette dernière. Tout comme c'est l'éditeur qui s'en occupe si tu redige un livre.

Pour moi c'est d'autant plus important qu'on parle, avec les tutos et les articles, de textes destinés à être relus longtemps après leur écriture ; c'est-à-dire très probablement quand la mise en page du site aura changé par rapport au moment de la rédaction.

Si l'auteur se contente d'indiquer une sémantique, les designers de la prochaine version du site peuvent obtenir un rendu lisible et harmonieux avec tous les tutos et articles.

Si l'auteur est responsable de la mise en page, il faudrait repasser sur tous les tutos et articles pour les mettre à jour.

En réalité le problème se pose dès aujourd'hui, de part la multitude de formats de lecture disponibles pour ces contenus longs :

  • Écran de PC (plusieurs résolutions possibles)
  • Écran de mobile (portrait et paysage, plusieurs résolutions possibles)
  • ePub
  • PDF

Fort belle préoccupation que la lisibilité (je ne suis cependant pas convaincu de la pertinence de vos arguments, mais passons).

Je me permets d'attirer votre attention sur le fait qu'à côté de ça, vous laissez vos membres joyeusement concevoir des smileys qui décuplent votre interligne.

+1 -1

Ces smiley sont des images et ajoutés comme toute autres ressources externe. Si ils son présent, c'est sur le forum et pas dans les tutos. Et le coup des images, c'est ce que je dis plus haut : je doute de l'intérêt de conserver la possibilité de rajouter des images inline. Pour moi elles devraient être interdites.

PS : si tu n'es pas d'accord avec certains arguments, débat. Le forum est là pour ça et si des choix ont été fait au début ils peuvent être remis en cause.

Ce n'est pas ce que semblent dire tes collègues. On a fait miroiter l'intégration officielle des smileys Clem au même titre que ceux du SdZ sont intégrés.

Tu as toi-même mentionné l'option utilisateur qui permettrait de switcher aux smileys de 33 px de haut.

Quant aux cours, un rapide tour dans ceux-ci m'a montré qu'ils ne sont pas exempts de ces petites frimousses.

P.S. – Je ne suis pas un spécialiste d'ergonomie, mais ce n'est pas parce que vous dites que c'est mieux que je vais vous croire sur parole, surtout lorsque je pense le contraire (non pas que le justifié est plus adapté que le drapeau (car ça, ça dépend des cas), mais qu'il est pertinent de laisser l'auteur mettre en forme quand il veut mettre en forme. Oh oui j'ai des arguments pour étayer ça (Apollinaire, quelqu'un ?), mais vu la levée de boucliers de la part du staff, j'ai pas spécialement envie de perdre mon temps).

+2 -4

Le problème de la justification sur le site web, c'est qu'il est pratiquement impossible d'obtenir une justification propre sur un site web ; en particulier à cause de la gestion catastrophique des coupures de mots – ou plus exactement à cause de sa non gestion.

Les problèmes de laisser la main à l'auteur pour la mise en page ont déjà été donnés (gestion de formats différents, évolutions du site, connaissances de l'auteur en ce domaine). Si tu as des contre-arguments, ils sont les bienvenus et nous sommes prêts à les écouter. Ça s'est déjà fait. On a déjà eu des débats sur ces sujets, et on a même déjà modifié des implémentations suite à ces débats (les sauts de ligne et de paragraphes par exemple).

Par contre ça nécessite des arguments et non des affirmations péremptoires du style "c'est complètement idiot" ou "vous n'écouterez pas mes arguments alors je vais me contenter de râler sans les donner".

Et pour l'instant je n'ai vu que très peu d'arguments dans ce sujet : il a commencé avec une demande, et a continué avec principalement des avis personnels.

Bon je pense qu'on s'ai mal compris. Concernant les smileys, perso, 'ai répondu pour la technique : si plusieurs pack de smileys doivent être proposé, je pense que le choix doit être spécifique a l'utilisateur.

Je suis d'accord avec toi que ces smileys trop hauts sont bof pour la lecture. Mais a la limite on peut considérer que si Le lecteur veut se bousiller l'affichage, c'est son prob. Techniquement ça peut permettre aussi de proposer une option "navigation sans smileys" (suffit de faire un pack vide). Dans tous les cas, et comme tout, c'est pas encore implémenté donc encore sujet a des changements.

Quand au reste, j'ai juste cité ce qui avait dit a l'époque. Perso je n'ai pas d'avis pour savoir si du justifié c'est mieux ou non. Mais je reste convaincu que ce n'est pas a l'auteur de s'en occuper. La preuve est qu'actuellement le texte est déjà justifié il me semble au moins sur la sortie pdf. Je pense que tout ce qui concerne la mise en forme / page devrait être géré par le site et non l'auteur pour adapter celle ci au support.

Staff ou pas, tout peu changer. Preuve en est l'histoire des +/-1 : certains membres voulaient la supprimer, d'autre les garder. Au final ce sont les membres qui ont votés.

Si tu ne veux pas en parler, comme tu veux mais alors faut pas reprocher aux outils de pas correspondre a ce que tu veux.

Perso je pense qu'il faudrait étendre les balises sémantiques pour permettre a l'auteur et au site de faire des choses plus propre. Mais ce n'est que mon avis.

Pour l'instant on fera avec ce que l'on a donc, ce serait quand même bien de poser un vrai débat sur l'intégration des flottants (car ils sont facilement identifiable et repositionnable en front pour votre design responsive…) qui seraient d'un grande aide pour l'esthétisme des articles tout du moins et très certainement des tutos…

Quant au images, et au fait que vous ne voulez pas que l'on utilise de wallpaper pour faire des icônes, moi j'aimerais surtout un moyen simple d'intégrer une image en miniature cliquable pour l'agrandir sans devoir réaliser deux images et mettre la seconde en lien sur la première ^^"

+2 -0

Quant au images, et au fait que vous ne voulez pas que l'on utilise de wallpaper pour faire des icônes, moi j'aimerais surtout un moyen simple d'intégrer une image en miniature cliquable pour l'agrandir sans devoir réaliser deux images et mettre la seconde en lien sur la première ^^"

Sur ce point, y'a 3 choses :

  1. Notre moteur de galeries gère aujourd'hui le redimensionnement en tailles multiples. Donc on peut très bien imaginer de fournir la miniature et l'image pleine taille à partir de l'image pleine taille, sans que l'auteur ne touche quoi que ce soit.
  2. Aujourd'hui c'est chiant d'importer une image dans la galerie depuis un formulaire de rédaction (il faut ouvrir un autre onglet, aller dans la galerie, etc.). De mémoire il y a déjà une réflexion en cours pour améliorer ça.
  3. Aujourd'hui la galerie ne propose pas de raccourci direct du type "miniature avec le lien vers l'image complète", il faut se le taper à la main. Je pense qu'on peut créer directement le ticket pour avoir cette possibilité.

Tu veux des arguments ? Soit.

Je ne trouve pas de raison d'interdire à un auteur qui le désire de mettre en forme son texte (centrer, justifier, mettre à droite). Un comportement par défaut respectant les principes que vous trouverez importants est évidemment une très bonne chose, mais pourquoi limiter ? Pourquoi vouloir penser à notre place ? Ça me semble fort radical. D'autant plus que quand je lis dans cette même discussion « après tout, si les membres veulent se tuer la mise en page en mettant des smileys gigantesques, c'est leur problème », c'est faire deux poids deux mesures.

J'ai mentionné Apollinaire, mais peut-être n'était-ce pas assez évident. C'était essentiellement pour répondre à l'affirmation hâtive prétendant qu'un éditeur s'occupait de la mise en forme, pas l'auteur : ce n'est pas toujours le cas. Certes, le cas est extrême, mais il illustre bien mon propos. Pourquoi diable restreindre ?

Vous préférez ne pas laisser l'auteur mettre son texte en forme n'importe comment ? Je suppose que vous ne le laissez pas non plus écrire n'importe quoi. S'il décide de gérer sa mise en page lui-même (je rappelle que, le comportement par défaut étant l'actuel, il faut qu'il prenne l'initiative de mettre les choses en forme) et que celle-ci est aberrante, votre processus de contrôle de qualité aura tôt fait de le remettre dans le droit chemin.

Il est vrai que le Markdown ne propose pas de balises de justification, mais ce sujet parle d'étendre le langage. Je pense que nous serons tous d'accord pour dire que le md « de base » n'est pas adapté pour rédiger des textes longs et riches.

Petite suggestion pour les images : mettre dans l'interface d'insertion d'images un formulaire qui uploaderait une image choisie dans une galerie « Vrac » et l'insérerait automatiquement dans la zone de rédaction.

Edit pour Alex-D en dessous : merci de lire attentivement mes messages au lieu de déformer mes propos.

+2 -0

Donc on peut très bien imaginer de fournir la miniature et l'image pleine taille à partir de l'image pleine taille

C'est déjà le cas actuellement. A chaque upload, une miniature est crée.

J'ai mentionné Apollinaire, mais peut-être n'était-ce pas assez évident.

Utilise LaTeX pour faire ça, il y a MathJax sur le site, ça devrait faire l'affaire :)

Hors humour : on est sur un site on le but est de proposer du contenu rédactionnel, clairement pas des poèmes ou des calligrammes. L'idée de justifier du texte est mauvaise pour la simple raison que notre design est responsive et que justifier = modifier l'espacement entre les mots pour adapter à la largeur. Quand on modifie l'espacement entre les mots d'une ligne à l'autre, on casse le rythme de lecture et l'habitude prise. Sur des contenus cours et peu larges, tels que dans les journaux, ça peut se faire. Là on parle de contenus qui valent plusieurs pages A4 réelles, c'est autre chose. CSS4 saura gérer les césures, mais CSS3 ne le sait pas encore, donc on doit faire sans et se contenter d'aligner à gauche et de garder un espacement régulier.


Pour les images, tout le monde semble d'accord, il me semble qu'on en parle dans la ZEP sur l'assistant d'édition Markdown.

En ce qui concerne ta mauvaise foi au sujet des smileys, tu noteras la nuance claire et précise dans le message de firm1 :

[…] si ça convient ça sera adopté […]

Ce qui signifie que si ça fait péter les interlignes, ça ne conviendra pas, a priori. Ca a déjà été mentionné sur le sujet et la taille des feuilles a été réduite au fil du sujet.

Enfin, si l'utilisateur veut une mise en forme / page moche, c'est son choix : il peut même se faire ses propres styles sur Stylish et utiliser des UserScripts pour rajouter des boutons ou autre ; mais nous voulons une interface par défaut la meilleure possible. Donc par défaut, on fait quelque chose de propre, soigné, optimisé, ergonomique et si l'utilisateur veut péter son UX, on a rien pour l'en empêcher. Typiquement, proposer de pouvoir changer de pack selon les utilisateurs, c'est éviter de se retrouver avec des images en dur partout qui feraient du site un carnaval de smileys qui changent de couleur à chaque message et qui deviendraient ingérables à notre niveau, ce qui est plutôt gênant. Or en proposant de changer de pack, on permet de garder une homogénéité sur l'ensemble du site.

je doute de l'intérêt de conserver la possibilité de rajouter des images inline. Pour moi elles devraient être interdites.

Kje

Je ne suis pas aussi catégorique que toi sur ce sujet.

Dans pas mal de cours, il y a des images inline utilisées pour décrire/montrer des éléments d'interface graphique de logiciels par exemple, qui rendent très bien et ce peu importe le support de lecture.

C'est peut-être un moyen d'éviter les faux smileys en pagaille sur les forums, mais dans les cours ça me paraît pas déconnant de les laisser activées.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte