Как стать автором
Обновить

Комментарии 42

Пример нельзя посмотреть:
Forbidden

You don't have permission to access /anchornav/ on this server.
Автор оперативно поправил. Спасибо ему.
а у меня все равно 403 =(
Автор, твой сервер не бо-бо. 403 ошибка.
Спасибо кому-то из хабрапользователей за недавнюю статью про CDN coralcdn.org. С его помощью автора страничка все же открывается:
http://vbolshov.org.ru.nyud.net/anchornav/
Я так полагаю поисковик будет нас на такие урлы приводить anchornav/?something (без хеша), а нажав скажем на with я получу такой урл anchornav/?something#a:?with. Не айс ИМХО. + ещё не удобно что при откытии в отдельном окне сначала грузится дефолтная страница, а потом аяксом подсасыватся контент, по идее должно всё сразу идти одним запросом.
Одним запросом, к сожалению, невозможно: хэш (часть УРЛа после #) на сервер не отсылается. «Не айс» — это если использовать подобные вещи напропалую. Они хороши не всегда. Один из примеров использования, когда оно к месту: у вас есть на странице аудио-плеер и ваши пользователи не хотят, чтобы он переставал играть во время переходов между страницами.
С хешами да, тут ничего не поделаешь, но есть вариант сделать через скрытый iframe: соответственно история навигации будет сохраняться там, у ссылок оставить урлы без хешей, а таргеты им js ом проставить. Но это тоже всё как — то не совсем по феншую.
Для ИЕ (а может, и еще для каких браузеров) плагин BBQ как раз и хранит историю в ифрейме, у большинства браузеров нет проблем с этим.

Если же отображать сам контент в ифрейме — то не получится на сервере отделить запрос на часть страницы — от запроса на целую страницу. В общем, мне кажется, что используя такие вещи осторожно и взвешенно, можно таки повысить юзабилити и не слишком пострадать от недостатков, которые, знамо дело, есть. Вот только что товарищ высказал такую мысль:

Если кто-то скопировал ссылку с хэшом к себе в блог, то поисковик ее распарсит и пойдет по ссылке, в которой хэш будет потерян, и получит не ту страницу. Так что: осторожно, осторожно и еще раз осторожно.
Отделить то можно всегда, например дополнять get параметром или ещё както. Да и не обязательно через ифрейм, можно и плагин этот использовать и менять window.location.hash чтобы он отрабатывал.
Ссылки мне ваши не нравятся, если честно. Ну и что что якоря нна сервер не отсылаются? Разве нельзя на все ссылки с определенным классом навесить onclick, и оттуда устанавливать якоря?
к примеру, <a href="/products/gallery" class=«ajax-link»>галерея</a>
$('.ajax-link').click(function(){
// берем href ссылки, подгружаем аяксом, ставим window.location
return false;
})
Эх, если бы все было так просто. Но нет, не все. В вашем случае в нельзя будет использовать кнопки вперед-назад браузера.
Только что проверил. На сайте в контактах 10 филиалов, вверху страницы select на карты проезда.
выбираете в select город, в javascript:

$('#sel_city_btn_id').click(function(){
window.location = '/' + CURR_LANG + '/markets/#' + $('#sel_city_id').val();
});
Перематывает вниз, как и надо. Кнопка назад возвращает наверх.
У меня Opera 10.10. Также смотрел на Chrome, Firefox 3.5, IE8. работает везде
Вы не совсем поняли, что имеется в виду под " нельзя будет использовать кнопки вперед-назад браузера". Дело вот в чем.

Допустим, по нажатию одной из ссылок вы сменили location и подгрузили в <div id=«content»> содержимое, заменив этим содержимым то, которое было там ранее. Затем нажали назад. В вашем случае никто не сменит содержимое дива обратно на исходное, а стало быть, навигация по хистори работать не будет, и что толку с того, что хэш в адресной строке будет исправно меняться?
Содержимое всегда заново подгружать, естественно! Разве не на этом построен ваш пример? Я лишь имел ввиду, что вовсе не обязательно ссылки таковыми делать, с передачей параметров скрипту, ничто не мешает прописать в ссылке /products/prices, а javascript пусть обвешивает их событиями! какая разница то?
На этом построен мой пример, но не ваш. У вас никто и не думает отслеживать навигацию по хистори. Я и хочу вам показать, что наши два примера не эквивалентны по функциональности.

Если вам не нравятся ссылки типа #a:/some/path/ — мою разработку вам вряд ли получится использовать. Дело в том, что «a:» — это существенная часть, она, собсно, помогает определить, следует ли обрабатывать тот или иной хэш с помощью anchornav, а также каким экземпляром навигатора следует его обработать (а следовательно, в какой части страницы показать).

Если вам не нравятся ссылки типа #a:?something — то есть не нравится знак вопроса — то это вообще отношения к делу не имеет. Просто данный пример использует такие ссылки (мне не хотелось прописывать правила для mod_rewrite). С тем же успехом ссылки могли бы быть "#a:something" или "#a:/something/". Здесь никаких ограничений плагин не накладывает.
Своим примером я лишь хотел показать, что кнопки вперед/назад работают с якорями во всех браузерах. Разумеется, подгружать надобно отдельно, и да, нужен какой-либо идентификатор контейнера. Ветка началась с того, что будет со ссылками из поисковиков, и как это обрабатывать. Я лишь добавил, что по моему мнению, все же стоило бы добавить пару строчек в упомянутый вами mod_rewrite :)
Чем вам мой первый пример плох? Он работает также, за исключением лишь того, что я не учел неймспейс :)

