Ernestine

Bienvenue quand même

Salut, Empêcher l'indexation d'une page peut notamment servir à éviter du duplicate content par exemple. Certains l'utilisent aussi pour éviter la dilution de pagerank vers des pages sans intérêt, mais il me semble avoir lu dernièrement sur ce forum, que désormais, ce phénomène de dilution de pagerank n'existait plus, ou du moins est beaucoup moins marqué qu'avant (à confirmer par les experts). Par contre, je ne sais pas quelle est la différence profonde entre un "noindex" dans les métas de la page, et une directive dans le fichier robots.txt, je pense que le résultat est identique d'un point de vue SEO (également à confirmer par les experts).

Salut Hugo, Le plugin Autocomplete de jQuery UI devrait faire ton bonheur : http://jqueryui.com/demos/autocomplete/ Si le nombre de propositions n'est pas énorme (quelques dizaines/centaines), tu peux charger directement la liste au départ, ce qui évitera les requêtes Ajax.

Je ne connaissais pas, au temps pour moi. Ça m'apprendra à chercher un peu avant de dire un truc

Salut, Impossible en CSS. Changer la classe de certains li avec php, pourquoi pas, mais ce n'est pas terrible, faire du php pour de la décoration... Mieux vaut le faire en javascript. Déjà, dans le css, mettre une puce commune à tous les li, à l'aide non pas de "list-style-image", mais tout simplement un background-image aux <li>. Ensuite, avec jQuery, il est très facile de sélectionner certains li (par exemple un sur deux) et de lui appliquer un changement de propriété, en l'occurence modifier la valeur de la propriété background-image.

Salut, Il est interdit de modifier le bouton : Source : http://www.google.com/webmasters/+1/button/policy.html De toutes façons même si c'était autorisé ce ne serait pas possible à mon avis : le code génère une vieille iframe sur laquelle tu n'as pas vraiment la main.

Effectivement, déclencher le rechargement côté client à partir du serveur, c'est une toute autre histoire, beaucoup plus compliquée

Salut, Apparemment ce n'est pas un bug : c'est tout simplement que le rechargement automatique n'est pas prévu. La page se recharge uniquement quand le formulaire est soumis. Je pense que tu peux faire un refresh automatique toutes les cinq secondes en ajoutant ceci au code : setInterval(function(){ updateShoutbox(); }, 5000); A ajouter par exemple juste après : //Load for the first time the shoutbox data updateShoutbox();

Ceci est du barratin : le webmaster de cet annuaire a juste envie de recevoir un lien, et au lieu de le demander franchement et honnêtement, il passe par quatre chemins en essayant de nous faire croire qu'on va y gagner quelque chose.

Je n'ai jamais rencontré ce genre de problèmes avec Cufon, qui n'a en principe aucun impact sur les propriétés CSS.

Effectivement, c'est "Times New Roman" qui est standard. Cependant, Times et Times New Roman, c'est très similaire : Times : http://www.identifont.com/list?2+times+1+WP+1+WM+577+3ZG+793+WR+987+58M+1035+7BT+1058+8KA+1081+1WCS+1081+2258+1081+7XV+1081+CT+1081+L27+1081+L29+1081+382+1081+WO+1081+GUK+1081+2BC+1081+58L+1081+8KY+1081+DDV+1081+J7K+1081+WQ+1081+3R4+1081+NJE+1081 Times New Roman : http://www.identifont.com/find?font=times&q=Go La différence est quasiment invisible à l'oeil nu. A la limite, la différence est un peu plus visible en italique : Times italique : http://www.identifont.com/list?2+times+17+WP+1+WM+577+3ZG+793+WR+987+58M+1035+7BT+1058+8KA+1081+1WCS+1081+2258+1081+7XV+1081+CT+1081+L27+1081+L29+1081+382+1081+WO+1081+GUK+1081+2BC+1081+58L+1081+8KY+1081+DDV+1081+J7K+1081+WQ+1081+3R4+1081+NJE+1081 Times New Roman italique : http://www.identifont.com/list?2+times+4+WP+1+WM+577+3ZG+793+WR+987+58M+1035+7BT+1058+8KA+1081+1WCS+1081+2258+1081+7XV+1081+CT+1081+L27+1081+L29+1081+382+1081+WO+1081+GUK+1081+2BC+1081+58L+1081+8KY+1081+DDV+1081+J7K+1081+WQ+1081+3R4+1081+NJE+1081 Les lettres sont un peu plus épaisses en Times italique, le A majuscule est moins penché, et surtout le z minuscule est assez différent. S'il n'y a aucun texte en italique dans la page web, il n'y a donc aucun problème à utiliser Times New Roman plutôt que Times. A moins de tomber sur un graphiste hyper pointilleux qui ne supporte pas le moindre écart entre sa maquette et le rendu final à l'écran, ce qui peut arriver, surtout avec les graphistes habitués au print. Et de toutes façons, comme dit Dudu, cette police de caractères est tout à fait inadaptée à la lecture écran. Personnellement ça fait des années que je n'ai pas vu la moindre maquette comportant cette police, ou alors sur des bouts de texte très ponctuels. En général, dans les polices avec serif, on recommande plutôt la Georgia, qui est standard et beaucoup plus lisible à l'écran.

