Les frames (cadres) et iframes : a méditer...

(reprise du message précédent)

bonjour à tous

je ne suis pas un pro mais je trouve que parfois les frames peuvent être sympas...

un exemple de site que j'ai fait avec des frames: un site qui explique comment faire un batch de sauvegarde pour firefox

dans ce cas par exemple, je trouve que les frames m'ont permis un design sympa sans avoir à être un génie du web dev...


automatiquement, je me pose une question:
ne serait-ce pas aux navigateurs d'évoluer et d'être capables de marquer ou imprimer une page avec ses frames actifs?
pour ce qui est du référencement, si google est pas assez malin pour suivre des frames, est-ce à google de s'adapter ou aux web dev de bannir les frames?



bref: les frames, vraiment à bannir ou plutôt est-ce aux navigateurs et au reste de les prendre réellement en charge?

je trouve très intéressant de pouvoir interagir avec des liens dans un frame target...
ce serait dommage de perdre cette fonctionnalité, ou de la reserver aux pros du php alors qu'il existe une solution aussi simple que les frames...


je trouve qu'internet est un espace sympa car il est ouvert à tous:
c'est bien qu'un pro puisse faire des sites en flash carrément époustoufflants
mais c'est bien aussi qu'un pûr débutant puisse partager ses passions en créant un vrai site de noob

tout standardiser, tout limiter, alors que la machine pourrait facilement apprendre à faire la différence (pour référencer, imprimer, bookmarker), je trouce ça dommage
Modifié par D-ude (01 Jan 2007 - 23:46)

Salut, je viens mettre mon grain de sel dans ce sujet fort intéressant.
Il y a quelques temps, j'ai fais une gallerie photo et je ne voulais pas que la page se recharge à chaque photo car à chaque fois, le scroll retourne au début et ce n'est pas pratique quand il y a beaucoup de photos.
Grace à Alsacréations, un peu de javascript et php, j'ai fait ca

L'avantage est qu'on peut mettre beaucoup de photos sur une page, le scroll ne bouge pas à chaque fois... Comme avec les frames.

Bon, c'est pas valide W3C que je ne connaissais pas bien à l'époque, je vais peut être m'y remettre.

L'avantage du php est aussi qu'on met les photos dans un dossier, et la page va les chercher tous seul, pas besoin de les insérer une à une dans le <li>, mais c'est une autre histoire.

Bref, si ca peut faire avancer le schmil...

Zil...

Bonjour,

Je suis nouveau sur ce forum et je n'ai pas lu les 6 pages de réponse au sujet... J'ai eu la flemme...

Il faut dire que plein de bonne volonté, j'ai lu la foire aux questions, tout les "bins" pour bien faire le forum, et tout et tout... Donc là, je commençais un peut à fatiguer.

Juste pour dire que j'ai été surppris de constater que live messenger (hotmail) utilisait les frames. Il est vrai qu'il n'a pas la contrainte des moteurs de recherche (les comptes mails ne sont pas indexés sur google), donc dans un sens cela parait un bonne idée.

Je ne me suis pas connecté à internet depuis un an et quelque, et j'essaie de me remettre à nouveau dans le bain. On parle beaucoup du web 2.0, et dans le même temps des normes du w3c.

L'idée, de ne pas recharger toute la page je trouve ça super, mais personnellement, à part sur live messenger qui utilise les frames, je n'ai pas trouvé de pages et .. de manière ... pour charger seulement un élément de la page (excepté les images, musiques etc en JS).

Aussi je vous pose la question à vous grands manitou de la conception web ...

Personnellement j'aimerai bien sur mon site pouvoir recharger seulement élément par élément.
Combiné au php, ça serait super !

=>Demander à javascript d'appeler un script php qui faire une requète dans une base de donnée et d'afficher ça dans un div... !!!
Sans avoir besoin de tout recharger.

Tout recharger, c bien beau, mais même si nos connexions d'aujourd'hui sont ultra-rapides, mais imaginons que notre utilisateur il soit en train de remplir un formulaire, et que pour ça on ai besoin d'une information qu'il y a dans la base de donnée ?

