Нативные элементы на мобильных

В мобильных браузерах нативный элемент <select> тесно интегрирован с операционной системой, и его поведение определяется не JavaScript-библиотекой, а самим движком платформы. При работе с такими элементами критически важно учитывать особенности iOS Safari, Android Chrome и встроенных WebView, поскольку они по-разному обрабатывают фокус, рендеринг и пользовательский ввод. Tom Select, как библиотека кастомного селекта, не заменяет нативное поведение полностью, а адаптируется к нему в зависимости от конфигурации.

Нативное открытие списка и ограничения контроля

На мобильных устройствах открытие <select> почти всегда приводит к отображению системного UI — колесо выбора (iOS) или диалоговый список (Android). Этот интерфейс:

  • не поддаётся стилизации через CSS;
  • игнорирует DOM-структуру кастомных элементов;
  • блокирует доступ к остальной части страницы;
  • управляется исключительно ОС.

Tom Select в базовой конфигурации может либо:

  • использовать нативный <select> (fallback-режим),
  • либо заменять его кастомным dropdown-интерфейсом.

При включённом режиме кастомного UI библиотека стремится избежать вызова системного селектора, однако полностью предотвратить его появление в некоторых сценариях невозможно (например, при программном вызове focus() на оригинальном элементе).


Различие поведения iOS и Android

iOS Safari

На iOS нативный <select> всегда открывается в виде модального колесного интерфейса. Особенности:

  • экран полностью затемняется;
  • фокус блокируется на элементе выбора;
  • виртуальная клавиатура не участвует;
  • скролл страницы временно фиксируется.

Критический момент: если кастомный интерфейс Tom Select не полностью отключает фокусировку оригинального элемента, iOS может перехватить событие и открыть системный picker вместо кастомного dropdown.

Android Chrome

На Android поведение зависит от версии браузера и настроек устройства:

  • может использоваться диалоговый список;
  • иногда применяется встроенный dropdown поверх страницы;
  • в WebView возможна гибридная реализация.

Android более предсказуем в плане перехвата событий, однако менее единообразен между устройствами.


Проблема виртуальной клавиатуры

Одной из ключевых проблем мобильного взаимодействия с селектами является появление клавиатуры.

Когда клавиатура не нужна

Для <select> клавиатура не требуется, но она может появиться если:

  • элемент получает фокус как текстовое поле;
  • Tom Select работает в режиме поиска (searchable select);
  • мобильный браузер интерпретирует input внутри компонента как текстовый ввод.

Поведение Tom Select

Tom Select использует внутренний <input> для поиска, и именно он активирует клавиатуру. Это приводит к нескольким эффектам:

  • перекрытие dropdown-контента клавиатурой;
  • изменение высоты viewport;
  • скачки позиционирования списка;
  • потеря видимости выбранного элемента.

На мобильных устройствах особенно важно учитывать динамическое изменение window.innerHeight, так как виртуальная клавиатура может «сжимать» доступную область экрана и ломать абсолютное позиционирование dropdown.


Управление фокусом

Фокус — центральный механизм, определяющий поведение мобильного селекта.

Tom Select перехватывает фокус с оригинального <select> и переводит его на собственный input. Однако в мобильной среде это приводит к ряду нюансов:

  • фокус может автоматически возвращаться к нативному элементу;
  • некоторые браузеры игнорируют preventDefault() на touch-событиях;
  • двойной фокус (select + input) вызывает конфликт поведения.

Практическая особенность

При использовании controlInput внутри Tom Select важно учитывать, что:

  • любой focus() инициирует клавиатуру;
  • скрытие input через CSS не всегда предотвращает её появление;
  • лучше контролировать доступность input через логическое состояние, а не визуальное скрытие.

Позиционирование dropdown на мобильных экранах

Dropdown в Tom Select обычно позиционируется относительно контейнера через абсолютное или фиксированное позиционирование. На мобильных устройствах это усложняется из-за:

  • динамического изменения viewport при открытии клавиатуры;
  • отсутствия стабильного 100vh в iOS Safari;
  • смещения элементов при появлении системных панелей.