Il y a un vieux proverbe zen qui dit : "Une fois que tu as tout appris, tu dois tout oublier". Cela signifie que lorsqu'on parvient à la maîtrise dans un domaine, alors tout devient intuitif et évident, sans avoir besoin de se référer à telle ou telle technique. Effectivement, un expert en référencement ou ergonomie ou accessibilité ou autre, n'a plus besoin d'une checklist pour faire son travail. Mais quand on ne maîtrise pas encore, ça aide

Allons pas de chichis Ce n'est pas une compétition et on se fiche complètement de savoir qui est bon ou moins bon. Le seul truc qui compte, bien plus que le niveau, c'est l'aide que l'on reçoit/apporte. Personnellement je préfère quelqu'un qui ne sait pas grand chose mais qui partage ses connaissances, plutôt que quelqu'un de très fort qui garde tout pour lui.

Salut, Niveau accessibilité, tu peux checker cette liste : https://checklists.opquast.com/opquastv2

Bonjour, Dans cette conversation il est question de deux cas extrêmes : tout coder à la main ou utiliser un CMS. C'est oublier qu'il existe une solution intermédiaire : les frameworks, comme Symfony. Avec Symfony, on fait tout à la main, on design le schemas de BDD, on organise les modules, etc, tout en partant sur un socle solide, et en profitant de fonctionnalités qui permettent de gagner du temps, telles que la génération d'un CRUD en ligne de commande à partir d'une simple class, un système de création/validation de formulaires, un ORM, etc Faire du php en utilisant Symfony, c'est un peu comme faire du javascript en utilisant jQuery : on code à la main, mais on bénéficie d'un environnement tout prêt et performant.

Bonjour, En effet, @font-face fonctionne parfaitement sur ie7. Pour le mettre en place facilement, je te conseille d'utiliser ce générateur : http://www.fontsquirrel.com/fontface/generator qui, à partir d'un fichier de police, te fournit tous les fichiers nécessaires (.eot, .svg, .ttf, .woff) ainsi que le code @font-face à insérer dans la feuille de styles. Il y aussi la possibilité d'utiliser Cufon (c'est du javascript), qui n'est pas si sale que ça à mon humble avis, si on l'utilise avec parcimonie (à éviter sur des textes entiers). Evidemment, @font-face est préférable. Mais sous Chrome, le rendu des gros titres, avec @font-face, est assez mauvais (polices crénelées). Voila pourquoi, personnellement, j'utilise Cufon pour les gros titres, et @font-face pour les textes. Ou alors j'ajoute un très léger shadow sur les textes pour atténuer le crénelage. Attention quand même à ne pas surcharger la page et augmenter son poids. Embarquer une police (quelle que soit la méthode choisie), ça fait du chargement en plus. Ton client veut quatre polices différentes, dont trois qui ne sont pas standard, ce n'est pas une bonne idée à mon humble avis. Il y a fort à parier que le graphiste qui a pondu cette maquette n'est pas un graphiste orienté web. D'ailleurs, dans les normes d'accessibilité généralement publiées (Opquast, Accessiweb), il est conseillé de ne jamais utiliser plus de trois typographies différentes au sein d'un site web, pour des raisons de lisibilité et de cohérence visuelle. Voir : https://checklists.opquast.com/11/criteria/702/

Salut Tabouet, Aucune idée de ce qu'on peut faire avec Blogger, mais si ta première idée était d'utiliser Wordpress, eh bien si j'étais toi je resterais sur cette première idée (Wordpress, SPIP ou autre CMS). Un hébergement de nos jours, ça ne coûte pas plus cher qu'un livre d'Hérodote, et au moins tu serais chez toi. Et vu la quantité énorme de plugins wordpress, tes possibilités seront toujours largement supérieures qu'avec Blogger. Et puis il sera plus facile de faire évoluer le site par la suite, voire de le migrer sur un autre systètme, etc...

Bonjour, Sur Safari mobile, le scroll à un doigt n'a d'effet que sur le body. S'il y a une div (ou autre bloc) dans la page qui nécessite un scroll (c'est à dire un bloc avec un overflow: scroll ou auto), alors il faut scroller avec deux doigts sur ce bloc. Ce comportement est malheureusement ignoré par de nombreux utilisateurs d'iPad/iPhone et c'est assez problématique : en voulant scroller sur un bloc, c'est la page toute entière qui scroll (vu que l'utilisateur n'utilise qu'un seul doigt pour scroller). Savez-vous s'il existe un moyen d'annuler ce comportement de Safari mobile, de dire au navigateur : tout scroll basique (à un doigt) doit être fait non pas sur le body, mais sur le bloc où le glissement de doigt est effectué ? L'idéal serait un simple paramétrage. Au pire un script javascript, à condition qu'il soit léger et que le résultat soit fluide. Merci

