HTML5 History API уже сегодня и без ограничений

[Mithgol]

Аллилуйя! Лучше и придумать почти нельзя, а где можно, там патчи пришлют.

[devote]

Спасибо, я постарался учесть все по максимому, но с удовольствием выслушаю любые предложения/улучшения.

[extensible]

А чем вам не угодил проект github.com/balupton/history.js? Вроде как задачи те же, захотелось повелосипедить? :)

[devote]

Нет, дело не в велосипеде, дело тут в очень простом. Суть данной библиотеки максимально снизить написание лишнего кода. А в будущем ее легко извлечь из проекта, при этом не затрагивая основной код сайта. Например если я буду писать с использованием библиотеки от balupton, и захочу отказаться от старых браузеров, то мне нужно будет переписать основной код сайта что бы вырезать эту библиотеку.

Еще один недостаток библиотеки представленной вами это громоздкость, весит она в разы больше, а с учетом того что сейчас довольно сильно развивается мобильный интернет, это не особо хорошо для них. Конечно это не огромный аргумент, но все же. Ну и конечно же что бы пользоваться библиотекой от balupton, ее нужно изучить, точнее прочитать документацию по ней. Плюс ко всему та библиотека не работает полноценно с браузером ИЕ7, хотя это тоже не аргумент, но все же маленький но аргумент.

[panenko]

Не аргумент… но рагумент :)
Отличный инструмент.

[Fr3nzy]

History.js от balopton'а использую уже давно. Единственные косяки связаны с urlencode/decode (неверно работает со всякими японскими, китайскими и т.п. языками + избыточно работает с некоторыми системными символами). Чтобы выключить поддержку HTML4-браузеров ничего особенного делать не придется, если вы изначально пишите с умом. Достаточно будет просто загрузить History.js только с поддержкой HTML5.

[devote]

Я и не заставляю отказаться от привычных инструментов, конечно же каждый выбирает то что ему по душе, тем и пользуется. Но зачем загружать «History.js только с поддержкой HTML5»? Вот этого я не могу понять, да конечно она будет поправлять косяки браузеров, а если их не сегодня а завтра поправят в браузерах? Конечно я утрирую и дождаться от разработчиков браузеров тяжело чего либо, но все же.

Суть в том что в моем случае я просто отключу библиотеку и сайт не упадет а продолжит работать как работал. Единственное что нужно будет сделать это заранее об этом подумать и прописывать где нужно примерно такой код:

// .........
if ( history.pushState ) {
    // .........
    var locationObject = history.location || window.location;
    // .........
}
// .........

Тем самым отключение моей библиотеки не нарушит работоспособность сайта в HTML5 браузерах, а в браузерах HTML4 просто будет обычный переход по ссылкам. Хотя конечно дело выбора и желаний.

[Fr3nzy]

Ну да. В случае с Балуптоноским методом, простое отключение библиотеки не поможет, так как у него используется объект History, а не history. Но, как и в вашем случае, можно будет сделать довольно быстро работоспособным код этот :)
Да и не понимаю я, зачем нужно использовать history.location. Если есть pushState.

[devote]

Да и не понимаю я, зачем нужно использовать history.location. Если есть pushState.

Объект history.location содержит ссылку информирующую нас о том куда мы вернулись по истории, не зависимо от присутствия объекта state. То есть в в браузерах HTML5 для этих целей служит обычный window.location и/или document.location. Это я считаю один из важных параметров в отличии от объекта state, который на мой взгляд ввели избыточно.

[Fr3nzy]

Извините, опечатался: balupton'а, конечно.

[Arterius]

Такое ощущение что есть специальные задроты которые только и ждут чтобы указать на «велосипеды». Если мир состоял только вами то вы никуда дальше от развития одноклеточных амеоб не дошли бы.

[extensible]

Я лично сам прошел долгий путь от велосипедирования и пришел к выводу что писать что-то свое целесообразно лишь когда:

1) похожего инструментария вообще нету
2) есть что-то похожее, но оно совсем не нравится

Задротства тут никакого не вижу, главное чтобы цели оправдывали средства.

[Arterius]

Ну да! зато я могу теперь выбрать что использовать.

[VolCh]

А если просто не нравится, а не совсем? Где грань?

[extensible]

Нету никаких граней, это же и коню понятно. Сами определяете границы. Некоторые пишут велосипеды «джаст фор фан» или ради практики в программировании.

Ничего не имею против велосипедов.

[creage]

Я в таких случаях форкаю, и делаю так, чтобы «нравилось».

