test avec la balise PRE - Page 1

test :

ce mot est important : [b]toto[/b]

on peut pas mettre de gras ou autre mise en forme basique dans un pre ????

Non mais bizzarement les smileys passent :/

chiant ca, si on veut mettre en valeur un truc dans un code par exemple

En effet

hé oui

#include <stdlib.h>
#include <string.h>
#include <malloc.h>
#include <limits.h>
#include <signal.h> #attention# Ce truc sert a rien
#include <unistd.h>
#include <sys/uio.h>
#include <sys/mman.h>
#include <asm/page.h>
#define __KERNEL__

(this a test)

edit: on peut tjours utilise de smileys...

bon, je fais chier yAro avec ca ou pas moi....

ce serait plus utile d'avoir le gras que les smileys

clair...



qu'en penses-tu ?

r les balises dans le [ pre ] parce qu'il arrivait que certaines parties du code étaient interprétées alors qu'elles ne le devraient pas (exemple for(int i ....) ... array[i]Il avait été demandé de vire => italique).

Pour les smileys ca ne posait pas pb donc ils n'ont pas été désactivés dessus.

(je suppose que ta signature, c'est un bug connu ? )

est-ce qu'il y aurait moyen d'avoir une balise pour avoir la même police que le pre, mais en ligne tout comme le b ou le i ?

Ha tiens, c'est ce que je demandais là

Flanker (./12) :
(je suppose que ta signature, c'est un bug connu ? )

bah justement le [pre] evite ce bug ^^

ok ^^
(et pour la police à châsse fixe ? )

en fait, il faudrait une balise [prebis] qui fonctionne comme pre, mais qui autorise les mises en forme de base, ca serait le top

si le [i] avait besoin d'un [/i] pour fonctionner, ça éliminerait déjà pas mal de problèmes #furtif#

En fait sbib demandait a une epoque un [code] et un [pre ] avec [code] qui agit comme actuellement mais les smileys en moins (et oui les smileys genent aussi...) et un [pre ] ou les [i ][b ] & smileys sont géré

(Cas ou les smileys genent :

Blabla::Data

la::Datadonne : Blab

:/

(ou dans ma console :

MacBook-Pro-de-MTR:~ godzil$ cd Desktop/
MacBook-Pro-de-MTR:Desktop godzil$ ls

[nosmile] [nosmile] ?

Zephyr (./17) :
si le [i] avait besoin d'un [/i] pour fonctionner, ça éliminerait déjà pas mal de problèmes #furtif#

Je ne suis pas une star mais ça me paraît déjà un peu plus chiant à programmer

et un [ font=courier ] ?

./20 : C'était une petite attaque déguisée en fait : c'est trivial, et yAronet fonctionnait comme ça a une époque. yAro a choisi la solution actuelle (ne plus vérifier la présence de la fin d'une balise pour la fermer) pour des raisons de rapidité, et comme d'hab ce sont des choix sur lesquels on ne tombera jamais d'accord ^^

./22 => c'est bien ce qu'il me semblait

Sans trop m'avancer je pense que spipu serait plutôt du même avis que moi d'ailleurs ^^

Mais bon j'ai tendance à être un peu pour l'extrême inverse : quand je parse des balise je m'assure de générer du code XHTML valide (décroisement des balises imbriquées & co), ce qui coute encore bien plus cher en temps de génération, et ça n'est pas pour autant une meilleure solution (ni une moins bonne), juste une façon différente de prendre le problème.

idem ^^

mais après, c'est toujours une question de trouver le juste milieu...

ici par exemple, il faut peut-être mieux en effet sacrifier la "conformité" du code généré pour certaines balises comme b ou i, étant donné que les messages sont par la suite mis dans des divs => aucune influence sur le reste de la page, afin de gagner en temps de génération

après, je suppose que yAro a protégé les balises qui en avaient réellement besoin...

En meme temps le préparsage du post peut etre fait au moment du post et non de l'affichage

heu..... non, il ne s'agit pas de dire qu'un post est invalide, mais de ne pas prendre en compte les balises non fermées, car tu dois pouvoir mettre $toto[i] si tu en as besoin...

je parle de ce que fait bob (remise des balises dans le bon ordre & co) qui consome du temps, que plutot que le faire a l'affichage on peu le faire au moment ou le post est posté

cf :

Zephyr (./24) :
quand je parse des balise je m'assure de générer du code XHTML valide (décroisement des balises imbriquées & co), ce qui coute encore bien plus cher en temps de génération, et ça n'est pas pour autant une meilleure solution (ni une moins bonne), juste une façon différente de prendre le problème.

tu veux dire le faire en javascript lorsque tu tapes ton texte (ou l'envoie)?

[edit] cross ./29 : non, plutôt enregistrer le texte parsé en base je suppose.

ça a déjà été envisagé, mais ça implique plein d'autres problèmes chiants : il faut soit sauver les deux versions parsée et non parsée, soit prévoir une fonction de "déparsage" pour pouvoir éditer les posts. Dans le premier cas ça coute une place monstrueuse, dans le second ça pose plein de problèmes avec certaines balises un peu complexes (les sondages par exemple). On peut toujours "tricher", par exemple en utilisant l'attribut "id" d'une balise au parsage des sondages pour retrouver leur numéro quand on déparse, mais pour gérer tous les cas ça devient assez rapidement lourd et moche.