ça me fait penser à des formulaires que j'ai vu sur certains sites qui renseignaient tout les départements de france dans la page ("<select>Paris</select><select>yvelines</select>") etc... En php, c'est vite fait mais d'un point de vue logique, cela ne l'est absolument pas.

on peut recharger en conservant les données du formulaire, mais ce n'est pas pratique.

Alors j'ai cherché mais j'ai pas trouvé la solution ...

document.getElementById["blabla"].innerHTML.src = "requeteVille.php";

=>ça existe ?

Tant que j'y suis, je voulais vous demander ce que vous pensez de IE 7 ?

Personnellement sur ma page, j'ai une image avec du transparent.
Le transparent ne s'affichait pas sur IE6, sur IE7 il s'affiche mais il met horriblement de temps (le processeur décolle à 100% d'utilisation, et il met environ 5 secondes pour l'afficher). Sous netscape, mozilla, opéra, c'est instantané.

En dehors de cela, j'ai l'impression qu'il est généralement très lent...
Il est possible que mon installation ait été corrompu, mais bon...

Et à part ça, des petits problèmes de centrage de ma page (text align dans body et dans le div conteneur principal), ça marche à moitié sur ie7, et pas du tout, sur netscape, mozilla et opéra.

Autrement j'espère que ça va bien pour vous ...

Bonjour à tous, d après la lecture de ce sujet je vois que vous déconseillez les frames , que tout site pro digne de ce nom ne peut adopter ce systeme ...

Et moi en fait j ai en stock une bannière animée en flash que je vais placer sur chaque page de mon site et on m a conseillé de mettre cette bannière en frame pour pas que ca doive etre chargé sur chaque page..

Je vois que l autre solution que vous proposez fait intervenir du php , langage dans lequel je ne suis pas encore familiarisé mais bon ca ne coute rien d apprendre , alors a votre avis il vaudrait mieux éviter les frames à tout prix?

Bonjour, j'ai bien tout lu ces 6 pages de débat.

Finalement, qu'en est-il de l'accessibilité des iframes ?

Posent-elles un problème nettement moins grand que les frames "structurelles" (par opposition à ces iframes = inline frames = cadres dans le flux) ?

Sont-elles autant à proscrire que le duo frameset + frame ?

(Je ne compte pas les utiliser, demande juste une mise au point.)
Modifié par accessibilisation (01 Mar 2007 - 19:42)

Bonsoir,

Il n'est pas question de proscrire quoi que ce soit, et surtout pas des technologies valides prenant en compte les nécessités de l'accessibilité. Mais de servir des éléments normalisés à bon escient.

Un iframe (ou un frameset) respectant les règles WCAG pourra être accessible là où diverses astuces de contournement des cadres ne le seront pas.