Осязание грани «велосипеда» и «инновации» считаю талантом. Нужно уметь вовремя остановиться.

[Iskin]

Кстати, есть ещё более высокоуровневые framework’и, чтобы удобнее писать код с History pushState. Например, Pages.js: github.com/ai/pages.js

[devote]

Спасибо, я посмотрю на досуге на эту библиотеку, но сомневаюсь что в ней увижу что-то новое. Хотя моя цель была сделать библиотеку без добавления всяких лишних методов, которые нужно изучать.

[Iskin]

Да, тут разные цели. Pages.js не имеет поддержи для старых браузеров, просто framework для упрощения разработки :).

[devote]

Да вы правы, но при использовании моей библиотеки совместно с библиотекой Pages.js боюсь приведет к плачевному результату лишь по одной причине того что у меня реализован history.location который не будет учитывать Pages.js. Хотя конечно же можно попросить разработчиков той библиотеки добавить поддержку.

[Iskin]

Тут вообще глобальный вопрос, должны ли мы поддерживать старые браузеры. History pushState разработан так, что сайт будет работать и без поддержки pushState, просто не так круто. А если у пользователей старых браузеров сайт один-в-один с современными браузерами, то какой смысл обновлять браузер ;).

[devote]

Да, риторический вопрос, но с заказчиками не поспоришь. Если требуют, то либо делаем либо теряем заказчика, уж таковы реалии и с этим не поспоришь.

[Iskin]

Ну для заказчика главное бизнес, чтобы деньги приносил, а не какие технологии используются :). Не думаю, что пользователи особо пострадают, если страница будет грузиться старым способом.

Тем более, обычно новые технологии отсутствуют на старых медленных браузерах и старых компьютерах. Так что при попытке заставить их показывать «как все», сайт будет просто больше тормозить.

[Iskin]

Про тормоза, например, утечка памяти из-за особенностей сборщика мусора у старых IE — при обычной загрузке память будет очищаться при переходе между страницами.

[devote]

Я посмотрел внимательнее на ваш плагин для jQuery, и вы можете добавить поддержку моей библиотеки изменив всего три строки кода в своем плагине.
Это строки 151, 152

        if ( Pages._lastUrl != location.href ) {
          Pages.open(location.pathname);
        }

заменить на:

        if ( Pages._lastUrl != ( history.location || location ).href ) {
          Pages.open( ( history.location || location ).pathname );
        }

И строку 448

    Pages._lastUrl = location.href;

заменить на:

    Pages._lastUrl = ( history.location || location ).href;

И у вас появиться поддержка моей библиотеки, как видите ничего сложного и трудоемкого производить не нужно.

[devote]

Верно подметили, я с вами совершенно согласен. Но люди разные, кто-то имеет иной взгляд на это все.

[Programmer]

А это нормально что при несколькоих кликах на 1 и ту же ссылку в историю попадают одинаковые сущности?

[devote]

Да это совершенно нормально, поэтому это нужно отслеживать самостоятельно. Но это не глюк библиотеки, так как все браузеры HTML5 делают именно так и в спецификации противоречий этому я не нашел.

[f0rk]

Я правильно понимаю, что нужно просто подключить эту либу и мое приложение, к примеру на backbone c pushState роутером, будет работать во всех браузерах без fallback-а на хеши?

[devote]

нет, fallback-а на хеши конечно же будет присутствовать в браузерах HTML4 но для этого не нужно делать лишних телодвижений и писать лишний код. Суть в том если backbone использует при работе History объект window.location то скорее всего эта библиотека не совсем будет выполнять требования backbone.

К сожалению браузеры HTML4 не позволяют перезагрузить объект window.location и/или document.location, поэтому пришлось добавить дополнительный объект history.location, который и нужно добавить в тот код который тесно связан с объектом window.location при работе с HTML5 History API. В ином случае вполне возможно что библиотека будет корректно работать, но я не тестировал ее совместно с библиотеками которые осуществляют работу с историей.

[devote]

Этого не нужно, потому как ссылки в тегах имеют обычный вид, то есть никакого хеша в ссылках, обычные всеми привычные ссылки. В примере указанной в статье это хорошо видно, и робот зашедший на страницу, спокойно может перейти по нужно ссылке.

[merkuriy]

