Iframe: adapter les dimensions au contenu

Bonjour à tous

Nouveau sur ces forums et quelque peu débutant, je me tourne vers vous afin d'avoir un peu d'aide.

Su le site que je suis en train de préparer, je voudrais afficher des contenus issus des fichiers Html autonomes à l'intérieur d'un "iframe", seulement, les contenus en question occupent des espaces assez différents, aussi bien en largeur qu'en hauteur, or je voudrais que le "iframe" adapte ses dimensions automatiquement au contenu qui sera affiché...

Connaissez-vous un moyen pour faire ça ?
D'autres pistes possibles ?

Merci à tous de vos lumières

Bonjour Florent

Florent V. a écrit :
Comme la question m'intéresse, j'ai fait quelques recherches.

À priori, ça n'est pas possible en HTML (ou CSS, d'ailleurs). Il faudra passer par Javascript pour re dimensionner l'iframe.

Ok, donc, manifestement, sans JavaScript, point de salut... dommage

Merci beaucoup pour toutes ces pistes, j'avais aussi cherché pas mal, mais mon anglais étant ce qu'il est (une catastrophe), j'ai privilégié les recherches sur les page franchophones, et je dois avouer que les solutions disponibles sont vraiment très (trop) peu nombreuses...

Enfin, je suis tombé sur une discussion, sur un autre fourm, où ils parlent de remplacer les "iframe" par des "object", car il paraît que c'est plus "propre" et "valide" suivant les standards du web... mais, hélas, ceci ne semble pas résoudre le problème des dimensions d'affichage par rapport au contenu inclus...

En tout cas, cette piste de remplacer les "iframe" par des "object" m'interroge, car je ne sais pas quels sont en réalité les avantages et incovénients d'une méthode par rapport à l'autre... des idées à ce sujet ?

Pour revenir à nos moutons, quitte à utiliser du JavaScript, je me demande si ce ne serait pas plus judicieux d'envisager une solution à la sauce Ajax, mais là, sincèrement, je ne maîtrise absolument pas la chose...

Bref, je vais étudier de plus près tes propositions Florent, mais la question de l'inclusion dynamique de contenus reste ouverte pour moi, car, visiblement, il n'y a aucune solution qui l'emporte sur l'autre, faut voir maintenant laquelle choisir, et sur quels critères...

Merci beaucoup Florent pour ton aide, je ne manquerais pas d'y revenir pour apporter un retour d'expérience, quelque soit la méthode retenue, car je pense que cette question peut intéresser d'autres développeurs web en herbe comme moi...

à+

FredoMkb a écrit :
Enfin, je suis tombé sur une discussion, sur un autre fourm, où ils parlent de remplacer les "iframe" par des "object", car il paraît que c'est plus "propre" et "valide" suivant les standards du web...

Cette histoire de « plus propre » et « valide » est un peu une hallucination collective d'enthousiastes des standards W3C.
Si on regarde la spécification HTML ou même XHTML, les iframes sont tout à fait valides... avec un doctype Transitional. Le fait d'utiliser une ou des iframe(s) est justement un motif pertinent d'utilisation d'un doctype Transitional.

Quant à la notion de propreté, ça ne veut rien dire. On a par contre :
- la lisibilité du code HTML (sympa pour le développeur/intégrateur, et pour sa productivité) ;
- les qualités et défauts des solutions utilisées ;
- la robustesse des solutions utilisées.

FredoMkb a écrit :
En tout cas, cette piste de remplacer les "iframe" par des "object" m'interroge, car je ne sais pas quels sont en réalité les avantages et incovénients d'une méthode par rapport à l'autre...

- object c'est plus gratifiant pour l'ego des enthousiastes des standards (qui ne lisent par contre pas les spécifications qui définissent ces standards ) ;
- iframe c'est aussi bien sur le principe et beaucoup plus utilisable dans la pratique.
On gardera donc des iframes, sans hésiter.

FredoMkb a écrit :
Pour revenir à nos moutons, quitte à utiliser du JavaScript, je me demande si ce ne serait pas plus judicieux d'envisager une solution à la sauce Ajax, mais là, sincèrement, je ne maîtrise absolument pas la chose...

