Ernestine

Si je passe de mapage.html#monAncre1 à mapage.html#monAncre2 puis à mapage.html#monAncre3, chaque fois que je passe d'une ancre à l'autre, la page ne se recharge jamais, ça reste toujours la même page (donc aucun évènement n'est déclenché, notamment pas un window.onload)

Sur une page donnée il y a plusieurs ancres : quand l'utilisateur passe d'une ancre à l'autre (en cliquant sur les liens ou bien en faisant "Précédent / Suivant" dans son navigateur), la page ne se recharge pas...

Bonjour, Je cherche le moyen de détecter un changement d'ancre dans la page. Par exemple si j'ai un lien du style : <a href="#monAncre">cool</a> Et ailleurs dans la page : <a id="monAncre"></a> Je veux détecter l'évènement "Arrivée sur l'ancre". Vous allez me dire : tu n'as qu'à simplement détecter le clic sur le lien qui mène à cette ancre. Oui mais non car l'utilisateur peut aussi arriver sur cette ancre en cliquant sur le bouton "Précédent" de son navigateur, ou bien directement dessus s'il a mis l'url avec l'ancre dans ses bookmarks, etc... Comme vous l'aurez sûrement deviné : le but est de pouvoir gérer l'historique de navigation (Précédent / Suivant) pour un site full Ajax : chaque "arrivée" sur une ancre déclenchant donc le chargement d'une nouvelle vue. Au départ je pensais naïvement qu'un simple focus() suffirait (je pensais que quand le navigateur se plaçait sur une ancre, cette ancre prenait le focus), mais non. Pour l'instant le seul truc que j'ai trouvé est franchement pas terrible : un timer qui, chaque seconde, regarde l'url pour voir sir le hash (ce qui suit le #) a changé Avez-vous une solution ? Merci.

Bonjour, et bienvenue quand même

Non mais après tout dépend du contexte, des éléments qu'il y a autour, etc... Quand je parlais de mettre un inline-block sur le lien, c'était dans le but de pouvoir lui appliquer des dimensions, mais évidemment c'est à adapter, je ne sais pas ce que tu as autour. En épurant tes styles CSS au maximum (entre autres sans les border-radius) la différence de rendu est toujours la même (mais tout rentre dans l'ordre avec le input::-moz-focus-inner) Sinon, je me demande pourquoi tu as un gros pâté de border-radius, alors qu'un simple : border-radius: 12px; suffirait. En effet, border-radius (sans préfixage) est reconnue par Firefox, Chrome et Opéra depuis déjà plusieurs versions, ainsi qu'IE9. Tes préfixages n'ont évidemment aucun effet sur IE8-, et la proportion de gens utilisant des (relativement) anciennes versions de Firefox, Chrome et Opéra est quand même assez faible, en tout cas suffisamment faible pour éviter de charger le code avec toutes ces lignes. Après, si vraiment tu y tiens, tu pourrais tout au moins te contenter de : -moz-border-radius: 12px; -webkit-border-radius: 12px; -khtml-border-radius: 12px border-radius: 12px; (pas la peine de le faire pour les quatre coins puisque la valeur est la même) Quoiqu'il en soit, si vraiment tu n'y parviens pas, tu peux toujours déclarer deux class différentes (une pour les boutons, une pour les liens)

Bonjour, bienvenue

Google n'est jamais qu'un visiteur comme un autre... donc oui, un mot de passe l'empêche d'accéder au contenu.

Merci Aenoa mais c'est au niveau de la connexion qu'était le problème J'ai fini par trouver en bidouillant partout dans les options : il fallait aller dans les options Internet dans l'onglet Connexions, puis sur Paramètres réseau et cocher la case "utiliser un serveur proxy pour votre réseau local". Je ne sais pas pourquoi ça marche, mais ça marche

