On dit souvent que les frames c'est pas bien ...
Pourtant, c'est souvent le moyen le plus simple pour quelqu'un qui veut maintenir son site facilement. En effet, si on veut avoir un menu de navigation sur toutes les pages de son site, c'est très pratique.
Mes cela pose d'autres problèmes.
On a donc une solution (la seule que je conaisse en ce moment): le PHP out tout autre language de script coté serveur. Mais:
- Pour envisager quelquechose comme le PHP, il faut deja connaître les bases de l'HTML
- Il faut un hébergeur compatible
J'ai souvent imaginé d'autres solutions. Malheureusement qui ne sont pas mises en place:
- Une balise ou encore <?include src="" ?>
- que la balise soit plus utilisée. On pourrait par exemple immaginer que lorsque Mozilla rencontre un <link rel="index" ... />, on ait le paneau de navigation (à droite) qui s'ouvre avec la page indiquée ...
Je pense que de telles solutions pourraient faciliter les choses. D'autant que:
- Moins de données à télécharger: on ne télécharge qu'une seule fois le sommaire
- Le sommaire ne figure plus dans le document lui même ce qui peut être très bien pour tout les navigateurs texte.
Personellement, je trouve que les menus n'ont rien à faire dans les documents fournis à l'utilisateur. Car notament, lorsqu'il imprimme la page, il n'en a plus rien a faire.
Voila mes pensées autour de 5-6h du matin ...
Mildred
Journal Remplacer les frames
22
août
2004
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Remplacer les frames
Posté par Mildred (site web personnel) . Évalué à 3.
Par exemple, on ne trouve pas le sommaire du W3C dans les recommandations.
[^] # Re: Remplacer les frames
Posté par plagiats . Évalué à 3.
[^] # Re: Remplacer les frames
Posté par Obsidian . Évalué à 5.
Pour la place du sommaire dans le document, cela se discute. Certes, il ne fait pas partie de l'information liée au lien que tu as employé (d'autant qu'il est répété sur toutes les pages), mais si on reprend l'exemple de l'impression, l'utilisateur voudra peut-être avoir des enêtes et pieds de page sur son papier, alors qu'ils sont complètements inutiles à l'écran. Il en reste que ceux-ci devront bel et bien être spécifiés par la page HTML. Dans le même esprit, une personne dont la vision est bonne n'a que faire de modules « aural » par exemple, alors qu'ils sont pratiquement nécessaires pour un non-voyant.
Tout cela pour dire qu'un document HTML doit contenir toutes sortes d'informations qui peuvent être utiles à l'utilisateur dans le contexte qu'il a choisi en suivant une URL. C'est ensuite aux CSS de moduler la présentation - voir faire carrément disparaitre - les différentes sections du document en fonction de l'environnement de travail.
Enfin, si cela te saoule (et je le comprends) de réinsérer un même sommaire dans chaque page et de tous les maintenir par la suite, tu peux utiliser <iframe>. Le problème de référencement sera le même, mais au moins ton iframe est soumis aux CSS et se trouve à l'intérieur de la structure de ton document, pas autour.
[^] # Re: Remplacer les frames
Posté par Mildred (site web personnel) . Évalué à 1.
Mais c'est un regret de ne pas avoir un système (une simple balise <link) qui permette facilement de faire référance à un menu pour:
- éviter les frames
- éviter d'avoir a télécharger toujours le même menu mais incorporé par SHTML ou PHP
Et par exemple, lorsque X ne fonctionne plus, je pense que ce serait beaucoup mieux sous lynx (je sais, il y a links et w3m)
[^] # Re: Remplacer les frames
Posté par Obsidian . Évalué à 2.
La syntaxe est la suivante:
<iframe src="l'url de ta page">
Cela créé une division à l'intérieur de ta page et pas plusieurs cadres indépendants. Essaie, c'est probablement ce que tu cherches à faire.
[^] # Re: Remplacer les frames
Posté par plagiats . Évalué à 7.
En general un menu mis en forme est une liste. Il peut donc choisir de cacher l element [ul id="menu"]. Ca permet d eviter les div inutiles.
# - Moins de données à télécharger
Posté par plagiats . Évalué à 7.
Je crois comprendre ce que tu veux dire mais un menu mis en forme grace a une feuille de style c est juste du texte. Quelques caracteres, peut etre une vingtaine selon ton menu, bref pas plus que une phrase.
Tandis que la bidouille que tu proposes va faire inserer du gros code de partout et c est mal.
Avoir le menu dans chaque page me parait etre une bonne chose: l utilisateur est sur de pouvoir naviguer. Et comme le dit un commentaire plus haut, avec le media "print" il te suffit de le cacher.
http://www.openweb.eu.org/articles/finir_cadres/(...)
http://www.alsacreations.com/articles/frames/(...)
http://www.openweb.eu.org/articles/css_impression/(...)
[^] # Re: - Moins de données à télécharger
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
dans l'en tête, mettre une balise de type
<link rel="stylesheet" type="text/css" href="print.css" media="print" />
ensuite tu crées un
<div class="NoPrint">
- le
- joli
- menu
- avec les bonnes balises et tout
</div>
et dans ton fichier print.css tu mets :
.NoPrint{display:none;}
il y a au moins cinq autres manières de faire ça, mais j'aime bien celle là.
[^] # Re: - Moins de données à télécharger
Posté par Mildred (site web personnel) . Évalué à 1.
Quelle bidouille ?
je remet juste en question le menu incorporé dans la page
# PHP... pas forcément
Posté par Yusei (Mastodon) . Évalué à 9.
Le problème du PHP c'est qu'il faut un hébergeur qui le propose, et que ça fait effectuer des calculs en plus au serveur web alors que ce n'est pas toujours nécessaire. L'autre solution, c'est les langages de script "côté auteur". Ça peut être du PHP ou n'importe quel autre langage qui propose une fonction include, comme cpp ou m4, et il suffit de générer du HTML lors du transfert du site vers l'hébergeur. Un exemple de comment je fais moi avec m4 ici:
http://yusei.ragondux.com/informatique_documentation_automatiser_m4(...)
Bon c'est un peu du bricolage, parce que c'est surtout un tutorial sur m4 et make, plutôt qu'un truc sérieux, mais c'est déjà assez efficace, et il doit exister des systèmes plus complet, j'en avais vu un en perl une fois qui semblait pas mal.
[^] # Re: PHP... pas pas forcément ;)
Posté par kd . Évalué à 4.
Sinon, pourquoi est-ce que personne ne pense à utiliser php lui-même ?
Il suffit d'écrire les fichiers du site comme si on faisait un site dynamique. On utilise un répertoire séparé ou se trouve les résultat de la "compilation" par php. Ce répertoire sera celui qu'on mettre sur le serveur web qui ne sait donner que des pages statiques.
Pour aider, on peut écrire un Makefile (vive la puissance UNIX !).
Je ne m'y connais pas en Makefile, mais une petite règle pour qu'il comprenne quoi faire avec les fichiers à l'extension .php et c'est déjà beaucoup plus simple.
* Par exemple :
Le répertoire site_dev contient :
. entete.inc.php
. mapage1.php
. mapage2.php
. site_html/
mapage1.php et mapage2.php font appel à entete.inc.php via un include pour écrire le menu.
site_html
Il suffit de faire un
$ php mapage1.php > site_html/mapage1.php.html
pour avoir la page statique correspondante.
Pour le Makefile (que je place dans site_html) simplifié, c'est à dire sans une règle spécifique à php, ça donne grosso modo ça :
mapage1.php.html: ../mapage1.php ../entete.inc.php
php ../mapage1.php > mapage1.php.html
Avec une règle appropriée, il n'y a même plus besoin de la deuxième ligne qui est fastidieuse à écrire à chaque fois.
Ça, c'est la méthode qui devrait fonctionner facilement pour un petit site. Personnellement, celle que j'utilise est la suivante :
Installation de Apache+PHP sur ma machine sur laquelle je développe le site.
Il me suffit de faire un wget avec les options qui vont bien pour faire un miroir du site web (contenu statique).
La commande que j'utilise (certainement à adapter et man wget pour plus de précision) est :
$ wget -rpkE --quiet http://127.0.0.1(...)
On se retrouve alors avec un site avec que des pages html qu'on peut mettre sur le serveur de son hébergeur. Pour cette phase, j'utilise sitecopy. C'est un petit utilitaire très utile qui permet d'uploader seulement les fichiers qui ont changé. Très utile je vous dis ! :)
Voilà, c'est cette dernière méthode que j'utilise pour ma page perso : perso.wanadoo.fr/kdntl/kd_at_aiguebelle (je ne mets pas le "http://" pour pas qu'il y ait des râleurs qui me disent que je veux augmenter mon googlerank ;)
[^] # Re: PHP... pas pas forcément ;)
Posté par gros_rouge . Évalué à 2.
« On se retrouve alors avec un site avec que des pages html qu'on peut mettre sur le serveur de son hébergeur. Pour cette phase, j'utilise sitecopy. C'est un petit utilitaire très utile qui permet d'uploader seulement les fichiers qui ont changé. »
Make (encore lui) et ftp sont tes amis. Dans la conclusion de son tuto, Yusei proposait justement de traiter cette partie. Est-ce toujours d'actualité Monsieur Yusei ? ;)
Fab.
Un autre article sur le sujet (avec M4) : http://www.linuxfocus.org/Francais/September1999/article111.html(...)
[^] # Re: PHP... pas pas forcément ;)
Posté par Yusei (Mastodon) . Évalué à 3.
Oui, si je trouve le temps de le faire... Le script que j'utilise génère la liste des fichiers qui ont été changés lors du "make", donc il est assez facile d'utiliser cette liste pour faire ensuite une mise à jour sélective avec lftp... Faut juste que je me motive pour rédiger ça ;-)
[^] # Re: PHP... pas forcément
Posté par Krunch (site web personnel) . Évalué à 4.
Website META Language http://thewml.org/(...)
Exemple: http://krunch.servebeer.com/~krunch/src/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Server Side
Posté par Infernal Quack (site web personnel) . Évalué à 6.
http://httpd.apache.org/docs/howto/ssi.html(...)
Par contre je ne sais pas si c'est activé chez les FAI
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Server Side
Posté par Mildred (site web personnel) . Évalué à 1.
# D'autres possibilités
Posté par Cali_Mero . Évalué à 6.
Tu sais, y'a eu des dizaines de milliers de personnes ces dernières années qui ont eu ce problème. Et vu la très faible proportions de sites en frames qu'on peut rencontrer en surfant sur le net, il faut croire que ce n'est pas si pratique que ca. explication :
- Les frames créent une séparation totale entre les différents morceaux de ton contenu. Elles gênent le référencement (à ce que je sais, les moteurs de recherche ne suivent pas les framesets), elles empechent le visiteur de bookmarker simpement une page de contenu, enfin ca devient une contrainte très lourde à gérer si tu veux que ton menu soit un minimum contextuel. Je ne parlerai même pas de l'obligation de spécifier un target pour tous les liens externes de ton site pour virer le frameset (d'ailleurs, l'attribut target est déclaré comme deprecated - périmé dans la spécification XHTML Strict, ce qui veut bien dire que le contenu servi en frames n'est pas du contenu publié pour durer... http://www.texastar.com/tips/2004/target_blank.shtml(...) ).
- Une balise ou encore [?include src="" ?]
Sais tu que la forme courte des balises php te permet d'obtenir ce genre de choses ? exemple :
[?=include('/chemin/fichier');?]
Effectivement, ca nécessite d'avoir php avec les short tags activés. Mais de nos jours cette configuration n'est pas rare à trouver chez les hébergeurs, et puis les SSI permettent également de faire la même chose.
- que la balise soit plus utilisée. On pourrait par exemple immaginer que lorsque Mozilla rencontre un <link rel="index" ... />, on ait le paneau de navigation (à droite) qui s'ouvre avec la page indiquée ...
Si tu parles de la sidebar (à gauche, et non à droite), ce que tu dis est déjà possible... et en plus, les sidebars se comportent comme une frame. Mais ton site reposant sur ce principe ne sera plus consultable avec rien d'autre que les browsers Mozilla/FireFox (soit une petite minorité de surfeurs)... C'est vraiment ce que tu veux ?
------------------------------------------------------
Mon avis perso : les technos (x)HTML sont bien telles qu'elles sont, à quelques exceptions près qui devraient trouver des réponses dans XHTML 2. (Malheureusement, en cassant la compatibilité avec les versions précédentes, mais pour des changements de cette ampleur c'est bien nécessaire).
Aussi, je pense qu'avec tous les outils que les webmasters ont à leur disposition aujourd'hui pour gérer leur site web (et le nombre de gens qui en publient), il ne faut pas perdre de vue que la raison d'être du web, c'est l'accès optimum à l'information pour le visiteur, pas la facilité de publication pour l'auteur.
[^] # Re: D'autres possibilités
Posté par Cali_Mero . Évalué à 4.
[^] # Re: D'autres possibilités
Posté par Mildred (site web personnel) . Évalué à 1.
Je dois mettre: <<?php ?>?xml version="1.0" encoding="utf-8"?>
# Link rel
Posté par 桃白白 . Évalué à 3.
<LINK REL=Contents HREF=toc.html>
<LINK REL=Previous HREF=doc31.html>
<LINK REL=Next HREF=doc33.html>
<LINK REL=Chapter REV=Contents HREF=chapter2.html>
Ça rajoute un menu en haut de la fenêtre.
Trouvé sur http://www.w3.org/TR/REC-html32(...) .
[^] # Re: Link rel
Posté par Mildred (site web personnel) . Évalué à 1.
# Frontpage 2003 ?
Posté par Benjamin (site web personnel) . Évalué à 2.
c'est con à dire, ça n'a rien à voir ni avec Linux ni avec le libre, mais des outils (merveilleux) comme FrontPage 2003 font cela très bien, c'est calculé avant l'envoi des fichiers sur le serveur et ça s'appelle les "borders"...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.