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...
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs qu'on imaginerait pas... y compris d'effacer des balises...
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.
Tu penses auquel en particulier ?
-- Pascale 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
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs
qu'on imaginerait pas... y compris d'effacer des balises...
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.
Tu penses auquel en particulier ?
--
Pascale
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
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs qu'on imaginerait pas... y compris d'effacer des balises...
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.
Tu penses auquel en particulier ?
-- Pascale 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 20:01, SAM a écrit :
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 ?
C-:
Le 30/10/2008 20:01, SAM a écrit :
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 ?
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 ?
C-:
Pascale Peyrol
SAM écrivait news:4909f935$0$890$:
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 ?
En l'occurence, c'est l'utilisateur...
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
Un Javascript.
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.
Elles sont tout de même limitées à 100 Ko.
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.
Oui, le mieux serait de les redimensionner à l'origine.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
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
C'est comme cela que ça marche...
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.
Oui, mais il sera difficile de les priver de la possibilité de mettre de la couleur, de l'italique, du gras... à l'intérieur même du texte.
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
Sûr que ce serait préférable...
-- 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
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait
news:4909f935$0$890$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 ?
En l'occurence, c'est l'utilisateur...
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
Un Javascript.
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.
Elles sont tout de même limitées à 100 Ko.
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.
Oui, le mieux serait de les redimensionner à l'origine.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de
fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
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
C'est comme cela que ça marche...
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.
Oui, mais il sera difficile de les priver de la possibilité de mettre de la
couleur, de l'italique, du gras... à l'intérieur même du texte.
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
Sûr que ce serait préférable...
--
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
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 ?
En l'occurence, c'est l'utilisateur...
Qu'est-ce qui vous produit ce genre de code tout bordélique ?
Un Javascript.
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.
Elles sont tout de même limitées à 100 Ko.
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.
Oui, le mieux serait de les redimensionner à l'origine.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
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
C'est comme cela que ça marche...
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.
Oui, mais il sera difficile de les priver de la possibilité de mettre de la couleur, de l'italique, du gras... à l'intérieur même du texte.
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
Sûr que ce serait préférable...
-- 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
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Pascale Peyrol ecrit ce qui suit en ce 30.10.2008 18:17 :
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.
Mauvais générateur, changer de générateur : c'est plus simple que de le corriger de fond en comble.
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.
Je trouve plutôt curieux que des utilisateurs qui ne sont pas censés écrire du code mais du texte (je suppose que c'est bien la finalité du bouzin ?) y soient autorisés : c'est la porte ouverte à tous les "bugs". C'est donc la conception même de l'interactivité du site qui est à revoir, me semble-t'il.
Cordialement, -- docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/ Guide des champignons d'Europe : http://mycorance.free.fr/ La vallée de la Rance maritime : http://valderance.free.fr/ Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Pascale Peyrol ecrit ce qui suit en ce 30.10.2008 18:17 :
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.
Mauvais générateur, changer de générateur : c'est plus simple que de le
corriger de fond en comble.
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.
Je trouve plutôt curieux que des utilisateurs qui ne sont pas censés
écrire du code mais du texte (je suppose que c'est bien la finalité du
bouzin ?) y soient autorisés : c'est la porte ouverte à tous les "bugs".
C'est donc la conception même de l'interactivité du site qui est à
revoir, me semble-t'il.
Cordialement,
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, Pascale Peyrol ecrit ce qui suit en ce 30.10.2008 18:17 :
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.
Mauvais générateur, changer de générateur : c'est plus simple que de le corriger de fond en comble.
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.
Je trouve plutôt curieux que des utilisateurs qui ne sont pas censés écrire du code mais du texte (je suppose que c'est bien la finalité du bouzin ?) y soient autorisés : c'est la porte ouverte à tous les "bugs". C'est donc la conception même de l'interactivité du site qui est à revoir, me semble-t'il.
Cordialement, -- docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/ Guide des champignons d'Europe : http://mycorance.free.fr/ La vallée de la Rance maritime : http://valderance.free.fr/ Les côtes du nord de la Bretagne : http://docarmor.free.fr/
SAM
Le 10/30/08 8:17 PM, Pascale Peyrol a écrit :
SAM écrivait news:4909f935$0$890$:
Oui, mais il sera difficile de les priver de la possibilité de mettre de la couleur, de l'italique, du gras... à l'intérieur même du texte.
L'utilisateur *n'a pas à italiquer ni grassouiller* quoique ce soit ! encore moins *colorisationner* comme il veut ! (surtout si potanotiste ou je ne sais quel daltonisme) Il doit se conformer à la charte du site.
Il n'a le droit que de : - titrer (h1) (et qu'une fois) - sous-titrer (h2, h3) (et pas n'importe où) - paragrapher (P) - lister (<ul><li></li></ul> ou <ol><li></li>/ol>) - proposer des illustrations (principale, annexes) avec possibilité de les titrer - table avec thead, tbody et accessoirement titre (caption) et tfoot (interdit pour les images, on lui proposera pour ses albums le truc 'définition' (dl dd dt) par exemple) et dans les phrases - liens - citer - emphaser (en général : italique) - éventuellement strong (+ grand et souvent gras) et le webmaster ou le CA du site décide de comment tout ça doit apparaitre dans les pages afin de maitriser une certaine unité de présentation.
Le résultat final est bien entendu sans aucun table. (sauf si l'utilisateur a des données tabulées à communiquer) (résultats de matchs, calendrier-agenda ...)
Le menu de navigation dans la page par liens vers les sous-titres pourra être réalisé automatiquement par le php.
-- sm
Le 10/30/08 8:17 PM, Pascale Peyrol a écrit :
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait
news:4909f935$0$890$ba4acef3@news.orange.fr:
Oui, mais il sera difficile de les priver de la possibilité de mettre de la
couleur, de l'italique, du gras... à l'intérieur même du texte.
L'utilisateur *n'a pas à italiquer ni grassouiller* quoique ce soit !
encore moins *colorisationner* comme il veut !
(surtout si potanotiste ou je ne sais quel daltonisme)
Il doit se conformer à la charte du site.
Il n'a le droit que de :
- titrer (h1) (et qu'une fois)
- sous-titrer (h2, h3) (et pas n'importe où)
- paragrapher (P)
- lister (<ul><li></li></ul> ou <ol><li></li>/ol>)
- proposer des illustrations (principale, annexes)
avec possibilité de les titrer
- table avec thead, tbody et accessoirement titre (caption) et tfoot
(interdit pour les images, on lui proposera pour ses albums le truc
'définition' (dl dd dt) par exemple)
et dans les phrases
- liens
- citer
- emphaser (en général : italique)
- éventuellement strong (+ grand et souvent gras)
et le webmaster ou le CA du site décide de comment tout ça doit
apparaitre dans les pages
afin de maitriser une certaine unité de présentation.
Le résultat final est bien entendu sans aucun table.
(sauf si l'utilisateur a des données tabulées à communiquer)
(résultats de matchs, calendrier-agenda ...)
Le menu de navigation dans la page par liens vers les sous-titres pourra
être réalisé automatiquement par le php.
Oui, mais il sera difficile de les priver de la possibilité de mettre de la couleur, de l'italique, du gras... à l'intérieur même du texte.
L'utilisateur *n'a pas à italiquer ni grassouiller* quoique ce soit ! encore moins *colorisationner* comme il veut ! (surtout si potanotiste ou je ne sais quel daltonisme) Il doit se conformer à la charte du site.
Il n'a le droit que de : - titrer (h1) (et qu'une fois) - sous-titrer (h2, h3) (et pas n'importe où) - paragrapher (P) - lister (<ul><li></li></ul> ou <ol><li></li>/ol>) - proposer des illustrations (principale, annexes) avec possibilité de les titrer - table avec thead, tbody et accessoirement titre (caption) et tfoot (interdit pour les images, on lui proposera pour ses albums le truc 'définition' (dl dd dt) par exemple) et dans les phrases - liens - citer - emphaser (en général : italique) - éventuellement strong (+ grand et souvent gras) et le webmaster ou le CA du site décide de comment tout ça doit apparaitre dans les pages afin de maitriser une certaine unité de présentation.
Le résultat final est bien entendu sans aucun table. (sauf si l'utilisateur a des données tabulées à communiquer) (résultats de matchs, calendrier-agenda ...)
Le menu de navigation dans la page par liens vers les sous-titres pourra être réalisé automatiquement par le php.
-- sm
SAM
Le 10/30/08 8:17 PM, Pascale Peyrol a écrit :
SAM écrivait news:4909f935$0$890$:
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.
Elles sont tout de même limitées à 100 Ko.
C'est trop. (je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester sensible au poids des images) une image 600/800 devrait ne peser que 40 à 60ko. L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3 ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant de sauvegarder.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
Il ne devrait pas pouvoir, l'illustration (principale) devrait être positionnée au même endroit dans toutes les pages.
-- sm
Le 10/30/08 8:17 PM, Pascale Peyrol a écrit :
SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait
news:4909f935$0$890$ba4acef3@news.orange.fr:
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.
Elles sont tout de même limitées à 100 Ko.
C'est trop.
(je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester
sensible au poids des images)
une image 600/800 devrait ne peser que 40 à 60ko.
L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3
ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant
de sauvegarder.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de
fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
Il ne devrait pas pouvoir, l'illustration (principale) devrait être
positionnée au même endroit dans toutes les pages.
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.
Elles sont tout de même limitées à 100 Ko.
C'est trop. (je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester sensible au poids des images) une image 600/800 devrait ne peser que 40 à 60ko. L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3 ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant de sauvegarder.
Il faudra qd même m'expliquer comment l'utilisateur peut encadrer de fonts balbutiantes une simple image (code cité ci-haut) ?
Il le peut, puisqu'il a le droit de situer les photos avant le texte.
Il ne devrait pas pouvoir, l'illustration (principale) devrait être positionnée au même endroit dans toutes les pages.
-- sm
SAM
Le 10/30/08 7:31 PM, Olivier Miakinen a écrit :
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.
Vu le résultat obtenu qui n'ira sans doute que de mal en pire au cours de l'évolution du site, en effet un relookage complet commence à s'imposer.
Déjà l'idée de vouloir sortir des frames est un bon départ. Le commencement de l'apprentissage des CSS est une bonne suite. Ne reste qu'à concevoir ou trouver un web-éditeur-texte-embarqué plus au gout du jour pour remplacer celui mal fagoté ou mal t'employé.
Je vois celui-là (pas pour IE) qui modifie le code produit suivant ce qu'on choisit même après coup (paragraphe, titre, normal) mais, malgré ce, ne parvient pas entièrement à s'affranchir complètement de "font" (dépend du contexte) <http://www.twistermc.com/shake/rich-text-editor.php>
et puis celui-là qui a l'air d'être celui du site de Pascale (en un peu moins pire mais pas beaucoup) <http://koivi.com/WYSIWYG-Editor/>
il y en a bien d'autres
à mon idée, l'idéal est : - la page canevas type - le formulaire pour remplir et personnaliser ses parties - enregistrement avec modif automatique du menu Comme ça pas d'erreur ni de personnalisation de +/- bon aloi par les contributeurs.
-- sm
Le 10/30/08 7:31 PM, Olivier Miakinen a écrit :
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.
Vu le résultat obtenu qui n'ira sans doute que de mal en pire au cours
de l'évolution du site, en effet un relookage complet commence à s'imposer.
Déjà l'idée de vouloir sortir des frames est un bon départ.
Le commencement de l'apprentissage des CSS est une bonne suite.
Ne reste qu'à concevoir ou trouver un web-éditeur-texte-embarqué plus au
gout du jour pour remplacer celui mal fagoté ou mal t'employé.
Je vois celui-là (pas pour IE) qui modifie le code produit suivant ce
qu'on choisit même après coup (paragraphe, titre, normal) mais, malgré
ce, ne parvient pas entièrement à s'affranchir complètement de "font"
(dépend du contexte)
<http://www.twistermc.com/shake/rich-text-editor.php>
et puis celui-là qui a l'air d'être celui du site de Pascale (en un peu
moins pire mais pas beaucoup)
<http://koivi.com/WYSIWYG-Editor/>
il y en a bien d'autres
à mon idée, l'idéal est :
- la page canevas type
- le formulaire pour remplir et personnaliser ses parties
- enregistrement avec modif automatique du menu
Comme ça pas d'erreur ni de personnalisation de +/- bon aloi par les
contributeurs.
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.
Vu le résultat obtenu qui n'ira sans doute que de mal en pire au cours de l'évolution du site, en effet un relookage complet commence à s'imposer.
Déjà l'idée de vouloir sortir des frames est un bon départ. Le commencement de l'apprentissage des CSS est une bonne suite. Ne reste qu'à concevoir ou trouver un web-éditeur-texte-embarqué plus au gout du jour pour remplacer celui mal fagoté ou mal t'employé.
Je vois celui-là (pas pour IE) qui modifie le code produit suivant ce qu'on choisit même après coup (paragraphe, titre, normal) mais, malgré ce, ne parvient pas entièrement à s'affranchir complètement de "font" (dépend du contexte) <http://www.twistermc.com/shake/rich-text-editor.php>
et puis celui-là qui a l'air d'être celui du site de Pascale (en un peu moins pire mais pas beaucoup) <http://koivi.com/WYSIWYG-Editor/>
il y en a bien d'autres
à mon idée, l'idéal est : - la page canevas type - le formulaire pour remplir et personnaliser ses parties - enregistrement avec modif automatique du menu Comme ça pas d'erreur ni de personnalisation de +/- bon aloi par les contributeurs.
-- sm
Sergio
Pascale Peyrol a couché sur son écran :
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.
Ben, c'est que ton générateur est buggé. Mauvais générateur -> Chnager de générateur !
Par exemple les éditeurs de messages BBCode de PhpBB et autres forums générent en général du code HTML correct, même si les utilisateurs sont des brelles. Idem pour les logiciels de Blog, de Wiki...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Pascale Peyrol a couché sur son écran :
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.
Ben, c'est que ton générateur est buggé. Mauvais générateur -> Chnager
de générateur !
Par exemple les éditeurs de messages BBCode de PhpBB et autres forums
générent en général du code HTML correct, même si les utilisateurs sont
des brelles. Idem pour les logiciels de Blog, de Wiki...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
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.
Ben, c'est que ton générateur est buggé. Mauvais générateur -> Chnager de générateur !
Par exemple les éditeurs de messages BBCode de PhpBB et autres forums générent en général du code HTML correct, même si les utilisateurs sont des brelles. Idem pour les logiciels de Blog, de Wiki...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Sergio
Dans son message précédent, Pascale Peyrol a écrit :
Olivier Miakinen <om+ écrivait news:4909f5e0$:
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs qu'on imaginerait pas... y compris d'effacer des balises...
Veut pas le savoir ! Va faire un tour, par exemple, sur le bac à sable de Wikipédia : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Bac_%C3%A0_sable
Et essaie de faire de la soupe de balise (les <i>, <b>, <font> etc. sont tolérés), le logiciel va générer du code correct !
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Dans son message précédent, Pascale Peyrol a écrit :
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs
qu'on imaginerait pas... y compris d'effacer des balises...
Veut pas le savoir !
Va faire un tour, par exemple, sur le bac à sable de Wikipédia :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Bac_%C3%A0_sable
Et essaie de faire de la soupe de balise (les <i>, <b>, <font> etc.
sont tolérés), le logiciel va générer du code correct !
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Dans son message précédent, Pascale Peyrol a écrit :
Olivier Miakinen <om+ écrivait news:4909f5e0$:
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.
Il le fait... mais les utilisateurs sont capables de faire un tas de trucs qu'on imaginerait pas... y compris d'effacer des balises...
Veut pas le savoir ! Va faire un tour, par exemple, sur le bac à sable de Wikipédia : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Bac_%C3%A0_sable
Et essaie de faire de la soupe de balise (les <i>, <b>, <font> etc. sont tolérés), le logiciel va générer du code correct !
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
docanski
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, SAM ecrit ce qui suit en ce 30.10.2008 23:38 :
C'est trop. (je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester sensible au poids des images) une image 600/800 devrait ne peser que 40 à 60ko. L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3 ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant de sauvegarder.
Si l'hébergeur l'offre à ses abonnés, il y a plus simple encore : l' API "imagemagick" qui permettra d'optimiser les images sans intervention particulière de la part de celui qui veut les publier. Soit en dur, soit par l'intermédiaire de l'interface qui est par ici : http://pecl.php.net/package/imagick -- docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/ Guide des champignons d'Europe : http://mycorance.free.fr/ La vallée de la Rance maritime : http://valderance.free.fr/ Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
SAM ecrit ce qui suit en ce 30.10.2008 23:38 :
C'est trop.
(je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester
sensible au poids des images)
une image 600/800 devrait ne peser que 40 à 60ko.
L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3
ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant
de sauvegarder.
Si l'hébergeur l'offre à ses abonnés, il y a plus simple encore : l' API
"imagemagick" qui permettra d'optimiser les images sans intervention
particulière de la part de celui qui veut les publier. Soit en dur, soit
par l'intermédiaire de l'interface qui est par ici :
http://pecl.php.net/package/imagick
--
docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/
Alors que les eleveurs et agriculteurs polluent toujours la Bretagne, SAM ecrit ce qui suit en ce 30.10.2008 23:38 :
C'est trop. (je n'ai pas quitté le RTC depuis assez longtemps pour ne pas rester sensible au poids des images) une image 600/800 devrait ne peser que 40 à 60ko. L'utilisateur uploade ce qu'il veut ou ce qu'il a (ça peut même faire 3 ou 500ko), le php en fait ce qu'il veut : dimensions et poids maxi avant de sauvegarder.
Si l'hébergeur l'offre à ses abonnés, il y a plus simple encore : l' API "imagemagick" qui permettra d'optimiser les images sans intervention particulière de la part de celui qui veut les publier. Soit en dur, soit par l'intermédiaire de l'interface qui est par ici : http://pecl.php.net/package/imagick -- docanski
Portail et annuaire du nord-Bretagne : http://armorance.free.fr/ Guide des champignons d'Europe : http://mycorance.free.fr/ La vallée de la Rance maritime : http://valderance.free.fr/ Les côtes du nord de la Bretagne : http://docarmor.free.fr/
