(В идеале в гифке false должен было бы меняться на true.)

Заодно обновил документацию в MDN, чтобы эти два пункта были заметнее — я не знал о них именно из-за того, что они не были хорошо описаны. Редактируйте MDN тоже, если видите, что что-то можно улучшить :–)

Вообще говоря, задачу с шапкой всё равно можно решить через IntersectionObserver, но другим способом. Придётся посчитать высоту шапки, убрать опцию root и задать опцию rootMargin. Это менее удобно — если высота шапки поменяется, придётся создавать IntersectionObserver заново — но работает.

К сожалению, другие задачи, где элемент не с края экрана, так решить не получится. (А это плохо, потому что тогда, скорее всего, придётся слушать события resize и scroll — а это прилично медленнее.)

Тут ещё говорят, что IntersectionObserver отдаёт информацию с задержкой и поэтому не подходит для некоторых задач. Я пока не нашёл сходу какой-то дополнительной информации и не знаю, насколько задержка большая (найду — расскажу), но имейте в виду:

Привет. Читал про IntersectionObserver на google developers:
https://developers.google.com/web/updates/2016/04/intersectionobserver

Цитата от туда:
>Something to keep in mind is that IntersectionObservers are intentionally neither pixel perfect nor low latency. Using them to implement endeavours like scroll-dependent animations are bound to fail, as the data will be – strictly speaking – out of date by the time you’ll get to use it.

Правильно ли я понимаю, что на IntersectionObservers мы не можем полагаться полностью?

И вот ещё (для старых браузеров, кстати, есть почти полноценно работающий полифилл):

Вообще стоит иметь в виду, что IntersectionObserver пока не поддерживается в IE и Safari. Вкладка audits в Chrome предлагает использовать его для ленивой подгрузки картинок вне вьюпорта после того, как страница стала interactive (впрочем, без готовых советов как именно)

Узнал про <input type="month"> — поле ввода для выбора месяца, которое описано в спецификации, но почти нигде не документировано. Выглядит круто (это в Microsoft Edge):

#TodayILearned

Поддерживается он так же, как <input type="date"> — работает в Chrome и Edge, но не работает в Firefox и Safari.

Из-за средней поддержки использовать его в центральных элементах интерфейса пока нельзя, но в нецентральных, которыми пользуются мало пользователей, можно. Главное — аккуратно деградировать его до текстового инпута там, где он не работает:

<input type="month" placeholder="YYYY-MM" pattern="\d{4}-\d{2}">

(placeholder и pattern применятся, только если браузер не будет поддерживать <input type="date">, и подскажут пользователю о формате поля)

вот как бы правильная мысль, но у меня всё равно есть к чему докопаться.

Слово «запретить» подразумевает тут некое намерение, преступный сговор, желание испортить жизнь посетителям. Что происходит на самом деле это что люди просто не понимают, что делая вместо настоящей ссылки onclick они ломают это поведение. Они просто не знают о нем.  Никто ничего не запрещает. Они ж не вахтеры.

Почему выбор слова важен? В первом случае (запретить) решением проблемы будет обозлиться на таких людей, считать их идиотами, итп. Во втором (ломают по незнанию) очевидно, что надо объяснять и просвещать.

Никита Прокопов напомнил ↑↑ про проблему с onclick вместо ссылок, а я расскажу, как её избегать.

Проблема
Иногда вместо ссылок, ведущих куда-то, разработчики делают кликабельные div-ы. Как на Яндекс-Музыке (клик на «Жанры» поменяет урл, но это просто div):

Из-за этого сайт становится менее удобным. Я, например, не могу теперь открыть «Жанры» в соседней вкладке — в контектном меню просто не будет такого варианта.

Как избегать
Мне кажется, проблема возникает из-за двух причин — или человек не знает про неё, или он забыл про это в рабочей возне. И то, и другое решается постоянной тренировкой мозга замечать кликабельные элементы и думать.

Думать можно по такому алгоритму:
1. Вам нужно сделать новый элемент. Этот элемент как-то изменяет адрес страницы? Если да — это ссылка (<a>).

2. Этот элемент не изменяет адрес страницы, но кликабельный и как-то влияет на интерфейс (например, это вкладка/переключатель/сердечко/что угодно)? Если да — то это кнопка (<button>).

div-ы для кликабельных элементов лучше вообще не использовать. Преимущество кнопок перед div-ами в том, что они 1) нормально фокусируются и активируются с клавиатуры и 2) произносятся как «Кнопка» в экранных читалках. Есть и недостаток — придётся дописать несколько CSS-cвойств, чтобы убрать рамку и фон — но преимущества важнее.

В общем, правило:
Кликабельный элемент — ссылка, если он меняет URL, и кнопка во всех остальных случаях.

В личке добавляют:

Привет!

> постоянной тренировкой мозга замечать кликабельные элементы и думать

Можно ещё линтер настроить. Например, для реакта есть вот такой:
https://github.com/evcohen/eslint-plugin-jsx-a11y

Там есть правило jsx-a11y/no-static-element-interactions

Он сам замечает, что ты назначаешь обработчики статичным элементам и напоминает их сделать доступными, заодно можно вспомнить добавить href ссылке. Тэг <a> он тоже считает статичным почему-то

Вадим прав ↓
Я, когда писал пост, вообще не смог придумать нормального примера, зачем нужен кликабельный див. Отредактировал его

Привет!

> 3. Элемент не изменяет адрес страницы и не влияет на интерфейс? Тогда и только тогда можно сделать обычный <div> или <span> с onclick, да.

Очень вредный совет. Сразу хочется свалить в него все случаи и не думать. Это всегда либо кнопка, либо ссылка. Остальное — имитация несуществующих элементов, которую ещё нужно уметь делать.

Проверил сообщение Евгения (https://t.me/iamakulov_channel/93) о том, что IntersectionObserver срабатывает с задержкой. (IntersectionObserver — это штука в браузерах, которая позволяет определять, когда элемент пересекает экран или другой элемент.)

Задержка действительно есть. У меня на реальном проекте она составляет около полсекунды-секунду — то есть между тем, как я прокручиваю элемент за экран и тем, как срабатывает колбек, проходит минимум половина секунды. В отдельном кодпене (https://codepen.io/iamakulov/pen/QMOjqZ) при этом мне повторить эту задержку не удалось — возможно, она зависит от размера DOM-дерева или ещё чего-то.

Задержка значит, что часть задач с помощью Observer решать не получится. Например, у меня на текущем проекте есть прилипающая шапка, которая при прилипании меняет свой внешний вид. Сейчас это реализовано через window.addEventListener('scroll') с getBoundingClientRect() и тормозит. Я надеялся, что Intersection Observer сможет заменить слушатель события, но придётся искать другие способы.