LaurentDenis

Petit truc mnémotechnique : pense à une horloge et au sens des aiguilles d'une montre en commençant à midi : - en haut midi - à droite 3h - en bas 6h - à gauche 9h heure : midi, puis 3h, puis 6h, puis 9h. margin : haut, droite, bas, gauche.

Veux-tu dire un moteur de recherche strictement interne ou un service de recherche appliqué à un site ? Dans le second cas, Atomz offre un service gratuit assez intéressant, à condition de mettre les mains dans le cambouis pour concilier validité, accessibilité et ergonomie du formulaire de recherche et des pages de résultat. Voir Un moteur de recherche valide XHTML 1.0 Transitional avec Atomz. Je trouve très intéressant, en particulier, la possibilité d'obtenir les résultats dans le dialecte XML de son choix, librement transformable en (X)HTML. Voir Atomz en XHTML 1.0 Strict (Mais je n'ai guère eu le temps de finaliser, ce ne sont que des pistes).

Une page Web ne peut pas être rédigée à la fois en HTML et en XHTML. Ces deux dialectes ont des DTD (Déclaration de Type de Document) différentes, et des règles de syntaxe différentes. Ce site est effectivement valide HTML4.01, mais sa DTD (Déclaration de Type de Document) est incomplète. Esprit : tu devrais vraiment lire par exemple au moins l'article de Monique Un code valide (1) Le doctype dans les publications du Hub. Ecrire des cours sur le HTML et les CSS est un bon moyen de fixer les connaissances qu'on est en train d'acquérir. Mais il faut tout de même être rigoureux

Cela n'a effectivement aucun rapport avec l'accessibilité, à ma connaissance. Spécifier la taille des images accélère simplement la restitution des pages dans la plupart des navigateurs graphiques en leur permettant de réserver l'espace nécessaire à l'image et d'afficher la suite du contenu, pendant que l'image se charge. Peut-être est-ce Wave.

Aurais-je dis que la structuration n'apportait rien en termes de référencement ? A me relire, je crois bien avoir dit exactement le contraire La différence que je faisais est entre validité et structuration. Un document peut très bien être excellement structuré... et invalide (il suffit qu'il n'ait pas de DTD ou qu'il comporte une erreur de syntaxe mineure du type <P> en XHTML au lieu de <p>). Les robots des moteurs de recherche ayant jusqu'ici été conçu pour exploiter essentiellement des documents invalides (la majorité des documents Web actuels le sont).... la facilité de traitement que leur apporterait la validité est actuellement toute théorique, AMHA. La sémantique est encore une autre question. Lorsque j'utilise correctement mes titres <h1>..., j'utilise effectivement l'aspect sémantique du HTML et les robots font de même. Mais aujourd'hui, ils n'ont pas toujours un tel comportement. Par exemple, si je souhaite qu'une page contenant des définitions informelles soit "sémantique", je devrais utiliser l'élément <dfn> : la <dfn>feurtasse</dfn> est un terme de patois morvandiau désignant une parcelle de terrain en friche. Mais en pratique, Google ne semble pas exploiter pour l'instant cet élément (du moins, rien ne l'indique d'après le code des pages référencées par google:definition). Ce qu'il exploite manifestement pour repérer des pages contenant ce type de définition, c'est l'élément <strong>... et le <b> : la <strong>feurtasse</strong> est un terme de patois morvandiau désignant une parcelle de terrain en friche. la <b>feurtasse</b> est un terme de patois morvandiau désignant une parcelle de terrain en friche. Le second exemple est le plus pauvre sémantiquement puisque <b> est un élément de présentation non sémantique.... Mais c'est justement celui qui semble avoir le plus de chance d'indiquer une définition informelle à Google (Pour le vérifier, utilisez google:definition et regardez le code-source des pages qu'il vous trouve. J'y ai trouvé essentiellement des <b>, puis des <strong>, mais jusqu'ici jamais de <dfn>. Et je serais très heureux si quelqu'un avait un contre-exemple !) Maintenant, vous avez remarqué que j'ai utilisé beaucoup d'expressions du type Aujourd'hui, actuellement, etc. Comme le dit Fabrice à propos des metadonnées Dublin Core, la validité, la sémantique... sont un investissement à faire, dans la mesure où on peut supposer que les moteurs de recherche chercheront à en tirer profit dans l'avenir.