Bonjour, Sur mon PC portable, j'ai installé un serveur Apache avec tout le reste (php, mysql, etc) afin de travailler en local. J'accède donc à mes sites de test par des noms de domaines définis dans le fichier HOSTS et des hôtes virtuels configurés dans le fichier de conf d'Apache. Il m'arrive très souvent de devoir travailler sans connexion internet. Le problème : si je ne suis pas connectée à internet et que je tente d'accéder à un site local, Internet Explorer m'affiche une vieille petite fenêtre avec un double choix : "Travailler hors connexion" ou bien "Se connecter à internet". Evidemment la deuxième option est à éliminer (puisque dans ces moments-là je n'ai pas de connexion), mais si je coche "Travailler hors connexion", alors Internet Explorer n'essaie même pas de se connecter à mon serveur local et m'affiche une page blanche sous prétexte que je ne suis pas connectée à Internet ! Tout se passe très bien avec tous les autres navigateurs (Chrome, Firefox, et compagnie), seul internet explorer refuse de me laisser accéder à mon serveur local sous prétexte que je n'ai pas de connexion internet. Du coup je ne peux pas effectuer les traditionnelles petites vérifications incontournables sur IE. Par ailleurs ce problème est récent : ça me le fait seulement depuis une dizaine de jours. Je suppose que c'est un paramétrage à faire quelque part, mais lequel ? Merci d'avance. PS : je suis sous Windows 7 avec IE9.

Bonjour, Il y a clairement un manque de clarté au niveau des quantités sur ce site. Comme Nullette, j'ai voulu ajouter un bracelet au panier : résultat, il m'en impose trois ! Et pour le piercing bleu, si j'en ajoute un, je me retrouve avec cinq dans le panier ! C'est d'autant plus problématique qu'il n'existe aucun moyen de mettre à jour les quantités une fois sur la page du panier. Car les champs de quantité sont éditables mais il n'y a que deux boutons : "retour à la boutique" et "commander". Tout au mieux on peut supprimer un produit, à condition de comprendre qu'il faut pour cela cliquer sur la petite croix rouge à gauche (je suis presque certaine que 95% des utilisateurs ne la voient pas, ou bien ne devinent pas immédiatement à quoi elle sert). On m'impose des quantités sans explication et on ne me donne pas la possibilité de les modifier : tout ceci ne donne vraiment pas envie de commander

Salut, Nicolas > même sans les border-radius ça ne change pas son problème Je n'avais jamais remarqué ce phénomène : Firefox rajoute une marge interne au bouton, non contrôlable par un simple 'padding' dans la CSS. Après quelques recherches, pour empêcher cet ajout, il faut inclure dans la feuille de style : input::-moz-focus-inner /*Remove button padding in FF*/ { border: 0; padding: 0; } Par contre, pour que le rendu soit vraiment identique entre le lien et le bouton, tu devrais aussi ajouter à la class .bouton ceci : display: inline-block;

Salut, L'icône RSS, c'est un peu comme un moteur de recherche interne : par convention et par habitude, l'utilisateur s'attend habituellement à la trouver en haut à droite. Ça c'est la règle générale, mais après c'est au cas par cas, tout dépend de la charte graphique. Si cette icône est unie à d'autres icônes du style Facebook, Twitter, etc (toutes les icônes de suivi), alors il peut être judicieux de les regrouper ensemble dans un bloc, qui sera en général placé en haut ou en bas du menu latéral de navigation. En tout cas, le plus important, c'est de ne pas faire de fantaisie, c'est à dire ne pas afficher une icône RSS customisée qui pourrait induire en erreur : mieux vaut s'en tenir au traditionnel petit carré orange et blanc que tout le monde connaît, éventuellement précédée ou suivie du libellé "RSS". Et s'il y a plusieurs flux RSS différents (par exemple flux des articles et flux des commentaires), il est important de bien afficher textuellement de quel type de flux il s'agit. Non, aucun problème, tant que ça n'induit pas l'utilisateur en erreur (il ne faut pas qu'il croie, par exemple, que ces deux icônes conduisent à deux flux différents s'il s'agit du même). Il est également recommandé d'indiquer ce flux RSS dans le head de la page : <link rel="alternate" type="application/rss+xml" title="Titre du flux" href="http://www.monsite.com/rss.xml>

Bonjour, Si les deux versions sont strictement identiques, alors l'affichage doit l'être aussi dans un même navigateur. Eventuellement ça peut être dû à une image qui en local (ou en ligne) ne se serait pas chargée, ce qui casserait la mise en page, ou bien une erreur php affichée (mais pas forcément visible à l'écran) due à une différence de configuration entre les deux serveurs qui casserait un div quelque part, etc... impossible de le savoir sans voir ton site.

Bonjour, Ces derniers temps, je me demande quelle est la bonne façon de structurer le javascript dans un site web "full ajax" entre guillemets, c'est à dire un site où on ne recharge que des parties de page. Supposons que j'ai un layout général, et dans ce layout j'ai une région #main dont le contenu va changer en fonction des clics de l'utilisateur. Au premier chargement, la région #main va contenir par exemple une vue A. L'utilisateur clique quelque part, et en Ajax on charge une vue B qui vient prendre la place de la vue A. Je reclique ailleurs, une vue C vient se placer et ainsi de suite. Jusque là rien de sorcier. Mais la plupart du temps, chaque vue a elle aussi besoin de son propre javascript. Par exemple la vue A contiendra un slideshow, sur la vue B on aura un widget qui affiche la météo, sur la vue C on aura je ne sais quoi. Jusqu'à présent, je charge la totalité des "class" javascript nécessaires dès le premier chargement. Chaque class contient une fonction init() : quand une vue est chargée, j'appelle la fonction init() adéquate. On pourrait aussi charger le javascript adéquat en même temps que la vue. Donc déjà, avec ce système, la question est toujours de savoir : j'exécute quelle class javascript en fonction de la vue ? Au moment où la vue A est chargée, il faut appeler la fonction init() de la class slideshow. Au moment où la vue B est chargée, il faut appeler la fonction init() de la class Meteo. Et éventuellement déclencher d'autres fonctions, au cas par cas. Mais savoir quelle fonction appeler de quelle class, ça ne se fait pas automatiquement : encore faut-il appeler la bonne fonction de la bonne class. Ce que je fais actuellement, c'est que je déclare le type de vue dans un champ input hidden dans le html de la vue, et quand la vue est chargée, je lis la valeur de cet input et j'exécute le javascript correspondant. Mais cette méthode me semble un peu mauvaise, c'est plein de switch/case illisibles. Et là où ça se complique encore, c'est quand il y a des dépendances entre les différents objets. Par exemple, on peut supposer que j'ai un objet javascript commun à l'ensemble du site. Disons que cet objet, par exemple, possède une fonction qui modifie l'image de background. Et cet objet peut avoir des interactions avec les objets spécifiques à telle ou telle vue. Par exemple sur la vue qui contient le slideshow, on peut imaginer qu'un clic sur le slideshow déclenche la fonction qui modifie le background du layout. Du coup je me retrouve avec tout un tas de références entre les objets, objets qui apparaissent / disparaissent au fur et à mesure que l'utilisateur passe d'une vue à l'autre (sauf l'objet de base bien sûr qui lui persiste tout au long de la navigation), c'est un peu nul. Et pour couronner le tout, l'arborescence peut tout à fait être constituée de plusieurs niveaux de profondeur, et là ça devient ingérable. Voila. Je sens que mes pages web commencent à tourner à l'usine à gaz, alors je cherche une bonne méthode pour organiser / structurer le code javascript. Voila pourquoi j'en appelle aux experts du Hub. Auriez-vous des recommandations, des bonnes pratiques ?

Je n'ai strictement rien compris à ce que tu cherches à faire ! Comment faire ? A priori : avec un clavier et des doigts Mais sinon, il nous faudrait quand même un peu plus de détails.

Bonjour, bienvenue sur le Hub

Un tuto pour faire un tableau ? Heu là je vois pas trop... Ton script actuel affiche les annonces dans un tableau, à raison d'une annonce par ligne, chaque ligne contenant elle-même trois cellules. Partant de là, tu as juste à adapter comme il faut. Je suis sûre que tu peux y arriver

Salut, Avec ton tableau de résultats (contenant les annonces), tu fais une simple boucle for : for ($i = 0; $i < count($tonTableau); $i++) Dans chaque itération de la boucle tu fais un modulo 2 de $i (c'est à dire : $i % 2) afin de savoir si $i est pair (résultat : 0) ou impair (résultat : 1). S'il est pair : tu ouvres une nouvelle ligne et une nouvelle cellule. S'il est impair : tu crées une nouvelle cellule et tu fermes la ligne. Et lors de la dernière itération, si $i est pair, il faut penser à créer une dernière cellule vide. Ou mieux : Tu peux éviter de faire un tableau : tu fais simplement une liste <ul> / <li>. Tu crées un <li> par annonce et tu les mets en float: left. Et le <ul>, tu lui donnes une largeur double de celle des <li>. Ainsi les <li> se rangeront les uns à la suite des autres par rangées de deux.

BINGO !!! J'ai trouvé. Aussi incroyable que ça puisse paraître, c'est un simple body { background-size: 100%; } dans la CSS qui faisait buguer Chrome. Certes, c'est une propriété CSS3, mais même avec -webkit-background-size: 100%; ça pose problème, de même qu'avec -webkit-background-size: cover; et toutes autres sortes de combinaisons pour la valeur (excepté "auto" bien sûr). Si vous voulez tester, voir le fichier en pièce jointe : c'est un slideshow minimaliste qui tient en un seul fichier (les images sont sur le net). Sous chrome, si vous laissez le backround-size sur le body, ça fait saccader considérablement le slideshow. Si vous l'enlevez (ou le mettez en "auto"), ça devient parfaitement fluide. Etonnant non Pour quelle raison un background-size sur le body a-t-il un impact sur la fluidité du slideshow ? Uniquement sur les ordinateurs un peu anciens (je l'ai constaté sur 3 PC sur 5 ici). index.html

Salut, Cette balise n'est pas prise en compte par les moteurs de recherche, en fait elle sert surtout d'indication au navigateur web pour la mise en cache, et encore, elle n'est pas très fiable, il vaut mieux lui préférer l'envoi de headers adéquats. Tant qu'elle est publiée sur le web et que rien n'indique qu'elle ne doit pas être indexée (noindex ou dans le robots.txt), Google continue de l'indexer, c'est logique.

Bon, j'ai un peu amélioré les choses en faisant quelques optimisations : _ utiliser des boucles for plutôt que la fonction each() de jquery (grosse différence de performance) _ éviter au maximum d'insérer des éléments dans le DOM avec javascript. Il vaut mieux que les éléments soient présents dès le départ dans le code HTML. Donc suppression (dans la mesure du possible) de tout ce qui est wrap(), append(), etc... C'est moins bien d'un point de vue "portabilité" (car c'est quand même préférable quand le javascript s'occupe de générer tout ce dont il a besoin), mais ça permet un vrai gain de performance. _ faciliter les sélectors en ciblant mieux (mettre des id plutôt que des class dans la mesure du possible) _ et surtout : quand c'est le JS qui redimensionne les images, c'est surtout là que ça saccade sur Chrome, quand on fait un slideshow avec ces images (surtout qu'en plus je dois faire slider le slideshow lui-même !). Le problème c'est que dans mon cas précis la taille de ces images doit s'adapter en proportion à l'écran et à sa position et d'autres critères. Au final je charge les images en Ajax, en envoyant les dimensions voulues en paramètre (donc envoyées correctement dimensionnées par le serveur). Par contre si l'utilisateur redimensionne sa fenêtre, le redimensionnement en js est obligé (je peux quand même pas les redemander au serveur pour si peu) _ il y a aussi le fait que j'ai toujours l'outil de développement de Chrome ouvert. Or cet outil consomme beaucoup : dès qu'on le ferme, la fluidité des effets visuels complexes est bien meilleure. Au final, ça va donc à peu près, désormais c'est encore légèrement saccadé, mais ça reste très correct, quoique nettement moins fluide que sous Firefox, Safari iPad et même IE. En tous cas merci à vous

Captain >Je fais tout en jquery. Par contre je n'utilise aucun plugin tiers. En fait, c'est un site "one page" : à chaque clic sur un lien, seule la partie centrale de la page est modifiée. Le contenu de la page suivante est chargé en ajax et vient glisser sur l'écran. En plus de ça, il y a de nombreux redimensionnements et repositionnements en JS. Donc au final, je reconnais que le JS est lourd. Mais étant donné que c'est fluide sur les autres navigateurs, je ne comprends pas pourquoi Chrome a tant de mal. Oui, c'est tout à fait possible, et c'est justement pourquoi j'ai ouvert ce sujet : il y a sûrement un truc que je fais mal. Depuis hier matin je fais des essais et j'ai quelques pistes. Par exemple, si je fais un slideshow dans lequel les images sont préalablement redimensionnées en JS, on dirait que Chrome le digère mal, et que par la suite, le glissement de ces images est légèrement saccadé. Mais je n'ai pas vraiment de réponse claire sur ce sujet. Sur certains forums, j'ai vu que d'autres personnes avaient eu ce genre de problème, mais jusqu'à maintenant, ça reste très flou. Et c'est vrai que sur le papier, Chrome est réputé pour être performant au niveau javascript. Et il l'est certainement. C'est plutôt dans le rendu visuel que ça pêche. PS : je vais essayer de vous montrer un exemple de code qui rame dans le courant de la journée, ou demain.

Bonjour, Après plusieurs mois d'utilisation de Google Chrome, je reviens progressivement à Firefox, car Chrome est vraiment décevant : _ incapable de rendre correctement les polices de caractères non standard (elles sont toutes crénelées dès que le texte est un peu gros) _ incapable d'afficher le contenu alternatif d'une image (quand l'image n'existe pas il la remplace par une vieille icône) _ la plupart des extensions, ou fonctionnalités d'extensions, ne fonctionne pas sur les fichiers locaux, pour des raisons soit disant de sécurité. _ et surtout : le manque de fluidité des effets javascript Et c'est le sujet de mon message : le javascript. Sur un PC correct, avec une carte graphique correcte, les effets visuels fonctionnent correctement. Mais dès qu'on est sur du matériel un tout petit peu ancien, les effets visuels en javascript sous Chrome sont très mal rendus : ça rame, ça sacade, etc... Je réalise actuellement un site bourré de JS. Tout marche très bien sous tous les navigateurs : IE (versions 7, 8 et 9), Firefox, Opéra, de même que sur Safari iPhone et iPad. Mais sous Chrome, c'est visuellement franchement pas terrible. Testé sur cinq ordinateurs différents : ceux qui sont dotés d'une carte graphique correcte, ça passe, mais sinon, ça sacade. Les effets de slide, de fade, etc, ne sont pas fluides. Ce n'est pas dramatique, mais quand même assez gênant. Ma question : y a-t-il des bonnes pratiques à mettre en place pour développer du JS qui fonctionne bien sous Chrome ? Des trucs à éviter ? Des astuces ?

Bonjour, Les visiteurs utilisent leur navigateur habituel, et tu ne peux strictement rien faire pour les obliger à passer sur un autre navigateur. Ce n'est évidemment pas le serveur qui dicte aux visiteurs quel navigateur il faut utiliser. La solution ? Faire en sorte que ton site soit pleinement compatible avec Internet Explorer, tout simplement (même si effectivement, Internet Explorer est un débris jusqu'à sa version 8 incluse).

Bonjour, Ce que tu ne nous dis pas, c'est ce que tu as fait, pendant un mois, pour tenter d'améliorer ce référencement. "location voiture tunisie" : dans google, cette requête retourne de nombreux sites concurrents, tu es loin d'être le seul à chercher à optimiser ton référencement là-dessus, donc pour grapiller des places et remonter jusqu'à la première page, il va falloir mettre le paquet, et non pas simplement attendre et regarder un mois plus tard où tu en es Ton site n'a pas été pénalisé, tu as juste perdu une place. Il suffit que l'un des nombreux sites concurrents te passe devant, et automatiquement, ton site descend, même si tu n'as rien changé.