Какая-то оптимизация уже явно появилась в Chrome (v75.0 x64). Но при этом поведение не такое, как с предложенным здесь способом с отключением hover, а заметно лучше. Подсветка (hover) срабатывает значительно реже во время скроллинга. В микро-паузах, пока палец меняет свою позицию над скроллом, успевает сработать подсветка. А самое главное, по окончанию скроллинга элемент, над которым остановился курсор становится подсвеченным — это самое большое отличие не в пользу способа с отключением hover.
В Chrome способ с отключением hover показывает себя лучше по FPS примерно на 10% и возможно в отдельных сценариях он даже сейчас будет уместен.
В FF (v60.8 x32) такой оптимизации не ощущается, либо она там чуть меньше сделана. Способ с отключением hover показывает себя лучше по FPS примерно на 15-20%.
В MS Edge (v44 x64, EdgeHTML v18) такая оптимизация явно есть, при том что она визуально работает почти так же как с отключением hover. Даже при остановке после скролинга hover не срабатывает у элемента находящегося под курсором. Вообще очень похоже. Во время скроллинга hover срабатывает только, если перемещать курсор. Разница по FPS почти незаметна.
Согласен. Хорошее замечание. У меня есть ещё предложения:
Проверка classList.contains()бесполезна в тех случаях, когда нужно сделать classList.add(). Built-in метод add уже внутри нативно содержит такую проверку, поэтому избыточно делать дважды эту проверку.
Можно не добавлять дополнительную переменную hover_disabled, а объединить её вместе с timer. Их логика для данных целей синхронна, поэтому можно удачно их объединить.
Можно не вызывать clearTimeout() лишний раз, когда timer уже отработан.
Таких эффектов, которые не вызывают repaint очень мало. И сложно представить ради каких из них может вообще использоваться :hover. Ну cursor, да, не редкий в таких случаях. А другие — большая редкость.
Вот так интересно получилось, что на видеозаписи с моим билетом на самом деле не мой билет. Был ли вообще напечатан мой билет, наверное никто не сможет сказать.
С последним абзацем верно подметили. Не лишним будет об этом иногда напоминать коллегам-разработчикам. Ведь в наше время даже провайдеры не стесняясь внедряют чужеродные объекты на загружаемые страницы. Тому примеров даже на хабре можно найти много (вот к примеру).
И вы так со всеми «third-party» системами поступаете? И как в дальнейшем вы хотите мониторить изменения IP адресов для каждой системы? Это каждому маломальскому проекту понадобится отдельный сотрудник в штате, который этим будет заниматься, и то не факт что всегда всё актуально будет.
за это место нельзя было особенно заddos-ить
Против этого существуют более эффективные методы. Они так же используют блокировку по IP адресам, как один из факторов обеспечения безопасности, но чёрный список адресов формируется динамически при поступлении подозрительных запросов, и в редких случаях изменяется вручную.
Нельзя доверять вообще каким-либо запросам от «third-party» систем. После получения каких-либо запросов в вашу систему, вы должны сами запросить подтверждающие данные у «third-party» системы с определённого белого-адреса. И для такого общения систем часто достаточно лишь HTTPS. Посмотрите к примеру на протокол-авторизации OAuth — это отличный пример, как нужно поступать при реализации всех других схем общения различных систем.
этот функционал никогда, подчеркиваю, никогда не будет запрограммирован
— Не ради пиара, но мы об этом заботимся, т. е. есть всё таки исключения.
— Вообще, конечно, на такую печальную действительность наталкивают сами ПС. Другие, «правильные» ПС, предоставляют магазину возможность получать лишь событие об обновлении состояния платёжной транзакции предоставляя при этом лишь номер транзакции (внутренний номер транзакции в ПС). Т. е. такой колбек не говорит о том, что случилось событие успешной оплаты. А уже используя полученный номер, магазину нужно делать запрос в ПС, для того чтобы узнать, в каком состоянии сейчас находится транзакция и все данные о ней. Если бы так поступали не единичные ПС, а все, то программисту просто пришлось бы делать всегда правильно.
Вообще магазину, как мне кажется, можно особо не заботиться, о том на сколько круто продуманы подписи создания платежа. Магазину от платёжной системы (ПС) важно только, что бы та позволила пользователю быстро и удобно оплатить определённую сумму. А если пользователь каким либо образом оплатил меньшую сумму, то такие махинации легко нейтрализуются одним лишь запросом проверки статуса и оплаченной суммы от ПС.
Какие-то ну уж очень «детские» ошибки, которые исправляются все разом — просто добавив на стороне callback-метода проведения платежа отправку запроса в API Liqpay для проверки статуса и суммы платёжной транзакции. Проверив статус и оплаченную сумму по определённой транзакции уже можно наплевать на махинации с подменой параметров.
Случайно вспомнил про свой старый аккаунт и поиск выдал мне этот старинный пост. Я даже ради забавы решил проверить работоспособность своего некро-аккаунта. :)
Эти сервисы раньше реально работали. Сам попробовал ради смеха завести E-mail на таком домене. Но позже этот сервис «Мыльница» отключили, но сами учётные записи привязанные к этим смешным доменам остались рабочими.
В большинстве случаев этого, наверно, будет достаточно для того, чтобы создать объект с методами и свойствами для удобного разбора и работы с URL. Плюс получается максимальная приближенность к стандартам работы с URL в браузерах.
Вообще достаточно легко найти даже на Github множество либ для работы с URL. Вот к примеру Polymer/URL, тут небольшой список, и множество других.
Отличное обновление!
Панель задач может быть расположена у любого края экрана, а не только у нижнего. Но смысл понятен. Проверил — работает на других краях экрана.
В дополнение к takeUntil и takeWhile для автоматической отписки можно использовать подход untilDestroyed (статья).
Какая-то оптимизация уже явно появилась в Chrome (v75.0 x64). Но при этом поведение не такое, как с предложенным здесь способом с отключением hover, а заметно лучше. Подсветка (hover) срабатывает значительно реже во время скроллинга. В микро-паузах, пока палец меняет свою позицию над скроллом, успевает сработать подсветка. А самое главное, по окончанию скроллинга элемент, над которым остановился курсор становится подсвеченным — это самое большое отличие не в пользу способа с отключением hover.
В Chrome способ с отключением hover показывает себя лучше по FPS примерно на 10% и возможно в отдельных сценариях он даже сейчас будет уместен.
В FF (v60.8 x32) такой оптимизации не ощущается, либо она там чуть меньше сделана. Способ с отключением hover показывает себя лучше по FPS примерно на 15-20%.
В MS Edge (v44 x64, EdgeHTML v18) такая оптимизация явно есть, при том что она визуально работает почти так же как с отключением hover. Даже при остановке после скролинга hover не срабатывает у элемента находящегося под курсором. Вообще очень похоже. Во время скроллинга hover срабатывает только, если перемещать курсор. Разница по FPS почти незаметна.
В MS IE (v11 x64) примерно так же как в MS Edge.
ЦП: Intel® Core(TM) i5-4200H CPU @ 2.80GHz
ОЗУ: 8,0 ГБ DDR3, 1600 МГц, SODIMM
GPU: Intel® HD Graphics 4600, 2,0 ГБ
Согласен. Хорошее замечание. У меня есть ещё предложения:
classList.contains()бесполезна в тех случаях, когда нужно сделатьclassList.add(). Built-in методaddуже внутри нативно содержит такую проверку, поэтому избыточно делать дважды эту проверку.hover_disabled, а объединить её вместе сtimer. Их логика для данных целей синхронна, поэтому можно удачно их объединить.clearTimeout()лишний раз, когдаtimerуже отработан.Вот мой вариант:
Прошло 5+ лет — поддержка pointer-events в браузерах осталась.
Таких эффектов, которые не вызывают repaint очень мало. И сложно представить ради каких из них может вообще использоваться
:hover. Нуcursor, да, не редкий в таких случаях. А другие — большая редкость.Екатерина ayocommon, благодарю за статью, историю и примеры.
Жаль, что все примеры кода оформлены картинками, когда есть встроенная подсветка в редакторе статьи.
Куда-то пропало
transform rotateZпосле преобразования CSS в Styled-components:В примере про BEM-XJST в этом куске пахнет плохо
На мой взгляд так дышать лучше и выглядит читабельные
Против этого существуют более эффективные методы. Они так же используют блокировку по IP адресам, как один из факторов обеспечения безопасности, но чёрный список адресов формируется динамически при поступлении подозрительных запросов, и в редких случаях изменяется вручную.
Нельзя доверять вообще каким-либо запросам от «third-party» систем. После получения каких-либо запросов в вашу систему, вы должны сами запросить подтверждающие данные у «third-party» системы с определённого белого-адреса. И для такого общения систем часто достаточно лишь HTTPS. Посмотрите к примеру на протокол-авторизации OAuth — это отличный пример, как нужно поступать при реализации всех других схем общения различных систем.
Такие методы аналогичны использованию пластилина или скотча там, где обязательно нужно использовать саморезы или другие специализированные крепления.
— Не ради пиара, но мы об этом заботимся, т. е. есть всё таки исключения.
— Вообще, конечно, на такую печальную действительность наталкивают сами ПС. Другие, «правильные» ПС, предоставляют магазину возможность получать лишь событие об обновлении состояния платёжной транзакции предоставляя при этом лишь номер транзакции (внутренний номер транзакции в ПС). Т. е. такой колбек не говорит о том, что случилось событие успешной оплаты. А уже используя полученный номер, магазину нужно делать запрос в ПС, для того чтобы узнать, в каком состоянии сейчас находится транзакция и все данные о ней. Если бы так поступали не единичные ПС, а все, то программисту просто пришлось бы делать всегда правильно.
В большинстве случаев этого, наверно, будет достаточно для того, чтобы создать объект с методами и свойствами для удобного разбора и работы с URL. Плюс получается максимальная приближенность к стандартам работы с URL в браузерах.
Вообще достаточно легко найти даже на Github множество либ для работы с URL. Вот к примеру Polymer/URL, тут небольшой список, и множество других.
А как банки понимают, что была произведена замена?