Dudu

Rien ni personne n'interdit d'écrire de l'HTML (non modularisé, non XHTML) en caractères bas-de-casse D'autre part, il est peut-être préférable de rester cohérent en restant en HTML si l'on a commencé en HTML. Ensuite, nulle part il est écrit ni "financire" ni "dvlopper": certainement une version de Lynx qui a du mal à capter les caractères Latin-1. Ou un mauvais réglage. Même si effectivement le titre est écrit avec les caractères accentués alors que le reste est écrit en entités HTML tout est correct. Et Google (et Yahoo, et Exalead et MSN....) verront bien les bons mots. Pour finir, le sujet a dévié sur sejour-vacances-ski.com si ma vue est bonne

Et c'est bien dommage.Quand je navigue en 56k j'ai l'habitude de demander à mon navigateur de ne pas afficher les images pour éviter que ça ne me prenne trop de bande passante. Je me passerais de ton site. Pas mal d'internautes ont des problèmes de vision et naviguent sur le web, non pas avec internet-explorer-sur-windows-xp-pro mais avec des configurations plus étranges: plages brailles, lecteurs vocaux, etc.. Ils se passeront de ton site. Googlebot, le robot de Google; Slurp, le robot de Yahoo; et les autres ne lisent que le texte. Ils se passeront de ton site: les moteurs de recherche c'est juste 80% du trafic normal d'un site, tu te prives de beaucoup de monde. Mais bon, tu fais comme tu veux. Bon courage, A+

Salut Obligé ? Ne te sens pas obligé de bousiller ainsi la sacro-sainte sémantique Très simplement, tu as des propriétés CSS telles que padding ou margin qui te permettent de gérer les marges intérieures et extérieures (respectivement) d'un élement donné. Au vu de ton code, tu aurais à mon avis intérêt à morceler ta page en 3 ou 4 <div> fondamentaux (pas besoin d'en mettre des tonnes), d'assigner à des <div> des noms bien précis via l'attribut id et de régir ta mise en page via CSS ainsi. Cela t'éviterait encore quelques gros paragraphes de code inutile comme tout ce Javascript juste pour faire un effet de survol (1 ligne de CSS), ou les atroces <font> qui traînent par-ci par-là. Alléger son code le rend plus lisible Pour ton histoire d'alignement des images, je te conseille également le lien donné par slender. Et j'y rajoute ces deux-là: Practical CSS Layout Tips, Tricks, & Techniques Floating Thumbnails Et puis en passant: - sous Safari aussi, l'affichage est franchement atroce - félicitations aux parents

Salut Il n'y a pas qu'avec IE que tu vas avoir des problèmes: avec des navigateurs textes comme Lynx.. ou tout simplement avec Googlebot, Slurp, et autres Faire du <div> à l'envi en ne mettant que des images, en CSS ou en HTML, n'est pas véritablement conseillé: il n'y a pour ainsi dire aucun texte sur ta page. Je te conseille plutôt d'écrire 'en dur' le texte, puis de le remplacer par des images en CSS. De plus ça te donnera l'occasion de placer tes textes dans des balises moins vides de sens que des simples <div> pas terribles: par exemple des <h1>/<h2> etc.. bref un peu de sémantique dans ce monde de brutes. Ah je n'ai pas répondu à ta question: pratiquement tous tes <div> sont positionnés. Soit en relative, soit en absolute. Il y a de fortes chances pour que cela bloque des directives d'affichages telles qu'un "text-align: center" Personnellement, j'utilise le positionnement CSS avec beaucoup de précaution: c'est bien plus traître que ça n'en a l'air.

Ah oui au temps pour moi, j'ai du confondre avec autre chose En fait c'est carrément plus simple que ces histoires de block et d'inline: un <li> ne peut avoir comme enfant que <ul> ou <ol> Sources: http://www.w3.org/TR/html401/struct/lists.html http://fr.selfhtml.org/html/reference/elements.htm#li http://fr.selfhtml.org/html/reference/elements.htm#ul