Хотя в вашем случае видимо, не потребуется делать редирект, а отдать страницу по GET параметру, и потом просто менять содержимое javascript'ом. Но я считаю, что такая ссылка будет вводить людей в заблуждение. Я бы сделал как-то так:

RewriteRule ^(.*)/{0,1}$ /#$1 [R]

javascript

$(document).ready(function(){

//взяли hash, загрузили контент
// бежим по ссылкам, ставим онклики, и далее по сценарию…

})
ах да, вся соль же была в graceful degradation, редирект тоже должен быть в javascript :) простите за невнимательность
в фф и хроме история сохраняется и кнопки вперед-назад работают

$(function(){
$('a').click(function(){
window.location.hash = $(this).attr('href');
$('#box').text($(this).text());
return false;
});
});
На первый взгляд, хорошая вещь, сделал закладку. Спасибо, посмотрю подробнее на досуге.
как-то совсем не нашел я там никакой документации, примеров использования или ссылки на демо.
всё в коде…
ну уж нет, увольте. Чтобы кодом кто-то воспользовался, кроме автора, хоть пара строчек документации необходима.
_она_ в коде
спасибо, я как раз искал это =)
Хм… у меня волшебство… Во втором блоке тыкаю на ссылку внутри блока и у меня обновляется первый блок… WinPX SP3 Opera 10.00
Это не волшебство :) Ссылки внутри блоков и должны открываться в первом блоке (я просто не упомянул об этом на страничке, а надо бы — кстати, спасибо вам за этот коммент, обновлю тексты, чтобы было понятнее)
Это не глюк, это фишка))))))
Сильно мучают сомнения по поводу того, что это будет индексироваться поисковиками, покажите пример проиндексировности.
Дело в том, что поисковики «увидят» ровно то же самое, что и вы сами можете увидеть, отключив javascript. Отключите и посмотрите.
Посмотрел, да, идея очень интересная, но есть одно но…
Яндекс не выполняет javascript на страницах и увидит именно то, что было задумано, а вот google яваскрипт на страницах выполняет и увидит ссылки типа site.ru/#a:?page которые он вряд ли сможет проиндексировать правильно, скорее всего он просто отбрасывает все, что идет после # в ссылках.
Тоже интересное замечание, хотя мне хотелось бы почитать подробнее о том, что происходит при индексации гуглом, а то я лично только краем уха слышал про выполнение им жабоскриптов. Ну, на крайняк можно не перманентно менять href ссылок, а обрабатывать событие click. Но для начала нужно подробнее разобраться с процессом индексации.
Проблема: Если я возьму ссылку на сайте такого типа vbolshov.org.ru.nyud.net/anchornav/#b:?with и оставлю ее везде везде, то она не проиндексируется поисковиками. Правильно понимаю? Ведь юзеры обычно берут ссылки из адресной строки браузера. Как решить такую проблему?
По большому счету, конечно, никак. Однако, если использовать подобные вещи аккуратно, то можно свести риски к минимуму. Использовать такой способ навигации лучше не на всем проекте, а лишь там, где это действительно облегчает жизнь пользователю.

Например, у вас есть страничка описания некоего объекта, свойства которого развиты на 3-5 категорий. Делаем навигацию по группам свойств с поомщью якорей и получаем набор УРЛов:

example.com/object/12345/#description,
черт, отправилось раньше времени… так вот, такой набор УРЛов:
example.com/object/12345/#description,
example.com/object/12345/#properties,
example.com/object/12345/#photoes,…

Таким образом, поисковик, найдя ссылку на чужом сайте, по прежнему может проиндексировать не совсем тот контент, что имел в виду пользователь — но по крайней мере, ошибется не так сильно, как если бы УРЛы были такими:
Черт бы побрал отправку комментария по ctrl+enter…

поисковик ошибется не так сильно, как если бы УРЛы были такими:
example.com#/object/12345/description,
example.com#/object/12345/properties,
example.com#/object/12345/photoes,…

То есть, это во много вопрос грамотного применения технологии.

Кроме того, я вижу и такой выход из ситуации: расположить на странице кнопку «ссылка на эту страницу» — которая будет выдавать ссылку, сформированную для поисковиков.
>Кроме того, я вижу и такой выход из ситуации: расположить на странице кнопку «ссылка на эту страницу» — которая будет выдавать ссылку, сформированную для поисковиков.

Да. Я вот пока вижу это как единственный выход.

хостинг с демо накрылся…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории