Denis

Si je n'étais pas déjà convaincu, cet exemple visuel entrainerait ma conversion immédiate aux css ! 

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.

Perso, je suis assez intransigeant lorsque le site demande (oblige?) l'utilisation de tel ou tel logiciel.

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.

Le seul "hic" (c'est aussi une de ses forces) c'est qu'il n'integre que les fonctionnalités minimum. La communauté des utilisateurs est toutefois tres active, et beaucoup de mods sont disponibles

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.

Denis, je crois qu'au fond on est d'accord... Mais j'avoue que même si j'ai du recul par rapport au choix d'un CMS (qui n'est qu'un outil, pour finir), j'ai un avis assez clair sur les outils avec lesquels je préfère travailler.

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.

Ceci dit, ça n'engage que moi

Au fond, c'est pas ça l'important?

Ceci dit, je voudrais bien que ça m'engage aussi!

Ensuite il multiplie le nombre de point obtenues par le PR pour obtenir le score final.

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

il me semblait bien avoir vu un test sur l'impact de la balise H1 sur le positionnement d'une page: le voila ... il date un peu mais bon ...

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?

Il ne me semble pas que le fait que le fichier soit caché interdit l'accès au fichier, c'est plutot au niveau de la config d'apache qu'il est précisé que .htaccess est un fichier "protégé" non ?

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

Cela permet d'éviter le spam... même si je ne vais voir les logs que si un membre se plaint de recevoir du spam par email. Cela a déjà valu à quelques membres de se faire interdire de post, MP et email.

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

bon, alors imaginons maintenant que ce poids augmente au point qu'il devienne un élément prépondérant dans le positionnement d'une page ... que risque t'il de se passer ? nous risquons de voir fleurir des pages avec des balises Hx dans tous les sens (on voit déjà des pages avec des balises H1 bourrées de mots clés) ... comment se comporteront les lecteurs vocaux avec de telles pages ?

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).

C'est bien pour ça que les moteurs multiplient les critères de scoring

Scoring? Bon, c'est quoi ce truc encore?

c'est pour cela et pour les raison que j'ai essayé de développer plus haut que je ne pense pas que ces balises n'aient un poids important en regard de l'ensemble des élements pris en compte dans le positionnement d'une page ... mais ce n'est que mon avis ...

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é.

mais ne pense tu pas, s'il s'avérait (voire même si juste une rumeur dans ce sens se répendait) que ces balises ont un poids important (ce que je ne pense pas) dans le positionnement des pages, qu'elles seraient alors rapidement et massivement détournées de leurs fonctions et du coup perdraient tous sens sémantique (un peu comme ce fut le cas de la méta keyword)? 

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.

D'ailleurs les moteurs ne devraient pas tenir compte du contenu des sites, c'est trop facilement manipulable, les webmasters pourraient se mettre à écrire

Bon c'est malin ça, je me suis pi**é dessus!

J'en entends beaucoup de bien, c'est le forum utilisé sur le site Dotclear...

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.

Guerre de religion, n'exagérons 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é.

Pour en revenir aux "guerres de religion" si je critique aussi souvent ces deux solutions c'est qu'on a souvent tendance à ne jurer que par elles alors qu'elles ne sont pas parfaite et qu'il y a peut-être mieux dans certains contexte et pour certains projets... Il faut savoir évoluer, se remettre en question voilà tout ce que je dis 

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?

le problème c'est que s'il le fait, cela risque de rapidement dénaturer l'utilisation de ces balises

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!

Je suis entièrement d'accord, c'est d'ailleurs pourquoi je ne dirige jamais le tout débutant (ou celui qui n'a jamais utilisé que du WYSIWYG) vers Alsacreations ou Openweb qui sont les réfèrences pour l'étape suivante.

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.

A mon avis, la première chose à faire est de prendre ta page et enlever toute la mise en page qui n'a rien à y faire (les balises font, les hauteurs et les largeurs (sauf images),  les attributs, etc.). Ensuite il n'y a pas de secret il faut se plonger dans le sujet !

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!

Le point dans ".htaccess" signifie un fichier caché, et un accès direct retourne une erreur 403 (forbidden).

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...

Attention, il faut mettre seulement le .htaccess dans la directory htdocs et .... le .htpasswd ailleurs (dans les /home ou les /etc par exemple) On met seulement le chemain du .htpasswd dans le .htacess.

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?

bon, ben cela ne devrait pas contribuer à baisser la pression déjà très importante sur cet annuaire ...

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.

On en revient tous simplement à la question de la sémantique.

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.

Ensuite ce n'est pas parce que le titre de ton livre n'est pas "dieu" que le contenu du livre n'est pas truffe de ce mot cle (et la a priori dans la bible il y est un ou 2 fois quand meme) donc du coup je pense que sur la requete "dieu" il y a des chances pour que la bible (toujours dans notre analogie) ressorte plutot bien.

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!