Denis

Effectivement, tout ceux à qui j'ai montré cette animation ont automatiquement vu la différence entre la méthodologie de conception traditionnelle et celle conforme aux normes. Quand on dit qu'une image vaut mille mots, ici, c'est plus de l'ordre du 10 000 mots.

Je partage ton avis. Par contre, ce qu'il y a de pire encore, c'est quand j'arrive sur un site avec mon Firefox sous Mac OS X et qu'on me dit que je dois télécharger Internet Explorer pour pouvoir naviguer sur le site en question.

C'est marrant, moi c'est justement un des trucs qui me séduisent le plus de PunBB justement. À chacun son PunBB, en fonction des besoins.

Oui, sûrement. Et c'est normal, car on devient tous plus efficaces avec nos outils de prédilection, quels qu'ils soient. L'important, c'est que nos choix s'arrêtent autant que possible sur des outils agréables à utiliser et qui produisent des résultats de qualité (reste alors à définir ce qu'est la qualité, mais c'est un débat que je nous réserve pour un autre thread, pas celui-ci). Si ce n'est pas le cas, alors ça devient un peu plus problématique. Au fond, c'est pas ça l'important? Ceci dit, je voudrais bien que ça m'engage aussi!

J'avais cru comprendre que le PageRank avait perdu de sa pertinence d'antan...

Hummm. ça porte à réfléchir, c'est clair... mais en même temps, avec le temps et la prise de conscience montante face aux normes, peut-être est-ce différent aujourd'hui. Car après tout, il est tout de même vrai que les sites qui utilisent (exploitent) un HTML valide, sémantique et conforme ont une tendance naturelle à bien se positionner sans trop d'effort... qu'en comprendre?

Donc que la configuration par défaut d'Apache veille à protéger ces types de fichiers?

De toute manière, j'imaginerais mal Dan avoir le temps de fouiller là-dedans pour assouvir une quelconque curiosité voyeuriste...

Si un tel changement vien un jour à arriver, il faudrait que les ingénieurs de Google soient assez lucides pour prévoir le spam potentiel et juger d'une manière de bien doser la quantité de balises hx par rapport aux contenus... ce qui serait simple d'un point de vue de l'algo, mais terriblement compliqué du point de vue de l'évaluation des risques d'abus de la part des concepteurs. Une page ne peut pas avoir 300 h1, comme je l'évoquais plus tôt dans cette discussion. Quant aux synthétiseurs vocaux, ça ne change rien, l'information pouvant être tout aussi bien lue. Cependant, d'un point de vue d'accessibilité, ce pourrait être catastrophique parce que les utilisateurs faisant appel à ces technologies d'assistance perdraient encore une fois un des indicatifs clairs leur permettant de se faire une image globale du contenu de la page (en assumant bien sûr que les contenus des hx soient pertinents et utilisés dans l'esprit de structure de contenus, comme dans une table des matières). Scoring? Bon, c'est quoi ce truc encore?

Là on est d'accords par contre... je ne crois pas que la sémantique occupe une place privilégiée dans le coeur de Google... ce que je crois là-dessus, c'est qu'à positionnement égal, la sémantique devrait faire une différence (mais que par elle-même, elle ne vaille pas encore grand chose, pas plus que la conformité d'ailleurs). Pour le reste, je suis globalement d'accord avec toi, quand on place justement la question en regard de l'ensemble des éléments pris en compte dans les algorithmes.

Ok, je suis convaincu. Après tout, mieux vaut prévenir que guérir, et mettre toutes les chances de son côté.

La première question que j 'ai envie de te poser c'est pourquoi douterais-tu de l'importance du poids de cet élément? Crois-tu réellement que pour trois manières d'écrire un titre soit : <h1>Titre de la page</h1> <p style="font-size: 125%; font-family: verdana; font-weight: bold;">Titre de la page</p> <font face="verdana" size="5"><b>Titre de la page</b></font> Que pour Google ce soit du pareil au même? Que le moteur est assez intelligent pour comprendre que c'est un titre, donc un identifiant de contenu? Personnellement, j'en doute fort. Il y a une différence fondamentale entre les éléments hx et les balises meta. Les balises metas n'ont aucune valeur sémantique, mais plutôt une valeur de meta-information ce qui est complètement autre chose. De plus, contrairement aux éléments HTML contenus dans le <body>, il n'y a aucune association directe entre le contenu d'une balise meta et le véritable contenu d'une page Web. C'est pourquoi ces balises ont rapidement perdu leur raison d'être et leur pertinence et que l'on peut encore discuter de la pertinence des éléments avec une réelle valeur sémantique. Bon c'est malin ça, je me suis pi**é dessus!