Chercher à transposer à l'identique en CSS un rendu obtenu avec des tableaux mène souvent à ce type de déception : ces deux modes de présentation ne sont pas équivalents, en effet. Cela dit, la solution d'un contenu flottant peut te permettre d'obtenir ce que tu cherches en CSS, à condition d'utiliser l'astuce du "spacer" en fin de bloc englobant. Voir http://openweb.eu.org/articles/initiation_float/ : HTML: <div class="englobant"> <div class="content"> ... </div> <div class="menu"> ... </div> <hr /> </div> CSS: .content { float: left; width: 70%; } .menu { margin-left: 80%; } hr { clear: both; }

Il ne peut pas : le vocabulaire est identique, mais : - certaines règles de syntaxe sont différentes entre HTML et XHTML, par exemple la fermeture des balises du type <img ... />, <br />, etc. - la déclaration de type de document doit être unique (HTML ou XHTML).

Disons qu'un CMS peut-être souvent être modifié (le Hub en est un bon exemple) sans pour autant le réécrire entièrement. Tout est affaire de personnalisation, ce qui est en général assez facile sans être un "pro" du PHP par exemple, si le CMS en question est codé proprement et bien documenté. Il s'agit juste ici d'exploiter l'existant pour ajouter une fonctionnalité assez basique. Je n'ai pas testé SPIP sur ce point précis, mais : - la génération de métadonnées robots, mot-clé, description, date de publication et et de mise à jour, etc. est effectivement un point faible de tous les CMS que j'ai rencontré. - le fond du problème, AMHA, est que ces métas recèlent un énorme potentiel (voir le Dublin Core)... qui reste potentiel faute de prise en compte déterminante par les moteurs. Donc, sous cet angle, je ne crois pas que ce soit une question avec laquelle il faille se prendre la tête actuellement. Qu'en pensent les spécialistes en référencement ?

Petite phrase relevée dans la spécification HTML4.01: http://www.la-grange.net/w3c/html4.01/pres...mes.html#h-16.3 Autrement dit, l'attribut target a été conçu pour pouvoir être ignoré par l'utilisateur si celui-ci, pour une raison ou une autre, souhaite que le lien s'ouvre par exemple sans ouverture d'une nouvelle fenêtre... Ce n'est pas du tout anecdotique : on ne devrait pas essayer de définir un bon usage de l'attribut target sans tenir compte du fait essentiel qu'il ne force pas le comportement de l'utilisateur, mais qu'il est simplement là pour lui proposer un comportement... Même si ce n'est pas son implémentation actuelle.

Hum... lorsque le script en question empêche de lier une page précise du site, c'est un peu dommage, non ? Exemple classique, le pourtant excellent : GDT (Grand dictionnaire terminologique)...

J'avoue ne pas bien comprendre la question. - Le choix d'XHTML au lieu de HTML n'a aucune incidence possible sur le référencement d'un site : les moteurs de recherche actuel, à commencer par Google, traiteront de toute façon tes pages comme du HTML, et non en tant que XML. En fait, ils traiteront probablement tes pages standards comme de la soupe de tag, car rien n'indique qu'ils fassent une quelconque différence... - SPIP peut être utilisé pour produire du XHTML (quoique cela ne soit pas évident du tout). Il faut être clair, je crois, sur cette vieille utopie : le respect d'un des standards HTML / XHTML du W3C n'apportera rien quant au référencement au sens des techniques spécifiques de celui-ci. Il faut différencier en effet : - le respect d'un standard (la validité); - et l'approche "structurelle" des pages, avec l'exemple classique de l'utilisation des titres <h1>... C'est cette approche structurelle qui favorise le référencement. Il se trouve que ceux qui font des pages conformes aux standards adoptent généralement cette approche. Mais on peut tout aussi bien: - faire des pages valides très peu référençables, - respecter cette approche sans pour autant faire des pages valides. Conclusion ? Avec les moteurs de recherche actuels, respecter les standards ne nuit pas au référencement et aux techniques de celui-ci. C'est déjà beaucoup

PowerPoint produit un code spécifiquement conçu pour être exploité par un serveur Microsoft... et qui peut donc contenir de multiples "erreurs" (celle signalée par beornide par exemple) du point de vue des autres technologies serveur... En outre, les pages HTML produite sont conçues pour IE... d'où des problèmes prévisibles dans les autres navigateurs... Enfin, le résultat est en général très peu fonctionnel : code inutilement alourdi, ergonomie limitée des pages... Bref, c'est le type même d'outil à éviter pour faire des documents Web