Inversement, un frameset ou un iframe lui-même utilisé comme contournement (l'iframe si "pratique" pour masquer un bug d'élément fenêtré, par exemple), ou de manière aberrante (je pense à un grand site d'e-commerce ne comportant pas moins de 12 frames) posera évidemment des problèmes d'accessibilité.

Enfin, on peut tout de même noter que le frameset pose (potentiellement) un problème de complexité de l'interface (relations entre des cadres multiples) qui ne pose pas (ou pas au même degré) un "simple" iframe isolé dans un contenu HTML. <edit>Mais bien-sûr, il y a aussi les gens qui font des choses perverses à ces pauvres iframes, par exemple à coup de javascript </>
Modifié par Laurent Denis (01 Mar 2007 - 22:11)

Euh... merci Laurent.

Laurent Denis a écrit :
[...] Enfin, on peut tout de même noter que le frameset pose (potentiellement) un problème de complexité de l'interface (relations entre des cadres multiples) qui ne pose pas (ou pas au même degré) un "simple" iframe isolé dans un contenu HTML.

C'est bien ce que je croyais... merci de confirmer.



Petite parenthèse :
En parcourant ce forum, je pense souvent aux point de contrôle n°14.1 des WCAG 1.0 :

a écrit :
Utiliser le langage le plus clair et le plus simple possible adapté au contenu de votre site. [ Priorité 1 ]

Les interventions sont parfois très pointues et précises que hardues.
Modifié par accessibilisation (01 Mar 2007 - 22:24)

DSC a écrit :
le problème, selon moi se trouve dans le fait que tout le monde n'a pas acces au php. De plus <object> n'insere pas le code mais une page dont meme probleme qu'avec les frames voir pire.

Tous les hébergeurs gratuits, tel Free, proposent php, et du coté des hébergeurs payants, php est inclus dans les hébergements à partir du 60GP pour OVH par exemple ... et dans le cas d'un hébergement de moindre importance, celà sous-entend que le site est un site "vitrine" de peu de pages, donc soit on utilise les <? includes ?> afin de faire un menu unique dans un site conséquent, soit on met le menu sur chaque page du site si celui-ci ne fait que 15 pages par exemple ...

Pour moi les frames ne devraient plus exister parce qu'elles sous-entendent une complexité de conception (3 pages pour faire 1 frame ! la page principale, la page frame et la page contenant les 2 précédentes) chacunes ayant sa propre url ... un cauchemard en terme de référencement, d'accessibilité etc. Et de plus les frames peuvent s'apparenter à de la mise en page (proche du position:fixed du CSS) dans certains cas, or le xhtml tend vers une dissociation de la mise en page et du contenu ... pourquoi donc le w3c a t il créé un xhtml 1.0 frameset ...

Je ne sais pas combien sont dans le même cas, mais en ce qui me concerne, je développe des site pour communiquer des infos, pas pour le plaisir de "programmer". J'utilise frontpage, qui faisait partie de la "suite" office, simplement parce qu'il est aussi simple à utiliser que word, et que je n'ai pas à me préoccuper de connaître le html, le php le javascript ou d'autres joyeusetés similaires.

Les frames me permettent de garder une barre de menu toujours visible et "scrollable" à gauche, ce dont les visiteurs de mes sites me disent qu'ils l'apprécient beaucoup. Si j'avais inclu le menu dans chaque page je devrais les modifier toutes (il y en a des centaines mainenant) chaque fois qu'il y a un changement dans le menu. Voir par exemple www.betancourt.info

L'utilisation de frames n'a jamais empêché un bon référencement (certains sites que j'ai développé avec cette technique apparaissent systématiquement en tête de la première page d'une recherche google). Ce n'est donc pas un argument.

Je serais très heureux d'utiliser une autre technique si elle existe - mais je n'ai pas la possibilité d'apprendre des langages de programmation - je modifie mes sites quotidiennement et si je devais programmer plutôt que travailler en wysiwig cela me prendrait trop de temps. Quelqu'un a-t-il une suggestion pour moi ?
Modifié par armand (31 Mar 2007 - 15:06)

Bonjour,

armand a écrit :
Je ne sais pas combien sont dans le même cas, mais en ce qui me concerne, je développe des site pour communiquer des infos, pas pour le plaisir de "programmer".

Le problème de faire ça avec Frontpage, c'est que la qualité du site obtenu est sous-optimale. Problèmes d'accessibilité, de compatibilité du rendu sur tous les navigateurs, d'adaptabilité à des configurations différentes (c'est à dire pas forcément IE6 sous Windows et avec un écran en 1024x768...), etc.
Si on n'a ni le temps ni l'envie de faire l'apprentissage nécessaire à des productions de meilleure qualité technique, autant utiliser un éditeur WYSIWYG, effectivement. En gardant à l'esprit que la partie « What You Get » peut être assez aléatoire.

armand a écrit :
Si j'avais inclu le menu dans chaque page je devrais les modifier toutes (il y en a des centaines mainenant) chaque fois qu'il y a un changement dans le menu.

