Потому что вы не предложии простого и естественного способа - стандартного геотаргетинга в HTML5 Большинство броузеров давно его поддерживает. Включайте и наслаждайтесь. Броузер обязательно предупредит юзера о вашем желании узнать откуда он, даже если он ходит через прокси.
И вот тогда мы точно будем знать что юзер хочет.
А до этого мы оба этого не знаем.
Не факт что юзер этого хочет, если ходит напрямую. Вы же его об этом не спрашиваете?
А смысл? Движок тот же что и у хрома. Только хромовские баги апдейтятся медленее, да и свои наверное еще вносят.
Без сервера верстать ну очень лениво. HTML c CSS все-таки очень тупая вещь. Ну а что лучше - FF или Chrome скорее дело привычки. Мне больше FF нравится, но иногда Хром значительно лучше.
Плюется на кодировку. Проверяйте заголовки, которые отдает сервер, кодировку самой страницы. Все должно быть в UTF
А "уникальный контент" в виде картинки на страничке в бонус не идет?
Ну даже если и не идет - все равно вариант защиты от автоматической покражи вполне нормальный. Проще парсить то что можно юзать без лишних хлопот.
Хорошая идея - плодить абсолютно не уникальные картинки да еще и с описанием товара, которое практически повторяет то же самое что на тысяче таких же клонов как у топикстартера?
document.getElementById('#parent')
А я и не отрицаю :) Уже несколько лет вынужден обходиться без него. Но синтаксис $ активно юзаю в своей собственной библиотеке.
Мне приходилось когда-то писать программы в машинных кодах на перфокартах. Это намного "культурнее" чем как сейчас. В кодах программы получались эффективнее, а перфокарты в случае ядерного удара не теряли информацию в отличие от современных носителей. Но писать программы как мы с вами сейчас пишем, намного удобнее. Ну а ядерную войну мы все равно не переживем.
Никто никуда не ушел. Пока мерзотный DOM/JS синтаксис жив, синтаксис DOM/jQuery никуда не денется (В jquery, zepto или куче других аналогичных библиотек). Он красив, понятен и лаконичен. В отличие от альтернатив, которые еще хуже. Поэтому все конкуренты вымерли, а то что идет дальше (MV*, UI-фреймворки) или идут в паре с jQuery или идут лесом. В ExtJS к примеру есть родная DOM-библиотека, но она настолько ужасна, что в основном если есть надобность юзают jQuery
Т.е. элемент DOM это тоже объект не извращение, его жуткий синтаксис - не извращение, разночтение полей вплоть до краха системы это не извращение, а удобная обертка вокруг этого ужаса - извращение???? Месье, знает толк :)
грамотный программист знает не про баблинг и капчуринг, а про шаблон делегирования событий. Ну и в контексте JS (как у Кантора) нужно понимать естественно и "баблинг и капчуринг" если речь идет о делегирования события DOM . В данном конкретном случае ваш выпад был против любителей jquery, которым для делегирования события DOM не нужно юзать этот синтаксический ужас
document.getElementById('#parent').addEventListener('click'...
вместо изящного
$('#parent').click(...
К тому же отмечу что ваш пример в отличие от $ еще и не кроссброузерный.
Не даст :) Разработчики броузеров никогда(!) не дают никакой гарантии что страница содержащая ошибки будет правильно обработана, а валидатор https://validator.w3.org/check подсказывает, что " Attribute h not allowed on element a at this point."
Вы застали времена, когда Opera изображала из себя валидатор и отказывалась иметь дело со всем чего не было в W3C? Не так уж и давно это было.
Seredniy Извините, не пятница, но все равно последний рабочий день недели располагает к холиварам. А холивар jQuery ver PureJS это святое :)
Вот не надо обощать. Бибо и Кац - наше все.
Отнюдь.
1. Смысл думать возникает каждый раз когда все начинает тормозить из-за 100 одинаковых обработчиков или когда по недомыслию вместо hover юзается mouseover
2. Писать больше нужно только плохим программистам. Хорошие пишут свой jquery :)Ну ей-ей, лениво же писать document.getElementById. Проще самый минимум выделить в отдельную библиотечку и естественно совпадающую по синтаксису с jquery. Или на худой конец взять что-то из microlib
Читаем современный учебник Javascript Ильи Кантора:
Всплытие событий позволяет реализовать один из самых важных приёмов разработки — делегирование. Он заключается в том, что если у нас есть много элементов, события на которых нужно обрабатывать похожим образом, то вместо того, чтобы назначать обработчик каждому — мы ставим один обработчик на их общего предка. Из него можно получить целевой элемент event.target, понять на каком именно потомке произошло событие и обработать его.
Прочитайте про делегирование событий в js вообще и в jquery в частности. Суть в том что когда у вас в контейнере не один элемент, а непонятно сколько нужно отлавливать событие клика (или что-то еще) не на каждом элементе, а только на родителе.
Когда кликаете по какому-то элементу событие передается дальше родителям вплоть до body. Там можно проанализировать кто отдал событие и отреагировать на него. В этом случае у вас значительно снижаются накладные расходы, меньше вероятность утечки памяти, и не нужно знать был ли элемент статическим или динамическим.
Пример
<div id="parent"> <div class="tracked">1</div> <div class="tracked">2</div> ................................................ <div class="nonTracked">3</div></div>$('#parent').click(function(e) { // cлушаем предка, любого, можно слушать например 'body' var who = e.target; // определяем откуда пришло событие if (who.hasClass('tracked')) { // определяем это то за чем следим или нет. В данном случае следим за элементом с классом tracked alert(who.text()); } });
Раньше все болели jquery, теперь все болеют backbone :( Ну вот нахрена в данном случае приплетать backbone или что-то еще? Вы еще ExtJS присоветуйте. Там тоже MV* есть
Отнюдь. Глава про делегирование событий есть в любом учебнике по jquery и это было доступно в самых первых версиях.
На каждый из 15 сайтов для каждой картинки лепите свою рамку со случайным позиционированием элемента
пример:
На сайте естественно рамки кропать.
все три картинки уникальны. за счет того что позиция картинки на плашке рэндомная автоматом ее выкусить будет сложно, а парсить лениво. Проще стырить этот холодильник у кого-то другого.
От накладных расходов в виде трафика никуда не деться
Как вариант снижения накладных расходов - склеить несколько видов продукции во фрейм. порядок видов перемешать для каждого сайта. подозреваю что и в этом варианте картинки будут уникальными.
