Dudu

C'est vrai.. .. mais on dit "Bienvenue sur [mon site]", je t'assure que si Heureux d'avoir pu t'aider, A+

Bonsoir XHTML 1.1 ! Ciel ! tu es donc un professionnel de la conception web qui aime prendre des risques Cette norme, quand elle utilisée correctement (ce qui n'est pas ton cas, désolé) n'est pas lue ni par certains moteurs de recherche (Google), ni par certains navigateurs (Internet Explorer): tu te priverais de beaucoup de monde ! De plus: cela voudrait dire que tu cherches activement une interopérabilité entre ton site et des applications purement XML, MathML et autres: est-ce vraiment ce que tu cherches ? De plus: le validateur du w3c a un bug connu: il ne donne pas d'erreur quand un DOCTYPE XHTML 1.1 est envoyé avec un "Content-Type" text/html (ce qui est ton cas) alors que c'est parfaitement interdit: il faut utiliser application/xhtml+xml obligatoirement quand on travaille en XHTML 1.1 C'est l'erreur la plus grave de toute ta page, bien au-delà des petites erreurs sur les <ul> insérés dans des <p> Bon, je charrie mais je n'ai pas donné de conseils Alors => Ce qui est à retenir c'est qu'XHTML 1.1 n'est pas une norme qui soit réellement pour toi Je ne dis pas que tu es un gros nul qui ne sait pas ce qu'il fait, attention ! Juste qu'il n'y a que des fous furieux qui peuvent se permettre de l'utiliser, à l'heure où peu d'agents utilisateurs savent interpréter cette norme correctement (ce n'est pas parce que ça s'affiche bien que c'est correctement interprété). Un DOCTYPE XHTML 1.0 Strict te sera amplement suffisant. Moi-même je ne dépasse jamais ce DOCTYPE: en 2006 c'est encore inutile d'aller plus "haut". Pour ce qui est de tes erreurs, maintenant (tu auras exactement les mêmes en XHTML 1.0 Strict normalement): - la première est due à un conflit d'encodage: très certainement ton éditeur HTML n'est pas en ISO Latin-1 alors que ta page web l'est. D'ailleurs pourquoi l'ISO alors que l'XHTML (a fortiori le 1.1) est "optimisé" UTF-8 ? - pour les autres, tu n'as pas le droit d'insérer une liste (<ul> ou <ol>) dans un paragraphe (<p>), tout simplement. Il faut donc que tu refermes ton paragraphe avant la liste, et que tu en rouvres un autre après PS: tant que j'y suis, une petite faute de frappe sur ta page d'accueil: le mot "bienvenue" s'écrit systématiquement avec un "e" final (du moins, lorsqu"il n'est pas utilisé comme adjectif comme dans ton cas) A+

Bonjour, j'ai l'impression, à la vue du code, que tu as mis en CSS les images qui devraient se trouver dans l'HTML.. et dans l'HTML les images qui devraient se trouver dans le CSS

Contenu dupliqué car ce n'est pas qu'un simple frame. L'adresse principale est *****.free.fr L'autre est ****.fr.tc/moteurxdir (<= nulle part dans le frameset il y a une frame dont la source est l'URL @ free.fr)

Salut, j'ai peur de ne pas avoir tout compris, mais pourquoi ne pas mettre à la racine du domaine .de un robots.txt qui interdit /fr, /gb etc etc.. et ainsi de suite pour chaque domaine ? Georges: .htaccess c'est Apache uniquement. Si le site de campagne est en asp, le serveur web est probablement IIS

Bonjour Je suis en parfait désaccord avec cette phrase Combien de fois suis-je tombé sur le type de sites dont nous parlons (grosse société qui a fait faire son site par une agence de renom) et où je me suis vu refuser l'accès, sous prétexte que "nous utilisons des technologies qui blablabla.. changez de navigateur et prenez donc Internet Explorer 6" ? (tu parles, si je modifies mon User-Agent, je passe) Combien de fois n'ai-je pas pu consulter la profondeur de mon découvert sur le site de ma banque ? () Sous de faux prétextes de sécurité en plus (ben voyons) Pourquoi sur le site de l'Elysée (on parle pas d'une petite PME ) je ne peux pas lire les vidéos ou pire encore, de vulgaires mp3 ? Pourtant, j'ai le plugin idoine pour les vidéos.. Ces sites-là ne sont pas des sites "faits en tableaux pour que ça passe partout", ce sont la plupart du temps des sites orientés MSIE 6 parce que personne ne daigne prendre en compte des navigateurs qui ne sont pas 1er du classement dans les stats mondiales. D'ailleurs à ce propos, pourquoi constate-t-on une progression des demandes "conformes aux standards" ? Parce que "les-standards-c'est-super-bien-c'est-méga-cool" ? Parce que les gens s'émeuvent de l'accessibilité ? Je n'en absolument pas persuadé. C'est plutôt dû au buzz autour des "navigateurs modernes" qui a modifié les stats: Internet Explorer n'est plus à 90% comme autrefois, donc on s'affole et on arrête de le viser spécifiquement.. Il ne s'agit aussi que de mon opinion

Le spiritus, mazette un ami polonais m'en a fait boire une fois, je pense que je m'en souviendrais toute ma vie... Il m'avait dit que c'était fort, mais je pensais pas boire un truc qui frôle les 95° ;o Bienvenue sur le Hub ! Bien sûr que l'ambiance est bonne, ici

Bonjour D'éminents spécialistes ont déjà pensé à la même chose C'est notamment le cas d'Adam Kasley, qui a d'ailleurs publié un article très intéressant à ce sujet sur son blog: CSS dotted borders in Internet Explorer. Pour ma part, je rejoins un peu TheRec (mais sans rigoler): si je veux vraiment une bordure pointillée et que je doive passer trop de temps à "hacker" IE pour ce faire: je laisse tomber. À ce jour, il est encore important (malheureusement) de devoir supporter IE, car sa côte de popularité reste encore trop haute, même si elle descend.. mais j'avoue n'y prêter attention que si la mise en page est complètement destructurée: si c'est juste un "dotted" qui en tranforme en "dashed" et bien.. tant pis, il n'y a pas mort d'homme Après, c'est une question de choix personnel

Bonjour, bienvenue. Intéressant. Si je peux juste me permettre quelques petites remarques: - Les noms des liens disparaissent au survol avec Safari 1.2: est-ce réellement voulu ? - tu n'es pas valide XHTML 1.1. Ce DOCTYPE n'autorise pas l'envoi du contenu avec le type MIME text/html, mais uniquement avec application/xhtml+xml. XHTML 1.1 est de toute façon encore beaucoup trop jeune pour être utilisé en production; et il n'y a aucun intérêt à "frimer avec un gros DOCTYPE" (Le validateur du w3c ne référence pas cette erreur: c'est un bug connu) Cordialement edit: à ce propos, un lien fort intéressant: Servir du XHTML en tant que text/html jugé néfaste

Bonjour Pas simple ton histoire, je vois globalement 2 solutions: utiliser Javascript (désolé) en incluant avec PHP un code qui va provoquer le rafraîchissement de tout le frameset. Inconvénients - l'usage de JS - mauvaise "dégradation" pour ceux qui n'ont pas le JS activé - nécessite de bidouiller le code PHP pour n'envoyer le script JS que lorsqu'il faut (lors de la soumission du formulaire uniquement) - ça n'a pas l'air de te plaire (et je te comprends) se passer des frames. Honnêtement ça a plus d'inconvénients que d'avantages, et rares sont les applications nécessitant spécifiquement des frames (mais il y en a). Si c'est juste pour éviter le rechargement d'un menu, ça me semble très limité comme avantage: même en bas-débit, un menu se charge vite.. c'est pas comme si c'était un énorme truc en Flash de 20Mo. Je ne vois pas d'autre solutions Remarques: - l'usage de la balise <meta> utilisée pour rafraîchir une page est fortement déconseillé: beaucoup d'inconvénients et 0 ergonomie - le code Javascript pour recharger tout un frameset depuis une des frames est le suivant if (top.location != self.location) { top.location = self.location.href; }

Bonjour, ça demande effectivement du Javascript. Tu as un script tout prêt qui fait cela, qui s'appelle "nicetitles.js" (tu le trouveras dans ton moteur de recherche préféré). Et de mémoire il est très correct question accessibilité.

Salut L'intégration a été mal faite Tu te retrouves avec plusieurs balises <body> et <html>: regarde de ce côté-là. Ps: j'ai transformé tes images en liens cliquables, elles sont un peu grandes

Salut Le positionnement absolu fait en sorte que l'élement auquel il est appliqué sorte du flux. C'est comme si il flottait par-dessus la page et qu'on décide de le superposer à "x pixels à partir de la gauche" et "y pixels à partir du haut". Donc, dans ton cas, tout ce qui suit le header prend sa place dans le flux normal et vient se coller en haut de la page. Donc le header positionné en absolu vient se superposer Il faut donc, si tu pars dans l'optique de positionner ton header en absolu, que tu décales le reste de ta page. Si ton header fait 70 pixels de haut (par exemple) tu décales de 70 pixels .. ou un peu plus pour laisser une marge.

Je ne suis pas intégriste à ce point. Surtout parce que <strong> reste pour l'instant utilisé à peu près pareil que <b> l'est ou l'était D'autant que selon quelques référenceurs, il y aurait encore une petite différence de prise en compte par les moteurs décidément toujours en retard d'une guerre ..

Bonsoir Sérieusement, tu crois qu'on va pouvoir te donner une solution sans que tu ne nous communiques: - ni code - ni URL - ni le problème précis - ni les langages utilisés En attendant, je te conseille un bon coup de baguette magique. Ça arrangera peut-être les choses

[HS] Si tu es sous Firefox 1.5 c'est à mettre sur le dos de Firefox: il est victime d'un bug sur les polices.Solution à court terme en attendant que les développeurs de Mozilla se bougent: modifier la police par défaut dans tes préférences. [/HS]

Non, le DOCTYPE n'est pas du XML Je pense que vous êtes bien d'accord là-dessus Le DOCTYPE, c'est juste pour savoir en quelle langue on parle: argot, verlan, français littéraire, HTML 4.01, HTML 3.2, XHTML 1.0 ... ? C'est aussi très utile pour le webmaster, car à mon avis le DOCTYPE se choisit avant même la conception de la page. Il est donc très agréable d'avoir une documentation précise à laquelle se référer. Bien sûr, son utilisation la plus pratique reste la bascule des modes de rendus sur les navigateurs (quirks et standards-compliant) comme expliqués plus haut. Une dernière chose: c'est très important de ne pas chercher à frimer avec son DOCTYPE. Choisir le plus élevé, le plus contraignant n'est pas forcément une bonne chose. À l'heure actuelle, les quatre DOCTYPE réellement utilisables sont: HTML 4.01 Transitional HTML 4.01 Strict XHTML 1.0 Transitional XHTML 1.0 Strict En dessous c'est trop vieux (quoique l'éminent Slashdot faisait encore de l'HTML 3.2 jusqu'à il n'y a pas si longtemps et ça ne dérangeait personne), au dessus c'est trop tôt (sauf cas particuliers).

Bonjour Il y a plus simple: annuler depuis ce répertoire les effets du .htaccess placé à un niveau supérieur. À mettre dans un .htaccess dans le dossier lofiversion RewriteEngine off (ça ne marche pas pour les répertoires virtuels, mais il me semble que ce n'est pas le cas de "lofiversion" sur IPB) Pour le reste, je ne saurais pas te répondre: ça dépasse largement mes connaissances. Désolé

Comme dirait l'autre: "Les deux, mon général" Je dirais même plus: l'attribut title peut être placé sur à peu près toutes les balises. Un paragraphe, un champ de formulaire, un h1-h6, ... une image, un lien On peut même le placer sur un <link> qui appelle une CSS externe. Mais attention: c'est le seul cas où il n'y a pas d'infobulles (logique puisque <link> n'est pas un élément affiché) et surtout çà influe sur la prise en compte de la CSS par le navigateur. Un lien intéressant sur DevEdge Employer correctement l'attribut title avec des feuilles de style externes Son utilisation est facultative pour toutes les balises, par contre le alt sur les images a toujours été obligatoire, ça ne date pas d'XHTML 1.1 !

Bonsoir. Ah, l'ASCII-Art ! C'est toujours sympa d'en revoir de temps en temps ... Quant au rapport avec le webmastering, il est léger, mais je le vois bien. L'ASCII-Art (oui, Gribouille, c'est son nom) peut au départ n'être qu'un vulgaire fichier texte, c'est amplement suffisant pour mettre en forme du texte préformaté. Ensuite vient la couleur: c'est tout de même mieux que le noir est blanc. L'HTML devient alors la solution la plus évidente (MDR Sébastien )

Bonsoir, Le lien "Mes contrôles" en haut à droite. Ensuite, la rubrique "Abonnements" dans la colonne de gauche.

Bonjour. alt c'est pour le texte qui doit remplacer l'image si celle-ci ne peut pas être affichée (erreur 404, utilisateur qui désactive les images, etc etc..) title c'est la description de l'image. Sur un navigateur graphique elle apparaît au survol du curseur, dans une info-bulle. Note: En cas d'absence de l'attribut title, Internet Explorer affiche le alt comme si c'était un title: c'est une grave erreur et c'est contraire aux recommandations du w3c. Il me semble qu'IE 7 règlera ce problème, mais de toutes façons la côte de popularité d'Explorer descend tellement de manière rapide (*) qu'à terme ce ne sera plus vraiment un problème Pour ce qui est du référencement, oui les mots clés mis en valeur de ces attributs comptent. Mais il faut aussi noter que ces attributs doivent servir à des fins d'accessibilité: lorsque je suis en bas-débit je désactive systématiquement les images pour aller plus vite; un non-voyant (et il y en a plus qu'on ne veut le croire) va lire ces valeurs au lieu des images; etc etc.. les exemples ne manquent pas. Rien de plus énervant que de tomber sur un avalanche de mots-clés sans queue ni tête. Donc le but du jeu est de jongler entre les besoins de référencement et les besoins d'accessibilité. Comme partout: le compromis idéal est à chercher (*) C'est en tous cas ce que je constate sur les sites que je gère. Sans aucune promotion pour aucun navigateur, même pas le partenariat Adsense-Firefox.

Salut Je prends ma boule de cristal et je vais deviner quel est ton navigateur, ok ? Je me concentre... hummm Internet Explorer 6 ? Si la première ligne n'est pas un DOCTYPE (même si c'est un prologue xml ce qui est parfaitement valide, mais çà aurait très bien pu être une ligne blanche ou n'importe quoi) Internet Explorer passe en mode quirks. C'est-à-dire qu'il va estimer que la page n'est pas valide et tenter de la représenter (le plus souvent n'importe comment). C'est un bug archi-connu de Win IE. Deux solutions: - enlever le prologue. Il n'est pas indispensable, et l'enlever ne crée pas d'invalidité. - écrire un minuscule script PHP qui teste le navigateur. Si c'est IE => pas de prologue. Si autre => prologue. Par contre, si tu me dis que ça arrive sur un autre navigateur qu'Explorer, tu me surprendras.. PS: change de navigateur on est en 2006, pas en 1613

Bonjour. Le problème est plus complexe qu'il n'y paraît. Le code fourni par le w3c est de l'HTML, et non de l'XHTML. Cela étant, l'écrasante majorité des sites se targuant aujourd'hui d'être codés en XHTML envoient leurs pages avec un type MIME "text/html". En clair: on a une syntaxe XHTML mais le navigateur le reçoit comme étant de l'HTML. Et donc, que fait le navigateur quand il reçoit un <br /> dans une page envoyée comme étant de l'HTML ? Je le donne en mille: il ignore le slash, car en HTML ça ne veut rien dire Le code donné par le w3c est donc conforme, sans être valide (nuance). Mais effectivement, il est préférable de le corriger pour que le validateur (qui lui prend la page comme étant de l'XHTML, puisqu'il se base sur le DOCTYPE) soit content. Morale de l'histoire: faire de l'XHTML comme on fait de l'HTML n'a pas tellement de sens finalement. Autant passer une validation HTML 4.01 Strict qui n'est finalement pas si facile à avoir. Pour ma part, je travaille avec de l'XHTML (envoyé comme HTML à cause d'IE) uniquement parce que c'est rigoureux au niveau de la syntaxe et que j'aime bien avoir une certaine rigueur. Mais il ne faut pas oublier les aléas de travailler en XHTML en 2006: XHTML n'est pas encore tout à fait mature dans le sens où tous les navigateurs courants n'ont pas forcément la même facilité à l'interpréter.

Bonjour Un des codes les plus complets pour récupérer le favicon est celui utilisé pour le projet Favatar Et non, un favicon n'est pas nécessairement au format ICO. C'est juste que *un certain navigateur* ne lit pas autre chose. Pour transformer du ICO en PNG, il existe le très pratique favicon collector