LaurentDenis

Si ton en-tête et ton pied de page sont supposés occuper cette place dans la zone d'affichage du navigateur, et non dans la hauteur de la page scrollée... - utilise un iframe ou une div scrollable via CSS (le scroll résoudra ton problème) - ou utilise des tableaux, si ceux-ci t'apportent une solution. En effet, si c'ets bien le cas, il s'agit : - de figer deux zones (en-tête et pied) de hauteur fixe, ce qui ne pose pas de pb en soi, - mais de contraindre un contenu à s'adapter à la hauteur resultante, et non le contraire. Or CSS est conçue pour permettre à une zone d'affichage de s'adapter à l'étendu de son contenu (c'est la notion de flux). Pas le contraire. Pour cela, il faudrait rendre relatif à une hauteur fixe en pixels : - la tailles des polices, (font-size) - la hauteur de ligne (line-height) - les padding et margin verticaux Et réussir à tenir compte de la capacité du navigateur à redimensionner les polices (et du coup la hauteur de line). En gros, ce que tu veux faire, ce n'est pas adapter une présentation à un contenu, mais l'inverse : adapater un contenu à la surface disponible pour sa présentation. C'est impossible en CSS, tout simplement parce que c'est contraire aux mécanismes de base du rendu graphique d'un document HTML, avec ou sans CSS.

Tu obtiens le même résultat avec <img src="..." alt="..." class="tete">

Tu trouveras les informations nécessaires pour corriger les cours en questions dans les sources recensées par cet article : Ne validez pas en aveugle : lisez les spécifications !

Ah, au fait : pour décider d'activer le plugin démoniaque, encore faut-il qu'il y ait un contenu <noflash> qui me donne envie de le faire, donc, comme disait Denis, au moins " une transformation élégante de sa technologie pour me montrer une image à la place", ou une bonne explication de son choix quelque-part

Bah... je serais le dernier bastion alors, puisque l'ami Denis se renie Flash ? Installé, oui. Pour les très rares sites qui offrent un contenu en Flash. Un contenu. Qui justifie Flash. Parce qu'on ne peut pas le faire autrement. Et que c'est nécessaire. Et que SVG+SMIL est encore peu employé/employable. Mais activé, le plugin Flash... ça c'est une autre paire de manche ! Activé à la demande. Pas pour les pubs. Surtout pas. La pub n'est pas un "contenu" pour le visiteur moyen que je suis, juste un encombrement nécessaire qui se doit d'être discret Gif animé ? Il y a tellement longtemps que j'ai désactivé les gif animés dans mon navigateur que je ne sais plus ce que c'est Donc pub bête, statique, neutre, discrète, très discrète. Si jamais elle m'attire l'oeil, c'est par sa très, très grande pudeur. Je suis un brontosaure [edit] heureux [/edit]

Merci d'éviter les messages... pour ne rien dire ? Si tu changes d'image de logo, tu devras changer le fichier source, c'est à dire "écraser le fichier original de ton logo"... Tu ne devra modifier ta source HTML que si les dimensions de ton logo changent (tu gardes le même nom de fichier). Si tu places ton logo en image de background-CSS, et si tu ne changes que l'image en conservant ses dimensions... tu n'as qu'une ligne unique à changer dans ta CSS... Maintenant, si tu veux un jour changer l'emplacement de ton <img> de logo dans ta source HTML, tu devras effectivement modifier le code de tes pages. Mais pour l'instant, cette <div> vide gardée "en réserve" alourdi inutilement ton code.

Ce type de dégradation est relative : - à la détermination des tailles par l'auteur, - mais aussi à la configuration utilisateur ! Autrement dit, il serait illusoire de vouloir qu'une mise en page "élastique" (ce qui est déjà un progrès considérable à l'heure actuelle) ne se "casse" pas dans une configuration utilisateur donnée. Elle se dégrade. Et l'utilisateur y perd en utilisabilité. Selon son handicap (difficulté à scroller) cela peut nuire à sa capacité à accéder aisément au contenu. Mais là, on est dans le domaine de l'utilisateur, non de l'auteur (avec beaucoup de précautions d'usage, évidemment). En d'autres termes, identifier accessibilité et expérience de navigation identique n'est-il pas illusoire ? En d'autres autres termes : - une pages est ou n'est pas valide au regard des normes (X)HTML CSS, - mais au mieux elle tend vers un minimum d'inaccessibilité.

La seule solution réellement accessible que je connaisse consiste... à ne spécifier aucune taille de caractère : les réglages par défaut de l'utilisateurs s'imposent immédiatement sans autre intervention de sa part, et il est seul responsable de ses maladresses Cela dit, comme on a toujours du mal à ce que ça soit moche dans son propre navigateur avec ses propres réglages quand on regarde son propre site, cet article et surtout ses critiques peuvent te donner des éléments de réponse sur la technique des em : omment définir la taille du texte en ems (traduction) (Désolé, je n'arrête pas de citer mes propres textes. Je dois décidément avoir besoin de nouvelles lectures ).

Voir http://openweb.eu.org/articles/initiation_display/ pour les propriétés CSS à utiliser à cet effet et un exemple de base.

C'est à la fois l'intérêt et le danger d'un forum de ce type : - le danger parce que nos remarques peuvent donner à penser que nous faisons un travail d'expertise qui serait l'équivalent d'un "label" d'accessibilité. Or c'est loin d'être le cas. (A ce propos, je dissipe une confusion éventuelle : lorsque je disais qu'il n'y aurait plus de problème d'accessibilité, cela ne concernait que l'imagemap en question, pas le site dans sa totalité !) - l'intérêt, parce que des experts "validés" comme yobiwan (et bientôt Monique si je ne m'abuse) y participent avec une approche plus rigoureuse et systématique que la nôtre... Hum... Pourrais-tu approfondir les arguments ? J'avoue que le "en linéaire" me semble refléter une mauvaise compréhension des mécanismes de positionnement CSS, qui distinguent clairement les notions de flux et justement de "retrait du flux".

Je ne suis pas allé chercher très loin, mais pour l'exemple que tu donnes : http://www.lnf.fr/droitsReserves/droitsReserves.html Tu as donc tout intérêt à vérifier systématiquement les droits, et à faire des demandes d'autorisation...

Hum... Attention au cryptage des adresses e-mail : - les solutions reposant sur javascript, ou sur une image... rendront votre adresse inutilisable pour un certain nombre de visiteurs (prévoyez alors un formulaire de contact sur votre site); - d'autres solutions d'encodage de l'arobase et du . perdent rapidement leur efficacité à mesure que les robots sont prévus pour les contourner. Mieux vaut se contenter de solution de filtres côté provider et côté client mail.

Le problème du nombre de résultats dans les pages Google a déjà fait l'objet de discussions dans ce forum... sans dérapages ni modération nécessaire (Je vous laisse le soin de les retrouver).

Sérieusement, la première mesure à prendre pour le référencement, l'ergonomie, etc... serait de supprimer cette page d'accueil "tunnel" qui ne passe ni dans IE, ni dans Opera, etc. http://jeuxvideo.guideo.fr/index.htm fera une bien meilleure page d'accueil, susceptible de retenir les visiteurs Ah, le javascript pour le message "Voulez-vous m'aider gratuitement" peut disparaître aussi : le référencement commence par un contenu de qualité, et celui de ton site est gâché par ce genre de chose.

le title de l'img est inutile. En revanche, reproduit les alt des area dans des title (les lecteurs d'écran l'utiliseront pour donner un intitulé au lien, en particulier IBM HPR) : <img alt="Plan illustré de la commune de Figari" src="http://www.villesurinternet.com/figari/img/plan/plan_de_Figari.jpg"" usemap="#Map" /> <map name="Map" id="Map"> <area alt="Eglise de San'Andrea et Patrimoine" shape="rect" coords="282,222,367,266" href="patrimoine.htm" title="Eglise de San'Andrea et Patrimoine" /> etc... Et vu le petit nombre de lien de l'imagemap, tu pourrais peut-être faire comme on fait pour les imagesmap côté serveur : reproduire carrément les 5 liens "en dur", dans un mini-menu texte en dessous de l'image. De la sorte, tu es certain de ne plus avoir le moindre problème d'accessibilité [edit]Concernant cette imagemap[/edit]

Deux choses encore : - l'accesskey du moteur de recherche n'est pas implémentée dans le formulaire : <label class="cache" for="recherche" accesskey="4">Texte recherché</label> - tu pourrais envisager un "menu d'accesibilité" tout en début de page (visuellement au dessus du "Bienvenue sur le site Officiel de la Commune de FIGARI, Corse-du-Sud") avec les liens vers : * le contenu (#content, ou plutôt le premier titre texte de la page) * le menu (rajouter une id sur le <ul class="menu nav">) * la recherche (#recherche) * la politique d'accessibilité (lien direct vers la page) Au fait, c'est un très beau site, particulièrement agréable à consulter

Que veux-tu dire ? Sur quelle page du site ?

Evite absolument les remplissages du type "photographie" ou "campagne pour les images de la page d'accueil. Donne une brève description du contenu de l'image en rapport avec celui de la page: par exemple, ton "route bordée de chênes-lièges" est bien, parce qu'il apporte au visiteur non-voyant une information nouvelle et pertinente qui autrement serait réservée au visiteur voyant : cette commune est dans une région où pousse ce type d'arbre... et le site comporte justement une page consacrée à l'artisanat du liège A ce propos, dans http://www.villesurinternet.com/figari/liege.htm : - si les chênes-lièges étaient essentiellement plantés en bordure de parcelle ou de route, plutôt que sur les parcelles elles-mêmes, comme l'image semble suggère, il serait intéressant de l'intégrer dans le alt de la première image - la seconde image montre que le liège était d'abord débité en bûches grossières... - la troisième image, récolte en 2002... est intéressante parce qu'apparemment, on utilise toujours l'âne... Autre exemple : dans http://www.villesurinternet.com/figari/pre...iremoyenage.htm, la photographie de la Chapelle San Quilico di Montilati : en quoi est-elle représentative d'une certaine architecture ? Son plan rectangulaire (pas en croix) ? Son toit presque sans pente ? L'appareillage de ses murs ? Le fait qu'elle soit apparemment isolée en pleine campagne ? Finalement, remplir les alt des images est très loin d'être un travail dénué de sens et d'intérêt en soi Si l'image ne te semble apporter aucune information de ce type... C'est peut-être bien qu'elle n'est que décorative. Dans ce cas, un alt="" l'évacue.

Tout simplement : non ! Cette "ruse" fait peut-être passer la validation formelle, mais ce n'est pas le but du jeu : il s'agit de rendre ce formulaire réellement accessible, autrement-dit de lui donner un vrai label textuel. Si tu veux à tout prix le masquer graphiquement, utilise plutôt cette ruse CSS qui elle est inoffensive : .hidden { position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden; } (Pour les détails, voir Lecteurs d'écran : cachez ce sein que je ne saurais voir

Oups, un oubli : j'aurais tout de même pu te donner cet excellent lien : Optimiser le poids et les mises à jour de son site web sur l'utilisation des include et d'un second moyen de te simplifier la vie pour la maintenance de tes pages, les feuilles de style, appelées aussi CSS. (tu croiseras sûrement l'auteur sur ce forum, d'ailleurs).

Pour la petite histoire, iframe n'a rien de Microsoft : c'est un élément tout à fait standard en HTML4.01 / XHTML1.0 transitional... Mais s'il s'agit juste d'obtenir ce type d'effet visuel (une zone scrollable incluse dans la page), le "truc" de la <div> de hauteur fixe avec overflow:auto a l'avantage de ne pas tomber dans les problèmes posés par les frames...

On ne peux que te conseiller d'utiliser les include, en effet. Sauf erreur de ma part, tu dispose d'un hébergement qui te le permet. Pourquoi ne pas commencer par la documentation fournie par ton hébergeur ? Ah... Zut ! Il semble que celui-ci ait un peu cassé son propre site. Heureusement, la page en question est toujours consultable via le cache de google Au passage, à lire cette page, il semble qu'il faille activer le PHP dans ton compte...

Le terme iframe peut justement induire en erreur ici, dans la mesure où ta page ne comporte pas de véritable iframe, et que tes liens rechargent la totalité de son contenu, aussi bien la <div id="vignette"> que la photographie agrandie affichée à côté. Comme ta page est rechargée en totalité, tu ne peux guère utiliser qu'une ancre visée par le lien cliqué, sur le modèle de ce test rapide : <div style="height: 100px;width: 150px; border: 1px solid;overflow:auto;"> <ul> <li>item</li> <!-- rajouter des items pour tester --> <li><a href="test.html#ici" id="ici">item ici</a></li> </ul> </div> Mais sans garantie sur : - la manière de marier ça avec tes urls et le passage de ta variable, - le comportement des divers navigateurs,

Concernant les frames, puisque ton site est en construction, c'est un choix qu'il faut bien peser ! Tu trouveras des éléments de réflexion pour t'aider dans cet article: Pour en finir avec les cadres, qui montre en montre bien les défauts. Et tu trouveras bien-sûr ici de l'aide pour mettre en place des solutions plus récentes et plus fonctionnelles, ou pour utiliser au mieux cette technologie malgré ses défauts si cela reste ton choix final

Simplement parce que ne pas inclure un élément en-ligne dans un élément-bloc fait partie des erreurs qui sont acceptées en (X)HTML Transitional mais refusées en (X)HTML Strict.