Il me semble qu'une solution en Ajax te permettra juste d'inclure du code, pas une page complète. Si le but est juste d'éviter la duplication du code d'une page à l'autre (n'écrire qu'une seule fois le code de l'en-tête ou du menu pour que ces éléments soient présents sur toutes les pages), on passera de préférence par PHP.

À mon sens, les iframes ne se justifient que dans trois cas :
- la reprise d'un vieux site utilisant les iframes, et que l'on ne peut pas refondre complètement ;
- une nécessité très forte de ne faire que des rechargements partiels de pages (si c'est juste pour du confort parce que « c'est plus sympa pour le visiteur », oublier cette fausse bonne idée) ;
- l'insertion d'éléments sur lesquels on n'a pas le contrôle (pages et éléments d'un prestataire et hébergées sur le serveur du prestataire, par exemple).

Dans les autres cas, on passera plutôt par PHP. Voir le tutoriel à ce sujet dans les tutoriels Alsacréations.

Florent V. a écrit :

Cette histoire de « plus propre » et « valide » est un peu une hallucination collective d'enthousiastes des standards W3C.

Surtout quand on voit que les réponses de cet autre forum proviennent d'une idée lancée ici-même il y'a 1 an 1/2

Re...

Florent V. a écrit :
Cette histoire de « plus propre » et « valide » est un peu une hallucination collective d'enthousiastes des standards W3C.
Si on regarde la spécification HTML ou même XHTML, les iframes sont tout à fait valides... avec un doctype Transitional. Le fait d'utiliser une ou des iframe(s) est justement un motif pertinent d'utilisation d'un doctype Transitional.

Ok, le doctype "Transitional" est donc adapté à l'utilisation des "iframe", c'est une très bonne info, merci !

Au fait, pour être franc, j'ai essayé de me renseigner sur les différents doctypes existants et de leur particularités, mais j'ai le plus grand mal à bien saisir leur différences et l'importance de celles-ci... bref, je pattoge grâve avec ces notions

Florent V. a écrit :
Quant à la notion de propreté, ça ne veut rien dire. On a par contre :
- la lisibilité du code HTML (sympa pour le développeur/intégrateur, et pour sa productivité) ;
- les qualités et défauts des solutions utilisées ;
- la robustesse des solutions utilisées.

Pour ce qui est de la lisibilité du code, je tente de respecter certains principes dont, notamment, l'insertion des commentaires au début de chaque bloc de code, afin de faciliter la comprhéension de leur rôle, et aussi pour me souvenir, plus tard, les raisons de certains choix...

Ceci-dit, il est souvent assez difficile de rester simple et informatif sur des petits commentaires, étant entendu qu'il est déconseillé de surcharger inutilement le poid du fichier avec trop de données "invisibles".

Concernant la qualité et défauts des solutions utilisées, là il n'y a pas de mystère, seules l'expérience et le retour des internautes permettent de faire les bons choix selon ce qu'on cherche à faire et, de ce point de vue, j'avoue que je ne suis pas très bien armé en la matière, c'est pourquoi je me tourne vers des développeurs bien plus expérimentés que moi, en venant vous soliciter ici par exemple...

Enfin, la notion de "robustèsse" est, elle aussi, un peu floue dans mon esprit, car elle sous-entend un aspect d'éfficacité, voire même de performance, en tout cas de fonctionnalité quelque soit le contexte ou, du moins, dans le plus grand nombre des contextes possibles... bref, très difficile, pour ne pas dire problèmatique ou carrément laborieux, de concevoir un site "robuste" lorsqu'on manque d'expérience et de recul sur les différentes techniques existantes...

Florent V. a écrit :
- object c'est plus gratifiant pour l'ego des enthousiastes des standards (qui ne lisent par contre pas les spécifications qui définissent ces standards ) ;
- iframe c'est aussi bien sur le principe et beaucoup plus utilisable dans la pratique.
On gardera donc des iframes, sans hésiter.

