J'ai une section d'un site avec plusieurs catégories de widget. Il y a un menu avec chaque nom de catégorie. Pour que n'importe qui avec JavaScript activé, cliquez sur une catégorie révèle le contenu de la catégorie dans la page. Ils peuvent cliquer entre les catégories à volonté, en voyant le DOM mises à jour au besoin. L'URL est également mise à jour à l'aide du hachage / Hashbang standard (si nous sommes en train d'être google). Donc, pour quelqu'un qui atterrit sur Toutefois, pour prendre en charge les agents utilisateur sans JavaScript activé, la suivante de l'une de ces liens de catégorie doit charger une nouvelle page avec la catégorie affichée, donc pour une personne sans JavaScript, ils navigueraient à Ma question est la suivante: Que devrait-il arriver quand quelqu'un avec JavaScript activé atterrit sur l'une de ces URL? Qu'est-ce que quelqu'un avec JavaScript est-il activé être présenté lors de l'atterrissage sur Veuillez noter que j'ai besoin d'une expérience de site unique pour n'importe qui avec JavaScript activé, mais je souhaite un site multicaptique pour un agent utilisateur sans JavaScript. Toute réponse qui ne traite pas de ce fait ne répond pas à la question. Je ne m'intéresse pas aux mérites ou aux problèmes de hashbangs ou de sites à page unique VS Sites multi-pages. exemple.com/widgets , ils peuvent naviguer vers exemple.com/widgets#two < / code>, exemple.com/widgets#freree etc.
Exemple.com/widgets/one , exemple.com/widgets/two , exemple.com/widgets/three etc.
exemple.com/widgets/one par exemple? Devraient-ils être redirigés vers exemple.com/widgets#one ?
4 Réponses :
Pourquoi devriez-vous les rediriger vers une page différente? L'utilisateur est arrivé à la page à la recherche d'une réponse. Il obtient la réponse même s'il a activé JavaScript. Peu importe. La requête de l'utilisateur a été remplie.
Mais que se passerait-il si l'utilisateur atterrit sur exemple.com/widgets#one? Vous auriez besoin de configurer une redirection automatique sur exemple.com/widgets/one dans ce cas. Cela pourrait être fait en vérifiant si JavaScript est activé dans l'événement et rediriger vers la page appropriée.
Je suis un peu incertain de votre réponse. Suggérez-vous qu'il est servi la page unique inhétanée? Si tel est le cas, vous n'avez pas compris la question.
Vous avez ajouté la partie sur l'expérience de MultiPage VS une seule page. Comment est-ce que l'une est censée comprendre vos exigences sans que vous donniez tous les détails? De toute évidence, si c'est ce que vous désirez, l'utilisateur doit être redirigé vers la page compatible JavaScript .. Quelle est la question alors?
Non, c'était là depuis le début. La clarification à la fin a été ajoutée.
Apparemment, votre question contient déjà la réponse. Vous dites:
J'ai besoin d'une expérience de site d'une seule page pour n'importe qui avec JavaScript activé
et ensuite demander:
Qu'est-ce que quelqu'un avec JavaScript est-il autorisé à être présenté lors de l'atterrissage sur
exemple.com/widgets/one par exemple? Devrait-ils être redirigé versexemple.com/widgets#one ?Je dirais
oui, ils devraient être redirigés . Je ne vois aucune autre option, compte tenu de vos besoins (et que les informations sur les capacités JavaScript et le fragment de hachage de l'URL ne sont pas disponibles sur le côté serveur).
Si vous pouvez accepter un peu la détente des exigences, je vois une autre option. N'oubliez pas que lorsque le Web était encombré de cadresets et nous avons atterri sur un cadre spécifique via Altavista (Google n'était pas encore autour!) Rechercher? Il était courant de voir un en-tête disant que la page était censée être affichée en tant que cadre et un lien pour emprunter l'utilisateur à la version de Cadreset.
Vous pouvez faire quelque chose de similaire: lorsque le script est disponible, détectez-vous que vous êtes à
exemple_widgets/one et ajoutez un lien à la version à une seule page. Je sais que ce n'est pas idéal, mais c'est mieux que rien, et peut-être mieux qu'un méchant redirect de côté client.
Cela me semble une solution médiocre, car il s'agit de deux pages séparées en cours de chargement. S'il était possible de détecter les capacités JavaScript de l'agent utilisateur sur le côté serveur, tout irait bien, mais étant donné que la redirection devrait être du côté client, il est méchant. Ne me trompe pas. Vous êtes le plus probablement correct. Je pose la question parce que je pense que c'est intéressant, pas parce qu'il y a nécessairement une réponse parfaite. C'est probablement la réalité de la situation.
Je comprends et j'ai mis à jour ma réponse avec une autre suggestion. J'espère que d'autres alternatives existent, voyons si quelqu'un propose quelque chose d'autre.
@Pedr Faites votre ancre Hrefs incluent en fait les fragments de hachage? Je pense à une autre option (une personne que j'utilise actuellement sur un site que je développe, en fait). Si vos liens pointaient des trucs comme / widgets / un , vous pouvez ajouter manuellement le hachage au navigateur avec JS lorsqu'il est disponible. Ensuite, les deux versions de la page semblent identiques, bien qu'on utilise JS / Ajax pour charger du contenu, tandis que l'autre demande normalement de nouvelles URL. C'est peut-être la meilleure option, en fait.
Je prévois d'utiliser une lib qui utilise l'API d'historique et redevient à l'aide de hachage uniquement si le navigateur n'est pas capable (IE8 et IE9). Donc, à tout le moins de ces navigateurs auront besoin d'un redirect Clientside à l'exemple.com/widgets. Pour Histoire, API Capabale navigateurs, atterrissage sur exemple.com/widgets/one ne cherchera pas d'URL différente que s'ils ont atterri sur Exemple.com/widgets et navigué sur Exemple.com/widgets/one.
Un moyen de concevoir de telles pages consiste à concevoir sans JavaScript en premier.
Vous pouvez utiliser des ancrages dans la page afin: sera un lien vers l'élément Avec ID 'One' Une fois que votre page fonctionne sans JavaScript, vous ajoutez la couche JavaScript. Vous pouvez empêcher les liens d'être suivi de l'utilisation de l'événement.PreventDefault. ( https://developer.mozilla.org/fr/docs/dom/dom/dom/dom ), ajoutez ensuite la fonctionnalité JavaScript souhaitée.
Voici comment je le structurerais:
Utilisez historyjs pour gérer l'URL. Les navigateurs JS Pushstate ont obtenu des URL correctes complètes et des navigateurs JS non-Pushstate ont des URL hachées. Les utilisateurs non-JS sont allés à la totalité de l'URL normale avec un rechargement de page.
Je pense que vous devez absolument avoir tout votre contenu accessible via une URL complète, correcte et la charger via AJAX, puis mettez à jour l'URL pour refléter l'adresse de votre contenu. De cette façon, lorsque JS ne fonctionne pas, vous n'avez rien à changer.
Est-ce ce que vous voulez dire?
Alors, que faites-vous lorsqu'un client avec JavaScript activé mais un navigateur qui ne prend pas en charge les terres API d'historique sur exemple.com/widgets/three ?
Si quelqu'un avec JS mais sans l'histoire de l'histoire visite example.com/widgets/three, ils devraient simplement obtenir une page complète. En ce qui concerne la structure de votre site, la teneur en Yoru doit être accessible via des URL complètes, vous choisissez simplement de les charger via AJAX. Cela a-t-il du sens?
Pouvez-vous clarifier ce que vous entendez par «page complète»? Voulez-vous dire qu'ils obtiennent une seule page de la même manière que quelqu'un atterrissant sur la page avec JavaScript handicapé?
Oui, ils auraient la même chose que s'ils ont atterri dessus sans JavaScript
Vous voyez, ça se sent comme un flexible pour moi. C'est exactement pourquoi j'ai posté cette question. Tous les liens que Google indiqueront seront à ces pages complètes. Tous les personnes qui suivent ces liens avec JavaScript ont permis d'obtenir l'expérience de merde que les gens sans JavaScript auraient. Ne me trompe pas. Cela semble être de la manière dont beaucoup de gens font des choses, mais cela signifie que les seules personnes qui obtiennent une expérience de riche en JavaScript moderne et à une seule page sont celles qui se produisent sur la page d'index.
Ce n'est pas ce que je veux dire - lorsqu'un utilisateur atterrit sur n'importe quelle page, vous devez avoir une JS qui exécute et configure votre expérience de type simple page. Vous ne devriez pas faire cela uniquement sur la page d'index. Sinon, vous limitez votre expérience aux personnes qui visitent la page d'index d'abord. Si vous avez JS et vous atterrissez sur n'importe quelle page, votre application devrait être en mesure de se préparer. J'espère que cela a du sens, c'est un gros sujet et très difficile de passer à travers des commentaires.
Sûr. Certains aspects de l'expérience Internet sont ridiculement datés. Dans un monde où nous pouvons parler en temps proche en temps réel aux astronautes, nous nous engageons dans une conversation textuelle avec 1 jour entre les réponses. J'aime comme jouer aux échecs par courrier ou parler à quelqu'un sur Mars;) a du sens. Je pense que nous venons du même endroit.
Absolument. Fondamentalement, je pense que toutes vos pages doivent être capables de charger dans toutes les autres pages via AJAX dans un conteneur. La première fois que vous atterrissez sur ce site, une sorte de configuration est terminée pour initialiser Historyjs, lier les gestionnaires d'événements, etc., mais après cela, le site agit comme une seule application. J'espère que vous résolvez le problème et j'aimerais avoir du temps / des ressources pour assembler un meilleur exemple.
somesite.com est un domaine existant; N'utilisez pas de tels domaines à moins que vous ne le signiez vraiment; Exemples.com est réservé pour une utilisation en tant que domaine factice.
J'ai remplacé par exemple.com
Ce poste de blog offre une idée qui pourrait offrir une nouvelle pensée à une solution Jenitennis.com/blog/node/154
@Newtriks merci. C'était un super poste.
Je pense que la question principale devrait être " Que se passe-t-il si quelqu'un avec JS handicape terres sur
exemple.com/widgets#two "?Ils arriveraient à la page racine. Je ne vois aucune autre solution autour de cela autre que de ne pas utiliser de hachage, qui prédit ensuite les utilisateurs sur IE9 ou moins.
@Pedr Cela ressemble à vous rechercher quelqu'un pour vous dire de les rediriger vers la page JavaScript, car vous avez commenté de rejeter les suggestions opposées de cela. Je vais le faire tourner par une manière différente, votre question n'est pas un scénario dans un site Web correctement codé avec une détection et une redirection appropriées.
@ Syn123, peignez une image d'un «site Web correctement codé avec une détection et une redirection appropriés» pour moi qui satisfait mes paramètres. J'ai rejeté cette réponse parce que cela ne résout pas ma question. Je veux que quiconque arrive avec JavaScript activé pour obtenir une expérience de montage unique où ils peuvent mélanger entre les pages sans chargement complet de la page. Je ne cherche pas quelqu'un pour me dire quoi que ce soit en particulier. Je suis intéressé par la discussion du scénario et des approches pour la résoudre.
Pourquoi un utilisateur JavaScript serait-il jamais ré-dirigé vers exemple.com/widgets/one en premier lieu?
@ Syn123 Il est tout à fait possible qu'un utilisateur non javascript puisse passer autour d'un lien vers exemple.com/widgets/one, qui pourrait ensuite être suivi d'un utilisateur activé par JavaScript. Et bien sûr, quiconque suivait les liens indexés par Google.
Je suppose que la solution évidente consiste donc à effectuer une redirection sur la page non-JS à la page JS avec détection, mais ... pourquoi ne pas tout coder dans 1 page et le présenter aux utilisateurs JS via la