Closed cgabard closed 10 years ago
Histoire de faire mon chieur, je suis pas convaincu de ces meta-issue (plutôt qu'un tag / issue + milestone éventuelle)
Sinon, à propos de bug, j'ai cru en voir quelques un dans le post fait sur ZdS :
*
sont bien affichées, mais pas les _
Dans les balises code, autant les * sont bien affichées, mais pas les _
C'est à dire ?
Regarde les exemples des textes italiques et gras. Dans la balise code d'utilisation avec les _
, ben on les voit pas
edit : nevermind, il semblerait que ce soit une sorte d'erreur css ?
Oui c'est à cause de la hauteur du bloc, un peu trop petite. Si tu descends un peu avec la scrollbar, tu les voies. En tout cas sur Chrome c'est comme ça. J'imagine que ce sera corrigé avec le nouveau design.
En tout cas ce n'est pas un bug du markdown. On ne pourrat pas vérifier ça avant l'integration finale
Sujet complété avec les limites/bugs de la syntaxe des tableaux. Les sauts de ligne intra-cellule ne marchent pas. Et l'échappement du | avec \ devant ne marche pas non plus.
En ce qui concerne les tables multi-lignes, il faudrait, @cgabard si possible que tu intègres cette extension. ça rajouteras la syntaxe suivante :
+---------------+---------------+--------------------+
| Fruit | Price | Advantages |
+===============+===============+====================+
| Bananas | $1.34 | - built-in wrapper |
| | | - bright color |
+---------------+---------------+--------------------+
| Oranges | $2.10 | - cures scurvy |
| | | - tasty |
+---------------+---------------+--------------------+
Qui est aussi celle de pandoc
Pour le |, si l'échappement ne fonctionne pas, je pense voir comment faire pour que ce soit le cas, si tu pense que ça peut être une solution viable. Car dans tous les cas il faut pouvoir différentier les deux
@medegit : La syntaxe actuel ne le permet pas. Je remarque que pandoc propose 2 autres syntaxes qui le permettes : http://johnmacfarlane.net/pandoc/demo/example9/pandocs-markdown.html :
Qu'en pense tu ?
je vais voir ce qui se fait dans les extensions existantes
Bon j'ai pas trouvé mieux que celle proposé par @firm1
Cela me plait comme solution car a priori je n'ai rien a codé et que c'est compatible pandoc.
La grande question est de savoir si on autorise les deux syntaxe ou juste celle grid_tables
Pour moi ça semble ok. Je sais encore pas trop comment le parseur devra se comporter sur les quelques tableaux qui utilisent du colspan et du rowspan, mais bon... Je vais me débrouiller.
Du coup, tu me confirmes : je peux partir sur la syntaxe grid_tables pour la conversion zCode -> md ?
En fait si tu regarde https://github.com/smartboyathome/Markdown-GridTables/blob/master/test_grid_tables.py tu verra que l'extension proposé par @firm1 supporte les colspan et rowspan.
Celle de pandoc non, mais ça ce n'est pas le prob actuel.
Yep je pense qu'on peut partir dessus. Reste a voir si je peux garder les deux d'activés sans que ça pose de probs.
Ok, c'est cool ça ! Sûrement chiant à gérer pour moi à la traduction du zCode (xD), mais bonne nouvelle quand même. Je pars là-dessus.
La grande question est de savoir si on autorise les deux syntaxe ou juste celle grid_tables
Je préfère qu'on autorise les deux syntaxe, parce qu'il y'en a une qui est plus simple a écrire à la main que l'autre.
@medegit privilégie lors de l'import la deuxième syntaxe (gridtable) pour être sur que tout sera toujours dans le pack.
@medegit : a priori je vais essayé de pousser ça rapidement. J'ai pas grand chose à faire vu que c'est déjà codé ! En attendant oui tu va pouvoir partir là dessus.
@firm1 : Oui je vais tenter de garder les deux, normalement ça devrait le faire mais les syntaxes étant proches, on est jamais à l'abris d'une connerie. Je pense que ça va se jouer selon une question d'ordre de parsage.
@ShigeruM : tu peux regarder la syntaxe de grid_tables expliqué plus haut pour les tableaux, en plus de celle précédente, pour mettre a jour ton tuto sur la syntaxe ? a priori les deux syntaxes seront supporté, celle de grid_table etant plus lourde mais permetant une édition plus avancé (colspan, rowspan, et multilignes dans les cellules, entre autre)
Bon, j'ai commencé par bricoler un truc qui semble marcher pour les tableaux sans rowspan/colspan.
Prévenez-moi dès que la syntaxe grid_tables est poussée sur ZdS, pour que je teste vite fait quelques trucs avant de continuer.
Btw, qu'est-ce que je fais des "légendes" des tableaux ? Je les sors et les affiche en tant que texte centré et gras en dessous du tableau ?
Dans une balise
Le 6 janvier 2014 16:40, Coyote notifications@github.com a écrit :
Btw, qu'est-ce que je fais des "légendes" des tableaux ? Je les sors et les affiche en tant que texte centré et gras en dessous du tableau ?
— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/57#issuecomment-31657638 .
Je les sors et les affiche en tant que texte centré et gras en dessous du tableau ?
C'est une solution qui me sied
@SpaceFox : L'extension md que @cgabard utilise ne me semble pas gérer les captions.
Argh. C'est dommage mais tant pis.
2014/1/6 firm1 notifications@github.com
@SpaceFox https://github.com/SpaceFox : L'extension md que @cgabardhttps://github.com/cgabardutilise ne me semble pas gérer les captions.
— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/57#issuecomment-31658112 .
Par contre, s'il est pas trop paresseux, il peut implementer le caption lui même. la syntaxe de pandoc pour celà, revient à faire un truc dans le genre :
: Le titre de mon tableau
+---------------+---------------+--------------------+
| Fruit | Price | Advantages |
+===============+===============+====================+
| Bananas | $1.34 | - built-in wrapper |
| | | - bright color |
+---------------+---------------+--------------------+
| Oranges | $2.10 | - cures scurvy |
| | | - tasty |
+---------------+---------------+--------------------+
@medegit : Je pense envoyer ça à @firm1 demain soir, donc j'imagine que mercredi ce sera en prod
Pour les captions, si ce n'est pas dans l'extension, je peux le mettre sur ma todo liste, dans une deuxième pass.
Mais la même question se pose pour les images : est ce qu'on essait de les détecter comme figure et utiliser les balises html5 correspondantes ? si oui quelle syntaxe ?
Pour les images, tu peux le mettre dans ta todolist avec la syntaxe de pandoc qui donne ceci :
![Légende de mon image](url)
Donc, du coup @medegit tu peux prendre ça en compte autant pour les tables que pour les images avec légendes ?
Ce que tu met comme légende est normalement le texte alt. En gros, si je comprend bien, quand on trouve une image seule dans son pragraphe, on fait un rendue de figure plutot que de img, c'est ça ?
je dirais les deux, alt et figure.
Certes mais l'idée est là : transformer une balise img en figure (avec caption) si elle est seule dans son praragraphe ?!
Cela ne me parrait pas specialement compliqué, au détail pret que je dois trouver un moyen de différencier un smiley d'une image classique. Car il va m'etre plus simple de faire une extension qui passe après la création des balises images (qui est intégré à python-markdown et donc pas facilement modifiable).
Cela ne me parrait pas specialement compliqué
Et donc tu confirmes donc à @medegit ce que tu feras, pour qu'il agisse dans le bon sens ?
Yep, il peut supposer que je fasse ça dans la semaine ou le week end prochain.
Pour les legendes de tableau aussi ça doit etre jouable.
Bon et bien j'ai de quoi m'occuper
NB, concernant les legendes de tableaux : Pandoc autorise ceci
"A caption may optionally be provided (as illustrated in the example above). A caption is a paragraph beginning with the string Table: (or just :), which will be stripped off. It may appear either before or after the table. "
Je vais juste ajouter une contrainte : la legende doit être placé APRES le tableau uniquement. Cela ne me semble pas illogique ni tres contraignant mais ça va simplifier largement l'implementation. Je verrais pour autoriser le "Avant" plus tard. En attendant je pense que c'est plus simple d'imposer ça aux membres et au parseur zcode -> markdown.
et du coup ça devrait marcher pour les deux syntaxes de tableaux
Ok, donc je colle la légende en fin de tableau avec le préfixe "Table:", c'est parfait.
Pour les images, mon parseur zCode -> md rend déjà ce que firm1 montre ici : ![Légende de mon image](url)
, parce qu'en réalité c'est déjà implémenté comme ça dans le zCode : la légende est le contenu du champ alt de l'image. Préviens-moi si tu veux que je sorte la légende du champ alt et que je l'ajoute sous une forme quelconque à la syntaxe d'une image en md.
Non c'est très bien comme ça. Le zcode gérais différemment les images inline des figures ?
Je ne me souvenait pas de ça, je pensais que les auteurs mettaient leur legendes "à la main" en dessous
a noter que tu n'es meme pas obliger de mettre le Table : il sera optionnel. Fait ce qui te semble le plus clair pour les auteurs
Les images avaient un champ "legendevisible="true"
pour choisir d'afficher le alt comme légende ou pas. Par défaut, ça s'affichait, et fallait passer à false pour que ça s'affiche pas. Personne ne s'en est jamais servi, à quelques exception près, et je ne les gère pas pour le moment.
Par défaut, je mets le texte "image" dans le champs alt, tu préfères que je le laisse vide quand y'a rien ?
Le coup de la légende a une jolie histoire sur le SdZ.
Le champ "legendevisible" n'existait pas jusqu'à quelques mois avant la v4. Un jour, SIT a décidé sur un coup de tête que pour être sémantique, il fallait afficher une légende sous les images, et donc a poussé la modif en prod sans aucun test et sans tenir compte de l'avis de quiconque (oui, déjà à l'époque). Résultat : tous les tutos ont vu leur mise en forme explosée, puisqu'aucun n'était prévu pour ce genre de gag. Après moult pressions sur SIT parce que c'était vraiment trop laid, ils ont concédé ce champ "legendevisible" avec le comportement décrit. Champ documenté à peu près nulle part sauf dans une obscure annonce (sur un forum je crois), d'où le fait qu'il n'a pas été utilisé...
Le 6 janvier 2014 17:52, Coyote notifications@github.com a écrit :
Les images avaient un champ "legendevisible="true" pour choisir d'afficher le alt comme légende ou pas. Par défaut, ça s'affichait, et fallait passer à false pour que ça s'affiche pas. Personne ne s'en est jamais servi, à quelques exception près, et je ne les gère pas pour le moment.
Par défaut, je mets le texte "image" dans le champs alt, tu préfères que je le laisse vide quand y'a rien ?
— Reply to this email directly or view it on GitHubhttps://github.com/Taluu/ZesteDeSavoir/issues/57#issuecomment-31664327 .
Oui il vaut mieux que tu le laisse vide du coup.
Bon actuellement c'est le comportement "à la sdz v3" qui est en place : une image est une image.
Je vais faire en sorte de mettre en place le comportement "à la sdz fin-v3" en transformant les images seules dans leurs paragraphes en legende. On verra ce que ça donne !
Notez que du coup si le tuto crée une legende manuellement, markdown ne devrait pas générer de figure mais conserver une image. Ce qui devrait permettre de rester compatible
Dans ce cas, pourquoi ne pas appliquer le comportement des caption des tables ? A savoir un :texte de légende
en dessous d'une balise image ?
Bah le alt peut très bien marché pour ça. De toute façon une figure n'a rien a faire ailleurs que seule et isolée.
Sauf que là tu te dis "OK si y'a un alt, que c'est "isolé" (comment le détecte tu ? Car le "seul dans le paragraphe" peut être très trompeur, je pense par exemple à un tableau), tu peux casser la mise en forme de la plupart des tutos, comme l'a montré @SpaceFox avec l'exemple de S-It.
Ce qu'on ne veut pas reproduire, n'est-ce pas ? Du coup, comme ce serait quelque chose de "nouveau" en soit, alors avoir une manière homogène avec les tableaux (qui peuvent avoir une "légende") me semble le plus optimal
Bah je le détecte en regardant si mon image est seule dans une balise p. Je peux te mettre des cas particulier si tu veux mais bon en soit cela ne me semble pas compliqué.
Pour le cas de SIT, c'est différent puisque on a pas d'existant. Ok il faut faire au mieux pour coyote mais ici, l'un ou l'autre, ne changera pas grand chose.
La question est de savoir ce que nous on veut comme comportement. Moi apres je l'implémente, je m'en fout.
Note qu'avec une legende pour les images :
Pour le cas de SIT, c'est différent puisque on a pas d'existant. Ok il faut faire au mieux pour coyote mais ici, l'un ou l'autre, ne changera pas grand chose.
Non, justement, comme eux, on a un existant : près de 800 tutos, qui eux peuvent avoir une mise en forme assez exotique (je pense par exemple aux tableaux ; pourquoi ne pas vouloir mettre une image avec une légende dans une cellule d'un tableau ? Comment peux-tu la détecter dans ce cas ?)
De plus, se baser sur le texte alternatif, je pense que c'est pas le plus utile. Une image qui ne se charge pas ==> un texte alternatif visible en double ? Et niveau accessibilité ?
Bref, une légende, c'est pas un texte alternatif, loin de là... Même si on a tendance à méler les deux (moi le premier)
Est ce que ça a un sens d'avoir un élément sémantique "Figure" dans un tableau ? Ça m'ettonerais bien. Si il veut mettre une image avec une légende il peut toujours le faire à la fin mais j'ai du mal à comprendre l'interet de le permettre.
Dans tous les cas ce sont des regles pour savoir où c'est autorisé, et j'aurais le même problème avec ta syntaxe : besoin de vérifier.
Ensuite pour l'existant, non le prob n'est pas le meme. L'exemple de SF c'est une modification du comportement du langage courant. Là on parle d'un tout nouveau langage avec l'outil de coyote pour faire la conversion. Ça change tout. On va rien casser du tout, pour coyote ça ne change rien de générer l'un ou l'autre. Donc l'existant n'a aucune importance ici, si il peut générer une forme, il peut générer l'autre.
Pour le reste je m'en fout mais je trouve ça un pue redondant.
Vous en pensez quoi les autres ?
J'en pense que :
En gros, vive la sémantique, vive pandoc ...
Hello, j'aimerais rapporter un peu ma science.
Pourquoi alt et figure existent ? Entre autre pour des raisons d'accessibilité. Si l'on considère un aveugle avec sa liseuse (braille ou synthèse vocale) que se passera-t-il si on met le même texte dans le alt et dans le figcaption ? Réponse : le texte est lu deux fois. Il y a donc redondance.
C'est pourquoi à mon sens, une légende (figcaption) apporte de l'information à l'image, tandis que l'attribut alt est là pour décrire l'image, en quelques mots.
Exemple, je veux mettre une photo de mouton. Dans le alt je vais y indiquer "Un mouton blanc dans un pré". Dans la légende j'y mettrais "Les moutons d'Ouessant vivent à l'origine sur l'Ile d'Ouessant, où il y a pléthore de pré verdoyants. Photo d'Alan Turing lors d'un de ses périples autour du monde."
Sentez-vous la nuance ? Ces deux "choses" n'ont pas le même but.
Par ailleurs, si vous souhaitez afficher en légende la même chose que vous mettriez dans le alt, alors il est conseillé de mettre un alt vide (mais de mettre un alt quand même, sinon c'est un oubli) : <img src="..." alt=""/>
L'inverse est possible : il est possible de mettre une image avec un alt dans une figure, sans figcaption.
Bref, je ne sais pas ce qui est le plus adapté au zCode, mais dans le MD il serait pas mal d'offrir cet éventail de possibilités : alt, figcaption ou les deux.
Mon avis est que si une image est "seule" dans un paragraphe : elle devient une figure avec figcaption et alt vide. Si il existe une balise zCode pour gérer la légende à part du alt, alors on renseigne le alt et le figcaption. Pour les images inline, alt uniquement.
Faites quand même attention à ce que vous faites. Le HTML est relativement pointu et suffisamment riche pour offrir une solution propre.
Merci de votre compréhension, en espérant que ces minutes passées à rédiger ce message vous aident à comprendre que vous faites fausse route à mon avis à ce niveau là.
NB : le figcaption est également valable pour les sons, vidéos et autres contenus riches.
Si on veut séparrer alt et caption, on le peut. La question est de savoir si on le veut. Le zcode on s'en fout : on fera au mieux pour s'adapter. Mais il ne faut pas baser le MD sur les possibilités du zcode.
On peut viser les deux : si une image est seule dans son paragraphe avec simplement un alt, on vire le alt et on le met en caption. Par contre avec la syntaxe dédié on laisse la possibilité aux auteurs de préciser les deux ! C'est peut être le mieux, non ?
Apres je maintient qu'une figure dans l'absolus ça doit etre dans le corps de texte, dans un tableau ça n'a pas de sens !
Les seules alt qui sont bien remplies dans les sources des 800 tutos en zCode, c'est celles des tutos officiels, et sémantiquement parlant c'est toutes des légendes. Concrètement, ça représente pas loin de 6100 images dans 64 tutos différents. Donc au final, c'est quand même pas rien.
Pour tout le reste des tutos, c'est très aléatoire et on (les ex-validos) n'a jamais vraiment fait gaffe à ça, vu que par défaut c'est un truc qui n'était pas affiché (cf. le rappel historique de @SpaceFox).
Au niveau de la conversion zCode -> markdown, je suis pour :
legendevisible="oui"
Du coup, comment dois-je construire ma balise image si je veux lui appliquer un texte en tant que légende et pas en alt ? Comme l'a proposéTalus ? Ou autrement ? Merci de me filer un exemple pour que je sache comment adapter le parseur.
Si légende visible, on doit arriver à ce HTML :
<figure>
<img src="image.jpg" alt="" />
<figcaption>Légende</figcaption>
</figure>
Pour le markdown, du coup je propose une variante de l'image simple :
![:Légende](url)
En rajoutant simplement :
devant la légende.
Enfin, pour le HTML à générer à partir de :
![Légende](url)
Si l'image est seule dans un paragraphe :
<figure>
<img src="image.jpg" alt="Légende" />
</figure>
Si l'image est inline :
<img src="image.jpg" alt="Légende" />
Ce qui me semble être le meilleur compromis.
Le prob de ta syntaxe Alex c'est qu'il n'est pas possible de préciser les deux pour les bons élèves. Car si on ne doit en préciser qu'un, autant utiliser celle classique des images et c'est moi, au niveau de markdown, qui la mettrait en alt ou en caption en fonction du contexte.
Donc soit on continue a supposer que les auteurs ne préciseront jamais les deux différemment et la partie entre crochet est utilisé comme alt en inline et comme caption de figure lorsque isolé, soit on leur laisse la possibilité de mettre les deux en rajoutant une ligne de légende comme proposé par Talus. Ce dernier choix pouvant être varié en "si isolé et pas de légende alors le alt devient caption"
Ca me semble être un bon compromis, en effet. Je répondais par rapport au zCode mais il est vrai qu'on peut faire encore plus propre vu qu'on repart de rien.
J'ouvre cette issue pour répertorier les bugs connus dans le markdown du site.
Une autre issue est ouverte pour discuter et répertorier les features demandées : changement de syntaxe, nouveau comportement, nouvelle extension, etc... : https://github.com/Taluu/ZesteDeSavoir/issues/58
Ici on se concentre sur les bugs.
Actuellement de connus :
La syntaxe de code "à la git hub" ne fonctionne pas dans des blocs persos ou citation : Ce bug a normalement été résolu mais n'est pas encore poussé en prod.Les smiley s'insères n'importe comment dans les codes ou messagesLa syntaxe actuelle des tableaux ne permet pas les sauts de ligne au sein d'une cellule, ni l'utilisation du caractère |.N’hésitez pas si vous en voyez d'autres.