Oui je connais un peu l'équipe d'Aquaray: c'est un petit hébergeur mais ils sont assez sérieux. Cela dit, ils visent clairement un marché de niche: hébergement sur Mac Mini ou sur xServe. Concernant leur infrastructure, ils sont sur le datacenter d'InterXion à Aubervilliers. Frontier, je viens de regarder rapidement; je n'ai rien vu sur les xServe (je regarderais plus en détail une prochaine fois). Mais si j'ai bien compris, ils mettent du Win ou du Linux sur un xServe ? Bof bof, quitte à louer un xServe autant qu'il y ait OS X Server dessus, sinon je prends le bidon de base chez un hébergeur lambda

captain_torche: Aucun risque puisque tout à fait correct. <ul> et <li> sont inline par définition, donc un <li> peut parfaitement contenir un <ul>. C'est ce qu'on appelle tout bonnement une liste imbriquée, et on s'ennuierait beaucoup si on ne pouvait pas le faire: c'est à la base de l'HTML

Tu as oublié un R dans le nom de domaine sur ton lien C'est l'image fly1.jpg que tu cherches à positionner ? Impossible à savoir pour nous: elle est manifestement affichée via l'intermédiaire de l'animation Flash donc c'est dans ton .fla qu'il va falloir chercher le problème (et la solution) À ce propos, je ne comprends pas bien l'intérêt du Flash pour ce site: ça va te nuire plus qu'autre chose. D'un point de vue accessibilité d'une part (on est dans la bonne rubrique), d'un point de vue référencement d'autre part: aucun lien HTML n'est présent donc tu vas avoir toutes les peines du monde à montrer ton site aux 'sans-Flash', et les robots de moteurs de recherche en font partie :!: Flash trouve surtout son utilité dans les animations interactives avec son. Certes il y en a sur ce site, mais à mon avis nul besoin de mettre aussi les textes en Flash. Surtout qu'il ne s'agit que d'inclusions de fichiers .txt Tu aurais tout intérêt à ne mettre en Flash que le player mp3, et l'animation "êtes-vous-prêt".. et le reste en HTML. Hors-sujet: Tu passes du Gunther en discothèque ? Magnifique, il faudra que je vienne ! PS: étonnant changement d'avatar ça change de Slipknot ..

