Mises à jour de yAronet - Page 30

Oui mais une fois la page générée (côté client) ça devient du html, non ? Si c'est pas ça, laissez tomber

Un petit détail dont je me suis rendu compte en lisant ce sujet (j'ai abandonné à la neuvième page, honte à moi), c'est le texte dans la bulle pour faire des citations de sélections à la souris avec la skin sombre. Le fond de la bulle (classe info) est jaune pâle (#FFFFCF), et avec la skin sombre, le texte pour les liens est blanc gras. Mais du coup, le contraste n'est vraiment pas terrible… Est-ce que, plutôt que de changer encore une fois la couleur des liens, on change la couleur de fond ?

Autre détail : sur les pages qui listent les membres, la cellule de la dernière ligne (tr.forumFoot td) ne fait pas le bon nombre de colonnes (colspan="3" au lieu de 4) (j'ai trouvé ça en cherchant quel était le numéro de ma skin, je redécouvre yAronet )

RHJPP (./868) :
Tu pourrais définir des balises qui changeraient le langage utilisé. Par exemple, si je suis en HTML et que je cite quelqu'un qui a utilisé yML, la citation pourrait être encadrée de <format type="yML"></format>. Ou sinon, tu pourrais inclure dans le HTML généré des informations non affichées (dans des commentaires ou autre) qui indiquent la fonction (par un numéro, un nom ou ce que tu veux) et les paramètres. Il suffirait d'établir une table de correspondance de la fonction dans le langage de l'utilisateur.

Je n'ai pas compris ce que tu voulais faire ?

deeph (./869) :
./866 heu... Je sais pas trop comment c'est codé derrière, mais pourquoi vouloir retrouver le texte original ? Suffirait pas simplement de récupérer le texte généré (sans les balises html ou autre) ?

Le texte original avec les balises HTML, ça va faire apparaître <b>ce genre<u>de choses dans un <a href="#" onclick="getPost(event, machin, truc)">post</a>, c'est pas franchement génial. D'où ma proposition de supprimer tout simplement les balises HTML pour récupérer le texte brut.

deeph (./871) :
Oui mais une fois la page générée (côté client) ça devient du html, non ? Si c'est pas ça, laissez tomber

Oui, mais il faudrait inverser l'opération pour récupérer du yML à partir de ce code HTML, pour que ça redonne à nouveau le même code HTML une fois posté une seconde fois. Et le problème devient plus compliqué quand il faut pouvoir inverser non seulement de l'HTML vers du yML, mais également vers toutes les autres syntaxes.

./872 : c'est noté, mais pour la page des membres je pense qu'elle ne va pas rester en l'état, du coup je ne sais pas encore si ça vaut le coup de la modifier ou si ça attendra qu'elle soit réécrite.

Si j'ai bien compris RHJPP propose de faire une copie du code d'écriture du post, et de le mettre dans la citation avec des balises qui indiquent quelle est la syntaxe.

Exemple : je suis en yML et je poste un smiley . Dans le alt de la balise on sauvegarde le code qui a crée la balise et la syntaxe.

Donc on mets : <img alt="yML|:p" src="/s/sprite/smile/tongue.gif"> dans le HTML.

Lors d'une quote on reprend les infos du alt et on insère le code d'origine encapsulé dans une balise qui indique le format du code. Genre : <format=yML>:p</format>, et le parseur sait quelle syntaxe prendre pour s'occuper du smiley.

Pareil pour une url : [url=google.com]Recherche[/url] deviens <a alt="yML|[url=google.com]Recherche[/url]" href="http://google.com" target="_blank">Recherche</a> et deviens <format=yML>[url=google.com]Recherche[/url]</format> lors d'une quote.

Valà, alors faudrait sans doute échapper des trucs dans les alt pour pas casser l'HTML de mémoire, et ça oblige à changer le parseur pour remplir les alt mais voilà l'idée je crois.

Ensuite je crois que c'est surtout pour les smiley qu'il faut trouver une solution (lee reste des balises, c'est pas la mort si elles sautent) alors ce que je décris plus haut est peut être un peu trop compliqué ...

pokito, c'est bien à peu près ça, mais j'imaginais plutôt que la balise format engloberait toute la citation, ça éviterait d'avoir des répétitions à chaque smiley ou changement de style.

L'autre idée est d'associer non pas le texte qui a généré l'HTML, mais les informations de haut niveau. Puisque le post a été analysé pour sa conversion, toutes ces informations sont disponibles lors de la génération du HTML.

]ça[/url] [4]va[/4] ?Par exemple, je tape [b]Salut[/b], [u]comment[/u] [url=http://www.yaronet.com
<span class="color4">va</span> ?Le message va être transformé en <b>Salut</b>, <span class="u">comment</span> <a href="http://www.yaronet.com" target="_blank">ça</a>
et="_blank">ça</a> <span id="a42_4" class="color4">va</span> ?Mais on pourrait y inclure des informations supplémentaires : <b id="a42_1">Salut</b>, <span id="a42_2" class="u">comment</span> <a id="a42_3" href="http://www.yaronet.com" targ
Ici, a42 est un identifiant unique du message. Il faut mettre dans un tableau JavaScript ce à quoi correspond chaque balise :

var info_balises = {
        "a42_1": {"fonc": "b"},
        "a42_2": {"fonc": "u"},
        "a42_3": {"fonc": "url", "url": "http://www.yaronet.com"},
        "a42_4": {"fonc": "color", "num": "4"}
};

Lors d'une citation, il faut regarder l'id des balises citées et appliquer la bonne fonction de balisage avec tous les paramètres renseignés dans le tableau, plus le contenu de la balise lorsqu'il y en a un. La fonction utilise bien sûr le langage de l'utilisateur.

C'est une idée jetée comme ça, il y a plein de problèmes auxquels il faudra faire attention et on peut faire des extensions, comme chercher si des balises ont été ouvertes avant la citation (par exemple un extrait d'un texte mis en gras garderait son style). La méthode de stockage que j'ai montrée n'est pas forcément optimale, mais l'idée et là et d'autres solutions existent.

Ça fonctionnerait, mais c'est un boulot monstrueux juste pour la citation JS, en gros il faut que je recode intégralement un truc qui reproduise un post au format interne à partir de l'HTML, pour ensuite pouvoir passer du format interne au yML/autre. Il n'y a que la deuxième partie qui existe actuellement et je n'ai vraiment aucune envie de coder la première, surtout que ça ajoute beaucoup de lourdeur pour cette seule fonctionnalité.

La seule chose qui me semble envisageable c'est ce que suggérait deeph, à savoir remplacer les balises <img> par le contenu de leur "alt", en supposant que les smileys vont s'écrire toujours de la même façon quelle que soit la syntaxe choisie (et encore, ça ne sera vrai que pour les smileys de base, pas les #machin#). C'est une contrainte mais elle reste acceptable, pour le reste c'est bien trop lourd et contraignant pour que je me lance là-dedans, désolé.

Zeph (./876) :
en gros il faut que je recode intégralement un truc qui reproduise un post au format interne à partir de l'HTML

Pas seulement à partir de l'HTML, il y a aussi toutes les informations que le convertisseur qui a donné le HTML a pu y placer. Le tableau JavaScript dont j'ai parlé a, par exemple, été généré lors de la création du HTML. En fait, en quelque sorte, le format interne est inclus dans le HTML pour être récupéré facilement.

Le convertisseur du HTML vers le format interne ne ferait que lire les id des balises et appliquer la fonction associée dans le tableau (ce n'est pas lors de cette conversion que le tableau est créé, il est fourni avec le post en HTML, je ne sais pas si j'ai été clair).

Mais je suis d'accord que ça représente quand même un travail important.

Zeph (./873) :
D'où ma proposition de supprimer tout simplement les balises HTML pour récupérer le texte brut.

Tu fais ça avec un truc du style replace(/(<([^>]+)>)/ig,""); ? Parce que si c'est le cas, y'a sûrement moyen de récupérer le texte alternatif de la balise img.

Mais je ne comprend pas trop pourquoi ça demande tant de travail, pour les autres balises (liens etc...) je ne sais pas, mais là tout ce que ça demande c'est de récupérer le alt des images des smileys, non ?

Perso j'aurai simplement utilisé getSelection() avant de coller la citation dans le textarea (je vois mal où ça pourrait poser problème, même d'un point de vue sécurité).

RHJPP (./877) :
Pas seulement à partir de l'HTML, il y a aussi toutes les informations que le convertisseur qui a donné le HTML a pu y placer. Le tableau JavaScript dont j'ai parlé a, par exemple, été généré lors de la création du HTML. En fait, en quelque sorte, le format interne est inclus dans le HTML pour être récupéré facilement.

Oui j'avais compris, mais ce tableau n'est pas utile, il est déjà contenu dans la version interne des posts (ils ne sont pas sauvegardés en yML). Par contre ça oblige quand même à modifier l'HTML et coder un nouveau parseur, ce que j'aimerais éviter (ou plus exactement ce que je ne ferai jamais, si ça vous tente libre à vous de vous y coller). Et puis d'un point de vue théorique, même s'il n'y aura probablement jamais d'autres rendus que l'HTML le système actuel ne cible pas spécifiquement de l'HTML, il est tout à fait possible de rendre les posts dans un autre format, donc il faudrait refaire autant de fois le code de ce nouveau parseur.

deeph (./878) :
Mais je ne comprend pas trop pourquoi ça demande tant de travail, pour les autres balises (liens etc...) je ne sais pas, mais là tout ce que ça demande c'est de récupérer le alt des images des smileys, non ?

Perso j'aurai simplement utilisé getSelection() avant de coller la citation dans le textarea (je vois mal où ça pourrait poser problème, même d'un point de vue sécurité).

Oui, pour les smileys et uniquement pour les smileys ça ne demande pas grand chose, si ce n'est accepter le fait qu'un smiley doit s'écrire toujours exactement de la même façon pour toutes les syntaxes proposées par yAronet (yML et autres). J'aurais bien aimé ne pas m'imposer cette contrainte, mais elle reste raisonnable donc c'est envisageable. Pour les autres balises en revanche c'est beaucoup plus compliqué, cf. discussion qu'on vient d'avoir.

Parce qu'actuellement les smileys ne s'écrivent pas tous de la même façons qu'importe la syntaxe ? D'un forum à l'autre, peut être (j'en sais rien), mais dans un même sujet, on a au moins tous accès aux mêmes, non ?

Mais bon, j'ai toujours pas trop compris ce qui défini la syntaxe d'un post (la version ?)...

Je sais pas pour vous, mais chez moi l'apparition du Popup "Sauver/Vider" est aléatoire. Parfois immédiatement, d'autres fois quand je déselectionne le texte précédemment sélectionné (supayr blague de debianiste), parfois pas du tout. Je ne sais pas du tout comment faire pour préciser le problème.

Fx 18.0.2 sous Win 7. Je verrai avec Linux.

Idem avec Fx 18.0.2 / Arch Linux (à tel point qu'hier j'ai cru que ça ne fonctionnait plus du tout)

idem avec mint14+FF17, IE9+win7 et IE8 et winxp

vince (./883) :
idem avec mint14+FF17

(hey, apt-get update && apt-get upgrade )

deeph (./880) :
Parce qu'actuellement les smileys ne s'écrivent pas tous de la même façons qu'importe la syntaxe ? D'un forum à l'autre, peut être (j'en sais rien), mais dans un même sujet, on a au moins tous accès aux mêmes, non ?
Mais bon, j'ai toujours pas trop compris ce qui défini la syntaxe d'un post (la version ?)...

