<input> Я ♥ тебя, но ты меня обламываешь

[aml]

Когда не знаешь ещё, в какую сторону будет развиваться технология, придумать правильный стандарт, правильный API очень сложно. Удачная абстракция быстро стала популярной, стала обрастать фичами, не вписывающимися в первоначальный дизайн, и вот результат. Своего рода проклятие первопроходцев.

[AreD]

Да, но какие то легаси проблемы, например, решаются. Те же флекс блоки позволяют вертикальное позиционирование делать. А тут казалось бы простая вещь – стандартизация и возможность широкой настройки стилей элементов форм. Веб состоит из дизайна/верстки и пользовательского взаимодействия с сайтом. Вот когда верстаешь, делаешь красоту и душа прям радуется, вот тебе веб инспектор, вот тебе и инструменты для оптимизации CSS, вот тебе удобные медиа-запросы. Но как только ты доходишь до пользовательского взаимодействия – боль.

[Hint]

Как-то установил на проекте тип email для всех полей, предназначенных для ввода почты. Сначала радовался (автоматическое добавление нужных символов на клавиатурах мобильных устройств), а потом вернул тип text. Почему? Потому что если случайно добавить лишний пробел (перед адресом или после), то браузеры считают значение неверным и не дают отправить форму. А ведь это происходит очень часто и вводит пользователей в заблуждение (особенно при copy-paste). В итоге, бесполезный тип без костылей на JavaScript, хотя при отправке достаточно было бы сделать trim. Возникает еще проблема с доступом к value из скрипта, но могли бы что-нибудь придумать.

[AreD]

Возникает еще проблема с доступом к value из скрипта, но могли бы что-нибудь придумать.

А о какой проблеме идет речь?

[Hint]

Я имею в виду, что если делать trim при отправке формы, то как быть, например, в случае ajax (когда скрипт сам берет значение из поля)? Как быть с псевдоклассами валидации? Т. е. визуально значение одно (с пробелом), а фактически для скриптов другое?

[jrip]

