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