Tiens, ça m'avait échappé ça. Merci pour le tuyau, je vais y jeter un oeil! Si d'autres ont des opinions, ne vous gênez pas.

Hé, hé... vraisemblablement, nous ne sommes pas passés par les mêmes intensités de discussions sur le sujet! J'en ai vu "des vertes et des pas mûres" qui n'ont pas manqué de me rappeler les guerres entre Mac et PC ou Netscape et Internet Explorer quand venait le temps de faire valoir un CMS par rapport à un autre. Ceci étant dit, il faut bien sûr prendre ma remarque au second degré. Je crois que comme dans toute chose, il faut se méfier de l'opinion de quiconque n'a aucun recul vis-à-vis sa propre opinion. Rien n'est jamais tout noir ou tout blanc et aucun CMS, pas plus qu'aucune manière de développer du Web n'est entièrement bonne ou mauvaise. Il faut juste savoir piger dans tout ça et en retirer le meilleur, pour la situation ou le besoin qui nous concerne au moment précis où celui-ci se pointe.

Donc la question est toujours d'actualité... pourquoi est-ce nécessaire de placer les deux fichiers à des endroits différents s'ils ne peuvent être récupérés par l'URL? Qu'est-ce qu'un hacker pourrait bien faire pour contrer la dynamique serveur d'une 403?

Je suis entièrement en désaccord et, avec tout le respect que je te dois, je ne crois pas que tes arguments (ou craintes) soient fondés - après tout, la raison d'être de cet élément, c'est de baliser le ou les titres d'une page... et en tant que tels, ils devraient être pris en compte puisque par définition, un titre peut potentiellement bien représenter le contenu qui le suit. Évidemment, si quelques abuseurs commençaient à créer des pages contenant 300 balises h1, ce serait autre chose... mais l'abus de ce type est facilement identifiable, il n'y a qu'à les dénombrer et mesurer le nombre de mots contenus dans chacun d'eux pour savoir si on fait face ou non à un usage abusif.

Quelqu'un aurait de l'expérience avec ce Forum? http://www.punbb.org/ Semble prometteur, mais avant de le considérer sérieusement, j'aimerais recueillir quelques commentaires de personnes qui le connaisssent un peu. Merci d'avance!

Effectivement, c'est une distinction intéressante. Car chez OpenWeb et AlsaCréations, on assume quand même un mimum de connaissances, ne serait-ce pour être capables de suivre la logique qu'impose la manière conforme de développer du Web. Les premiers articles référés devraient d'abord et avant tout expliquer les différences entre les méthodologies de conception traditionnelles par opposition aux méthodologies de conception normalisées. Un bel exemple de ce que tout cela veut dire, et qui démontre en même temps tout l'intérêt de séparer la structure d'un document de sa présentation : http://mboffin.com/stuff/designline-openair.gif Enjoy!

Ah parfait. Merci Sébastien pour la confirmation. Si c'est ce que je reçois sur mon propre serveur et que je n'ai rien fait de particulier pour le protéger, alors ce comportement est probablement valable partout...

Il y a certainement un truc qui m'échappe car si (théoriquement) c'est effectivement possible d'aller récupérer le .htaccess via le navigateur, rien de plus facile que de retrouver le .password par la suite, peu importe où il se trouve, si sa localisation est inscrite dans le .htaccess ... J'ai mal compris?

Au moins, c'est un annuaire contenant des ressources de haut niveau. C'est globalement positif.

Une question me trotte en tête depuis un moment à propos des .htaccess et .htpassword justement... c'est pas un peu facile d'aller les récupérer en saisissant leurs adresses en dur dans l'URL? J'ai essayé sur mon propre serveur, et ça me semble impossible, mais est-ce théoriquement possible sur un serveur ou ce type de fichiers ne seraient pas à priori protégés contre les regards indiscrets?

D'autres alternatives à SPIP qui pourraient aussi produire du code conforme (avec un minimum d'effort) : Plone Xoops Typo3 Certains membres du Hub pourront te vanter les mérites des uns et des autres. C'est une guerre de religion dans laquelle je préfère ne pas trop entrer.

Toujours. Et c'est le plus loin que nous pouvons aller dans nos hypothèses sur la question sans pour autant tomber dans les suppositions.

C'est pourquoi sémantiquement le HTML nous offre une série d'outils à ajouter dans notre arsenal : h2, h3, h4, h5, h6, p, blockquote, ul, ol, etc. À chaque outil son utilité et les pages Web seront (encore) mieux référencées!