(reprise du message précédent)

armand a écrit :
je ne savais pas qu'il y avait un match

Disons qu'au détour d'une phrase je me suis plu à décrire le comparatif frames/site dynamique comme un match. On appelle ça un effet de style.

armand a écrit :
mais plutôt une solution pratique qui fonctionne - avec si possible un exemple

Moi je veux bien donner des exemples, mais qu'est-ce que tu entends par « solution pratique et qui fonctionne » ? Une solution à quoi, à quels enjeux, à quels problèmes ?

En passant, au sujet du « opinions "religieuses" », je ne pense pas avoir jeté l'anathème sur l'utilisation des frames. Il peut être utile de rappeler que les frames peuvent être utiles (je l'ai dit plus haut), qu'elles sont une solution satisfaisante au regard de certaines contraintes (je l'ai dit encore un peu plus haut), et enfin qu'elles sont tout à fait valides en HTML 4.01 et en XHTML 1.0.

Je ne vois pas trop à quel moment j'ai sorti le numéro de l'ayatollah à coup de « les frames çayleumal ».
Modifié par Florent V. (31 Mar 2007 - 23:18)

ok; je tâche de résumer ce que je veux faire :

1. je veux publier des pages contenant de l'information (pages "info") en passant le plus de temps possible sur le contenu et le moins de temps possible sur la technique. Je ne suis pas programmeur et ne trouve aucun plaisir à "coder". Je veux donc utiliser un outil "wysiwig". S'il n'existe pas d'autre moyen je veux bien ajouter de temps en temps un peu de code (javascript ou autre) tant que cela ne rend pas mes pages difficiles à maintenir.

2. ces pages peuvent en principe être "appellées" depuis plusieurs endroits (différents menus dans le même site, ou même à partir de sites extérieurs). Je ne peux donc rien coder dans ces pages qui présuppose comment et à partir de quelle page elles vont être appelées.

3. je veux montrer en permanence à l'utilisateur (par exemple dans une barre verticale à gauche de l'écran) le menu lui permettant de naviguer partout dans le site. Ce menu change régulièrement en fonction de l'évolution du site; un changement dans le menu ne peut en aucun cas nécessiter de devoir modifier des pages "infos".

4. Les liens dans le menu de gauche doivent pouvoir charger des pages "infos" dans la partie droite de l'écran. Pour des questions de performance, je préférerais que le menu de gauche ne doive pas être rechargé à chaque fois qu'on veut charger une nouvelle page "info"

Bon... ceci étant dit, deux questions :

1. Parmi les 4 points ci-dessus, lesquels paraissent déraisonnables ? et pourquoi ?

2. Les frames me fournissent actuellement une solution extrèmement simple qui remplit ces 4 points. S'il s'agit d'une technologie dépassée et à proscrire, quelle autre solution me proposez-vous ? (un exemple serait le bienvenu)

Merci

armand a écrit :
1. Parmi les 4 points ci-dessus, lesquels paraissent déraisonnables ? et pourquoi ?

Le point numéro 1 n'est pas déraisonnable, mais bloquant, vu qu'il exclut l'apprentissage de bases de programmation. La solution restante sera alors l'usage d'un CMS. Un CMS est idéal, une fois mis en place, pour passer le maximum de temps sur le contenu et le moins de temps possible sur la technique. Mais il faut le mettre en place, ce qui est en soi une opération technique. De plus, si le type de site à réaliser est très spécifique, cela demandera une bonne maitrise de l'outil CMS en question, ce qui inclut un travail technique conséquent. Bien souvent, des CMS sont mis en place par des techniciens et utilisés (pour le rédactionnel) par des non techniciens. La solution intégrée où une même personne non technicienne gère tous les aspects d'un site, c'est effectivement l'éditeur WYSIWYG.

Le point 2 devrait être discuté en détail pour savoir quelle solution technique adoptée, mais les frames se prêtent effectivement mieux à ce type de modularité. À moins de plonger dans les profondeurs de l'interrogation des bases de données ou de la génération et de la reprise de données XML. À vrai dire, avec ce type d'échange de données (base de données ou XML) on peut réaliser beaucoup de choses, et ça sera au final beaucoup plus souple et performant que l'utilisation de frames... mais là ça demande d'être développeur.

Le troisième point ne pose pas de problème.

Enfin, le quatrième point est une exigence déraisonnable. Pas que ça soit impossible à faire, mais tout simplement parce qu'il n'y a aucun problème de performance lié au fait de devoir recharger le code HTML d'un menu de navigation. Aucune raison de se focaliser là-dessus.

armand a écrit :
2. Les frames me fournissent actuellement une solution extrèmement simple qui remplit ces 4 points.

Tout à fait.

armand a écrit :
S'il s'agit d'une technologie dépassée et à proscrire, quelle autre solution me proposez-vous ? (un exemple serait le bienvenu)

Il ne s'agit pas d'une technologie à proscrire. Elle fait d'ailleurs partie des spécifications HTML 4.01 et XHTML 1.0.

Quant à savoir si c'est une technologie dépassée... en quelque sorte, oui. Les frames ont été massivement utilisées afin de ne pas dupliquer du code HTML destiné à apparaitre sur plusieurs pages d'un site, ce qui diminue très nettement les couts de maintenance (en temps et donc, le cas échéant, en argent). Ce motif d'utilisation principal a depuis reçu des réponses tout à fait satisfaisantes, permettant par ailleurs de créer des sites dépourvus des défauts des frames, et donnant également plus de possibilités aux concepteurs de sites.

Pour les professionnels de la conception web, les frames sont effectivement dépassées, en dehors de quelques usages très spécifiques.

Cependant, les solutions de remplacement sont des solutions peu abordables pour les non professionnels qui n'ont aucune envie de plonger dans le code ou d'apprendre à se servir d'un CMS.

Salut Touvert. Oui, Spip est une expérience très intéressante - je crois que c'est un responsable du Monde Diplomatique qui est un des initiateurs du projet. Il a de grandes qualités, surtout pour permettre à des collaborateurs "occasionnels" (journalistes) de publier directement leurs articles dans un cadre défini et géré centralement. Je me suis intéressé à ce concept début 2005, quand il a enfin supporté le concept de sites multilingues.

Je ne suis pas sur d'avoir tout découvert concernant ce produit, mais j'ai été alors assez déçu du caractère assez "primitif" d'utilisation de balises dans le texte pour la mise en forme. Quand on veut créer un document à imprimer, tout le monde trouve normal d'utiliser un outil de traitement de texte wysiwig (word ou équivalent, comme openOffice) et personne n'oserait proposer aux utilisateurs d'insérer des balises dans leur texte pour le mettre en forme. Cela m'a toujours étonné de voir que ce système continue à être proposé quand il s'agit de créer du texte pourt internet.

Je ne sais pas quelle a été l'évolution du produit depuis lors. A-t-il évolué ?
Modifié par armand (03 Apr 2007 - 10:30)

armand a écrit :
mais j'ai été alors assez déçu du caractère assez "primitif" d'utilisation de balises dans le texte pour la mise en forme. Quand on veut créer un document à imprimer, tout le monde trouve normal d'utiliser un outil de traitement de texte wysiwig (word ou équivalent, comme openOffice) et personne n'oserait proposer aux utilisateurs d'insérer des balises dans leur texte pour le mettre en forme.

C'est pourtant un des systèmes les plus puissants et les plus fiables pour l'édition de contenus à dominante textuelle sur le Web.

Lorsqu'on fait de la PAO, on évite de balancer dans XPress ou InDesign un document fait sous Word par quelqu'un qui ne connait à la gestion des styles par Word. Il arrive souvent que l'on soit obligé de reprendre un texte en format texte brut et de recomposer une mise en forme plus cohérente et surtout plus propre et plus professionnelle.

Il existe des éditeurs WYSIWYG en Javascript utilisables dans les systèmes de gestion de contenu. Ils sont séduisants, mais d'expérience cela conduit à un contenu souvent mal mis en forme, à des manquements à la charte graphique, etc. L'utilisation d'une syntaxe simple comme le fait Spip ou Dotclear, couplée à des outils (Javascript cette fois) de génération de syntaxe (via des boutons, des fonctionnalités d'insertion d'images, etc.) permet au rédacteur de mieux se rendre compte de ce qu'il fait, des niveaux de titre choisis, des alternatives textuelles insérées ou non, etc.

Ça demande bien entendu une formation des rédacteurs. Mais l'autre solution c'est de laisser les rédacteurs se débrouiller avec un outil « comme Word », et produire des pages de qualité moindre.

Là encore, pas de secret : l'exigence de qualité demande un certain professionnalisme, ou à tout le moins un peu de rigueur et un temps de formation.

wayi a écrit :
C'est le principe même des frames qui est mauvais.
Jacob Nielsen ne s'y trompe pas puisqu'il place dès mai 1996 l'utilisation de frames comme l'erreur numéro 1 de design d'un site...

OK Wayi, je connais le dogme - pas besoin de faire du copier-coller d'un article paru dans projetweb en mai 2000. Mais si la technique a évolué depuis 1996, on peut imaginer que les opinions peuvent, elles aussi, évoluer ? En tout cas ceux qui ont édité les normes HTML 4.01 et XHTML 1.0 semblent ne pas avoir lu Nielsen, puisque les frames font toujours partie de ces normes.

Plutôt que de proclamer qu'il y aurait des "bonnes" et des "mauvaises" techniques (les bonnes menant au paradis des webmasters tandis que ceux qui utilisent les mauvaises iront brûler en enfer avec les autres mécréants...) je crois qu'il y a plutôt des manières sensées ou pas de les utiliser.

Par exemple, personne ne conteste que l'ajout d'images ou de gifs animés peut augmenter la convivialité d'une page - mais certains sites sont à ce point "bourrés" de machins qui clignotent et d'images qui bougent qu'ils font en général fuir les visiteurs au bout de la première minute de visite... Personne ne songe cependant à dire, j'espère, que les gifs animés sont par essence une "grossa merda" (qualificatif trouvé dans ce forum pour qualifier les frames).

Pour avoir une musique de fond sur un site le frameset est obligatoire. Comment peut-on faire pour avoir une page sans frameset et sans avoir une musique qui redémarre à chaque changement de page ?

Bonjour.

Les frames et les iframes n'existeront plus en XHTML 2 et seront remplacées par les XFrames d'après ce que j'ai compris.

Sources :
XHTML 2
XFrames

C'est un des reproche qui me vient le plus face aux normes.
Depuis que je viens ici j'ai une vision bien moins eloigné des normes. J'en suivrais certaines forcer de reconnaitre qu'elles detiennent du bon sens. mais pour d'autres je suis franchement sceptique.

il faut remplacer embed par object, il faut remplacer name par id , il va falloir remplacer mon iframe pour placer mon xframe.

a quoi servent ces changements de noms? pourquoi ne pas changer l'implementation des balises existantes.

A perdre ceux qui essaient de comprendre comment un faire un site web?

d'ailleurs le réel devoir des normes n'est-il pas de figer les choses aux lieu de les changer a chaque fois.
Modifié par CPascal (05 May 2007 - 14:44)

Ceux qui se tiennent au courant ne seront pas perdus.
Le rôle des normes n'est pas de figer les choses, il faut bien que le web évolue ... Les personnes qui font les normes réfléchissent sur cela en essayant de créer une cohérence entre les divers langages du web.

A première lecture, j'ai tendance à dire que les Xframes sont plus simples à mettre en oeuvre (row, column) mais la manière de déclarer leur source (via les ID) est bizarre.

notepad ++ le gère ^^ il y a remplacer dans tous les documents ouvert

Salut,
Est ce que je peux appliquer un effet css à un tableau de sorte que la colonne gauche puisse etre extensible par le visiteur (comme c le cas avec les iframes), je veux faire cela car je desire avoir un menu a gauche sous forme d'arborescence avec des titres de liens un peu longs, donc pas tres lisibles avec la largeur par defaut contenant le menu. Ca serait bien si le visiteur pouvait l elargir si besoin.
Marci par avance de votre aide
yazyaz