captain_torche

En jQuery, tu vas quand même bien galérer pour pas grand-chose ... A la rigueur, pourquoi ne ferais-tu pas les liens seulement en flash ? (Par contre, fais en sorte que le flash remplace les liens "normaux" au chargement de la page via jQuery).

Là, le souci, c'est que même si le site fonctionne, il renvoie une en-tête 500 (Erreur serveur). Dans ces conditions, Google ne va pas plus loin. Donc, le site n'est pas blacklisté, c'est tout simplement que Google considère qu'il ne fonctionne pas, donc il ne l'indexe pas.

Merci d'avoir posté la réponse, dimi3 !

Bonjour, Cet effet est-il réellement indispensable ?

Si tu utilises des .gif au lieu de .png, à moins d'avoir une transparence sans dégradé, tu vas galérer.

Techniquement, il est possible de trouver des collisions avec le MD5 (deux données qui génèrent le même hash), mais il n'y a aucune garantie de retrouver la chaîne d'origine.

Je le sais parfaitement, mais je parle de hash, qui est un algorithme par définition non décryptable. De (très) nombreux sites, forums et autres utilisent cette méthode, et seraient donc de facto hors-la-loi ?

Moi je lis "le mot de passe AINSI que les données permettant de le vérifier", et non pas "le mot de passe OU les données permettant de le vérifier". Le hash seul rentrerait dans cette seconde formulation, mais ne correspond pas à mon sens à la première.

Et donc, que va t'il se passer quand un site sera dans l'impossibilité technique de fournir un mot de passe aux autorités ?

Si on en croit les stats d'IE6 countdown, il y a un pourcentage d'utilisation mondiale de 12%, avec une très forte proportion en Chine. Sur les sites du boulot, destinés à une population française, on tourne autour de 5-6%.

As-tu corrigé ton code, et mis la balise DOCTYPE en TOUT PREMIER (Sans espace ni saut de ligne avant) ? Si ce n'est pas fait, Internet Explorer passe en mode "Quirks", et interprète le code de manière "historique", pour que les sites codés il y a longtemps continuent de se comporter de la même manière (Il utilise notamment le modèle de boîte IE). Avec un doctype valide, il passe en mode Standard, et la gestion du modèle de boîte devient identique aux autres navigateurs. Ca serait bête de te prendre la tête à bidouiller des CSS, alors que tu n'as qu'une seule ligne à modifier. Plus d'infos dans cet article : http://www.alsacreat...-ou-quirks.html

Tout dépend de comment sont gérés tes polygones. J'avais fait quelque chose de similaire il y a un moment, et lorsque j'appelais les coordonnées du polygone, je générais un KML avec un point sur 20. http://www.webmaster-hub.com/topic/45931-google-maps-recuperer-les-contours-des-regions-francaises/

Non,je ne te fais sélectionner que les pages qui commencent par des chiffres. Quant aux deux paramètres, je ne vois pas pourquoi ?

Et en faisant RewriteRule ^([0-9]+)-.* /index.php?perso=$1 ?

Le souci, c'est surtout que : il a commencé à exploiter son site avant toi. C'est surtout ça le problème. Si la seule antériorité de dépôt du NDD suffisait, je réserve maintenant plein de noms de domaines sans les exploiter, et je fais des procès à tous ceux qui lancent un site avec un domaine similaire plus tard. Pour ton second point, la génération de son contenu n'entre pas en ligne de compte pour justifier de sa légitimité. Et pour le dernier, je vais dire : ton site fait pour l'instant beaucoup moins : il n'est pas en ligne alors que le sien si.

Je t'envoie mon mail par MP.

Le souci, c'est que quoi qu'il arrive, son site sera exploité depuis plus longtemps que le tien. Comme vous avez des activités similaires, il peut très bien t'attaquer pour parasitisme.

C'est tout simplement une image, non ? À moins que je ne comprenne pas ta question.

C'est sur ton ordinateur que ça ralentit, ou sur tous ceux qui visitent le site ?

Que veux-tu dire par "parquer" ton ancien nom de domaine ? Si tu veux dire "ne plus le payer", c'est la pire des choses à faire. Pour que tout fonctionne de manière optimale (Même si un changement de nom de domaine est TOUOURS risqué), il faut que les deux noms de domaines (ancien et nouveau) pointent vers le même hébergement. Dans tes règles de réécriture, fais en sorte que tous les appels commençant par l'ancienne url soient redirigés vers la nouvelle. Tu devras conserver (et donc payer) l'ancien nom de domaine jusqu'à ce que tous les liens vers ton ancien site (Y compris les liens depuis d'autres sites) aient disparu. Il va falloir que tu contactes les webmasters des sites qui ont fait des liens vers le tien, et leur demander (sans garantie de succès) qu'ils changent les urls.

Le service commercial de Ciel n'a pas pu répondre à tes questions, ou tu as peur qu'elles soient un peu biaisées ?

Je pense que webytime fait référence au dernier article de Laurent sur Adicie.

En ce qui concerne la conservation des mots de passe par un hébergeur, est-ce une obligation légale désormais ? Techniquement, aucun hébergeur sérieux ne stockerait de mot de passe "en clair" dans une quelconque base de données. C'est le plus souvent un hash (une empreinte du mot de passe, non décryptable) qui est stocké, et qui ne permet aucunement de connaître le mot de passe originel.

En fait, je voulais savoir s'il est attribué à un seul li (dans le code généré), ou à plusieurs, auquel cas il y aurait un souci.

Dans le code source, le .current est attribué à quel(s) élément(s) ?