Ok, reçu 5/5

Florent V. a écrit :
Il me semble qu'une solution en Ajax te permettra juste d'inclure du code, pas une page complète.

C'est bien le cas dans ce que je cherche à faire pour l'instant...

Florent V. a écrit :
- une nécessité très forte de ne faire que des rechargements partiels de pages (si c'est juste pour du confort parce que « c'est plus sympa pour le visiteur », oublier cette fausse bonne idée) ;

Oui, c'est exactement la raison qui m'incite à m'intéresser à des solutions d'intégration dynamique des données, sans avoir à recharger toute la page à chaque fois.

Pour être un peu plus concrèt, il se trouve que je développe un squelette pour le Cms francophone Spip, dont vous pouvez découvrir le site de démo en suivant le lien qui se trouve en bas de ces messages.

En fait, je propose un calendrier avec le squelette, qui regroupe par date l'ensemble des contenus publiés sur le site.

Le problème est que lorqu'on veut naviguer sur les différents mois, précédent ou suivant, toute la page se recharge à chaque fois, ce qui est très lourd et qui empêche d'afficher rapidement le calendrier situé à plusieurs mois d'écart que celui qui est affiché... bref, c'est trop lourdingue

Donc, la solution que j'ai adopté pour l'instant, et que j'ai réussi à mettre en place et à tester dans la version de développement, est l'utilisation d'un "iframe" donc, sauf que, selon le nombre de jours et le début du premier jour du mois, le calendrier peut occuper 5 ou 6 lignes (rangées) et, du coup, comme le "iframe" ne s'adapte pas automatiquement à la dimmension du contenu, il arrive que la date du jours soit masquée sous le "iframe", ce qui est plutôt embêttant...

Voilà pour l'explication du cas concrèt, maintenant il faut que je trouve la meilleure technique possible, "robuste" dirons nous , pour autoriser une navigation plus souple et rapide dans le calendrier, sans avoir à recharger l'ensemble de la page à chaque fois...

Alors, soit j'adopte une solution JavaScript permettant de redimenssionner dynamiquement le "iframe" selon le contenu, en suivant tes propositions Florent, soit une autre solution JavaScript de type Ajax pour ne changer que le code du calendrier (méthode que j'ai essayé aussi, mais ça pose d'autres problèmes que je n'ai pas réussi à corriger)...

Bref, à moins d'une solution miraculeuse sans JavaScript, je ne sais pas bien comment faire pour faire simple et "robuste" (j'ai décidement bien aimé ce terme )...

Merci en tout cas pour votre aide, ça m'a déjà permis de mettre un peu d'ordre dans les différentes solutions envisageables, reste à savoir quelle serait la meilleure pour mon cas de figrue...

à+

PS. Oups, je me rends compte que j'ai réussi à faire une belle tartine de blabla... désolé

FredoMkb a écrit :
bref, très difficile, pour ne pas dire problèmatique ou carrément laborieux, de concevoir un site "robuste" lorsqu'on manque d'expérience et de recul sur les différentes techniques existantes...

Effectivement. D'où l'intérêt de bien décrire (et même mieux : de montrer, par exemple en donnant un lien vers sa version de travail en ligne) ce que l'on veut faire, pour avoir des retours des plus expérimentés... et ainsi gagner soi-même en expérience.

FredoMkb a écrit :
Oui, c'est exactement la raison qui m'incite à m'intéresser à des solutions d'intégration dynamique des données, sans avoir à recharger toute la page à chaque fois.

Attention, je rappelle les termes de la condition que j'énonçais : « une nécessité très forte de ne faire que des rechargements partiels de pages ».

La question sera donc : quelle est, très exactement, la contrainte forte qui s'applique à ton projet ?

Re...

Florent V. a écrit :
... même mieux : de montrer, par exemple en donnant un lien vers sa version de travail en ligne ...

Pour l'instant ma version de développement est en local, et elle est bien trop approximative (pour ne pas dire bordélique) pour la mettre en ligne en l'état... mais le site de démo illustre bien le problème.

