28173 sujets

CSS et mise en forme, CSS3

Menu externe en CSS/HTML

Bonjour,

Peut-on faire en CSS/HTML des pages avec un menu (vertical ou horizontal) et dont la définition du-dit menu serait dans un fichier externe (je parle des options du menu en HTML et non de la présentation en CSS) ?

Ceci afin d'éviter d'avoir à utiliser des FRAMEs.

Merci,
f31 a écrit :
Bonjour,

Peut-on faire en CSS/HTML des pages avec un menu (vertical ou horizontal) et dont la définition du-dit menu serait dans un fichier externe (je parle des options du menu en HTML et non de la présentation en CSS) ?

Ceci afin d'éviter d'avoir à utiliser des FRAMEs.


Pour faire court, non. Pour faire long : non, pas du tout, CSS ne permettant pas de décrire des contenus, juste leur présentation graphique (ou audio, d'ailleurs).

En gros on se tournera vers de l'include en PHP. C'est très simple, à partir du moment où l'hébergeur du site propose PHP, bien sûr.
Merci,

C'est ce que je pensais, n'ayant trouvé aucune info sur le sujet. L'herbergeur du site en question n'ayant ni PHP,ni CGI... retour aux FRAMEs donc. L'hebergeur rajoutant lui aussi ses frames pour son bandeau, je voulais éviter des frames dans des frames. Tant pis Smiley decu
Tu peux aussi faire des include avec Javascript et les requetes XMLHttpRequest dans le genre de celle-ci qui marche tres bien (une seule par action javascript par contre)

var xmlhttp=false;
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
// JScript gives us Conditional compilation, we can cope with old IE versions.
// and security blocked creation of the objects.
  try {
  xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
  } catch (e) {
   try {
    xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
   } catch (E) {
    xmlhttp = false;
   }
  }
@end @*/
if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
  xmlhttp = new XMLHttpRequest();
	// resolve, connect, send, receive - in milliseconds 
  xmlhttp.setTimeouts(1000,1000,1000,5000);
}

function loadFragmentInToElement(fragment_url, element_id) {
    var element = document.getElementById(element_id);
    element.innerHTML = 'Chargement en cours ...';
    xmlhttp.open("GET", fragment_url,true);
    xmlhttp.onreadystatechange = function() {
      if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
      element.innerHTML = xmlhttp.responseText;
      }
    }
    xmlhttp.send(null);
}


avec un appel dans le genre de celui là :
onclick="loadFragmentInToElement('./mon_repertoire/monfichier.html','mon_id');"
Merci, mais je ne suis pas vraiment fan de JS et je veux une page avec un bandeau haut, un menu vertical à gauche et un petit pied de page. Ca devient vite indigeste.
Certains logiciel d'édition, comme Dreamweaver, permettent de faire des "modèles" (chez dreamweaver il y a également le système de "bibliothèque"). Avec ça si tu modifies le modèle (ou l'objet de la bibliothèque), toutes les pages seront mises à jour. Peut-être as-tu l'équivalent sur ton logiciel ?

A part ça si j'étais toi je changerais d'hébergeur. Parceque sans PHP et avec une frame de pub en plus, là même du gratuit ce n'est pas intéressant !
Modifié par Alan (08 Mar 2006 - 14:56)
Oui je sais Smiley decu , mais je viens de récupérer la maintenance du site d'une association qui est déjà en place (chez voila) et déjà référencé (et le risque d'avoir des gens qui pointent sur l'ancien site plutôt que le nouveau parce que nous n'avons pas de nom de domaine spécifique). Je fais cela en dilettante pour améliorer un site un peu triste et peu convivial.
Je suis juste surpris, qu'avec la fronde actuelle contre les frames, qu'il n'y ait pas d'alternative HTML/CSS. On est obligé de lui adjoindre une autre techno (PHP, JS ou autre) ou d'utiliser un autre outil.
Si t'es pas sur que tous les sites qui pointent sur le tiens n'ont pas mis à jour leur lien tu peux faire une page avec un redirect sur ton adresse actuelle qui pointera sur ta nouvelle adresse.