Actuellement il n'y a qu'une seule syntaxe, le yML, donc le problème ne se pose pas encore. Mais j'aimerais poser le moins de contraintes possibles (idéalement aucune) sur les éventuelles prochaines syntaxes, et donc éviter d'imposer que les smileys s'écrivent de la même façon dans toutes les syntaxes.

./881 ~ ./884 : la sélection JS ne s'active que si 6 caractères ou plus sont sélectionnés (ne me demandez par pourquoi, je n'en ai aucune idée, mais c'est intentionnel). Êtes-vous sûrs que ça n'est pas cet effet que vous constatez ?

Négatif pour moi, ça peut me faire ça sur une phrase, plusieurs lignes, ...
Avant, ça pouvait arriver mais c'était quand même rare. Maintenant, c'est fréquent au point de se demander si ça marche, cf Nil.

J'ajoute que le comportement a un côté aléatoire :
Je sélectionne ça :

Folco (./886) :
ut me faire ça sur une

Je fais sauver. La popup se met à jour ("1 citation ajoutée") et reste apparente. Je sélectionne un autre texte. La popup est toujours là, identique. Je reclique sur Sauver. Et là, deux possibilités aléatoires quand je fais "insérer citations sauvées" :
Ou j'ai deux fois la citation initiale :

Folco (./886) :
ut me faire ça sur une