Florent V. a écrit :
La question sera donc : quelle est, très exactement, la contrainte forte qui s'applique à ton projet ?

Très bonne question !

En fait, je ne sais pas si c'est exactement une contrainte forte, mais voici le problème :

Admétons que le calendrier affiche le mois de Janvier 2007.

Admétons maintenant qu'on souhaite afficher le mois de Juillet 2006, pour voir les contenus publiés à cette période.

Donc, pour ce faire, on doit cliquer 6 fois sur le bouton du mois précédent, ce qui, malheureusement, implique de recharger la totalité de la page le même nombre de fois, 6 fois donc...

Voilà, c'est très lent et lourd, et du coup le calendrier devient vite inutilisable.

Je souhaite donc rendre la navigation dans le calendrier le plus fluide possible, afin de ne pas être obligé à chaque fois de recharger X fois l'ensemble de la page si on souhaite consulter un mois un peu distant de celui affiché.

Alors, ce n'est peut-être pas une contrainte forte, mais ça faciliterait considérablement l'utilisation du calendrier...

Tu en penses quoi ?

Merci... à+

Moi, je pense que dans ce cas, Ajax est plus indiqué que les iframe. C'est même typiquement un cas Ajax. D'ailleurs, c'est qu'utilise le calendrier-agenda de Google (mais tout le monde sait que Google adore Ajax)

