[Résolu] Galerie photo à l'aide de frames

Bonjour,

Voilà... De nombreux débutants souhaitent obtenir des galeries photos avec une image qui se met à jour lorsqu'on clique sur une des vignettes. Un bon nombre de solutions s'effectuent, en javascript ou php mais systématiquément, on embrouille l'esprit du néophyte qui a déjà bien assez de mal comme çà avec le html et les css.

Par ailleurs, un grand nombre d'entre eux se lancent dans les frames sans connaitre les comportements problématiques qui en découlent.

Aussi, j'ai tenté d'apporter, dans la mesure de mes moyens, une solution à ces deux problèmes lors d'une question de ce type. Je me suis servi des frames en complément des pages normales et non pour tout le site.

Voici ce que j'ai fait:galerie photo

Pour ceux qui le souhaitent, la totalité des fichiers se trouve dans un dossier zip de 71ko.

Mes impératifs étaient:

- d'utiliser les frames
- d'avoir des pages valides,accessibles, référencables, imprimables,...
- de faire ma galerie uniquement avec les langages xhtml/css
- d'introduire certaines bonnes pratiques.
- de donner la possibilité au débutant de retoucher plus facilement le code.

J'aimerais avoir votre avis sur cet exemple car je compte, si celà vous semble correct, faire de cet essai une sorte de tutoriel pour former mes petits gloomiths en douceur. Toutes critiques et autres suggestions sont les bienvenues... Je repasse cette nuit pour voir l'ampleur des dégâts.

Merci.
Modifié par koala64 (15 Aug 2005 - 09:09)

Salut,

désolé mais là je ne vois pas l'intérêt.

Pour quoi tout simplement ne pas faire :

page1.html correspondant à la première photo grande taille =

<div>
Toutes les vignettes
</div>

<div>
<img src="bigphoto_1.jpg" alt="" />
</div>

page2.html correspondant à la deuxième photo grande taille =

<div>
Toutes les vignettes
</div>

<div>
<img src="bigphoto_2.jpg" alt="" />
</div>

etc... etc ...

En ce qui concerne le temps de chargement et la souplesse c'est bon puisque toutes les vignettes sont chargées dans le cache du navigateur dès le première page.

En ce qui concerne la gestion de la liste des vignettes, he bien on peut quand même dire qu'il y a php et php, et que :

page1.php correspondant à la première photo grande taille =

<div>
<?
{include ('vignettes.inc');}
?>
</div>

<div>
<img src="bigphoto_1.jpg" alt="" />
</div>

page2.php correspondant à la deuxième photo grande taille =

<div>
{include ('vignettes.inc');}
</div>

<div>
<img src="bigphoto_2.jpg" alt="" />
</div>

etc ... etc ...
avec contenu de vignettes.inc = toutes les vignettes

résoud avec un code vraiment simple et léger cette deuxième question.
Modifié par clb56 (12 Aug 2005 - 16:58)

Salut,

Je n'ai pas été bien clair...

L'intérêt n'est pas de faire une galerie photo. Mon sujet principal reste les frames. Je suis tout à fait d'accord que la méthode que tu me montres est bien plus simple et qu'elle comporte quelques avantages non négligeables. Néanmoins, çà ne respecte pas ma contrainte. Pour moi, le principal soucis n'est pas de montrer l'absence d'intérêt des frames mais bien comment procéder avec...

Je pense qu'il existe un bon nombre d'articles traitant du sujet mais la plupart ne font qu'indiquer les problèmes sans donner de solutions quant au bon emploi de cette technique. Il me semble en effet bien difficile de trouver un article montrant comment concevoir correctement avec des cadres sur le web...

C'est pourquoi je trouve important d'ajouter une pierre à l'édifice... J'ai pris une galerie photo comme exemple, mais çà aurait pu être tout autre chose...

Bonjour,

Quelques éléments d'accessibilité à préciser :

- Utiliser systématiquement l'attribut [i]title[/b] des éléments frames, pour indiquer le rôle de chaque cadre ("menu: les vignettes des photographies", "photographie grande taille"). Il sera "lu" à ou par l'utilisateur.

- L'attribut [i]name[/b] ne sert pas à indiquer à l'utilisateur le rôle des cadres, mais à donner aux scripts un moyen de viser et de manipuler les cadres. Il ne doit pas comporter d'espace. Il doit cependant être aussi explicite que possible (navigation, contenu) car d'anciens outils qui ne savent pas exploiter le title se serviront du name.

- Donner à l'élément [i]title[/b] de chaque document frame un intitulé plus complet, identifiant brièvement le site et le document précis, permettant à l'utilisateur de "situer" chaque document, quelque-soit la manière dont il y sera arrivé.

- L'attribut [i]longdesc de frame[/b] ne sert pas à y placer une description, mais l'url d'un autre document contenant la description des relations entre les différents frames. Son usage est très limité, car il est très peu implémenté. Donc, ne pas se reposer uniquement sur lui, et s'appuyer plutôt sur l'attribut title, voire éventuellement en plus sur un lien <a...> placé dans chaque frame.

