Comments 16
Прекрасно. Ждём стилизацию датепикера ещё через 10 лет.
Веб всю историю пытается усидеть на трёх стульях. С одной стороны это желание дать пользователям привычный UX (что в переделе возможно лишь при использовании нативных контролов операционной системы). С другой - стилизация всего ради удовлетворения эстетических прихотей разработчиков либо их менеджеров (а значит отказ от нативных контролов в пользу самописных аналогов). И третья - не дать браузеру превратиться в полноценный кроссплатформенный UI toolkit (по типу XUL, XAML и т.п).
Стилизация всего — дело вполне осмысленное. Иначе вы навсегда будете привязаны к тем возможностям, что имеют нативные контролы. И всегда будете ими ограничены.
То есть да, пытается. Я не вижу в этом ничего плохого. Потребности разные. Кому-то нужно первое, кому-то второе. А третье — это попытка ограничить сложность. В том числе — хорошо бы научиться наконец переиспользовать все что можно от нативных контролов, чтобы не переписывать все с нуля, а писать только и именно то, что нужно.
Нативные контролы не имеют смысла в кастомном дизайне. Тут надо либо контролы в дизайне сайта иметь (а натив не настолько кастомизируем), либо дизайн сайта мимикрировать под систему (а тут любой кастомный элемент страницы превращается в 100500 версий под разные системные дизайны).
Вы так говорите, как будто это что-то плохое.
Скорее это что-то сложное. Написать кастомный контрол, имитирующий поведение нативных это дорого. Я имею ввиду полноценную поддержку нюансов различных устройств ввода и вывода, внутренней навигации, масштабирования и т.п. В нашем энтерпрайзе резко отказались от большинства кастомных контролов в вебе как только появились риски комплайнса по части a11y. Внезапно визуальная разница и хотелки перестали быть такой уж важной проблемой.
Сложно конечно. Вот как это ни удивительно, но в моей практике писать свои контролы проще всего было для Flex (который надстройка над Flash). И вот это вот все давненько уже было — а по сути с тех пор лучше особо не стало. Дорого и сложно. И баги, зачастую самые тупые. Скажем, некий явно кастомный контрол, вроде того, что тут описан в тексте. В поле ввода не работает удаление по кнопке backspace.
> риски комплайнса по части a11y
Слишком дорого поддерживать одновременно и хотелки, и a11y?
Когда вы используете стандартные контролы, то проблемы с a11y в этой части перееадресуются разработчикам браузера. Если кастомные - то это ваша ответственность (даже если вы купили библиотеку у вендора или взяли из open source). Конечно, можно делать две версии: одну соответствующую законным требованиям, а вторую - эстетическим. Но тут в дело вступают деньги.
Проблема с a11y в том, что поддержка добавляет изрядную пачку нефункциональных требований, а бардак по части браузеров и сопутствующих решений здесь как в нулевые.
добавить туда еще input:text для поиска и цены ему не будет. А то в интернете столько разных реализаций, что постоянно приходится делать свой вариант)
К нему еще API чтобы на сервер ходить за результатами, еще подгрузку данных при скролле в выпадушке, еще деревья чтобы с фолдингом. А, да, еще и вариант с выбором нескольких элементов, и чтобы тегами еще выбранное показывать. Вот этого всего - наверное уже хватит, чтобы начинать думать о замене кастомных реализаций на нативные. Без этого - ну такое: все равно для всех случаев не пойдет, а если уж тащить кастомный - то чего уж его везде не использовать.
вариант с выбором нескольких элементов, и чтобы тегами еще выбранное показывать
Кажется этот момент уже предусмотрели через multi-select, ссылка, хотя без JS и не обошлось.
А компонент, который будет делать API-запросы, если честно пугает.
Наверное стоит уходить от тегов в развитие канвас элементов посредством wasm, а не вот это вот всё. На текущий день у альтернативного подхода есть проблемы, отсутствие людей с ограниченными возможностями и вялое развитие wasm.
*поддержки для
Вам стоит посмотреть в сторону flutter, для веба он примерно так и рендерит.
Полный переход на canvas - это, по сути, просто поменять движок рендера. Останется все то же самое. Нативные контролы почему нужны? Потому что они реализуют все возможные варианты использования. Так они и в канвасе будут нужны.
Полет фантазии: в браузеры нужно добавить фолкбэк на канвас для подобных фичей: если нет нативной поддержки на уровне html - отрисовывать блок на canvas, в котором есть реализация компонента (я и сам вижу огромное количество проблем, но это лишь идея концепции).
Однажды у нас будет полностью настраиваемый select