Folco (./886) :
ut me faire ça sur une

Ou alors j'ai bien les deux citations différentes :

Folco (./886) :
ut me faire ça sur une

Folco (./886) :
était quand même rare. Ma

Encore une fois, je ne sais pas comment détailler ça plus.

Un indice cependant : quand le popup se décide à apparaitre sur une page, elle apparait systématiquement, comme si ça marchait très bien. Mais très régulièrement, il faut faire plusieurs sélections avant de l'obtenir une première fois.

OK, je regarderai...

Folco (./886) :
Négatif pour moi, ça peut me faire ça sur une phrase, plusieurs lignes, ...
Avant, ça pouvait arriver mais c'était quand même rare. Maintenant, c'est fréquent au point de se demander si ça marche, cf Nil.

à l'inverse un "bug" a l'air d'avoir été corrigé sous ie7, le positionnement de la fenêtre de popup qui ne prenait pas en compte le scroll de la page n'a plus l'air de se poser...

[nosmile]

Zeph (./885) :
et donc éviter d'imposer que les smileys s'écrivent de la même façon dans toutes les syntaxes.

Oui mais y'aura-t-il une grande différence ? Parce que si c'est juste une différence de style #smiley# = :smiley:, la conversion peut se faire rapidement, non ? Même peut être avec une table de correspondances si les différences sont un peu plus compliquées ?

