У Google есть много живых экспериментальных функций, которые включаются / выключаются в зависимости от ваших предпочтений, местоположения и других факторов (возможно, также случайного выбора). Я почти уверен, что вы упомянули одну из них.
Что происходит в фоновом режиме, когда вместо параметра строки запроса используется хеш, так это то, что он запрашивает «реальный» URL (http://www.google.com/search?q=hello) с использованием JavaScript, затем изменяет существующую страницу с содержимым. кажется гораздо более отзывчивым для пользователя, поскольку страница не должна полностью перезагружаться. Причина хэша в том, что история и состояние браузера сохраняются. Если вы перейдете к http://www.google.com/#q=hello, вы обнаружите, что на самом деле получаете результаты поиска "hello" (даже если ваш браузер действительно запрашивает http://www.google.com/) с отключенным JavaScript, он не сработает, и вы просто получите главную страницу Google.
Хэши появляются все больше и больше, поскольку динамические веб-сайты становятся нормой. Хеши хранятся полностью на клиенте и, следовательно, не вызывают запрос сервера при изменении. Это делает их отличными кандидатами на поддержание уникальных адресов для различных состояний веб-приложения, оставаясь при этом на одной и той же странице.
В последнее время я сам использую их все чаще и чаще, и вы можете найти один пример здесь: http://blixt.org/js - Если вы посмотрите на библиотеку "Hash" на этой странице, вы увидите мой Реализация поддержки хэшей в браузерах.
Вот небольшое руководство по использованию хэшей для хранения состояния:
Как?
Поддержание состояния в хешах подразумевает, что ваше приложение (я назову его приложением, поскольку вы обычно используете хэши только для состояния в более совершенных веб-решениях) использует JavaScript. Без JavaScript единственной функцией хэшей было бы указание браузеру находить контент где-то на странице.
После того, как вы реализовали некоторый JavaScript для обнаружения изменений в хэше, следующим шагом будет анализ хеша в значимые данные (так же, как вы это делаете с параметрами строки запроса).
Почему?
Как только у вас есть состояние в хэше, оно может быть изменено вашим кодом (или вашим пользователем) для представления текущего состояния в вашем приложении. Есть много причин, почему вы хотели бы сделать это.
Один общий случай - это когда только небольшая часть страницы изменяется в зависимости от переменной, и было бы неэффективно перезагружать всю страницу, чтобы отразить это изменение (Пример: у вас есть поле с вкладками. Активная вкладка можно найти в хэше.)
В других случаях вы динамически загружаете контент в JavaScript и хотите сообщить клиенту, какой контент загружать (пример: http://beta.multifarce.com/#?state=7001, приведет вас к определенной точке текстового приключения.)
Когда?
Если вы заглянули в мою "область JavaScript", то увидите граничный случай излишнего убийства. Я сделал это просто потому, что хотел вложить как можно больше динамики JavaScript в эту страницу. В обычном проекте я буду осторожен в отношении того, когда это делать, и делаю это только тогда, когда вы увидите положительные изменения в одной или нескольких из следующих областей:
- Интерактивность пользователя
- Обычно пользователь не видит большой разницы, но URL могут сбивать с толку
- Помните индикаторы загрузки! Динамическая загрузка контента может разочаровать пользователя, если на это требуется время.
- Отзывчивость (время от одного состояния к другому)
- Производительность (пропускная способность, процессор сервера)
Нет JavaScript?
А вот и большой сдерживающий фактор. Хотя вы можете смело полагаться на 99% своих пользователей, чтобы иметь браузер, способный использовать вашу страницу с хэшами для состояния, во многих случаях вы просто не можете полагаться на это. Сканеры поисковых систем, например. Хотя Google постоянно работает над тем, чтобы их сканер работал с новейшими веб-технологиями (знаете ли вы, что они индексируют Flash-приложения?), Он все же не человек и не может понять некоторые вещи.
По сути, вы находитесь на перекрестке между совместимостью и пользовательским опытом.
Но вы всегда можете построить промежуточную дорогу, которая, конечно, требует больше работы. Говоря менее метафорически: реализуйте оба решения таким образом, чтобы на каждом клиентском URL-адресе, который выводит релевантное содержимое, был URL-адрес на стороне сервера. Для совместимых клиентов он будет перенаправлять их на хеш-URL. Таким образом, Google может индексировать «жесткие» URL-адреса, и когда пользователи нажимают на них, они получают информацию о динамическом состоянии!