Ça marche partout, sauf sur Safari !

radada · 8 Mars 2008

Bonjour à tous,

J'ai un problème complètement incroyable ! J'ai refait mon site. Il s'affiche parfaitement sur tous les navigateurs, SAUF sur Safari ! Il est en frame. Pourquoi Safari ne les supporterait pas quand ça ne pose aucun problème ailleurs ? Si quelqu'un pouvait m'aider à comprendre avant que je m'arrache tous les cheveux...

Voici le code source de ma page. Qu'est-ce qui n'est pas correct ?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<html>
<head>
<title>Musique des annees 60 et 70</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<HTML><HEAD><TITLE>rock6070.com</TITLE>
<META content="rock des annes 60 et 70" name=description>
<META lang=fr-ca
content="Yardbirds, led zeppelin, Armageddon, Keith Relf, Jimmy page, jake holmes, radio.blog, radioblog, medicine head, Jim McCarty, renaissance, musique"
name=keywords>
<META http-equiv=Content-Language content=fr-ca>
<META [email protected] name=reply-to>
<META content=Internet name=category>
<META content="index, follow" name=robots>
<META content=global name=distribution>
<META content="7 days" name=revisit-after>
<META lang=fr-ca content="Beatrice Andre" name=author>
<META content="Beatrice Andre" name=copyright>
<META content="MSHTML 6.00.6000.16608" name=GENERATOR>
<META content=http://www.rock6070.com name=identifier-url>
<META content=never name=expires>
<META content="" name=Date-Creation-yyyymmdd>
<META content="" name=Date-Revision-yyyymmdd></HEAD>
<FRAMESET border=0
frameBorder=0 frameSpacing=0 rows=142,*><FRAME scrolling=no src="logo.html" name=menuhaut><FRAME scrolling=no src="indexframe.html" width="780" height="400" name=tout></FRAMESET><noframes></noframes></HTML>

Et l'adresse du site : http://www.rock6070.com/

Merci à tous !

Béatrice

ntx · 8 Mars 2008

radada a dit:
Il est en frame. Pourquoi Safari ne les supporterait pas quand ça ne pose aucun problème ailleurs ? Si quelqu'un pouvait m'aider à comprendre avant que je m'arrache tous les cheveux...

Ca ne se fait plus les frames, utilise des div.

grumff · 9 Mars 2008

Ça c'est encore un avis bien arrêté qui a le dont de faire avancer les choses. "ça ne se fait plus", voilà encore une parfaite affirmation pour inciter les gens à coder par effet de mode plutôt qu'en utilisant leur tête.

Un frame ça a un avantage énorme qui est de ne pas faire recharger toute la page à un utilisateur quand on ne veut en rafraîchir qu'une partie. Bien sûr on peut faire ça en ajax, mais ça a les mêmes inconvénients que les frames, sinon plus et c'est plus complexe à mettre en oeuvre.
Le seul inconvénient des frames est que ça ne permet pas de mettre une page du site en favoris. Mais pour moi le problème viens plus des navigateurs qui n'ont pas évolués sur ce point depuis 15 ans, et non des frames en eux même.

Enfin bref, là vu le site je suppose que le problème est résolu ?

ntx · 9 Mars 2008

grumff a dit:
Bien sûr on peut faire ça en ajax, mais ça a les mêmes inconvénients que les frames, sinon plus et c'est plus complexe à mettre en oeuvre.

C'est pas mortel, faut pas exagérer et ça rend quand même le site beaucoup plus agréable à consulter.

Anonyme · 9 Mars 2008

Les frames (cadres) c'est bourré d'inconvénients, il n'est pas nécessaire d'utiliser ajax (tout le monde n'utilise pas javascript aussi

), on peut utiliser les includes en php avec des pseudos frames en css.

grumff · 9 Mars 2008