Autrement le système de citation marche parfaitement ici (ff 18.0.2 et win xp).

edit : tiens la balise [nosmile] ne marche plus ?

Il suffit d'échapper le premier dièse : #black#

(c'est vraiment important de parser des syntaxes différentes ? #humfus#)

(pour les balises, ça se discute, maintenant pour un ;) je vois mal ¤leSmileyJauneQuiFaitUnClinDOeil¤)

./891 : ce qui est important c'est de savoir s'il y a une différence ou pas ; grande ou petite, ça oblige à coder des fonctions de conversions dans tous les sens et c'est exactement ce que je veux éviter :/
./893 : ça faisait partie des features demandées ; c'est vraiment important de conserver les smileys dans les citations JS ?
./894 : justement, je disais qu'à la limite il serait possible d'admettre que les smileys "simples" (ceux qui s'écrivent avec de la ponctuation) pourraient être identiques quelle que soit la syntaxe, c'est une contrainte mais elle n'est pas trop importante

Il y a quoi d'autre comme syntaxe d'ailleurs ?

le Wikimedia?
le Markdown?

Ca a vraiment du sens sur un forum?!

Le markdown oui, ça me parait avoir sacrément plus de sens sur un forum que du simili-bbcode en tout cas

Heuuuu O_o tu rigole j'espère ?

Pour des articles à la limite, mais pour un forum le markdown est vraiment pas pratique du tout (en plus il y a des contraintes plutôt bien chiantes sur l'indentations, l'insertion d'image, de liens etc..) et en plus ce n'est pas standardisé :/

Le markdown a été fait pour tenter de "standardiser" les fichiers types NFO et pouvoir les rendre sous une forme HTML un peu plus "moderne" que le texte brute tout en restant lisible en texte brute (enfin presque l'inclusion d'image par exemple est d'une horreur sans nom...)

Franchement, tu aurais parlé de la syntaxe type wiki/wikimedia j'y aurais un peu plus cru, le markdown, ça ressemble plus a une blague qu'autre chose...

C'est pas bien grave, tu auras encore le yML -standard reconnu- à disposition et tu pourras continuer à taper 7 caractères juste pour mettre un mot en gras. Ça va devenir fatiguant s'il faut que je me justifie même pour les features totalement rétrocompatibles, ça vous dirait de vous mettre deux minutes en tête que c'est *mon* temps qui est utilisé pour tout ça ?

C'est ce que j'allais ajouter, que tu allais dire qu'on est pas obligé de l'utiliser, mais perso qui a simplifier la syntaxe je prefere une a la wiki/wikimedia que le markdown qui a trop de contraintes et pour le coup n'est pas du tout un language a balise. (c'est d'ailleurs pour ça que le HTML n'est pas fait comme le markdown)

D'ailleurs pourquoi ne pas pouvoir mettre du LaTeX ? Du Textile ? De l'AsciiDoc?