Paraît que les « cadres » c'est désuet, pas bien tout ça (vrai ou faux ?).
Donc je me suis dit que ce serait bien des les remplacer par des div mises
en forme correctement avec une CSS qui va bien.
Mon souci est cette page : http://www.valinfo.org/galpres.php
La liste de gauche doit pouvoir défiler de haut en bas et de bas en haut
sans que la partie droite ne bouge. Facile théoriquement, en mettant
position: fixed sur la div de droite (l'affichage de contenu).
Seulement, là où ça se gâte, c'est que si on clique sur l'un des sigles à
gauche, on affiche à droite un contenu qui dans la plupart des cas
nécessite lui aussi un défilement vertical, indépendant de celui de la
liste à gauche. Et c'est là que le positionnement fixed ne convient pas,
car il n'y a pas de défilement possible (ce qui se comprend).
Si quelqu'un pouvait m'aider, ce serait BIEN, parce que là, compte tenu de
mon niveau d'ignorance en CSS, je galère un peu beaucoup...
Je remarque un autre problème, uniquement avec Firefox : il manque une balise </font> à la fin du texte en rouge (« animations et concerts »).
Oui, il en manque même deux.
[...] Opera, Chrome, Safari et même IE « comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils insèrent donc implicitement le </font> manquant). Seul Firefox en est incapable et écrit tout le texte en rouge...
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs sont quand même vachement sympas d'afficher quelque chose sur un tel code. Note que, même s'il peut sembler surprenant que Firefox ait fait ce choix, au moins il est cohérent avec lui-même.
Regarde par exemple le bout de code suivant sur la même page : ------------------------------------------------------------------------- <br>aux demandes d'animation des restaurants et bars musicaux.<br><BR><font size="4">
<p alignÎnter><font color=red>Ci-dessous, le TRIO VIRDEBORD enregistre son premier CD.</p> -------------------------------------------------------------------------
Ici, tous les navigateurs choisissent de faire franchir le « font size="4" » à la balise P qui suit, comme tu peux t'en rendre compte en remplaçant la taille 4 par 1 ou 7. Alors pourquoi IE et les autres traiteraient-ils différemment l'entrée et la sortie ?
Au fait, IE et Gecko interprètent de la même manière le code suivant, avec à la fois une entrée imprévue et une sortie imprévue : <B>gras <I>gras italique</B> italique</I> Si IE était cohérent, il quitterait le mode italique ici à l'endroit du </B>, comme il quitte la couleur rouge sur la page en question au </P>.
Je remarque un autre problème, uniquement avec Firefox : il manque une
balise </font> à la fin du texte en rouge (« animations et concerts »).
Oui, il en manque même deux.
[...] Opera, Chrome, Safari et même IE
« comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils
insèrent donc implicitement le </font> manquant). Seul Firefox en est
incapable et écrit tout le texte en rouge...
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs
sont quand même vachement sympas d'afficher quelque chose sur un tel
code. Note que, même s'il peut sembler surprenant que Firefox ait fait
ce choix, au moins il est cohérent avec lui-même.
Regarde par exemple le bout de code suivant sur la même page :
-------------------------------------------------------------------------
<br>aux demandes d'animation des restaurants et bars
musicaux.<br><BR><font size="4">
<p alignÎnter><font color=red>Ci-dessous, le TRIO VIRDEBORD enregistre
son premier CD.</p>
-------------------------------------------------------------------------
Ici, tous les navigateurs choisissent de faire franchir le « font
size="4" » à la balise P qui suit, comme tu peux t'en rendre compte en
remplaçant la taille 4 par 1 ou 7. Alors pourquoi IE et les autres
traiteraient-ils différemment l'entrée et la sortie ?
Au fait, IE et Gecko interprètent de la même manière le code suivant,
avec à la fois une entrée imprévue et une sortie imprévue :
<B>gras <I>gras italique</B> italique</I>
Si IE était cohérent, il quitterait le mode italique ici à l'endroit du
</B>, comme il quitte la couleur rouge sur la page en question au </P>.
Je remarque un autre problème, uniquement avec Firefox : il manque une balise </font> à la fin du texte en rouge (« animations et concerts »).
Oui, il en manque même deux.
[...] Opera, Chrome, Safari et même IE « comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils insèrent donc implicitement le </font> manquant). Seul Firefox en est incapable et écrit tout le texte en rouge...
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs sont quand même vachement sympas d'afficher quelque chose sur un tel code. Note que, même s'il peut sembler surprenant que Firefox ait fait ce choix, au moins il est cohérent avec lui-même.
Regarde par exemple le bout de code suivant sur la même page : ------------------------------------------------------------------------- <br>aux demandes d'animation des restaurants et bars musicaux.<br><BR><font size="4">
<p alignÎnter><font color=red>Ci-dessous, le TRIO VIRDEBORD enregistre son premier CD.</p> -------------------------------------------------------------------------
Ici, tous les navigateurs choisissent de faire franchir le « font size="4" » à la balise P qui suit, comme tu peux t'en rendre compte en remplaçant la taille 4 par 1 ou 7. Alors pourquoi IE et les autres traiteraient-ils différemment l'entrée et la sortie ?
Au fait, IE et Gecko interprètent de la même manière le code suivant, avec à la fois une entrée imprévue et une sortie imprévue : <B>gras <I>gras italique</B> italique</I> Si IE était cohérent, il quitterait le mode italique ici à l'endroit du </B>, comme il quitte la couleur rouge sur la page en question au </P>.
SAM
Le 10/30/08 11:52 AM, Olivier Miakinen a écrit :
Le 29/10/2008 17:35, SAM répondait à Pascale Peyrol :
Ben, paske tu avais écrit (-: au lieu de :-)
C'est juste un souriard de gaucher. (-;
et qu'il me semble que le premier est à l'envers (en usage courant) et que seul le second me donne une image-smiley dans mon Thunderbird
C'est là qu'est le bug : Thunderbird ne devrait pas remplacer les séquences de caractère par des images
Je ne sais si c'est Th ou une de ses extension, ces remplacements ne me gênant pas je n'ai pas cherché à les désactiver.
car ce n'est pas lui qui peut deviner si une séquence donnée est censée être un souriard, ou autre chose. Idem pour le gras, le soulignement ou l'italique.
Pour l'italique c'est assez c...t le + souvent, c'est vrai.
Tiens, un exemple :
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit passer.
« (j'avais eu 5, 7- et 8- ) »
« j'avais à calculer 3 * pi * pi * 1/3 »
-- sm
Le 10/30/08 11:52 AM, Olivier Miakinen a écrit :
Le 29/10/2008 17:35, SAM répondait à Pascale Peyrol :
Ben, paske tu avais écrit (-: au lieu de :-)
C'est juste un souriard de gaucher. (-;
et qu'il me semble que le premier est à l'envers (en usage courant)
et que seul le second me donne une image-smiley dans mon Thunderbird
C'est là qu'est le bug : Thunderbird ne devrait pas remplacer les
séquences de caractère par des images
Je ne sais si c'est Th ou une de ses extension, ces remplacements ne me
gênant pas je n'ai pas cherché à les désactiver.
car ce n'est pas lui qui peut
deviner si une séquence donnée est censée être un souriard, ou autre
chose. Idem pour le gras, le soulignement ou l'italique.
Pour l'italique c'est assez c...t le + souvent, c'est vrai.
Tiens, un exemple :
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit
passer.
Le 29/10/2008 17:35, SAM répondait à Pascale Peyrol :
Ben, paske tu avais écrit (-: au lieu de :-)
C'est juste un souriard de gaucher. (-;
et qu'il me semble que le premier est à l'envers (en usage courant) et que seul le second me donne une image-smiley dans mon Thunderbird
C'est là qu'est le bug : Thunderbird ne devrait pas remplacer les séquences de caractère par des images
Je ne sais si c'est Th ou une de ses extension, ces remplacements ne me gênant pas je n'ai pas cherché à les désactiver.
car ce n'est pas lui qui peut deviner si une séquence donnée est censée être un souriard, ou autre chose. Idem pour le gras, le soulignement ou l'italique.
Pour l'italique c'est assez c...t le + souvent, c'est vrai.
Tiens, un exemple :
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit passer.
« (j'avais eu 5, 7- et 8- ) »
« j'avais à calculer 3 * pi * pi * 1/3 »
-- sm
Olivier Miakinen
Le 30/10/2008 17:22, SAM a écrit :
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit passer.
« (j'avais eu 5, 7- et 8- ) »
Ben non... quand on fait attention, justement, on ne met jamais d'espace avant une parenthèse fermante. En outre, encore faudrait-il connaître les séquences que Thunderbird considère comme émoticôgènes, or malgré une longue recherche ce matin je n'ai rien trouvé.
« j'avais à calculer 3 * pi * pi * 1/3 »
Admettons. Un autre exemple alors :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ? As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
Le 30/10/2008 17:22, SAM a écrit :
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit
passer.
« (j'avais eu 5, 7- et 8- ) »
Ben non... quand on fait attention, justement, on ne met jamais d'espace
avant une parenthèse fermante. En outre, encore faudrait-il connaître
les séquences que Thunderbird considère comme émoticôgènes, or malgré
une longue recherche ce matin je n'ai rien trouvé.
« j'avais à calculer 3 * pi * pi * 1/3 »
Admettons. Un autre exemple alors :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ?
As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
Comme tu le sais, onnaka faire attention à ce qu'on écrit et là ça doit passer.
« (j'avais eu 5, 7- et 8- ) »
Ben non... quand on fait attention, justement, on ne met jamais d'espace avant une parenthèse fermante. En outre, encore faudrait-il connaître les séquences que Thunderbird considère comme émoticôgènes, or malgré une longue recherche ce matin je n'ai rien trouvé.
« j'avais à calculer 3 * pi * pi * 1/3 »
Admettons. Un autre exemple alors :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ? As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
Michael DENIS
Olivier Miakinen a écrit :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ? As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
*_pas mal !_* :-)
-- Michaël DENIS
Olivier Miakinen a écrit :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ?
As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ? As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
*_pas mal !_* :-)
-- Michaël DENIS
Pascale Peyrol
docanski écrivait news:gecl00$25ce$:
Reste cette histoire d'interprétation des </font> manquants.
Si tu veux passer aux CSS, oublie totalement cette balise !
Euh... oui mais non. Les éléments de style en question sont entrés par les utilisateurs à l'aide d'un générateur (un peu comme le BBCode, sauf que c'est pas du BBCode) que je serais bien en peine de réécrire, vu que c'est plein de Javascript beaucoup trop compliqué pour moi. On se trouve donc inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des négligences des utilisateurs qui, pour la plupart, ne savent pas vraiment, voire pas du tout ce qu'est une balise HTML. Ce qui m'étonne, c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en rouvrir un autre derrière avec mes éléments de style définis correctement, ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques, couleurs, etc. qui n'ont pas été fermés dans le div précédent.
-- Kekcestruc, Raphia, Le Jardin des Amis, frj-gazette, Mon Beau Jardin, Valinfo et autres outils de jardin sont sur http://www.la-grille-verte.net
Reste cette histoire d'interprétation des </font> manquants.
Si tu veux passer aux CSS, oublie totalement cette balise !
Euh... oui mais non. Les éléments de style en question sont entrés par les
utilisateurs à l'aide d'un générateur (un peu comme le BBCode, sauf que
c'est pas du BBCode) que je serais bien en peine de réécrire, vu que c'est
plein de Javascript beaucoup trop compliqué pour moi. On se trouve donc
inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des
négligences des utilisateurs qui, pour la plupart, ne savent pas
vraiment, voire pas du tout ce qu'est une balise HTML. Ce qui m'étonne,
c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en
rouvrir un autre derrière avec mes éléments de style définis correctement,
ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques,
couleurs, etc. qui n'ont pas été fermés dans le div précédent.
--
Kekcestruc, Raphia, Le Jardin des Amis,
frj-gazette, Mon Beau Jardin, Valinfo
et autres outils de jardin sont sur http://www.la-grille-verte.net
Reste cette histoire d'interprétation des </font> manquants.
Si tu veux passer aux CSS, oublie totalement cette balise !
Euh... oui mais non. Les éléments de style en question sont entrés par les utilisateurs à l'aide d'un générateur (un peu comme le BBCode, sauf que c'est pas du BBCode) que je serais bien en peine de réécrire, vu que c'est plein de Javascript beaucoup trop compliqué pour moi. On se trouve donc inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des négligences des utilisateurs qui, pour la plupart, ne savent pas vraiment, voire pas du tout ce qu'est une balise HTML. Ce qui m'étonne, c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en rouvrir un autre derrière avec mes éléments de style définis correctement, ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques, couleurs, etc. qui n'ont pas été fermés dans le div précédent.
-- Kekcestruc, Raphia, Le Jardin des Amis, frj-gazette, Mon Beau Jardin, Valinfo et autres outils de jardin sont sur http://www.la-grille-verte.net
Pascale Peyrol
Olivier Miakinen <om+ écrivait news:4909db13$:
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs sont quand même vachement sympas d'afficher quelque chose sur un tel code.
Je suis bien de cet avis...
Note que, même s'il peut sembler surprenant que Firefox ait fait ce choix, au moins il est cohérent avec lui-même.
Dans d'autres cas, il fait « mieux » qu'Opera : http://www.valinfo.org/testgalpres.php?presid"13383
Regarde par exemple le bout de code suivant sur la même page
:[explications]
Tes explications sont claires (comme d'habitude (-: ) mais je ne sais pas comment je vais sortir quelque chose de ce galimatias... À l'heure actuelle, ces problèmes sont masqués grâce à l'usage systématique de tables, mais je sais que ce n'est pas une bonne solution...
-- Kekcestruc, Raphia, Le Jardin des Amis, frj-gazette, Mon Beau Jardin, Valinfo et autres outils de jardin sont sur http://www.la-grille-verte.net
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs
sont quand même vachement sympas d'afficher quelque chose sur un tel
code.
Je suis bien de cet avis...
Note que, même s'il peut sembler surprenant que Firefox ait fait
ce choix, au moins il est cohérent avec lui-même.
Dans d'autres cas, il fait « mieux » qu'Opera :
http://www.valinfo.org/testgalpres.php?presid"13383
Regarde par exemple le bout de code suivant sur la même page
:[explications]
Tes explications sont claires (comme d'habitude (-: ) mais je ne sais pas
comment je vais sortir quelque chose de ce galimatias... À l'heure
actuelle, ces problèmes sont masqués grâce à l'usage systématique de
tables, mais je sais que ce n'est pas une bonne solution...
--
Kekcestruc, Raphia, Le Jardin des Amis,
frj-gazette, Mon Beau Jardin, Valinfo
et autres outils de jardin sont sur http://www.la-grille-verte.net
C'est le phénomène GIGO « garbage in, garbage out ». Les navigateurs sont quand même vachement sympas d'afficher quelque chose sur un tel code.
Je suis bien de cet avis...
Note que, même s'il peut sembler surprenant que Firefox ait fait ce choix, au moins il est cohérent avec lui-même.
Dans d'autres cas, il fait « mieux » qu'Opera : http://www.valinfo.org/testgalpres.php?presid"13383
Regarde par exemple le bout de code suivant sur la même page
:[explications]
Tes explications sont claires (comme d'habitude (-: ) mais je ne sais pas comment je vais sortir quelque chose de ce galimatias... À l'heure actuelle, ces problèmes sont masqués grâce à l'usage systématique de tables, mais je sais que ce n'est pas une bonne solution...
-- Kekcestruc, Raphia, Le Jardin des Amis, frj-gazette, Mon Beau Jardin, Valinfo et autres outils de jardin sont sur http://www.la-grille-verte.net
Olivier Miakinen
Le 30/10/2008 18:17, Pascale Peyrol a écrit :
[...] Les éléments de style en question sont entrés par les utilisateurs à l'aide d'un générateur [...]. On se trouve donc inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des négligences des utilisateurs qui, pour la plupart, ne savent pas vraiment, voire pas du tout ce qu'est une balise HTML.
Si je peux me permettre, dans ce cas la faute n'en revient pas tant aux utilisateurs qu'au générateur lui-même. Le minimum qu'on peut demander à ce genre de bestiole, ce serait de ne pas ouvrir une balise à moins de la refermer aussitôt.
Bien évidemment, il n'est pas pensable de /corriger/ un tel outil : la seule alternative consiste à le garder et vivre avec ses bugs, ou le remplacer complètement par un CMS bien conçu.
Ce qui m'étonne, c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en rouvrir un autre derrière avec mes éléments de style définis correctement, ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques, couleurs, etc. qui n'ont pas été fermés dans le div précédent.
« It's not a bug, it's a feature » comme dans l'exemple que j'ai déjà donné : <B>gras <I>gras italique</B> italique</I>.
Sachant que ce genre d'horreur existe, et qu'il faut savoir faire aussi bien que le logiciel concurrent, Firefox le traduit en : <b>gras <i>gras italique</i></b><i> italique</i> (comme on peut le voir avec View/Selection source ou en sauvant la page HTML sur son disque).
De la même manière, le code de la page que tu citais : ----------------------------------------------------------------------- <font color="red"> <font size="4">animations et concerts</p> <div class="milieu"> ----------------------------------------------------------------------- devient : ----------------------------------------------------------------------- <font color="red"> <font size="4">animations et concerts</font></font></p> <div class="milieu"><font color="red"><font size="4"> -----------------------------------------------------------------------
Le 30/10/2008 18:17, Pascale Peyrol a écrit :
[...] Les éléments de style en question sont entrés par les
utilisateurs à l'aide d'un générateur [...]. On se trouve donc
inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des
négligences des utilisateurs qui, pour la plupart, ne savent pas
vraiment, voire pas du tout ce qu'est une balise HTML.
Si je peux me permettre, dans ce cas la faute n'en revient pas tant aux
utilisateurs qu'au générateur lui-même. Le minimum qu'on peut demander à
ce genre de bestiole, ce serait de ne pas ouvrir une balise à moins de
la refermer aussitôt.
Bien évidemment, il n'est pas pensable de /corriger/ un tel outil : la
seule alternative consiste à le garder et vivre avec ses bugs, ou le
remplacer complètement par un CMS bien conçu.
Ce qui m'étonne,
c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en
rouvrir un autre derrière avec mes éléments de style définis correctement,
ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques,
couleurs, etc. qui n'ont pas été fermés dans le div précédent.
« It's not a bug, it's a feature » comme dans l'exemple que j'ai déjà
donné :
<B>gras <I>gras italique</B> italique</I>.
Sachant que ce genre d'horreur existe, et qu'il faut savoir faire aussi
bien que le logiciel concurrent, Firefox le traduit en :
<b>gras <i>gras italique</i></b><i> italique</i>
(comme on peut le voir avec View/Selection source ou en sauvant la page
HTML sur son disque).
De la même manière, le code de la page que tu citais :
-----------------------------------------------------------------------
<font color="red"> <font size="4">animations et concerts</p>
<div class="milieu">
-----------------------------------------------------------------------
devient :
-----------------------------------------------------------------------
<font color="red"> <font size="4">animations et concerts</font></font></p>
<div class="milieu"><font color="red"><font size="4">
-----------------------------------------------------------------------
[...] Les éléments de style en question sont entrés par les utilisateurs à l'aide d'un générateur [...]. On se trouve donc inévitablement avec des <i>, des <u> et des <font> pas fermés suite à des négligences des utilisateurs qui, pour la plupart, ne savent pas vraiment, voire pas du tout ce qu'est une balise HTML.
Si je peux me permettre, dans ce cas la faute n'en revient pas tant aux utilisateurs qu'au générateur lui-même. Le minimum qu'on peut demander à ce genre de bestiole, ce serait de ne pas ouvrir une balise à moins de la refermer aussitôt.
Bien évidemment, il n'est pas pensable de /corriger/ un tel outil : la seule alternative consiste à le garder et vivre avec ses bugs, ou le remplacer complètement par un CMS bien conçu.
Ce qui m'étonne, c'est que lorsque je ferme un paragraphe </p> et même un div </div> pour en rouvrir un autre derrière avec mes éléments de style définis correctement, ceux-ci sont ignorés et je trimballe toujours les soulignés, italiques, couleurs, etc. qui n'ont pas été fermés dans le div précédent.
« It's not a bug, it's a feature » comme dans l'exemple que j'ai déjà donné : <B>gras <I>gras italique</B> italique</I>.
Sachant que ce genre d'horreur existe, et qu'il faut savoir faire aussi bien que le logiciel concurrent, Firefox le traduit en : <b>gras <i>gras italique</i></b><i> italique</i> (comme on peut le voir avec View/Selection source ou en sauvant la page HTML sur son disque).
De la même manière, le code de la page que tu citais : ----------------------------------------------------------------------- <font color="red"> <font size="4">animations et concerts</p> <div class="milieu"> ----------------------------------------------------------------------- devient : ----------------------------------------------------------------------- <font color="red"> <font size="4">animations et concerts</font></font></p> <div class="milieu"><font color="red"><font size="4"> -----------------------------------------------------------------------
ce n'est pas la peine ! Rien qu'avec un petit extrait de celle-ci on est servi ! Et bien servi !
exemple : <font color="red"><font size="4"><font size="2"><font size="4"><font color="red">
C'est kiki begaie ? et n'arrive pas à se décider sur la taille ?
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
mais sur celui-ci, on voit bien le débordement de l'image sur la droite.
Ben si votre interface d'upload est mal foutue ... faut pas s'étonner. C'est au php à redimensionner les images en fonction de leur emplacement. Ça peut se faire côté navigateur par une règle css mais c'est la porte ouverte à pouvoir donner des images mal dimensionnées et inutilement lourdes.
C'est comme le menu à base de logos de toutes tailles. Il faudrait à minima que votre php (ou un humain ?) redimensionne les images qui sont trop larges pour y entrer.
Je remarque un autre problème, uniquement avec Firefox : il manque une balise </font> à la fin du texte en rouge (« animations et concerts »). Ce code est rentré par l'utilisateur, il est donc un peu inévitable que ce genre de bévue se produise.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Non ce n'est pas inévitable, l'utilisateur - soit sélectionne un bout de texte et choisit une couleur et l'interface pose les balises (ou les styles) - soit choisit une couleur et tape son texte et quand il veut revenir en "normal" ça met la balise de fin. et finalement l'interface analyse le shmillblick
Si c'est trop compliqué il faut avoir une charte rigide - h1 (fonte, couleur, taille graisse, étoussa. Par css) - h2 (idem) - p (idem) - img (soit principale soit secondaire et le php les redimensionne en conséquence avant enregistrement lors de l'upload) - etc ... L'utilisateur n'a le droit de ne remplir que les champs autorisés (en texte simple), indiquer titres des images et qualités de celles-ci. Il a à dispo un bouton pour en visualiser le résultat stylé afin, éventuellement, pouvoir revoir/reprendre sa copie.
Opera, Chrome, Safari et même IE « comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils insèrent donc implicitement le </font> manquant). Seul Firefox en est incapable et écrit tout le texte en rouge...
Yaka utiliser des styles appliqués au texte "normal" dans P au moyen de span ou directement associés aux balises div, p, h1, h2 ... au lieu de se servir de balises font
-- sm
Le 10/30/08 3:13 PM, Pascale Peyrol a écrit :
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait
news:490890cc$0$895$ba4acef3@news.orange.fr:
ce n'est pas la peine !
Rien qu'avec un petit extrait de celle-ci on est servi !
Et bien servi !
exemple :
<font color="red"><font size="4"><font size="2"><font size="4"><font
color="red">
C'est kiki begaie ?
et n'arrive pas à se décider sur la taille ?
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
mais sur celui-ci, on voit bien le
débordement de l'image sur la droite.
Ben si votre interface d'upload est mal foutue ...
faut pas s'étonner.
C'est au php à redimensionner les images en fonction de leur emplacement.
Ça peut se faire côté navigateur par une règle css mais c'est la porte
ouverte à pouvoir donner des images mal dimensionnées et inutilement
lourdes.
C'est comme le menu à base de logos de toutes tailles.
Il faudrait à minima que votre php (ou un humain ?) redimensionne les
images qui sont trop larges pour y entrer.
Je remarque un autre problème, uniquement avec Firefox : il manque une
balise </font> à la fin du texte en rouge (« animations et concerts »). Ce
code est rentré par l'utilisateur, il est donc un peu inévitable que ce
genre de bévue se produise.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de
fonts balbutiantes une simple image (code cité ci-haut) ?
Non ce n'est pas inévitable,
l'utilisateur
- soit sélectionne un bout de texte et choisit une couleur
et l'interface pose les balises (ou les styles)
- soit choisit une couleur et tape son texte
et quand il veut revenir en "normal" ça met la balise de fin.
et finalement l'interface analyse le shmillblick
Si c'est trop compliqué il faut avoir une charte rigide
- h1 (fonte, couleur, taille graisse, étoussa. Par css)
- h2 (idem)
- p (idem)
- img (soit principale soit secondaire et le php les redimensionne
en conséquence avant enregistrement lors de l'upload)
- etc ...
L'utilisateur n'a le droit de ne remplir que les champs autorisés (en
texte simple), indiquer titres des images et qualités de celles-ci.
Il a à dispo un bouton pour en visualiser le résultat stylé
afin, éventuellement, pouvoir revoir/reprendre sa copie.
Opera, Chrome, Safari et même IE
« comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils
insèrent donc implicitement le </font> manquant). Seul Firefox en est
incapable et écrit tout le texte en rouge...
Yaka utiliser des styles appliqués au texte "normal" dans P au moyen de
span ou directement associés aux balises div, p, h1, h2 ... au lieu de
se servir de balises font
ce n'est pas la peine ! Rien qu'avec un petit extrait de celle-ci on est servi ! Et bien servi !
exemple : <font color="red"><font size="4"><font size="2"><font size="4"><font color="red">
C'est kiki begaie ? et n'arrive pas à se décider sur la taille ?
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
mais sur celui-ci, on voit bien le débordement de l'image sur la droite.
Ben si votre interface d'upload est mal foutue ... faut pas s'étonner. C'est au php à redimensionner les images en fonction de leur emplacement. Ça peut se faire côté navigateur par une règle css mais c'est la porte ouverte à pouvoir donner des images mal dimensionnées et inutilement lourdes.
C'est comme le menu à base de logos de toutes tailles. Il faudrait à minima que votre php (ou un humain ?) redimensionne les images qui sont trop larges pour y entrer.
Je remarque un autre problème, uniquement avec Firefox : il manque une balise </font> à la fin du texte en rouge (« animations et concerts »). Ce code est rentré par l'utilisateur, il est donc un peu inévitable que ce genre de bévue se produise.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Non ce n'est pas inévitable, l'utilisateur - soit sélectionne un bout de texte et choisit une couleur et l'interface pose les balises (ou les styles) - soit choisit une couleur et tape son texte et quand il veut revenir en "normal" ça met la balise de fin. et finalement l'interface analyse le shmillblick
Si c'est trop compliqué il faut avoir une charte rigide - h1 (fonte, couleur, taille graisse, étoussa. Par css) - h2 (idem) - p (idem) - img (soit principale soit secondaire et le php les redimensionne en conséquence avant enregistrement lors de l'upload) - etc ... L'utilisateur n'a le droit de ne remplir que les champs autorisés (en texte simple), indiquer titres des images et qualités de celles-ci. Il a à dispo un bouton pour en visualiser le résultat stylé afin, éventuellement, pouvoir revoir/reprendre sa copie.
Opera, Chrome, Safari et même IE « comprennent » que le texte en rouge s'arrête avec le </p> qui suit (ils insèrent donc implicitement le </font> manquant). Seul Firefox en est incapable et écrit tout le texte en rouge...
Yaka utiliser des styles appliqués au texte "normal" dans P au moyen de span ou directement associés aux balises div, p, h1, h2 ... au lieu de se servir de balises font
-- sm
Olivier Miakinen
Le 30/10/2008 19:13, SAM a écrit :
[ rien que du bon sens ]
Amen.
Sauf que Pascale sera bien embêtée avec ta réponse, à moins qu'il soit envisageable d'envoyer tout ce bouzin à la décharge et de le remplacer par un vrai BBcode, ou un SPIP, etc.
Le 30/10/2008 19:13, SAM a écrit :
[ rien que du bon sens ]
Amen.
Sauf que Pascale sera bien embêtée avec ta réponse, à moins qu'il soit
envisageable d'envoyer tout ce bouzin à la décharge et de le remplacer
par un vrai BBcode, ou un SPIP, etc.
Sauf que Pascale sera bien embêtée avec ta réponse, à moins qu'il soit envisageable d'envoyer tout ce bouzin à la décharge et de le remplacer par un vrai BBcode, ou un SPIP, etc.
SAM
Le 10/30/08 5:45 PM, Olivier Miakinen a écrit :
Admettons. Un autre exemple alors :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ? As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
Bon d'accord ! Je me demande bien pourquoi parfois j'essaie de te contredire ?
-- sm
Le 10/30/08 5:45 PM, Olivier Miakinen a écrit :
Admettons. Un autre exemple alors :
As-tu _constaté_ que *cela* donne parfois des résultats _étonnants_ ?
As-tu _vu_ que *ça* donne parfois des résultats _surprenants_ ?
Bon d'accord !
Je me demande bien pourquoi parfois j'essaie de te contredire ?