Ну я бы правда не забывал про ссылки из HTML4 браузеров, которые используют якорь (знак # (hash)). Ведь пользователи старых браузеров тоже могут распространять ссылки с якорями по интернету. Для таких ссылок в вашей библиотеке можно использовать параметр «type=!», если не лень специально для старых браузеров делать поддержку hashbang (#!) на стороне бэкэнда. Я же верно размышляю?

Кстати, меня, если честно, слегка смутило, то что вы не используете git теги для версий библиотеки, а вместо этого создали директорию «old». С тегами было бы проще и вам и пользователям библиотеки.

[devote]

Я же верно размышляю?

Да все верно

Кстати, меня, если честно, слегка смутило, то что вы не используете git теги для версий библиотеки, а вместо этого создали директорию «old». С тегами было бы проще и вам и пользователям библиотеки.

Ну я затруднений пока не вижу в этом, на сегодняшний день, версии меняются редко, так как библиотека во всем корректно работает. Ну или просто никто не присылает баг-репорты.

[student_ivan]

Я когда-то делал что-то подобное, но чисто для history-api (без хеш-навигации)
github.com/studentIvan/BatmanHand.JS/blob/master/index.html

[student_ivan]

Кстати, кто знает, есть ли разница между window.onpopstate и window.addEventListener('popstate'...?

[devote]

разницы нет никакой, разница лишь в том что при использовании addEventListener вы можете не ограничивать себя и назначать на тоже событие новые и новые перехватчики. Суть в том что событие popstate нельзя отменить и перехватить на стадии погружения. Поэтому разница тут не велика.

[devote]

Вы делали просто обертку для удобства работы с HTML5 History API, моя же библиотека это не обертка, а расширение для HTML4 браузеров, что бы ваша обертка могла работать и в старых браузерах тоже.

[GreyCat]

Подскажите, что-то нигде не нашел информации о лицензии — под какой лицензией опубликована эта библиотека?

[GreyCat]

Да, уже нашел:

 * Dual licensed under the MIT and GPL licenses:
 *   http://www.opensource.org/licenses/mit-license.php
 *   http://www.gnu.org/licenses/gpl.html

Вы бы куда-нибудь это на видное место добавили — и в README, и сюда, и в какой-нибудь файл типа LICENSE в корень репозитария…

[termi]

Спасибо большое за отличную библиотеку.
Я, с тех пор как прочитал webreflection.blogspot.com/2011/02/btw-getters-setters-for-ie-6-7-and-8.html, так и не смог придумать как же это использовать. А Вам это удалось!

Форкнул и рефакторю. Написал в личку

[devote]

Да я тоже очень долго решал как применить то что вы привели по ссылке, хотя по приведенной вами ссылке это сырой способ, просто человек писавший метод objectStatic не полностью осведомлен о реалиях VB, от того его способ имеет кучу ошибок и ограничений, поэтому помимо этого мне пришлось перелопатить еще и MSDN что бы получить более полную картину по скрипту VB

[devote]

Кстати насчет статьи про getters/setters я их еще применил в этом проекте https://github.com/devote/jsClasses#readme я как то о нем писал на хабре. Если вам интересно конечно их применение не только в библиотеке history.

[Methos]

VB — это Visual Basic? Зачем он используется в этом скрипте?

[devote]

Для возможности использовать setters/getters в ИЕ<9

[merkuriy]

Кстати как бы вы поступали с адресами страниц, при которых HTML-содержимое страниц на самом деле не меняется, а изменения применяются только для мультимедиа элементов на самой странице, т.е. адреса на контент которым управляют скрипты. Примеры: адреса слайдов в swf-презентации, адреса определённого видео-фрагмента. Я бы для таких адресов использовал именно якоря (hash), т. к. нужно учитывать, что HTML будет один, и дубликаты однотипного ресурса для поисковиков не хотелось бы создавать.

Ваша библиотека нормально будет работать при совместном использовании адресов без якорей и с ними в HTML5 и HTML4 браузерах?

[devote]

Ваша библиотека нормально будет работать при совместном использовании адресов без якорей и с ними в HTML5 и HTML4 браузерах?

Да мои тесты это проходили успешно, но учитывая то что подобное мало кому нужно. Возможно где-то, может и выползет косяк при попытке использовать это.

[Aliance]

Извиняюсь за поднятие старого топика, нашел его в поиске.

url: this.getAttribute( «href», 2 ) // двоечка нужна для ИЕ6-7

а можете объяснить, почему? нигде в документации не нашел второго аргумента. или это опечатка?

[devote]

О втором параметре написано тут msdn.microsoft.com/en-us/library/ie/ms536429%28v=vs.85%29.aspx
Но так же вы можете почитать на форумах о проблеме получения ссылки у элемента HTMLAnchor средствами getAttribute, в ИЕ6-7 он возвращает абсолютную ссылку, вместо того что реально написано в атрибуте.