Типичные проблемы

  • dropdown уходит за нижнюю границу экрана;
  • список обрезается системной клавиатурой;
  • прокрутка страницы конфликтует со скроллом списка;
  • позиция пересчитывается после открытия, вызывая «скачок».

Поведение Tom Select

Библиотека пытается:

  • пересчитывать позицию при открытии dropdown;
  • учитывать scroll контейнера;
  • переключаться между режимами top и bottom.

Однако на мобильных устройствах эти расчёты могут быть неточными из-за асинхронного изменения layout после появления клавиатуры.


Scroll-lock и взаимодействие со страницей

При открытии dropdown часто применяется блокировка скролла страницы. На мобильных это особенно важно, потому что:

  • пользователь может случайно прокручивать фон;
  • viewport постоянно меняется;
  • жесты прокрутки интерпретируются системой по-разному.

Особенности реализации

Tom Select может:

  • добавлять класс блокировки на body;
  • фиксировать позицию страницы через overflow: hidden;
  • сохранять scroll position перед открытием.

На iOS Safari существует дополнительная проблема: overflow: hidden не всегда предотвращает скролл, поэтому может потребоваться фиксация через position: fixed.


Сенсорные события и их ограничения

Мобильные браузеры по-разному обрабатывают события:

  • touchstart часто имеет приоритет над click;
  • click может срабатывать с задержкой;
  • preventDefault() может игнорироваться;
  • пассивные event listeners ограничивают контроль прокрутки.

Tom Select вынужден учитывать эти ограничения, особенно при работе с:

  • открытием dropdown по тапу;
  • выбором элемента списка;
  • закрытием при касании вне области компонента.

Оптимизация производительности на мобильных устройствах

Кастомный селект с поиском может быть тяжёлым для мобильных браузеров при больших списках.

Основные источники нагрузки:

  • частая фильтрация списка при вводе;
  • перерасчёт DOM при каждом символе;
  • перерисовка dropdown;
  • обработка scroll событий.

Подход Tom Select

Используются:

  • debounce для поиска;
  • виртуализация частично (через ограничение отображаемых элементов);
  • кеширование результатов поиска;
  • минимизация reflow при обновлении списка.

Поведение при смене ориентации

При повороте устройства:

  • изменяется viewport;
  • пересчитывается высота dropdown;
  • сбрасывается позиционирование;
  • может закрываться виртуальная клавиатура.

Tom Select обычно не отслеживает orientation change как отдельное событие логики, но полагается на перерасчёт позиционирования при изменении размеров окна.


Влияние безопасных зон (safe area)

На современных устройствах с вырезами и жестовыми панелями (особенно iOS):

  • нижняя область экрана может быть недоступна;
  • dropdown может перекрываться системными элементами;
  • требуется учёт env(safe-area-inset-bottom).

Tom Select по умолчанию не добавляет safe-area адаптацию, поэтому она должна учитываться в CSS слоях обёртки.


Сценарии конфликтов с нативным select

Наиболее частые проблемы возникают при смешанном использовании:

  • оригинальный <select> остаётся в DOM;
  • кастомный интерфейс активен поверх него;
  • события фокуса не синхронизированы.

Это приводит к:

  • двойному открытию UI;
  • потере выбранного значения;
  • расхождению состояния между DOM и компонентом.

Поведение в WebView и гибридных приложениях

Внутри WebView (Android/iOS):

  • нативный select может полностью заменяться системным диалогом;
  • кастомный dropdown может конфликтовать с жестами приложения;
  • фокусировка может управляться нативным слоем приложения.

Особенно часто наблюдается:

  • задержка открытия dropdown;
  • отсутствие анимаций;
  • некорректное позиционирование при встроенном скролле.

Итоговая модель поведения Tom Select на мобильных

Поведение библиотеки в мобильной среде формируется как комбинация трёх слоёв:

  • нативный UI операционной системы (select picker);
  • JavaScript-логика Tom Select (input, dropdown, фильтрация);
  • браузерные ограничения (viewport, события, клавиатура).

Ключевая особенность заключается в том, что мобильный селект никогда не является полностью управляемым компонентом. Любая реализация должна учитывать, что часть поведения остаётся под контролем платформы, а не JavaScript-кода.