Une alternative à ça est l'utilisation d'un langage serveur tel que PHP. En n'apprenant que deux ou trois notions très basiques de ce langage et en appliquant des tutoriels, on arrive à faire quelque chose de semblable (ne pas répéter le code HTML des éléments communs à toutes les pages, ce qui permet en particulier de ne changer qu'une fois le menu pour qu'il change sur toutes les pages).
C'est un apprentissage pas insurmontable, mais un apprentissage tout de même. Lorsqu'on en a déjà fait un (utiliser la technique des frames de manière correcte n'est pas automatique, et ça demande un minimum de travail), on peut ne pas avoir envie d'en faire un supplémentaire. À chacun de décider des investissements (en temps) qu'il veut bien consentir.

armand a écrit :
L'utilisation de frames n'a jamais empêché un bon référencement (...). Ce n'est donc pas un argument.

Désolé, mais ça reste un argument. On peut effectivement avoir un site utilisant des frames qui soit bien référencé. Mais 1) on aurait probablement obtenu un référencement un peu meilleur avec un site équivalent mais sans frames et 2) le principal problème des frames lié au référencement est le fait que les résultats des recherches peuvent pointer vers des pages de contenu dépourvues de la navigation du site.

Autre problème probablement déjà soulevé : l'impossibilité, dans la plupart des cas, de mettre un marque-page (ou favori) pointant vers la bonne page avec le bon contenu (c'est à dire le bon fichier chargé dans la frame de contenu).

On pourrait également détailler les problèmes d'accessibilité que cette technique représente.

armand a écrit :
Je serais très heureux d'utiliser une autre technique si elle existe - mais je n'ai pas la possibilité d'apprendre des langages de programmation - je modifie mes sites quotidiennement et si je devais programmer plutôt que travailler en wysiwig cela me prendrait trop de temps. Quelqu'un a-t-il une suggestion pour moi ?

T'es-tu déjà intéressé aux systèmes de gestion de contenu ? Un CMS tel que SPIP pourrait être très utile pour un site documentaire (série d'articles par catégories, de brèves, etc.). Il y en a bien sûr d'autres.

L'utilisation d'un CMS a de nombreux avantages : possibilité d'éditer un contenu directement depuis une interface web, de faire intervenir plusieurs rédacteurs, de produire uniquement du contenu et de laisser le système l'intégrer à l'interface du site, etc. Si tu vas sur la partie des tutoriels d'Alsacréations, tu remarqueras que l'architecture des pages est constante, et que seul le contenu (l'article change). Les tutoriels sont gérés avec un système de gestion de contenu (CMS) nommé Plume CMS.

La mise en place et l'utilisation d'un système de gestion de contenu demandent, comme pour chaque outil en informatique, un certain apprentissage. Surtout si on veut s'écarter du fonctionnement par défaut du logiciel, en modifiant à sa guise l'architecture des pages ou leur présentation, voire même la structure organisationnelle des contenus.

En bref, il ne faut pas apprendre un langage de programmation, mais il faut apprendre à se servir d'un outil (à commencer par l'installation, heureusement en général pas trop compliquée).

Là encore, à chacun de voir si les avantages induits justifient l'apprentissage nécessaire.


Voili voilou... est-ce plus clair ?

Florent V. a écrit :
Une alternative à ça est l'utilisation d'un langage serveur tel que PHP. En n'apprenant que deux ou trois notions très basiques de ce langage et en appliquant des tutoriels, on arrive à faire quelque chose de semblable

Frontpage ne fonctionne pas avec les pages dcontenant du PHP - les deux systemes sont incompatibles - je crois qu'il y a des 'trucs" pour les faire fonctionner mais cela m'obligerait à passer mon temps à des problemes techniques, et je n'en ai ni le temps ni l'envie

Florent V. a écrit :
on aurait probablement obtenu un référencement un peu meilleur avec un site équivalent mais sans frames et 2) le principal problème des frames lié au référencement est le fait que les résultats des recherches peuvent pointer vers des pages de contenu dépourvues de la navigation du site.

d'accord avec le second point - pas le premier

Florent V. a écrit :
T'es-tu déjà intéressé aux systèmes de gestion de contenu ? Un CMS tel que SPIP pourrait être très utile pour un site documentaire]