Je suis résistant: je n'ai fait aucune attaque cardiaque je te rassure Pourquoi ? parce que ces messieurs du w3c ont dit non. Et pourquoi ils ont dit non ? Parce que si justement, une information contenue dans un élément <li> est obligatoirement inline, alors qu'un <div> est block.Je sais bien que c'est paradoxal car on peut forcer un <li> à devenir un élément block grâce aux feuilles de style.. Mais en attendant, ce n'est pas conforme, et si ce n'est pas conforme on ne peut attendre des navigateurs respectant les normes qu'ils aient un comportement normal devant ce type de code. C'est ce que je voulais dire. Je ne défends pas l'attitude du w3c sur ce coup-là car moi aussi parfois j'aimerais bien mettre un élément de type block dans un <li> dont j'ai forcé l'affichage en block.. mais le fait est que ce n'est pas conforme: donc risque d'affichage dégradé. Ça ne dépend pas du point de vue, à mon avis. L'HTML, et par extension l'XHTML, est un langage qui utilise des balises dans le seul but de présenter une information en l'encadrant avec des balises qui informent sur le contenu.Par exemple: un <li> (obligatoirement enfant de <ul>) nous informe que le contenu est un item de liste. Par exemple: un <p> nous informe que le contenu est un paragraphe Par exemple: un <var> nous informe que le contenu est un morceau de code de langage de programmation très concis etc.. Un <div> informe que le contenu est un élément de type block indeterminé (ça commence déjà mal), alors si en plus le contenu est inexistant.. ça voudrait dire qu'on informe de l'arrivée d'un OVNI sans qu'il y ait d'OVNI. Bref, c'est vraiment à déconseiller AMHA Strict ou Transitional ? En Transitional, ce n'est pas dur d'être valide avec un code non valide. Le but des normes Transitional est de faciliter la transition (comme son nom l'indique) entre l'HTML façon MS/NS des années 90 avec du véritable (X)HTML: à mon humble avis, ça n'a plus guère de raison d'être de nos jours En espérant ne pas t'avoir trop fait peur à mon tour avec ma prose

C'est justement une idée reçue à combattre activement :!: Tous les professionnels te diront l'inverse, et je vois que l'un d'entre eux a déjà commencé à vouloir te convaincre de ton erreur Ne te borne pas à croire ce que tu crois savoir De plus, le validateur n'est pas Dieu le Père et il n'est pas exempt de bugs. L'un des bugs les plus connus est d'accepter les pages XHTML 1.1 servies en tant que "text/html", on n'arrete pas de le dire, l'équipe qui s'occupe du validateur est au courant, et peut-être un jour ce bug sera fixé. En attendant, ce genre de pages n'est PAS valide.

Sur Mac OS X tu auras la réponse tout de suite et par toi-même en lançant le Colorimètre Numérique qui se trouve dans Applications/Utilitaires Rapidement, voici 'mes' valeurs trouvées avec la dite application, de haut en bas: - #ffcb99 - #ffd4a7 - #ffcc67 - #ff9934

Ne craque pas trop vite: ça ne reste que l'achat d'un nouvel ordinateur comme un autre. Ce n'est pas parce que c'est un 'switch' que c'est plus important Aucun souci pour répondre à tes questions quand tu en auras. Intéressant ! Moi qui rêvait de tâter du xServe avec OS X Server pour voir à quoi ça ressemblait..Mais avec ce que tu dis, ça voudrait dire qu'Apple a du aussi mettre des logiciels avec interface graphique pour faire ce genre de manips ? Si oui, ce n'est pas si gênant de ne pas pouvoir mettre les mains dans cambouis. Aquaray comme hébergeur ? Parce que si tu as un autre nom qui fait de l'hébergement spécialisé Apple je suis preneur.Pas que je sois spécialement déçu d'Aquaray, mais pour ne pas mettre tous mes oeufs dans le même panier

Normalement, tout est calibré pour éviter à l'utilisateur de se poser des questions trop techniques et utiliser un écran normalement calibré.Les différences sont plus sensibles entre différents constructeurs 'PC'. Au pire, le mieux à faire est de calibrer soi-même son écran. Le site de référence pour la chromie et le choix des couleurs sur le web est pourpre.com: leur page d'explication pour calibrer son écran

Salut :blink: Ton code fait peur à voir :!: Il n'est pas étonnant que tu butes sur des problèmes d'affichage, souviens-toi de la règle n°1 en CSS: toujours avoir un code propre avant d'attaquer le CSS Sinon tu n'es pas sorti de l'auberge.. PS: un <div> ne peut pas être dans un <ul>, et encore moins dans un <li>. D'autant qu'une balise vide n'a aucun sens, même si le validateur ne dit rien.

Sarc: dans ce cas, tu utilises un <span> juste pour y mettre tes textes d'infobulles ? Je préfère laisser l'attribut title faire son job comme il sait si bien le faire. Et pour ceux qui ont Javascript activé, l'infobulle a un bonus, sinon non (et ce n'est pas gênant). D'où ma préférence pour Nice Titles