Ну в идеале в такое поле не должен просто никак попасть пробел и не надо тогда никаких неожиданных trim`ов.

[kykint]

Кстати с value действительно был косяк, однажды столкнулся. Если в number поле было вбить невалидное значение, то value говорит, что там пусто

[Hint]

На самом деле проблема не только с email. Например, тип url. Значение www.ya.ru по сути неверное, но браузер может преобразовать в www.ya.ru и отправлять именно это значение (и предоставлять его скриптам).

[WaveCut]

В помощь призывается pattern!

[Hint]

И он воспринимается мобильными устройствами? Они добавляют на клавиатуру все нужные спец. символы?

[WaveCut]

Когда я последний раз тестировал — судя по поведению типизированные поля вроде url, email, tel просто используют некий pattern «по-умолчанию». Если его переписать — валидация будет плностью своя. При этом поле не теряло своих новых качеств на клавиатуре.
Но конечно, все может меняться от платформы к платформе. У меня яблоко.

[demimurych]

Так и есть.

[samosad]

достаточно форме добавить атрибут novalidate, тогда браузер не будет применять к таким инпутам правила валидации по умолчанию, а клавиатура на мобильных будет открываться нужная

[Methos]

Вы просто не умеете это готовить

[volk0ff]

Интересно мнение экспертов: если по аналогии с ВК, вместо инпутов использовать повсеместно дивы с атрибутом contenteditable="true" , ничего страшного не произойдет? (там то со стилями все менее плачевно)

[trikadin]

Придётся писать апи самому, хех. И насколько я помню (давно таким не занимался) — там далеко не нулевое количество кроссбраузерных несовместимостей.

[volk0ff]

Стоит ли так все усложнять? (Я, например, просто брал яваскриптом содержимое этих div-ов и отправлял на сервер аяксом)

[trikadin]

Ну это же в первую очередь от задачи зависит О_о

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

Нет, конечно, наверняка есть фреймворки, которые такое делают… Но в таком случае ты просто променяешь одно АПИ на другое.

[volk0ff]

Не исключаю, что у меня имеются пробелы в знаниях JS, но какая разница, куда, например, выводить сообщение об ошибке, которое пришло от сервака — под соответствующий инпут, или под такой же див? :)

[jrip]

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

[trikadin]

Я вам не про то. Давайте я вам набросаю краткий список того, что нужно дописать для редактируемого дива, чтобы они сравнился по функционалу с современным инпутом.

• Типы форм. Придётся делать проверку на ввод только чисел для чисельного ввода, отображение календарика для ввода даты, проверку ввода корректной даты и времени для соотв. типов, цветовой ввод для color, ползунок для rangе… Да и что я вам перечисляю, вот тут всё есть. Это уж не говоря про всякие радиобаттоны и флажки.
• Перехватывать нажатия таба для нормального перехода по элементам формы, и вообще разные сочетания клавиш для accesskey.
• Модификаторы поведения — disabled, readonly, checked, autofocus...
• Валидация. Это поля pattern, min, max, minlength, maxlength, step, встроенная регулярка для урлов, емейлов, телефонов...
• Разные другие плюшки — placeholder, list.
• Связь с формой отправки на сервер.
• Событийная система.

Наконец, есть вещи, которые вы никак не сможете эмулировать — автозаполнение, переключение видов клавиатуры на телефонах в зависимости от типа инпута, выбор файла (это можно кое-где, но тоже очень геморройно). Смекаете? Чтобы реально замениить инпуты чем-то другим, надо проделать огромную работу.

[Zibx]

А в случае инпутов в вебприложении приходится всё равно это делать, но и попутно рубить дефолтное поведение не совпадающее между браузерами.

[trikadin]

В случае contenteditable некроссбраузерного поведения гораздо больше, а фичей — меньше.

[jrip]

Можно и на канвасе полностью свой интефрейс намутить, вопрос в поддержке всеми браузерами, сложности разработки и с поддержкой нестандартных решений следующим разработчиком. Как по мне, так лучше использовать стандартные элементы и запариваться со стилями.

[dshster]

Придётся очень дико обрабатывать событие copy/paste потому что в contenteditable вставляется текст в формате text/html со всеми вытекающими. Но это еще не всё — так же придётся обрабатывать события перетаскивания в это поле и (внимание!) событие document.execCommand из консоли, через которое в contenteditable можно вставить всё что угодно. А это уже довольно объёмная портянка кода.

[Ohar]

ничего страшного не произойдет?

Нет, ничего. Просто отдельный котёл в аду.

[Meklon]

Безотносительно самого перевода. Вы цитаты вставляли как картинку верт икальной черты плюс обтекание текстом, который заголовок с выравниванием по центру? Просто очень непривычно. Синтаксисом не поделитесь?

[AreD]

Ответил в личку

[Meklon]

Спасибо большое. Только, видимо, не мне в личку)

[AreD]

Вам, вам, проверьте)

[Meklon]

Протупил мессенджер местный) Теперь оба сообщения пришло. Спасибо.

[Newbilius]

А можно и мне в личку? :-)

[AreD]

Можно и вам) Отправил

[Sild]

В андроид клиенте видны только полосы. Даже не догадывался что это что-то большее, чем разделитель глав, пока не прочёл эту ветку.

[AreD]

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

[Ohar]

Госпожа Динкулеску написала поток нытья вместо статьи.
Из перечисленных проблем реальная только одна — ограничение для selectionStart.

если тип элемента = 'file', то текст который будет отображаться на месте этого элемента, когда не выбран ни один из файлов: «No file chosen», «no file selected», «No file selected», и просто пустой текстовый блок в Chrome, Safari, Firefox и IE соответственно.

он выглядит одинаково везде

Почему это вообще кого-то беспокоит? Это нативные элементы браузера и пользователь этого конкретного браузера узнаёт их и понимает что от него в этом месте хотят.

[AreD]

да, статья написана в достаточно ироничном ключе, но скажите, вас устраивает, например, отсутсвие возможности стилизировать выпадающий список тега select с помощью css?

[Ohar]

И для каких именно браузеров вы собрались его стилизовать?
Вы, например, видели, как он отображается в мобильных браузерах? Скорее всего, видели.
Вы уверены что сможете полностью корректно стилизовать его для этого случая? Для других случаев?
Вы уверены что он будет выглядеть как минимум не хуже нативного, работать не хуже нативного и что после вашей кастомизации пользователь поймёт что это именно селект, а не что-либо ещё?

[Ohar]

Нет, я не шучу.
Просто я ставлю интересы пользователя выше интересов дизайнера.

[AreD]

На современном мобильном селект выглядит как часть интерфеса операционной системы, все ок, я не вижу проблемы.
Проблема с моей стороны с десктопными браузерами. Да, я знаю доводы за нативное отображение системных элементов и отчасти поддерживаю их, но вот нифигаж оно не работает, посмотрите на «нативный» селект фаерфокса под OS X. И как написал Drag13 ниже, мы за то, что бы мы могли выбирать, сделать веб приложение как нативное под ОС, или сделать дизайнерский сайт с теми формами которые мне надо. Да посмотрите же, никого это ограничение не останавливает и появляются монстры написанные на jQuery которые эмулируют селект, но с настраиваемым внешним видом, но вот не задача, то он криво под старыми бразуерами отобразиться, то он с помощью клавиатуры не выделяется, и прочие баги. Печальное это, 21 год уже как печально. Что касаемо вашего мнения, я его понимаю и принимаю, но спорить с вами не буду.

[Ohar]

Совершенно с вами согласен.

[jorgen]

Проблемы роста, проблемы архитектуры, неудачных решений, непредвиденных технологий, обратной совместимости, и много чего ещё. В программировании эти все грабли известны, изучены и классифицированы.
Но главное — если с такими проблемами не может справиться, например, десктопное приложение — его обгоняет конкурент, который молод, который другой, которому удаётся принять и похендлить новые вызовы. А в интернете, к сожалению, кто-то решил что конкуренция платформ не нужна, а всем хватит одного стандарта.

[bolk]

У четвёртого «Нетскейка» была тогда масса странных типов тега INPUT. Например, TYPE=OBJECT, TYPE=READONLY или TYPE=JOT.

[fetis26]

Хаха, детка. Это все ерунда. Вот попробуй застайлить дропдаун, вот где БОЛЬ. Причем дизайнеры этой проблемы не замечают и год из года рисуют всякое безумие в виде дропдаунов

[AreD]

Ты про <select>?

[fetis26]

да, конечно.

[Eefrit]

Что касается <better-input>… что тут скажешь.

Старо как мир

Собрались как-то инженеры и говорят — что-то у нас слишком много стандартов для проводов, передающих данные от устройства к устройству. Тут тебе и USB, и COM, и LPT, и FireWire, и ThunderBolt, и так далее. Аж 14 штук насчитали. А давайте, говорят, придумаем единый стандарт, который будет удовлетворять всем условиям, будет максимально универсальным, самым гибким и широкораспространённым? «Хорошая идея,» — поддержали все. И теперь у нас 15 стандартов.

[asave]

«у разработчиков браузеров был 21 год, чтобы починить отображение input'ов»
У разработчиков стандартов была куча времени чтобы понять что никогда не смогут заставить производителей броузеров выработать какой-то стандарт по отображению/поведению контролов. Но все равно наступили на эти грабли второй раз, когда придумали:
color
date
datetime
datetime-local
email
month
number
range
search
tel
time
url
week
…

[thinking]

Еще в мобильном Хроме из-за каких-то там системных сложностей событие keypress не возвращает код клавиши/символ. И разработчики говорят «а что-то мы не можем это реализовать» )))