Я ставил 5 ложных массивов, один из шести.
Поясните механизм, по которому 5% ботов смогут совершенно спокойно зарегистрироваться, при условии, что у него всего одна неправильная попытка, и следующую он сможет произвести через все большее время.
На данном ресурсе я несколько раз обновляю капчу, чтобы стопроцентно гарантировать ее прохождение с первого раза. Вопрос, чем отличается это от приведенного мной варианта?
Открою вам секрет, что custom tags в ИЕ поддерживаются с версии 5.0 или 5.5, точно не помню. Ищите в инете это ключевое слово. Там все не безоблачно, но использовать в проектах можно.
А в чём претензия, сказать не можете? Зачем с ними только работать в динамике, ума не приложу. Они предназначены для отображения каких-то изменений, например, между разными версиями документа. Откуда там динамика?
Хоть одну систему знаю. Да и сам использовал для внутренних инструментов сайта.
Конечно могу. Эти два тега имеют двоякую суть, могут быть блочными или строчными. Это вроде бы не проблема, но любой CSS, который будет учитывать позицию элемента в дереве, должен учитывать и этот элемент. Например, если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс. Если скрипт обходил детей ноды, и там всегда предполагался какой-то один элемент, то с учетом del/ins все может поломаться, и придется использовать другие варианты работы с деревом, которые могут быть не самыми быстрыми в реализации.
А это с какой ещё стати? Это поведение, а не отображение. Вы ещё скажите, что каким-нибудь атрибутам вроде onclick место в CSS.
А чем position: fixed не поведение? Вот в чем разница? position: draggable — аналогичное свойство. Псевдоклассами управляем состояние наведения на таргет, DOM будет работать так же как и сейчас.
Шанс ошибки валидации, говорите, выше? А что вам говорит бизнес, когда сайт не работает (страница вообще не отображается) из-за ошибки в XML из-за какого-нибудь неэкранированного амперсанда? А современные методы DOM (например, querySelector и др.) вполне способны справится.
Выше шанс. Пропустить div проще, чем пропустить отсутствие четко именованного тега. Доказанный факт. Валидацию XML проще сделать перед публикацией, чем валидацию HTML.
Вы отрицаете технологию в общем, из-за того что в каком-то частном случае она не так удобна. Во-первых, предложите лучше, во-вторых, когда в браузерах появится хоть что-то подобное, это будет уже большой прогресс.
Конечно отрицаю, потому что если изначально технология не справилась с современными задачами, то дальше пойдут или хаки, или полное переписывание спецификации в данном вопросе. Это будет ад для разработчиков браузеров и для веб-разработчиков. Если лопата не поможет быстро перекопать 1 гектар земли, то любые нанопокрытия, улучшенные формы для снижения трения и другие примочки не исправят ситуацию. Нужно заведомо более гибкое решение, чтобы не было потом как с menu, то его отменяют, то обратно возвращают.
От этого не избавиться никак :( Вроде бы никак. Надо подумать. Хм, первое, что приходит в голову — создать некий алгоритм создания логических задач, т.е. неповторяемого бота, генерирующего уникальную задачу по каждому запросу. Угадывать принципы создания таких задач сугубо по внешним факторам будет очень дорого.
Что даст анализ страницы? Не поленитесь, попробуйте найти ответ в коде.
Второй путь блокируется на ура простыми системами защиты от повторных срабатываний.
В одном из постов я написал, как можно запретить роботу отправлять пять постов — увеличивая лаг между отправками сообщений, и очищая сессию при второй неправильной попытке. Можно ведь изменить условия решения, и правильный массив вставлять на позицию после двух неправильных, а не после одного, как сейчас.
По поводу сети из тысячи машин. Ничего. Привязка идет по сессии.
Это дорого по ресурсам, и нисколько не эффективно. Зачем что-то делать два раза, если можно сделать один? Да и работать с CSS, DOM в XML будет в разы легче и проще. Попробовав раз, трудно от этого сладкого запретного плода отказаться.
Менеджерами не рождаются. Стоит серьезно пересмотреть систему доверия к людям. Люди будут факапить, будут писать неверный код, будут совершать простые ошибки. Лучше силы направить на то, чтобы человек был более самостоятельным в выборе решения. И тогда эффективность такого работника будет впечатлять, а работа менеджера будет состоять в указании морковки в том или ином углу.
Комфортная для руководителя, но не для работника. Вы работаете над задачей. В процессе реализации сталкиваетесь с проблемой. Проблема требует дополнительного анализа, тесткейзов, изучения матчасти и прочего. Менеджер считает, что вы должны уже пол часа как справиться с задачей, а вы занимаетесь в это время исследованиями. Он начинает вас пинговать запросами, сделано или нет. Вы нервничаете, раздражаетесь, пытаетесь пояснить проблему, но менеджеру ваше пояснение не нужно, у него уже стоит красный флажок. В итоге все скатывается к тому, что работнику либо нужно показывать эффективность любыми способами, либо делать вид, что показываешь эффективность.
Я могу неделю не трогать человека, если он работает над какой-то большой проблемой. Он работает над ней, и его трогать не нужно. Он сам придет с вопросами, или уточнениями, и это отлично покажет, на каком этапе он находится.
Поясните механизм, по которому 5% ботов смогут совершенно спокойно зарегистрироваться, при условии, что у него всего одна неправильная попытка, и следующую он сможет произвести через все большее время.
Конечно могу. Эти два тега имеют двоякую суть, могут быть блочными или строчными. Это вроде бы не проблема, но любой CSS, который будет учитывать позицию элемента в дереве, должен учитывать и этот элемент. Например, если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс. Если скрипт обходил детей ноды, и там всегда предполагался какой-то один элемент, то с учетом del/ins все может поломаться, и придется использовать другие варианты работы с деревом, которые могут быть не самыми быстрыми в реализации.
А чем position: fixed не поведение? Вот в чем разница? position: draggable — аналогичное свойство. Псевдоклассами управляем состояние наведения на таргет, DOM будет работать так же как и сейчас.
Выше шанс. Пропустить div проще, чем пропустить отсутствие четко именованного тега. Доказанный факт. Валидацию XML проще сделать перед публикацией, чем валидацию HTML.
Конечно отрицаю, потому что если изначально технология не справилась с современными задачами, то дальше пойдут или хаки, или полное переписывание спецификации в данном вопросе. Это будет ад для разработчиков браузеров и для веб-разработчиков. Если лопата не поможет быстро перекопать 1 гектар земли, то любые нанопокрытия, улучшенные формы для снижения трения и другие примочки не исправят ситуацию. Нужно заведомо более гибкое решение, чтобы не было потом как с menu, то его отменяют, то обратно возвращают.
Второй путь блокируется на ура простыми системами защиты от повторных срабатываний.
По поводу сети из тысячи машин. Ничего. Привязка идет по сессии.
Я могу неделю не трогать человека, если он работает над какой-то большой проблемой. Он работает над ней, и его трогать не нужно. Он сам придет с вопросами, или уточнениями, и это отлично покажет, на каком этапе он находится.