C'est inutile. Le problème des liens adjacents du type : <a href="...">lien1</a> <a href="...">lien2</a> ...c'est qu'un navigateur vocal ne fera pas de pause suffisante entre les deux liens pour permettre à l'utilisateur de bien les différencier et de les "cliquer". C'est pourquoi il est recommandé de séparer ces liens par un caractère "imprimable", c'est à dire lu par le lecteur d'écran. Or, avec une liste <ul>, les navigateurs signalent (chacun à leur manière) la puce ou le changement d'item de liste, ce qui suffit à différencier les liens. C'est la raison pour laquelle des liens en liste <ul> ne sont pas considérés comme adjacents par les validateurs d'accessibilité (Bobby, par exemple).

Impossible de te répondre sans un code plus complet. peux-tu donner une url ?

Cette méthode du test par une image pose d'évidents problèmes d'accessibilité aux mal-voyants Il me semble d'ailleurs que le sujet avait été discuté ici il y a quelques mois ? Pour info, des alternatives ont été étudiées par un groupe de travail du W3C dans Inaccessibility of Visually-Oriented Anti-Robot Tests

heu... C'est une des CSS fournie par défaut avec Opera... qui s'applique quand on choisit le style utilisateur "Disable table"... Donc on peut espérer que ça marche dans celui-ci Sinon, ça ne marche effectivement pas dans IE, trop pauvre sur le support de "display". ça n'est pas à utiliser au final, mais plutôt comme un autre moyen de voir ce que donne un tableau une fois linéarisé.

Voir ce message sur les plugins et astuces pour HTML-Kit : http://www.webmaster-hub.com/index.php?sho...indpost&p=25172

Pour info, la linéarisation d'un tableau peut aussi être faite sans application ou script spécifique, avec une simple CSS utilisateur. Je reproduis ici celle par défaut d'Opera (mode utilisateur disable table): @charset "UTF-8"; /* Name: Disable tables Version: 1.01 Author: Opera Software ASA Description: This style sheet disables tables. Copyright © 2003 Opera Software ASA. */ table, caption, tr, thead, tfoot, tbody, th, td { display: block !important; float: none !important; max-width: none !important; min-width: 0px !important; width: auto !important; max-height: none !important; min-height: 0px !important; height: auto !important; /* text-align: left !important;*/ } thead, th {font-weight: bolder !important;}

J'y reviens tout de même pour ne pas laisser traîner ici un gros contre-sens sur l'article de BlueRobot : en effet, celui-ci donne ses deux solutions en HTML, et pas en XHTML. La première solution n'est donc évidemment pas valide en XHTML, puisqu'un changement de syntaxe est nécessaire sur la balise link (le / de fermeture): <link rel="stylesheet" type="text/css" media="print" href="print.css" /> C'est important, parce que cette solution est de loin préférable à la seconde (celle du script vide qui ajoute un code inutile dans le seul but de patcher un bug mineur de navigateur). Avec le link, le site gagne une feuille de style d'impression (à condition de prendre la peine de faire celle-ci, bien-sûr).

Html-Kit, Présenté dans cette discussion récente sur le même sujet

Pourriez-vous donner des exemples d'url (ou de la syntaxe utilisée) pour la validité du link ? En effet, un <link rel=... est parfaitement valide, s'il est correctement écrit bien-sûr. Pour la différence de temps de chargement de la CSS, l'article de BlueRobot pointe un cas effectivement très rarement rencontré, qui ne justifie franchement pas qu'on détourne le code pour si peu, AMHA...

De plus en plus... je l'ignore, mais je viens d'être confronté au problème pour la première fois... dans un wiki pour le moins ultra-confidentiel

Arg... j'ai perdu la référence qui disait tout cela en français, mais l'essentiel est accessible depuis cet article en anglais du W3C (i18n): Tutorial: Using language information in XHTML, HTML and CSS (DRAFT)

En fait, ce qui fait tant de tort à IEWin, outre les problème de sécurité, c'est surtout son absence d'innovation depuis... quand déjà ? Je trouve assez intéressant le fait qu'IE Mac ait été, en son temps, le navigateur le plus innovant en termes de support CSS par exemple... et que son principal contributeur ait récemment quitté microsoft Tiens, au passage, une bonne analyse des enjeux d'une éventuelle future version d'IE...

Bienvenue sur le Hub, Steph. Une amélioration de l'ergonomie de tes tutoriels de bidbooster.net, à envisager : ajouter la possibilité de consulter un tutoriel en entier sans avoir à aller d'étape en étape... Pour qui cherche une info se trouvant dans une étape donnée, c'est plus pratique que de devoir passer par toutes les pages les unes après les autres