Le principe est ok - je connais spip mais c'est assez pénible à utiliser comparé à la facilité de frontpage. Par contre j'utilise la version gratuite de CityDesk ( www.fogcreek.com/CityDesk ) que je trouve remarquable - entre autre parce qu'elle permet de mettre en quelques minutes en ligne des infos en plusieurs langues. Je m'en sers entre pour publier chaque jour une revue de presse en 3 langues - à l'intérieur des frames de www.betancourt.info .
Y a-t-il une façon simple de gérer un menu "indépendant" avec <div> et une feuille de style ? Si oui, j'apprécierais un exemple (cela vaut 100 fois mieux que des explications théoriques)

armand a écrit :
Y a-t-il une façon simple de gérer un menu "indépendant" avec <div> et une feuille de style ? Si oui, j'apprécierais un exemple (cela vaut 100 fois mieux que des explications théoriques)

Salut armand et bienvenue sur Alsacréations ,

heu, si je comprends bien ta question, oui, il existe un moyen, mais comme le dit Florent, il faut utiliser un peu de php pour le faire.

En fait, ce n'est pas si grave si tu ne sais pas gérer le php dans Frontpage, tu peux toujours ouvrir les pages en question dans le bloc-notes par exemple et insérer les codes php par ce biais.

Faire ce que tu demande en php n'est vraiment pas difficile et ne demande pas beaucoup de temps d'apprentissage pour autant que l'on se donne la peine de lire un tutoriel.

Les deux tutoriels que je connais sont les suivants :

Celui d'Alsacréations

Celui du site du zero

Si tu l'apprends bien, tu verras le temps considérable que tu vas gagner, surtout avec des gros sites comme les tiens

ps : Si jamais tu utilise du php, chaque page qui en contient doit avoir une extension en .php au lieu de .html

Salut Touvert. C'est là que se trouve le problème : je peux insérer du code php sans problème sous frontpage (il suffit de travailler en mode "html") - mais frontpage n'est pas capable de gérer des pages avec extension .php. il y a incompatibilité.

De plus, si je comprend bien la technique, il s'agirait d'insérer ce code php dans CHACUNE des pages du site ... cela fait plusieurs centaines à modifier... La technique des frames me permet, elle, de gérer ces pages de manière complètement indépendente.
Modifié par armand (31 Mar 2007 - 18:31)

armand a écrit :
mais frontpage n'est pas capable de gérer des pages avec extension .php. il y a incompatibilité.

Ah bon, ouais, alors, c'est vrai que ça pose problème. Heu sinon, est-ce que tu as déjà regardé du côté d'autres éditeurs WYSIWYG ? Il y a par exemple NVU qui est entièrement gratuit, j'ai souvent entendu dire qu'il n'est pas mal pour les gens qui ne touchent pas beaucoup au code. Par contre, je ne sais pas si il gère les fichiers php, à voir donc.

a écrit :
De plus, si je comprend bien la technique, il s'agirait d'insérer ce code php dans CHACUNE des pages du site ... cela fait plusieurs centaines à modifier... La technique des frames me permet, elle, de gérer ces pages de manière complètement indépendente.

Oui, pour tes sites déjà en ligne depuis longtemps, c'est vrai que ça fait beaucoup, mais bon, peut-être réserver cette technique aux éventuels prochains sites que créeras.

touvert a écrit :


Ah bon, ouais, alors, c'est vrai que ça pose problème. Heu sinon, est-ce que tu as déjà regardé du côté d'autres éditeurs WYSIWYG ? Il y a par exemple NVU qui est entièrement gratuit, j'ai souvent entendu dire qu'il n'est pas mal pour les gens qui ne touchent pas beaucoup au code. Par contre, je ne sais pas si il gère les fichiers php, à voir donc.