Salut Il y a script de stat et script de stat. Tout dépend de ce que tu cherches. Analyseur de logs, marqueur PHP, marqueur JS, externalisé, à installer.. il y a le choix. Mes préferences sont: Pour les analyseurs de logs: AWStats et Webaliser (mais c'est compliqué à installer) Pour les marqueurs PHP: Shortstat (plus développé mais impeccable, dernière version ici) ou Slimstat (basé sur Shortstat) Pour les marqueurs JS: Mint (mais payant 30$)

C'est pourtant typiquement ce qu'on appelle une page random.Je m'amuse souvent à visiter "une page au hasard" sur Wikipedia, c'est de la redirection 301 avec un contenu différent à chaque fois, et je ne vois pas sur quel critère Zeus Google pénaliserait ça Pour les vidéos je trouve que ça reste du Matt Cutts: des trucs qu'on savait déjà + un zeste de bon sens. Sauf que c'est en vidéo et que ça promeut GoogleVideo. Rien de très renversant.

Bien le bonjour de la part du troll Mac officiel du forum Webmaster-Hub (je plaisante, on n'apprécie pas trop les trolls par ici ) Juste pour savoir: serveur local sur ton ordi ? ou un gros Max OS X Server des familles ? A+ PS: dldstyle, non easyphp n'existe pas sur Mac. Mais on a une bonne excuse: Apache et PHP sont pré-installés à l'achat du Mac Reste juste à installer la BDD de ton choix (MySQL, PosteGre.. etc..)

Salut Nice Titles est un bon script pour ce genre d'usages

Salut Tu mets l'adresse d'envoi (donc la tienne) dans le champ CC. Et toutes les autres en BCC (ou CCI selon)

Ce n'est pas réservé à l'XHTML. Tu peux très bien faire de l'HTML 3.2 en externalisant ta mise en page, en n'utilisant la balise <table> que pour de réels tableaux de données, etc.. La notion de sémantique est apparue bien avant l'XHTML: qu'on se le dise Pour ce qui est du réferencement, ça m'étonnerait beaucoup qu'il y ait un rapport. La seule chose qui est sûre, c'est qu'aucun moteur de recherche ne sait pour l'instant lire l'XHTML Strict, le vrai, servi en tant qu'application xhtml+xml (pas juste mettre un doctype XHTML strict) Et pour ce qui est de lire les CSS, je ne m'inquiète pas trop: déjà qu'IE peine à comprendre mes feuilles de style, je vois mal comment Google (qui cherche à dépasser Microsoft sur tous les fronts) y arriverait Blague à part: évite les class un peu trop spammy, abandonne ton idée de <h2> partout, et tu seras tranquille je pense.

(pour l'instant tout va bien.. pour l'instant tout va bien.. pour l'instant tout va bien ) Très belle présentation, et joli parcours: bienvenue sur le Hub ! Au fait, ça se soigne l'agoraphobie ? Psy, traitement ? Non ? Bon courage en tous cas..

Salut Je dirais que la raison est la suivante: tu as indexé cette URL dans beaucoup d'annuaires, fait beaucoup de liens même sur le Hub, et que tu n'as pas fait de redirection 301 vers la nouvelle adresse

Salut Le site Toulouse Renaissance a une des meilleures listes que je connaisse: à utiliser sans modération Slender: ia_archiver n'est pas du tout un aspirateur néfaste, c'est le robot du site archive.org et même si ce n'est pas très utile de savoir à quoi ressemblait son site en 1999, leur robot est respectueux du protocole robots.txt et ne pompe pas de la bande passante à tire-larigot. Après, c'est toi qui voit .. SurveyBot c'est idem, c'est le robot de whois.sc (devenu domaintools.com) et jamais eu de problèmes avec ce bot non plus Ces deux-là ne sont AMA pas à classer dans les "bad bots"

Salut Euh, ce que tu dis est déja valable depuis belle lurette pour de l'HTML pur Les notions d'accessibilité sont antérieures à la naissance d'XHTML on a tendance à l'oublier parfois. Et le validateur hurle pareil pour l'absence d'un alt sur une image en HTML 4.01 PS: je modifie le titre, alt et title sont des attributs pas des balises.