Heu oui, je n'ai rien à ajouter de plus que ce qu'a répondu Captain ci-dessus Ce qui peut aussi empêcher de fonctionner un js externe, c'est quand celui-ci contient des variables définies en php (ça va de soi), mais ce n'est pas ton cas. Sinon, ouvre ta page avec Chrome et appuie sur F12 pour voir les éventuelles erreurs (comme par exemple un fichier introuvable).

Si le script appelant (le javascript) et le script appelé (php) sont destinés à être sur le même site web (plus précisément sur le même domaine), alors le plus simple, c'est d'écrire tes urls en relatif, par exemple : machin.php ou ../truc/machin.php Ou bien en semi-absolue, c'est à dire à partir de la racine du domaine, donc en commençant par un slash : /machin.php ou /truc/machin.php etc... Ainsi, que tu sois en dev ou en prod, l'arborescence étant la même, ça marche dans tous les cas et tu n'as rien à changer C'est uniquement si le script appelant et le script appelé ne sont sont pas sur le même domaine qu'il faut alors écrire les urls en absolue (url complète avec le nom de domaine). Dans ce cas, l'idéal est de définir une bonne fois pour toutes une constante ayant pour valeur le nom de domaine où se trouve le script appelé.

Pour que ça fonctionne quel que soit l'emplacement de la page web exécutant le javascript, il suffit simplement d'écrire l'url absolue dans la requête ajax. Si l'url n'est pas absolue, alors il devient nécessaire que le chemin relatif soit toujours exact. En fait, ajax ou pas ajax, c'est pareil pour n'importe quelle requête...

Mettre du "nofollow" sur des liens postés par des visiteurs, c'est déjà très discutable, mais le faire sur des liens que tu as toi-même choisi de placer, c'est limite mesquin

Salut, Grosso modo, la fréquence de visite des bots Google est proportionnelle à la fréquence de mise à jour du site. Si un site est mis à jour plusieurs fois par jour, le bot passe plusieurs fois par jour, et s'il n'est mis à jour qu'une fois par mois, le bot s'adapte et passe une fois par mois (en simplifiant, en général il passe quand même beaucoup plus souvent). Evidemment d'autres critères entrent en compte : un site populaire (du moins jugé tel par google) est plus souvent visité par le bot qu'un site inconnu, etc... C'est un double avantage pour Google : si le site est rarement mis à jour, Google ne consomme pas de ressources à le visiter inutilement toutes les heures, et d'autre part, si le site est mis à jour intensivement, Google s'assure que son index sera quasiment synchrone avec le web. Donc au final, à mon humble avis, la réponse à ta question est sans importance : si tu fais une seule mise à jour par mois sur un site web, la nouvelle page ne sera prise en compte par Google qu'après un certain délai. Mais on peut considérer que ce n'est pas grave, puisque s'il n'y a qu'une mise à jour mensuelle, il n'y a aucune urgence à ce qu'elle soit rapidement prise en compte. Par ailleurs, ce n'est pas parce que google va visiter le site intensivement plusieurs fois par jour ou par heure, que les pages seront pour autant mieux placées dans les résultats (du moins ce n'est pas un rapport direct de cause à effet, et d'autres critères entrent en ligne de compte). Quant au calcul de la fréquence des visites par les bots Google, je pense que c'est une équation compliquée, que personne ne connaît précisément en dehors de Google lui-même Elle est en tout cas certainement beaucoup plus compliquée que celle que tu proposes (durée de vie du site divisée par le nombre de mises à jour depuis sa naissance). Mais il est certain qu'il vaut mieux des mises à jour régulières et agréablement réparties dans le temps. Google tient aussi compte de l'effet buzz : quand un sujet est d'actualité à un instant T, les sites/pages traitant de ce sujet sont alors plus souvent visitées par le bot, qu'en temps normal. Voila, ce n'est que ma réponse, je ne suis pas spécialiste en référencement, alors mieux vaut attendre d'autres réponses.

Eh oui, car l'acronyme WYSIWYG signifie : What you see is what you get plus a lot of garbage

Salut Melkior, Ici, plus qu'un problème de HTML ou de CSS, c'était surtout un problème de Dreamweaver : tu nous dis qu'il effectue le réglage des marges des images avec des hspace et des vspace : c'est nul Conclusion : tu as dû ajouter toi-même la propriété margin, c'est à dire court-circuiter le fonctionnement normal de Dreamweaver. Au final, avec Dreamweaver ou tout autre logiciel Wysiwyg, on passe plus de temps à corriger les horreurs qu'il produit, qu'on en aurait passé à faire les choses à la main dès le départ Tu aurais donc tout intérêt à poursuivre dans cette voie.