Comme ça ceux qui pourraient se perdre seront réaiguillés, et toi tu poura être plus libre sur ton code et ta présentation
f31 a écrit :
Je suis juste surpris, qu'avec la fronde actuelle contre les frames, qu'il n'y ait pas d'alternative HTML/CSS. On est obligé de lui adjoindre une autre techno (PHP, JS ou autre) ou d'utiliser un autre outil.

Vu que ni HTML ni CSS n'est prévu pour le dynamisme des contenus, ça ne me choque pas qu'on relègue ça à des langages mieux à même de gérer le dynamisme :
- soit côté serveur, avec du PHP par exemple ;
- soit côté client, avec du Javascript.

Je serais par contre relativement surpris d'avoir une fonction d'include en HTML, ou encore plus en CSS (les CSS ne devant a priori pas gérer le contenu, mais sa mise en forme !).
Bonjour,

f31 a écrit :

Je suis juste surpris, qu'avec la fronde actuelle contre les frames, qu'il n'y ait pas d'alternative HTML/CSS. On est obligé de lui adjoindre une autre techno (PHP, JS ou autre) ou d'utiliser un autre outil.


mpop a écrit :
Je serais par contre relativement surpris d'avoir une fonction d'include en HTML, ou encore plus en CSS (les CSS ne devant a priori pas gérer le contenu, mais sa mise en forme !).


Le problème n'est pas vraiment là. Le module generated content CSS3 offrira des capacités permettant ce type d'assemblage de contenu. Voir également les HTML overlay, etc.