gloup gloup a dit:
Les frames (cadres) c'est bourré d'inconvénients, il n'est pas nécessaire d'utiliser ajax (tout le monde n'utilise pas javascript aussi ), on peut utiliser les includes en php avec des pseudos frames en css.

L'article que tu cites est plutôt orienté et la plupart des points sont largements exagérés. Et le fait d'avoir des inconvénients ne signifie pas qu'ils soient mauvais dans n'importe que contexte. Un include php n'a rien à voir, puisqu'il n'empêche pas le rechargement des données, on perd les deux principaux intérêts des cadres. Le deuxième étant le fait de permettre de conserver des en-têtes, pieds de page et menu pour quelqu'un qui n'est pas développeur. Je suppose qu'on est dans ce cas d'ailleurs.

ntx : je dis pas que l'ajax n'est pas bien, je ne risque pas de dire une ânerie pareille, je dis juste que ça n'est pas une bonne solution pour remplacer des cadres.

Anonyme · 9 Mars 2008

Orienté non, Denis Boudreau est une pointure dans le domaine et je ne trouve pas que ce qu'il dit est exagéré. La preuve : les sites fonctionnant avec des frames on quasiment tous disparu. Il y a bien une raison non?

Le but des includes php est une façon assez simple de maintenir des éléments apparaissant sur toutes les pages dans des fichiers séparés, on ne peut pas dire que l'on fait de la programmation quand on fait deux ou trois includes dans une page, je pense que c'est accessible aux débutants.

Il y avait aussi jadis les includes apache, mais je ne sais pas si ce système est toujours activé chez les hébergeur.

fredmac75 · 10 Mars 2008

grumff a dit:
...

Un frame ça a un avantage énorme qui est de ne pas faire recharger toute la page à un utilisateur quand on ne veut en rafraîchir qu'une partie

Ce qui est justement l'un des l'objectif du développement en XHTML : la séparation du fond et de la forme. La css permet justement de n'avoir pas à recharger tous les éléments "graphique" contenu dans la page par l'utilisation du cache du navigateur de l'utilisateur. L'objectif est bien le même, mais les moyens pour y parvenir diffèrent.

Si les navigateurs n'ont pas évolués depuis 15 ans cela s'inscrit plus largement dans le fait de favoriser un développement XHTML + CSS, ne faisant pas appel aux frames.

Cela me semble logique si l'on souhaite favoriser ce type de développement, de ne pas continuer à travailler sur l'implémentation des frames.

De plus, le couple XHTML + CSS, est-il utile de le rappeler, envisage l'utilisation d'internet sur autre chose qu'un écran d'ordinateur.

Enfin, concernant les frames, je reviens sur une question non abordée qui est celle du référencement. Quelle URL faire pointer sur quel contenu ?

grumff · 10 Mars 2008

gloup gloup a dit:
Orienté non, Denis Boudreau est une pointure dans le domaine et je ne trouve pas que ce qu'il dit est exagéré. La preuve : les sites fonctionnant avec des frames on quasiment tous disparu. Il y a bien une raison non?

Le but des includes php est une façon assez simple de maintenir des éléments apparaissant sur toutes les pages dans des fichiers séparés, on ne peut pas dire que l'on fait de la programmation quand on fait deux ou trois includes dans une page, je pense que c'est accessible aux débutants.

Il y avait aussi jadis les includes apache, mais je ne sais pas si ce système est toujours activé chez les hébergeur.

L'article est exagéré dans le sens où il n'indique pas que la quasi totalité des points qu'il dénonce peuvent être contournés facilement. Et encore une fois, je n'aime pas cette façon de dire qu'une méthode est mauvaise juste parce qu'elle est inadaptée à certains cas, aussi nombreux soient-ils.

Et non un include php n'est pas accessible aux débutants. C'est peut-être simple en soit, mais ça demande d'avoir une serveur apache et php d'installé, ce qui complique pas mal les choses. Et ce point est sans doute le plus important, vu qu'effectivement les caches des navigateurs évitent le rechargement des données (dans la plupart des cas... pas tous).

Pour le référencement il en est questions dans l'article cité, c'est un des points que je trouve exagéré, évidemment un moteur de recherche pointera sur un seul cadre, ce qui peut se résoudre à l'aide d'un javascript de 2 lignes, mais qui n'est pas forcément indispensable, l'utilisateur qui fait une recherche n'a pas forcément besoin des autres cadres et de pouvoir naviguer dans le site, la page d'une rubrique peut être conçue pour être visualisée indépendamment du site. Encore une fois, c'est une question de contexte.

Mais on est bien d'accord, quand a le temps et les compétences, du xhtml/css et des include côté serveur, c'est souvent mieux (encore que le xhtml, c'est discutable).

Anonyme · 10 Mars 2008

grumff a dit:
L'article est exagéré dans le sens où il n'indique pas que la quasi totalité des points qu'il dénonce peuvent être contournés facilement. Et encore une fois, je n'aime pas cette façon de dire qu'une méthode est mauvaise juste parce qu'elle est inadaptée à certains cas, aussi nombreux soient-ils.

Là on n'est déinfitivement pas d'accord, pour moi les frames c'est fini, on en trouvera peut-être encore dans certains intranet mais c'est mort. Définitivement. Et si c'est pour apprendre à une débutante à faire son site, autant lui apprendre directement les bonne méthodes.

Comme fredmac75 l'a dit, il est impossible avec les cadres de séparer le contenu de la forme. Comment tu fais pour visualiser ton site en frames sur un gsm, une console de jeux? Et ne me dis pas que c'est négligeable car s'il y a actuellement un milliard d'ordinateur connectés à internet, les gsm sont 4 à 5 milliards pouvant potentiellement tous être connectés.

grumff a dit:
Et non un include php n'est pas accessible aux débutants. C'est peut-être simple en soit, mais ça demande d'avoir une serveur apache et php d'installé, ce qui complique pas mal les choses. Et ce point est sans doute le plus important, vu qu'effectivement les caches des navigateurs évitent le rechargement des données (dans la plupart des cas... pas tous).

C'est vrai on ne sait pas si notre amie va héberger son site chez un hébergeur offrant php mais hormis certains FAI, beaucoup offre cette possibilité.

grumff a dit:
Pour le référencement il en est questions dans l'article cité, c'est un des points que je trouve exagéré, évidemment un moteur de recherche pointera sur un seul cadre, ce qui peut se résoudre à l'aide d'un javascript de 2 lignes, mais qui n'est pas forcément indispensable, l'utilisateur qui fait une recherche n'a pas forcément besoin des autres cadres et de pouvoir naviguer dans le site, la page d'une rubrique peut être conçue pour être visualisée indépendamment du site. Encore une fois, c'est une question de contexte.

Tu imagines l'entretien d'un tel site? C'est un cauchemar!

grumff a dit:
Mais on est bien d'accord, quand a le temps et les compétences, du xhtml/css et des include côté serveur, c'est souvent mieux (encore que le xhtml, c'est discutable).

Euh non, c'est la dernière évolution de html qui s'intègre bien avec toutes les technologies xml actuellement disponibles. Et puis xhtml strict 1.0, c'est génial pour apprendre car on est obligé de fermer les balises et la syntaxe xml interdit les à peu près.

grumff · 10 Mars 2008

gloup gloup a dit:
Là on n'est déinfitivement pas d'accord, pour moi les frames c'est fini, on en trouvera peut-être encore dans certains intranet mais c'est mort. Définitivement. Et si c'est pour apprendre à une débutante à faire son site, autant lui apprendre directement les bonne méthodes.

Non on ne sera jamais d'accord. Aussi faibles que soient les cas dans lesquels une technologie est la plus adaptée, je conçois pas qu'on la décrète comme à proscrire à tous prix pour la simple raison que quelqu'un aussi connu et respectable soit-il décrète que c'est passé de mode.
Il y a des tas de contextes dans lesquels les inconvénients des frames n'ont pas la moindre importance. Quand tu développes une applications professionnelles destinée à un nombre réduit d'utilisateurs par exemple, et qui ne sera dispo que sur un réseau locale, le référencement c'est le dernier de tes soucis, la séparation contenu/forme n'a aucune importance, personne ne doit linker une page spécifique en favoris parce qu'on souhaite que les utilisateurs consultent les infos sur la page d'accueil de l'application. Curieuse coïncidence d'ailleurs je suis en train de reprendre une appli de ce genre au boulot, dont la cible est IE5 ou 6 sous windows2000/XP. Alors, tu m'expliques où sont les inconvénients dans ce cas ?

Comme fredmac75 l'a dit, il est impossible avec les cadres de séparer le contenu de la forme. Comment tu fais pour visualiser ton site en frames sur un gsm, une console de jeux? Et ne me dis pas que c'est négligeable car s'il y a actuellement un milliard d'ordinateur connectés à internet, les gsm sont 4 à 5 milliards pouvant potentiellement tous être connectés.

Parfois il faut aussi que les périphériques mobiles s'adaptent un peu d'eux même, l'iphone l'a prouvé, c'est le seul GSM sur lequel internet est véritablement utilisable, et on l'a prouvé vu qu'il surpasse déjà tous les autres téléphones du marché en terme de présence sur internet. Et sur lui frame ou pas, n'importe quel site s'affiche correctement. C'est le seul mobile qui ait réussi à me faire douter du principe selon lequel un téléphone, ça sert à téléphoner •|

Les périphériques mobiles sont certes nombreux à pouvoir "théoriquement" se connecter, mais le fait est qu'ils ne le font pas (sauf 1), et que ce ne sont pas les sites web qui sont en cause.
Même un site parfaitement bien conçu en xhtml et css, s'il est prévu pour une résolution de 1024 pixels de larges, il sera invisualisable sur un mobile, sauf si le développeur a fait des devs spécifiques pour l'adapter, ça peut être une feuille de style, mais ça peut aussi être géré côté serveur par un modèle mvc bien conçu, et là on se rend totalement indépendant des séparations contenu/forme, du moins elles sont pas faites au niveau de l'affichage. Pour tous les sites dynamiques le contenu c'est avant tout des données dans des structures de données, que ce soit en php (quoique

), en Java ou en c#. Et du coup on n'est pas obligés de séparer les choses deux fois...
Bref tout ça pour dire que même cette séparation contenu/forme en xhtml/css elle est parfois à relativiser.

C'est vrai on ne sait pas si notre amie va héberger son site chez un hébergeur offrant php mais hormis certains FAI, beaucoup offre cette possibilité.

Tu regardes que la partie émergée de l'iceberg, ça suppose aussi que pour développer le site il faut avoir un serveur apache sur la machine de dev, être capable de l'installer et le configurer, savoir où placer les fichiers. Devoir à chaque fois taper une adresse dans le navigateur au lieu de visualiser le site en double-cliquant sur un .html, c'est forcément des contraintes différentes. Ça te parait peut-être naturel comme ça me l'est aussi, mais je côtoie sans arrêt des gens pour qui c'est un calvaire.

Tu imagines l'entretien d'un tel site? C'est un cauchemar!

Précise, je vois pas en quoi. Il me semble que même la doc php était sous forme de cadre il n'y a pas si longtemps (je peux me tromper). Et dans un cas comme ça le cadre qui décrit une fonction n'a pas besoin du reste du site pour nous fournir les informations recherchées, je vois pas en quoi ce serait un cauchemar à maintenir, au contraire.

Euh non, c'est la dernière évolution de html qui s'intègre bien avec toutes les technologies xml actuellement disponibles. Et puis xhtml strict 1.0, c'est génial pour apprendre car on est obligé de fermer les balises et la syntaxe xml interdit les à peu près.

Le XHTML c'est du XML avec tous les avantages que ça implique oui. Et les inconvénients !
Ça signifie que n'importe qui peut parser facilement les données que tu fournis en rentrant simplement un x-path, ce qui n'est pas forcément un but recherché quand tu tiens à un copyright...

Anonyme · 10 Mars 2008

Bon je crois que je vais arrêter là, on a pas mal fait dévier le sujet de départ et je crois qu'on pourrait encore se prendre la tête pendant des heures

grumff · 11 Mars 2008

gloup gloup a dit:
je crois qu'on pourrait encore se prendre la tête pendant des heures

exact
pour le sujet je m'inquiète pas trop, le problème était apparemment résolu.

Ça marche partout, sauf sur Safari !

radada

Membre actif

ntx

Membre vénérable

grumff

Membre expert

ntx

Membre vénérable

Anonyme

Invité

grumff

Membre expert

Anonyme

Invité

fredmac75

Membre expert

grumff

Membre expert

Anonyme

Invité

grumff

Membre expert

Anonyme

Invité

grumff

Membre expert

Sujets similaires