Mais voir aussi les problèmes que ca implique :
* le contenu des pages des autres mois ne sera pas indexé par les moteurs de recherches (je ne sais pas exactement ce qu'il y a comme contenu, ni les contraines de référencement que tu as...)
* Sans javascript, tu n'as plus acces aux différents mois

Pour répondre à ces problèmes, personnellement, j'utiliserai Ajax pour naviguer entre les mois, mais je rajouterai des liens statiques, en plus petit, sous le calendrier, vers chaque mois.

Bonjour Yahrou

yahrou a écrit :
Moi, je pense que dans ce cas, Ajax est plus indiqué que les iframe. C'est même typiquement un cas Ajax.

Oui, c'est fort possible... en tout cas, j'ai essayé une solution de type Ajax, mais j'ai rencontré un problème que je n'ai pas su résoudre.

En fait, les boutons des liens des mois précédant et suivant sont eux aussi récupérés par le script Ajax, or, bizarrement, après une première utilisation, la suivante n'affiche plus le calendrier mais l'ensemble de la page

Bref, il semblerait que l'Ajax supporte mal de mettre à jour les liens mêmes qui déclanchent son utilisation, ça fait comme une référence en abime, ou quelque chose de ce type... à vrai dire, je serais totalement incapable d'expliquer ce phénomène... je suis encore très novice avec ces techniques, en tout cas, ça ne semble pas vouloir fonctionner correctement en l'état.

yahrou a écrit :
Mais voir aussi les problèmes que ca implique :
* le contenu des pages des autres mois ne sera pas indexé par les moteurs de recherches (je ne sais pas exactement ce qu'il y a comme contenu, ni les contraines de référencement que tu as...)
* Sans javascript, tu n'as plus acces aux différents mois

Le calendrier n'affiche que des liens vers des pages où les contenus seront en effet présentés, ça ne pose donc aucun souci côté indexation par les moteurs de recherche.

En cas de JS désactivé, ou non géré par le navigateur, j'ai prévu des liens rechargant les pages, comme ça fonctionne actuellement dans le site de démo, donc, la aussi, ça ne devrait pas poser de problème majeur...

yahrou a écrit :
Pour répondre à ces problèmes, personnellement, j'utiliserai Ajax pour naviguer entre les mois, mais je rajouterai des liens statiques, en plus petit, sous le calendrier, vers chaque mois.

L'idée, pour moi en tout cas, est de proposer un calendrier qui puisse fonctionner de la manière la plus souple et fluide possible, et si jamais une des techniques utilisées ne fonctionne pas chez un utilisateur, qu'il puisse au moins naviguer dans le calendrier par la méthode "standard", c'est à dire celle qui est en place actuellemnt sur le site de démo... ça me paraît le mode de fonctionnement le plus ergonomique que je pourrais proposer... non ?

Merci pour ta réponse Yahrou

FredoMkb a écrit :
Alors, ce n'est peut-être pas une contrainte forte

Si si, ça s'en rapproche.

Enfin, disons que ça dépend. Si c'est un petit calendrier intégré en « bonus » ou système de navigation alternatif dans une page, la contrainte (cliquer six fois est fastidieux) justifie un choix technique comme l'utilisation d'Ajax.

Si le calendrier est le contenu principal de la page ou le seul moyen d'accéder à une information... là c'est plus gênant.

Yahrou a raison de dire que c'est typiquement le genre de cas où on pourra utiliser Ajax. MAIS, l'idéal est de garantir une accessibilité minimale même si Javascript est désactivé. Ce qui signifie :
- un fonctionnement de base avec PHP (et il faut cliquer six fois pour revenir six mois en arrière... ou bien utiliser une liste déroulante, hein, ça aussi c'est possible !) ;
- une surcouche Javascript (ajax) qui prend le pas sur le fonctionnement de base en PHP.

Mais ça devient compliqué si on n'est pas développeur.
Quand on a des moyens plus modestes, on doit aller au plus raisonable, et donc au plus simple :
- puis-je simplifier mon mode de navigation entre les mois du calendrier pour que ça soit plus facilement plus utilisable, même sans Ajax, Bonuks et Omomicro ?
- dois-je fournir un moyen alternatif d'accéder à l'information ?
- est-ce que je me contente de la version accessible et pas trop compliquée à faire, même si elle peut être légèrement fastidieuse (« bien mais pas top ») ?
- etc.

Florent V. a écrit :
Enfin, disons que ça dépend. Si c'est un petit calendrier intégré en « bonus » ou système de navigation alternatif dans une page, la contrainte (cliquer six fois est fastidieux) justifie un choix technique comme l'utilisation d'Ajax.

Si le calendrier est le contenu principal de la page ou le seul moyen d'accéder à une information... là c'est plus gênant.

Non non, ce n'est pas le contenu principal de la page, c'est juste une méthode de navigation chronologique dans les contenus publiés sur le site.

Bref, le fonctionnement classique d'un calendrier de blog par exemple.

Ok, disons que le calendrier n'est pas vraiment indispensable, mais le fait même de le proposer, je me dois de le rendre le plus utilisable possible, sinon c'est inutile de proposer un truc qui n'est pas utilisable en situation réelle... non ?

Florent V. a écrit :
Yahrou a raison de dire que c'est typiquement le genre de cas où on pourra utiliser Ajax. MAIS, l'idéal est de garantir une accessibilité minimale même si Javascript est désactivé. Ce qui signifie :
- un fonctionnement de base avec PHP (et il faut cliquer six fois pour revenir six mois en arrière... ou bien utiliser une liste déroulante, hein, ça aussi c'est possible !) ;
- une surcouche Javascript (ajax) qui prend le pas sur le fonctionnement de base en PHP.

Tout à fait, c'est exactement ce que compte faire, c'est à dire que le calendrier doit fonctionner "normalement" quelque soit l'alternative technologique ajoutée pour le rendre plus fluide.

Autrement dit, le calendrier doit toujours rester opérationnel, iframe, javascript, ajax ou pas.

Florent V. a écrit :
Mais ça devient compliqué si on n'est pas développeur.
Quand on a des moyens plus modestes, on doit aller au plus raisonable, et donc au plus simple :
- puis-je simplifier mon mode de navigation entre les mois du calendrier pour que ça soit plus facilement plus utilisable, même sans Ajax, Bonuks et Omomicro ?
- dois-je fournir un moyen alternatif d'accéder à l'information ?
- est-ce que je me contente de la version accessible et pas trop compliquée à faire, même si elle peut être légèrement fastidieuse (« bien mais pas top ») ?
- etc.

Tu poses en effet les bonnes questions.

Mon niveau de compétences en développement web est pour le moins modèste, mais, tant bien que mal, j'arrive, en bataillant beaucoup, à avancer dans mon projet en découvrant des nouvelles solutions tous les jours... bref, je suis casi totalement ignorant, mais je me soigne

Sinon, j'ai déjà prévu un moyen alternatif d'accèder à l'information, avec la possibilité d'afficher une page regroupant l'ensembles des calendriers des mois d'une année entière, ce qui peut compenser un peu la lourdeur de navigation dans le calendrier, mais ce n'est pas une solution idéale, même si je ne compte pas pour autant l'abandonner.

Mais le mieux ce serait que tu visites le site de démo, tu pourras te faire une meilleure idée sur les options adoptées et les problèmes à résoudre.

Enfin, peut-être qu'une solution Ajax serait le mieux dans mon cas de figure, mais je dois absolument trouver une solution pour l'affichage lorsque les liens déclancheant le script Ajax se trouvent justement dans le contenu mise à jour par le script... bref, faut que je creuse... su tu as des pistes, je suis preneur

Merci encore Florent... à+

Bon, au vu du bouzin :

1 - Sauf erreur de ma part, le calendrier est un moyen de navigation alternatif (que pour ma part je trouve inutile, mais je connais des gens qui trouvent ça bien...), et qui dit alternatif dit : il y a un autre moyen -- qui est le moyen principal -- d'accéder au contenu, et celui-ci est donc « facultatif ». Donc : dans l'idéal, le moyen alternatif doit être accessible ; dans la pratique, si le moyen principal est accessible et le secondaire l'est moins ou pas du tout dans certains contextes, ça ne sera pas catastrophique.

2 - L'idée des pages d'index des calendriers par année est très bonne.

3 - Pas besoin d'Ajax pour gérer tout ça. On peut avoir dans un script JS externe toutes les informations pour le calendrier, et changer dynamiquement celles qui sont affichées lors d'une action de l'utilisateur. La quantité d'informations étant techniquement faible (quelques ko), ça sera sans doute plus simple que de passer par de l'Ajax... et plus rapide. Note en passant : on peut tout à fait générer le script JS en PHP (pour interroger la base de données et récupérer les infos qui vont bien).

4 - Comme le calendrier reposera sur JS, on créera le tableau HTML... en Javascript également. De sorte que si JS est désactivé, on aura juste, dans le bloc « calendrier », les liens vers les pages par années. Ce qui sera déjà pas mal.

5 - Par contre, pour réaliser correctement les points 4 et surtout le point 3 ci-dessus, il faut trouver un développeur Javascript, ou être soi-même bien versé dans les arcanes dudit langage.

Au final, et si on veut faire les choses bien, c'est un gros investissement pour quelque chose de pas forcément indispensable pour un petit site.
Modifié par Florent V. (28 May 2007 - 18:32)

Re...

Florent V. a écrit :
1 - Sauf erreur de ma part, le calendrier est un moyen de navigation alternatif (que pour ma part je trouve inutile, mais je connais des gens qui trouvent ça bien...), et qui dit alternatif dit : il y a un autre moyen -- qui est le moyen principal -- d'accéder au contenu, et celui-ci est donc « facultatif ». Donc : dans l'idéal, le moyen alternatif doit être accessible ; dans la pratique, si le moyen principal est accessible et le secondaire l'est moins ou pas du tout dans certains contextes, ça ne sera pas catastrophique.

En effet, le calendrier n'est pas le mode de navigation principal du squelette, mais il a aussi son utilité si on désire, par exemple, suivre l'évolution chronologique des contenus du site... enfin, disons que, sans être indispensable, il complète assez bien les différentes méthodes de navigation proposées :

- Thématique : les rubriques (ou catégories)
- Transversale : les mots-clés (ou tags)
- Chronologique : le calendrier
- Linéaire : la page Plan

Je vais donc le conserver, même s'il doit rester en l'état, à chaque utilisateur ensuite de l'utiliser ou pas.

Florent V. a écrit :
2 - L'idée des pages d'index des calendriers par année est très bonne.

Oui, elle n'est pas de moi, c'est un des utilisateurs qui l'a suggérée, je l'ai tout de suite adoptée, ça compensait un peu les défauts du calendrier.

Florent V. a écrit :
3 - Pas besoin d'Ajax pour gérer tout ça. On peut avoir dans un script JS externe toutes les informations pour le calendrier, et changer dynamiquement celles qui sont affichées lors d'une action de l'utilisateur. La quantité d'informations étant techniquement faible (quelques ko), ça sera sans doute plus simple que de passer par de l'Ajax... et plus rapide. Note en passant : on peut tout à fait générer le script JS en PHP (pour interroger la base de données et récupérer les infos qui vont bien).

Ha oui... ça a l'air très intéressant comme technique, seulement, je n'ai encore jamais vu fonctionner une solution de ce type, aurais-tu quelques liens me permettant de voir cette technique à l'oeuvre ? ... ou, du moins, quelques explications sur sa mise en place ?

Florent V. a écrit :
4 - Comme le calendrier reposera sur JS, on créera le tableau HTML... en Javascript également. De sorte que si JS est désactivé, on aura juste, dans le bloc « calendrier », les liens vers les pages par années. Ce qui sera déjà pas mal.

Bein, oui et non, dans ce cas je préfère conserver le calendrier à l'état actuel, moins réactif mais toujours fonctionnel.

Comme je le disais sur un post précédent, le but est de proposer quelque chose de mieux que ce qui existe actuellement, mais, le cas échéant, ne pas avoir quelque chose de moins bien, en tout cas de mon point de vue.

Florent V. a écrit :
5 - Par contre, pour réaliser correctement les points 4 et surtout le point 3 ci-dessus, il faut trouver un développeur Javascript, ou être soi-même bien versé dans les arcanes dudit langage.

Oui, j'imagine... hélas, ce n'est pas encore mon cas... mais, pour cette partie du projet, je pourrais éventuellement faire appel à des copains qui, eux, maîtrisent bien ces techniques... seulement, avant de les soliciter, je voudrais me faire une idée précise de quoi il s'agit exactement, c'est pourquoi toute piste ou lien explicatif serait le bienvenue.

Au fait, elle a un nom ou appéllation particulère cette technique ?

Florent V. a écrit :
Au final, et si on veut faire les choses bien, c'est un gros investissement pour quelque chose de pas forcément indispensable pour un petit site.

Bein, disons que si c'était uniquement pour moi, la solution actuellement présente me suffit amplement, mais certains utilisateurs m'on déjà fait la remarque, c'est un peu la raison pour laquelle je cherche à leur proposer une solution plus performante...

Voilà, en définitive je ne sais pas quelle solution je finirais par adopter, mais, en tout cas, ce topic a été vraiment très instructif pour moi... un grand merci Florent pour toutes tes infos, et aux autres aussi, vos réponses m'ont permis d'y voir un peu plus clair...

à+

Bonjour a tous,

Je reprend un peu ce sujet rapport au iframe.

Je suis entrain de faire un site web ou j'insere un forum phpbb, ce dernier s'affiche dans un iframe...

J'utilise un des scripts que vous proposez plus haut, qui permet de redimmentionner le iframe par rapport a la page charger.

Le seul probleme est que la navigation sur le forum se fait dans l'iframe et de ce fait le script javascript ne fonctionne plus car c'est uniquement OnLoad

une fois la page chargée le script ne fait plus son boulot..

pensez vous qu'il est possible que l'iframe retaille sa fenetre automatiquement par rapport au contenu qu'il affiche lors de la navigation ???

Merci de vos futurs reponses !!!

Aucune idée a ce propos !!!?

Bonjour

Apparemment sur le principe ça marche pareil, que la navigation soit dans la page contenant l'iframe (exemple proposé par Florent http://www.dyn-web.com/dhtml/iframes/height.html) ou que le menu de navigation soit dans chacune des pages appelées dans l'iframe (height1.html, height2.html, etc...). La hauteur s'adapte bien au contenu, sauf dans Safari qui affiche l'iframe en hauteur maxi quel que soit le contenu importé