- Utiliser l'élément noframe pour donner plus directement l'information : le lien vers un plan de site complet plutôt qu'une liste en page d'accueil, ou directement la liste complète des liens (explicites) vers les photographies grande taille.

koala64 a écrit :
Il me semble en effet bien difficile de trouver un article montrant comment concevoir correctement avec des cadres sur le web...

Un large éventail de solutions permettant d'éviter les frames est en effet aujourd'hui à la porté de tous : technologie serveur PHP d'accès quasi-gratuit sur la plupart des solutions d'hébergement, système de gestion de contenu client, éditeurs intelligent facilitant les opérations sur des lots de fichiers, etc. Ceci explique un certain désintérêt pour les frames, qui ne sont plus une solution utile dans la plupart des cas, y compris pour des webmestres "amateurs" utilisant des solutions "légères" (au sens de technicité réduite et de coût minimal, pas au sens péjoratif bien-sûr).

D'autre part, même si les outils d'accessibilité ont progressé dans leur gestion des frames, les problèmes de fond demeurent : cassure de l'historique chez l'utilisateur, pas de possibilité d'atteindre un jeu précis de cadre grâce à une URI.

Il est finalement tout aussi complexe, sinon plus, de limiter l'inaccessibilité des frames et leurs autres défaut (référencement) que d'apprendre à utiliser une autre solution qui n'aura pas ces défauts


Il reste donc important de limiter autant que possible le recours à cette technique, en attendant que ces problèmes soient éventuellement résolus par de nouvelles implémentations comme X-frames.
Modifié par Laurent Denis (13 Aug 2005 - 06:54)

Bonjour Laurent,

Tout d'abord un grand merci pour la réponse que tu viens de me donner...

Je vais donc apporter les corrections nécessaires puis ajouter une mention complémentaire fondée sur la deuxième partie de ton post.

De bon matin, Laurent Denis a écrit :
Un large éventail de solutions permettant d'éviter les frames est en effet aujourd'hui à la porté de tous...

Je ne placerais ce sujet en résolu que d'ici 2, 3 jours des fois que quelqu'un souhaite encore réagir.

D'ailleurs, à ce propos, auriez-vous un exemple d'un cas où les frames peuvent être utiles?

Bonne journée à tous les deux.

Je suppose que si les frames font toujours parties des spécifications, c'est qu'il doit bien y avoir une raison mais laquelle? J'ai vu que celles-ci n'auraient plus lieu d'être si le xml continu sa percée... Enfin, je n'ai pas bien compris pourquoi vu que je n'y connais rien.

koala64 a écrit :
Je suppose que si les frames font toujours parties des spécifications, c'est qu'il doit bien y avoir une raison

Les "spécifications", élaborées par les acteurs réels du web, y regardent nécessairement à deux fois avant de rompre la compatibilité avec l'existant (d'où l'intégration dans HTML3.2 de très nombreux éléments problématiques, reconduits nécessairement dans HTML4.0 et 4.01, puis XHTML1.0.). Les ruptures éventuelles induites par XHTML2.0 sont un bon exemple du côté problématique de ces incompatibilités éventuelles : elles sont très limitées, mais suscitent déjà des hurlements.

On ne peut pas, du jour au lendemain, annuler purement et simplement un format standard en disant : "on s'est trompé". On ne peut que développer de nouveaux standards et de nouveaux outils plus appropriés, si possible et si nécessaire, et encourager à la transition de l'un à l'autre pour les nouveaux contenus et le plus possible des anciens contenus.

Une spécification HTML, même s'il s'agit d'une spécification ancienne, reste assumée par le W3C (et donc l'industrie du Web), et validante : dès lors que les frames ont été à un moment donné validés par une des normes HTML, celle-ci reste valable. En ce sens, on peut toujours aujourd'hui faire du HTML2.0 (sans frame, celui-là ) si on le souhaite, tant qu'il restera des navigateurs qui l'implémentent (ce qui n'est pas très problématique).

Enfin, le concept à la base des frames n'est pas écarté (quoique devenu largement hors-sujet), comme en témoigne X-frames.
Modifié par Laurent Denis (13 Aug 2005 - 10:46)

koala64 a écrit :


Je n'ai pas été bien clair...

Effectivement

Ton sujet principal étant énoncé au mieux dans le deuxième paragraphe.

J'espère avoir été, pour ma part, assez clair dans ce que j'ai exposé. Car cela illustre assez bien, je trouve, "in concreto" et sur l'exemple que tu as toi même choisi ce qu'indique Laurent Denis (je me permet de condenser le propos).

Laurent Denis a écrit :

Un large éventail de solutions permettant d'éviter les frames est en effet aujourd'hui à la porté de tous ...

... y compris pour des webmestres "amateurs" utilisant des solutions "légères" (au sens de technicité réduite et de coût minimal, pas au sens péjoratif bien-sûr).

Modifié par clb56 (13 Aug 2005 - 10:53)