Discussion :

[clb56]

Le sujet s'égare.

Non, rien de cela n'est sans implications et il s'agit d'être très critique et prudent.

La question n'est pas seulement

Création d'un site avec ou sans frame ?

Mais:

Création d'un site avec ou sans frame pour de mauvaises raisons ou pour des considérations inutiles...

On peut aussi utiliser une solution assez propre qui est les include() en PHP...

Non, tout sauf la solution de l'include php quand la question est celle des frame, les choses sont bien assez embrouillées comme ça.

Il est indispensable de tenir compte du fait que les débutants ne saisissent pas du tout ce que sont techniquement les frames et ce que cela implique et encore moins les include php et ce que cela signifie (composition coté serveur avant envoie coté client notamment).

[Barsy]

Depuis le début, j'entends comme solution pour parer aux frames de faire un 'include()' en php...

Je ne vois pas le rapport... déjà parce que les frames sont côté client et le php côté serveur et que le langage serveur peut ne pas être du php (ça peut-être n'importe quoi en fait... même du C) alors que les frames elles sont faite en HTML qui est le langage côté client.

Pour ce qui est du site multi-onglet, je trouve ça assez moche... d'une part parce que tous les navigateurs ne gèrent pas le multi-onglet et ensuite parce que les sites qui ouvrent des onglets à chaque fois que l'on clique sur un lien, ça a tendance à polluer le navigateur... Mais comme le dit Er3van, tout n'est qu'un choix d'implémentation.

Les questions qu'il faut se poser dans le choix d'une solution c'est : combien de temps ça va me prendre pour le faire et pour quel résultat ? (penser à l'utilisateur final avant tout)

[Er3van]

Dans ce cas pense par exemple aux malvoyants pour qui un site en frame est inaccessible.

Alors, y a-t-il plus de malvoyants que de personnes qui détestent les sites multi onglets, c'est une question à laquelle je ne saurais répondre...

[clb56]

Dans ce cas pense par exemple aux malvoyants pour qui un site en frame est inaccessible.

Mmmm ce n'est pas absolument vrai non plus, un site peut être réalisé en frame (doctype frameset) et être accessible.

[Erwan31]

Mmmm ce n'est pas absolument vrai non plus, un site peut être réalisé en frame (doctype frameset) et être accessible.

Tiens d'ailleurs on peut se demander comment se comporte un lecteur d'écran
avec des frames même si pour ma part je n'utilise jamais de frame.

[Barsy]

J'avoue ne m'être jamais posé la question des lecteurs d'écran quand je développe un site (d'une part parce que je ne connaissais pas l'existence de ces engins et d'autre part parce qu'on ne m'a jamais rien demandé à ce sujet dans les specs...).

Après, j'imagine qu'avec la sortie prochaine... (enfin, future) du HTML 5.0, les frames disparaitront (en laissant la place à une alternative) ou s'amélioreront

[Erwan31]

J'avoue ne m'être jamais posé la question des lecteurs d'écran quand je développe un site (d'une part parce que je ne connaissais pas l'existence de ces engins et d'autre part parce qu'on ne m'a jamais rien demandé à ce sujet dans les specs...).

Tu n'es pas allé sur les bonnes specs Il y a aussi des recommandation pour l'accessibilité des contenus (WCAG 1.0) et maintenant les WCAG 2.0 passées récemment à l'état de recommendation.

Non, tout sauf la solution de l'include php quand la question est celle des frame, les choses sont bien assez embrouillées comme ça.

Il est indispensable de tenir compte du fait que les débutants ne saisissent pas du tout ce que sont techniquement les frames et ce que cela implique et encore moins les include php et ce que cela signifie (composition coté serveur avant envoie coté client notamment).

Tu généralises un peu là et je ne suis pas certain que la compréhension du fonctionnement côté serveur des includes soit une condition indispensables à leur utilisation.
Certe la frame est une technique d'intégration très différente de l'include et ce sont 2 choses très différentes mais
d'un point de vue pragmatique, tu ne peux pas nier que les includes
sont bien commodes lorsqu'il s'agit de centraliser un contenu répété sur plusieurs pages.

[thebeps]

Autre aspect négatif des frames...

Le référencement du contenu des frames... est quasi nul !

[SpaceFrog]

sans !

[popo]

Je suis tout à fait d'accord. Les frames sont à proscrire et à n'utiliser que si cela est vraiment nécessaire.

Si tu ne veux pas que les éléments qui ne bougent pas se rechargent (bannière, menu, header, footer, etc.), il te suffit de les définir dans des fichier séparés et de les appelés avec un include (PHP). Ainsi, il seront enregistrés dans le cache et se rechargeront immédiatement. Il n'y a rien de compliqué là dedans puisque le code que tu met dans ton fichier externe est le même que celui que tu aurais mis si tu ne l'avais pas fait.

En ce qui concerne l'utilisation d'une bande sonore dans un site, cela bon pour un site amateur qui ne tient pas à ce que les gens reviennent. Pour être clair, les gens n'aiment pas se taper du son en boucle pendant qu'il surfent, tout comme il n'aime pas lire du texte sur un fond foncé car cela leur abime les yeux.

De plus, un site fait avec des frames est très mal référencé. J'en ai fait l'expérience.

[thebeps]

En ce qui concerne l'utilisation d'une bande sonore dans un site, cela bon pour un site amateur qui ne tient pas à ce que les gens reviennent. Pour être clair, les gens n'aiment pas se taper du son en boucle pendant qu'il surfent, tout comme il n'aime pas lire du texte sur un fond foncé car cela leur abime les yeux.

A fond... Et je laisse imaginer l'effet si en plus tu n'aimes pas la musique de fond !