Mais cet assemblage du contenu côté client sera toujours soumis à la capacité du client à supporter les technologies nécessaires (CSS avancées, scripting...). Sans compter les agents utilisateurs anciens, cela pose le problème des clients "pauvres" (mobiles, verticals...) et des clients spécifiques ayant à effectuer un traitement plus complexe (les lecteurs d'écrans face aux frames, par exemple).
D'où de multiples questions d'interopérabilité et d'accessibilité de ces contenus, très difficilement gérables, au contraire des contenus assemblés côté serveur. Ces solutions côté clients sont peu robustes.

L'assemblage côté serveur est donc privilégié, puisqu'il permet d'adresser à n'importe quel agent utilisateur, quelque-soit ses capacités, un document HTML unique et finalisé, et que la question des capacités du serveur (ou d'un proxy type opera mini venant en renfort d'un client pauvre) à effectuer le traitement nécessaire est beaucoup plus aisée à résoudre (PHP, ASP, frameworks, etc.).
Modifié par Laurent Denis (09 Mar 2006 - 03:56)
Administrateur
Bonjour,

f31 a écrit :
Je suis juste surpris, qu'avec la fronde actuelle contre les frames, qu'il n'y ait pas d'alternative HTML/CSS. On est obligé de lui adjoindre une autre techno (PHP, JS ou autre) ou d'utiliser un autre outil.

Il n'y a besoin que d'UNE fonction en PHP et tous les hébergeurs dignes de ce nom proposent PHP ... (non, Voila n'est pas un hébergeur digne de ce nom enfin pas selon mon avis)

Nagaroth a écrit :
Si t'es pas sur que tous les sites qui pointent sur le tiens n'ont pas mis à jour leur lien tu peux faire une page avec un redirect sur ton adresse actuelle qui pointera sur ta nouvelle adresse.

Comme ça ceux qui pourraient se perdre seront réaiguillés, et toi tu poura être plus libre sur ton code et ta présentation

Smiley jap
Pèse le pour et le contre: un hébergement sans pub et avec PHP, ça vaut bien la migration je pense ... Surtout avec une redirection.
Et pour trouver les sites qui pointent vers ton site sur voila.fr, Google recherche avancée!
Exemple: qui pointe sur AlsacréatioN Smiley ohwell


Dernière solution: un éditeur de texte évolué qui permet le chercher/remplacer dans plusieurs fichiers à la fois (tout un répertoire par exemple).
Tu conserves ton site avec des ~~menuligne1 ~~menuligne2, tu le copies de ton DD vers un autre répertoire où tu substitues les lignes par ton vrai menu et tu uploades cela.
S'il y a une modif mineure à faire, tu peux la faire sur la copie directement. Si c'est carrément un menu différent, tu substitues à partir de l'original.
Méthode bourrine mais ça fonctionne si on est ordonné (et encore mieux si on écrit un script, parce que le refaire à la main 6 mois après ...)
tu peux utiliser la balise <object> pour inclure un autre fichier HTML mais tu auras les barres des scrolls il me semble...
Modifié par Zeke (09 Mar 2006 - 09:03)
Zeke a écrit :
tu peux utiliser la balise <object> pour inclure un autre fichier HTML


Oui mais cela revient à faire 1 iframe (d'ailleurs le menu contextuel de firefox parle bien de "ce cadre" dans ce cas)

Pour les barres de défilement par contre c'est gérable.
Merci pour toutes ces infos.

Felipe, je suis tout à fait d'accord sur Voila, mais bon le site est déjà là et je ne voulais pas me lancer dans un changement d'herbergeur. Idéalement on devrait même acheter le nom de domaine et cela serait plus simple.
Pas contre l'idée du remplacement de "positionneurs" est à creuser, je vais essayer.

Zeke, j'ai essayé les <objet> mais ça n'a pas l'air de marcher avec IE. Oui je sais ce n'est pas le meilleur navigateur mais 99% des gens qui accéderont au site auront IE.

Laurent, je comprends tes argument mais il existe déjà un tag qui permet d'avoir une certaine dynamique dans les pages HTML, en l'occurrence le tag <link> et qui, je pense, est traité au niveau du client. Il est juste dommage que l'on ne puisse pas utiliser ce tag pour des contenus html.
Bonjour,

f31 a écrit :
Laurent, je comprends tes argument mais il existe déjà un tag qui permet d'avoir une certaine dynamique dans les pages HTML, en l'occurrence le tag <link> et qui, je pense, est traité au niveau du client.


link n'est absolument pas destiné à cet usage, et serait bien incapable d'être utilisé ainsi Smiley cligne

(Rappel: link permet :
- d'associer à la source HTML des couches supplémentaires comme les feuilles de styles, le favicon, etc.
- de signaler des versions alternatives comme RSS ou PDF
- de tracer une série de liens de navigation dans une collection de documents (liens relatifs), sans que ces données n'aient à être intégrées à la restitution de l'interface de page proprement dit. Chaque agent utilisateur est libre de les restituer par le moyen de son choix. Et les liens relatifs se prêtent pour l'instant mal à autre chose qu'à une série très limitée de liens types (home, page suivante, précédente, index, etc).
Ce pourrait être une discussion sans fin, mais je voulais simplement faire remarquer que :

- les clients sont capables de combiner plusieurs pages html par le biais des FRAMEs. Le mecanisme est différent, bien qu'il doit quand même y avoir 1 GET pour chaque fichier.
- Link permet aussi dynamiquement d'intégrer des informations qui bien que non affichées sont intégrées à la restitution puisque les CSS indique comment la page doit être restituée.

Je comprend que l'on n'aime pas les FRAMES pour les inconvénients qu'elles peuvent apporter, je trouve juste dommage qu'il n'y ait pas d'alternative CSS. Je n'essaye pas de jouer les puristes, ni de démarrer une polémique, mais en faisant des recherches sur le net, on voit beaucoup de conseils pour ne pas utiliser les FRAMES, mais comme il n'y a pas d'équivalent CSS le choix est de rajouter une surcouche pour combler le manque. C'est un peu étrange.
Sujet clos
Aller à