Oui je connais Nvu que j'ai installé et essayé. Il est très "clean" et convient pour créer des petits sites simples - mais c'est plutôt un remplacement "propre" à FrontPage Express (la version "light" et gratuite de FrontPage - il ne se compare pas avec FrontPage...

...autre sujet de réflexion : insérer du code php dans une page "info"pour faire venir automatiquement la page "menu" par exemple dans une bande latérale à gauche, revient à "lier" par code les deux parties. Impossible d'afficher la page "info" sans afficher aussi la page "menu". C'est absolument contraire à l'un des principes de base de la programmation modulaire.

Avec les frames, les pages "infos" que je mets en ligne peuvent être appelées par n'importe quel menu - même dans des sites différents. C'est le cas pour un grand nombre de mes pages. D'autres sites utilisent par exemple mes pages "revue de presse" à l'intérieur de leurs sites (par frame également, ou par iframe). Si je codais du php pour appeler un menu, je rendrais cette application impossible.

Heu armand... là j'avoue que je suis un peu perplexe.

1. Tu utilises les frames. Ça t'a demandé un certain apprentissage, et maintenant ça te permet de réaliser quelque chose qui correspond à tes besoins.

2. Apparemment, tu gères plusieurs sites conséquents et tu as des besoins assez importants. Répondre à ces besoins demanderait sans doute plus que la simple utilisation basique de PHP. C'est à dire : soit apprendre les bases d'un langage serveur tel que PHP, soit t'investir dans l'utilisation d'un CMS. Tu n'as envie de faire ni l'un, ni l'autre.

Au vu de (1) et (2), il me semblerait bien que le problème soit réglé, non ? Les frames répondent à tes besoins, donc autant les garder, non ?


Au passage, je précise que « migrer » un site conséquent utilisant les frames vers un site dynamique (CMS ou codé à la main) demanderait une refonte complète.

effectivement les frames répondent à mes besoins; cela n'a rien de compliqué à utiliser. Néanmoins je lis régulièrement - y compris dans ce forum - des opinions très tranchées sur le sujet selon lesquelles "les frames représentent une technologie dépassée qui peut généralement être remplacée par des technologies ou des techniques plus récentes et surtout, plus efficaces. Moi je veux bien, mais je n'ai pas encore trouvé quelqu'un qui me montre comment les remplacer en gardant les mêmes fonctions. Je crois finalement que les frames ne sont ni meilleurs ni plus mauvais que n'importe quelle autre technique. Le tout c'est de les utiliser correctement. l

armand a écrit :
Moi je veux bien, mais je n'ai pas encore trouvé quelqu'un qui me montre comment les remplacer en gardant les mêmes fonctions.

Ah ?

Fonction « pas de reproduction du contenu » : ok avec les langages serveur (dont PHP).
Fonction « construction modulaire de pages » : ok et même beaucoup plus puissant avec les langages serveur, voire avec une base de données.

Pour ma part, je ne suis pas développeur mais je connais tout juste assez PHP pour exploiter correctement les deux fonctions évoquées ci-dessus. Les frames ne me sont donc d'aucune utilité.

Maintenant si on veut faire un petit comparatif :

Avantages des frames :
- le seul point sur lequel je les trouve utiles, c'est pour la construction d'interfaces compatibles IE6 où on veut avoir des éléments fixes (toujours visibles quelle que soit la longueur du contenu par ailleurs), par exemple des outils toujours accessibles dans une application sur un intranet.

Défaut des frames :
- référencement d'éléments seuls (éléments de contenu, de navigation) et possibilité pour l'utilisateur d'accéder seulement à cet élément, en particulier via les résultats d'un moteur de recherche ;
- gros problèmes d'accessibilité via un navigateur non graphique ou un lecteur d'écran.

Un avantage correspondant à un cas particulier contre deux défauts génériques : les frames perdent le match.

Plus sérieusement, dans un cas où j'ai réellement besoin des frames je n'hésiterai pas à les utiliser. Mais ces cas sont rares (pour moi qui sais utiliser des techniques plus puissantes).

? bon, je ne savais pas qu'il y avait un match, mais comme tu le dis, tu as certainement raison.

Maintenant, si quelqu'un a autre chose à ajouter que des opinions "religieuses" - mais plutôt une solution pratique qui fonctionne - avec si possible un exemple - je suis preneur.

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)