Дивовижний світ веброзробки

Енергоефективність. Слово, що перейшло з категорії "щось на політичному" до невідʼємної частини нашої буденності.Веброзробку це також не оминуло. Ідея робити заощадливі застосунки для зручності користувача далеко не нова. Та й лежить на поверхні — ніхто не буде користуватися вашим продуктом, якщо він буквально "висушує" батарею. І одним із рішень стала пропозиція Battery Status API.Цей дуже простий API був покликаний надати розробникам можливість оптимізувати роботу застосунку на льоту залежно від рівня заряду пристрою. Рідше синхронізуватися, відкладати важкі обчислення, вимикати анімації і так далі — на перший погляд, це чудовий спосіб дійсно потурбуватися про користувача. Хіба ні?І в певний момент здавалося, що технологія ось-ось злетить — Chrome та Firefox додали повну підтримку, навіть Safari мала реалізацію (але тільки в коді, доступу не було).Але що завадило проривному успіху? Відповідь проста — людство влаштовано так, що винайшовши щось нове, перші два питання, які воно собі ставить, звучать як "Чи можна цим когось вбити?" і "Як на цьому підняти грошенят?". І якщо з першим питанням у Browser API якось усе більш-менш зрозуміло, то от друге відкриває нескінченний простір для фантазії.Тут така річ, що будь-який додатковий сенсор стає частиною цифрового відбитка — і Battery Status API якраз із цієї категорії: він додає ще один стабільний сигнал про ваш пристрій.Є одна цікава, але доволі перекручена в медіа історія про Uber, і хоч вона не повʼязана напряму з бравзерним Battery Status API, однак дає чітке розуміння, як корисні і невинні речі можна використовувати далеко не на користь.2016 року Кіт Чен, на той час Head of Economic Research в Uber, висловив припущення, що клієнти з нижчим рівнем заряду набагато схильніші прийняти підвищену вартість поїздки. Це суто психологічне спостереження відкриває цікавий пласт питань — які ще непрямі поведінкові маркери можна зчитувати просто через ваш бравзер?Ця фраза так сподобалась медіа, що "Uber піднімає ціну, якщо бачить низьку батарею" стало стійким міфом. Але чи міфом? У 2023 бельгійське видання Dernière Heure зробила один тест: два телефони, однаковий маршрут у той самий час, 12% батареї проти 84% — і ціна на низькій батареї вийшла вища (приблизно +6%). Uber це заперечив і заявив, що батарея не впливає на ціну, а ціноутворення залежить від попиту/пропозиції.Реакція вендорів виявилася нетипово різкою для світу вебстандартів. WebKit заявили, що це суттєвий privacy-ризик і прибрали реалізацію Battery Status API з рушія. Mozilla також прибрала доступ до API у Firefox 52. А Chromium, хоч і не видалили його повністю, суттєво обмежили доступ до API.По суті, це вбило технологію. Не складність чи відсутність стандарту, а невідповідність сучасним викликам цифрової безпеки. Якщо фіча дає навіть невеликий додатковий сигнал для ідентифікації — її будуть різати, обмежувати або й геть вимикати.Але ж як щодо енергоефективності наших застосунків? — запитаєте ви. Ну та шо ж. Пишіть нормально — відповім я. Заощадливе використання вашим продуктом батареї варто закладати в саму архітектуру вашого коду, в поведінку застосунку. Менше затратних фонових процесів, менше надмірних анімацій, непотрібних розрахунків і перерендерів. Енергоефективність має бути додатковим виміром швидкодії та оптимізації.Не лише швидше — а й дешевше. Не варто забувати, що бюджети сучасного застосунку у вебі складаються не лише з CPU та RAM, а й з батареї. Тим паче, що для нас це актуально як ніколи.Тож пишіть енергоефективний код, забезпечуйте власну енергонезалежність та не забудьте подякувати енергетикам усіх областей, що цілодобово працюють над відновленням нашої енергосистеми за екстремальних умов та часто під обстрілами. Що почитати:MDN: Battery Status APIЩо почитати душнілам:Battery Status Not Included: Assessing Privacy in Web Standards (pdf)@babichdev

Про документацію. Багатьох розробників лякає саме це слово. В їх уяві постає щось громіздке, неповоротке й бюрократичне, що обовʼязково зʼїдає ваш час і не приносить жодної користі.З мого досвіду безліч непорозумінь, затримок, а то й зривів дедлайнів, можна було уникнути, якби певні рішення були… записані. Так-так. Я думаю, і вам знайома ситуація, коли переважна частина вимог і технічних дискусій існують лише в памʼяті учасників та десь у нетрях вашого слаку.Для цього не потрібно витрачати тижні на узгодження формулювань чи дотримання ритуалів. Обговорили — записали. Прийняли рішення — записали. І не на папірчику, а в доступному просторі.Для нас, технічних фахівців, записані рішення так само важливі, як і їхні результати. І тут взагалі не треба нічого вигадувати. Навіть коротка нотатка — це вже документ, якщо у вас є можливість до неї повернутись і перечитати.Особливо це важливо для випадків, коли ви впроваджуєте не дуже очевидне чи нетипове рішення у вашому коді. І ні, я не говорю про коментарі, це окрема історія. Дуже часто іншому фахівцю важливо знати не що саме написано, а які рішення стоять за цим кодом. Бо він ні в кого не еталонний.Я ж ставлю питання до причин та висновків, які призвели до появи цього коду. Це допоможе зрозуміти, а головне — прийняти, чого воно так написано.А ще я завжди раджу формалізувати свої звичні підходи. Пишете такі тести, а не такі? Напишіть для себе документ, в якому ви пояснюєте переваги й недоліки вашого підходу. Ви і самі зможете до нього звертатися час від часу, і, в разі чого, поділитеся із колегою, що матиме питання до цих підходів.Або починаєте роботу над задачею? Приділіть трохи часу, запишіть ваші роздуми. Знайшли якусь дич? Запишіть. Прийшла геніальна думка? Запишіть. І так далі. Як мінімум, коли ви за пів року подивитесь на свій код з доволі слушним запитанням "Якого хуя?!", відповідь на нього лежатиме просто перед вашими очима.І так, користуватися LLM в цьому не лише можна, а й треба. Що він точно робить краще за мене, так це систематизує інформацію. Я можу накидати в нього все, що маю під рукою, а потім з цієї безформеної купи думок робити різноманітні документи на всякий смак. Очевидно, не варто кидати в модель чутливі чи корпоративні дані. Анонімізуйте хоча б, чи шо.Насамперед я роблю документацію для себе. В процесі я набагато краще розбираюся в задачі, набагато швидше знаходжу невідповідності і пропущені питання. Це все я б побачив і так, але є суттєва відмінність — зазвичай це все вилазить уже в процесі розробки. А від цього — непорозуміння, затримки, зірвані дедлайни і попсуті нерви.Якщо навчитися вирішувати це все ще на березі, то сама розробка буде відбуватися набагато плавніше і приємніше. Повірте старому морському вовку[email protected]. Ви ж не забули, що у нас досі триває збір для Житомирського військового інституту? Правда? ПРАВДА?Тим паче, де ви ще зможете виграти артбук по STALKER 2 за 100 гривень донату? Отож.

Довге тире — вигадка ШІ?Правильна пунктуація існує не один рік. І в компʼютерній типографіці теж. Ба більше, існує великий набір символів, які є прямими відповідниками типографіки друкарської. І різновиди тире — лише верхівка айсбергу.HTML так само підтримує різноманітний набір символів, до того ж у різний спосіб. От ви знали, що існує більше одного пробіла? Чи що існує спеціальний символ мінуса? І ділення? І множення? Я свого часу теж не знав, але колись мені довелось трошки попрацювати в друкарстві, і з тих пір я ніколи не ставлю дефіс замість тире.В HTML існує ціла група спеціальних послідовностей для відображення таких символів. Називаються вони HTML Character Entities.Поділяються вони на іменовані, наприклад &lt; (<), та числові, виражені через десяткові коди — &#198; (Æ). Деякі символи мають обидва представлення, інші ж — лише DEC-запис. Звичайно, ви можете використовувати й безпосередньо самі символи прямо в розмітці, але є кілька «але».Деякі з них, як от <, є керуючими символами самого HTML, і можуть зламати розмітку. Або ж, якщо раптом ваш документ декодується не в UTF-8, символ може просто не відобразитись. А використання HTML-сутності гарантує, що бравзер покаже його незалежно від таблиці кодування (якщо документ взагалі парситься).HTML має багато спільного з друкарською типографікою. Наприклад, існує нерозривний пробіл  , який не дозволяє розрив рядка в цьому місці. Я досить часто використовую його у верстці, особливо там, де є довге тире. За правилами типографіки, довге тире не має знаходитися на початку рядка, якщо це не початок прямої мови або маркер списку. І послідовність слово —, або ще краще слово &mdash;, примушує бравзер правильно рендерити текст, щоб тире не переносилося на новий рядок.А ще є вузький пробіл, половинний, широкий, фіксований та «волосяний». Вони мають різну ширину і використовуються в різних ситуаціях для покращення візуального сприйняття тексту.Звідки вони усі пішли? Та з друкарства. Нагадаю, що довгий час друкарська матриця збиралася вручну з відливків з карбованими літерами, і довжина рядка регулювалася так само вручну. І різні пробіли — це по факту різної ширини залізячки, які вставлялися поміж літер.Лапок також існує велика кількість. І, що цікаво, деякі символи, які візуально нагадують лапки, ними не є. Наприклад, ″ — це не лапки, а подвійний штрих (&Prime;), який використовується для позначення координат на кшталт 50° 45′ 30″.Так само для трикрапки на письмі існує… трикрапка — окремий символ ….Ну і математика, куди ж без неї. Так, мінус — це не дефіс, а цілком собі мінус «−» (&#8722;), як от тут: «−15%». Для позначення нерівності варто використовувати символ ≠ (&ne;), а множення позначати символом × (&times;), а не астериском *.Якщо вже повернутися до тире, то зазвичай на письмі використовується два: довге «—» (&mdash;) та коротке «–» (&ndash;), яке використовується для позначення діапазонів. Тож записати, до прикладу, «девʼять чи десять» правильно можна ось так: «9–10», а не «9-10».Найпростіше ці символи вводити на Mac, адже там у стандартної клавіатури є спеціальний набір комбінацій саме для друкарських символів. На Windows з цим трохи сумніше — або користуватися Alt-послідовностями з «бухгалтерської» цифрової клавіатури, або ставити сторонні рішення.На мобільних з цим теж немає проблем — позатискайте різні кнопки на клавіатурі. Це дуже цікава вправа, яка покаже вам, скільки цікавих символів є у вашому розпорядженні.Ну а при верстці в HTML найнадійніший спосіб зробити ваші тексти гарними та типографськи правильними — це використовувати HTML Entities.Гарно оформлений текст і читається і сприймається набагато краще, навіть якщо це коротке повідомлення в месенджері.Що почитати:Technical Web Typography: Guidelines and TechniquesЩо почитати душнілам:WHATWG — Named character references***@babichdev

20 років тому я "навчався" на третьому курсі ЖДТУ, балансуючи між лютими пʼянками та маже авантюристськими спробами здавати сесії, не знаючи навіть, як виглядає викладач.І от, поки я віддавався доступним мені гріхам, десь за океаном Джон Резіґ під час BarCamp NYC представив світу свій маленький пет-проєкт під назвою jQuery. А вже в серпні світ побачила перша релізна версія. І лише декілька років потому ніхто в здоровому ґлузді не починав робити новий проєкт, не підключивши до нього в першу чергу останню версію цієї бібліотеки. Чим же пояснюється така популярність?Відповідь проста: бо jQuery був простий. Він дозволяв розробникам робити, а не витрачати незліченні години на сумісність між бравзерами. Так, друзі, колись поняття "кросбравзерність" мала геть інший сенс. Це зараз максимум, що вам загрожує — відсутність тієї чи іншої фічі, і то скоро вже додадуть. В часи давніх богів і царів це означало, що фічі працюють по-різному. Буквально. І ще можуть називатися по-різному.А jQuery дбайливо заховав він розробника усе це длубання, і залишив йому простий як двері декларативний інструмент, виражений одним символом $.До речі, цей синтаксис породив багато жартів, зокрема про те, що загадуючи мати багато $$$, я мав на увазі справжні долари, а не кількість викликів jQuery в своєму коді.Можна казати, що саме jQuery сформував культуру плагінів задовго до npm. Для усього був плагін — усі знають скриншот зі StackOverflow з питанням "як скласти два числа в JS" та відповідь на нього.Ці плагіни покривали все: буквально від a + b до складних компонентів на кшталт каруселі зображень. Магією було те, що якою не була складна задача, вона закривалася одним рядочком коду (умовно).І, звичайно, не можна не говорити про той вплив, який з часом здійснив jQuery на веб загалом. Саме завдяки йому ми маємо querySelectorAll, classList, fetch, addEventListener тощо. Зміни в стандарті підтягуються за потребами. Часто люди плутають причину й наслідок, і кажуть (в тому числі і я колись) щось типу "так а нафіг той jQuery треба, тето й тето є в стандарті!". Ну так от — а як воно в стандарті зʼявилось? Отож.jQuery перетворив нудний статичний інтернет на місце сміливих експериментів та цікавого досвіду. Анімації, динамічний контент, активне використання AJAX — усе це дозволяло будувати вже не сторінки, а сайти. У повітрі відчувався той самий вітер змін, і лише питанням часом було пришестя Single Page Applications.Так. Без jQuery не було б AngularJS, ReactJS та іншого зоопарку екзотичних способів забезпечити собі гідну зарплату та вбиті нерви."Write less, do more" — цей девіз відповідав дійсності на 100%. Крива входу нагадувала навіть не криву, а пряму лінію, яка ледь відлипала від осі X. Ваш покірний слуга так само прийшов до веброзробки ще 2010 року, взагалі нічого не розуміючи, але маючи змогу підключити плагін та налаштувати його так-сяк, покладаючись на матюки та інтуїцію.Очевидно, існували й проблеми. Першою і найбільшою був менеджмент залежностей. Маю підозру, що й npm має завдячувати своїм існуванням jQuery. Один плагін працює з однією версією бібліотеки, інший з іншою, вони несумісні, їх треба ізолювати і коному дати свою версію, а один плагі ламає інший, бо перевизначає метод з таким же імʼям.І це все вручну. Буквально. Жонглювання підключенням версій в HTML, маніпуляції з Immediately Invoked Function Expression для хоч якої симуляції модульности — дякую, спогад розблоковано.Може здатися, що він вмер, але це далеко не так. На ньому стоїть сучасний інтернет. Майже 90% сайтів у світі, на яких використовується JavaScript, мають в своєму складі jQuery. Згадайте це наступного разу, коли будете тішити себе популярністю React.Чому я раптом згадав про нього? Усе просто — буквально днями в реліз вийшла версія 4.0.0. Звичайно, всередині це не той jQuery, що 20 років тому, але він і далі дозволяє робити те, що й раніше."Write less, do more".@babichdev

Доброго ранку, товариство!Скінчилася моя тривала відпустка, тож час братися до справ. Як мінімум, треба згадати, чим я займаюсь на роботі.За час відпочинку зʼявилася купа ідей і для дописів, і для відео, і особистий сайт став на крок ближчим. Але найголовніше, чого мені вдалось досягнути за відпустку — це нічого. І я щиро цьому радий.Знаєте, оцей підхід, коли обіцяєш собі — от буде відпустка, і я як зроблю всі справи, як реалізую усі плани, ух! Можливо, це досвід, можливо вік, може й усе докупи, але я відверто насолоджувався неробством. І, хоч я й мав купу задумок і планів, я анітрохи не жалкую, що більшість із них так і лишилися планами.Натомість я проводив час з рідними: додивилися Stragner Things і навіть переглянули усі гідні уваги фільми про Чужого (так, час прийшов знайомити дітей з невмирущою класикою), завершив проходження ігор Gears of War із сином, шуфляв сніг надворі, хворів, читав. І от коли від цього усього лишалося трошки вільного часу, то займався своїми ідеями.Наприклад, зробив форму запису на індивідуальну співбесіду для свого сайту. Який ще не в релізі, очевидно. Але побавився з Astro, поплювався на Svelte і замінив його на htmx, зробив інтеграцію з Notion та зламав вщент мозок об Google service accounts і їхню авторизацію.Я не можу сказати, що після відпустки я повний сил підкорювати цей рік. Я звичайна людина, і сил у мене зараз вистачає хіба на підкорення сьогоднішнього дня, і то не впевнений, що повністю. Але слона треба їсти по шматочках.Проте я виніс дуже важливе усвідомлення — плани це чудово, але треба знаходити задоволення в тому, що вдається зробити, а не картати себе за те, що не вдається. Варто радіти власним здобуткам, навіть якщо вони видаються незначними. Бо, на відміну від великих планів, маленькі здобутки усе ж є втіленими.Тож зараз збиратимусь купки, готуватиму для вас нові цікаві дописи, запрошуватиму на класні події, і продовжу їсти свого слона. Ну а вас запрошую приєднатися до мене у цій повільній та поступовій подорожі.Гарного усім початку робочого тижня!@babichdev

DOU 2026Відсьогодні розпочинається голосування за переможців Третьої Премії DOU, і завдяки виключно вам, товариство, моє імʼя — серед номінантів в категорії "Вони надихають".Цього разу я не номінувався сам, а довірився вам. І тому бачити себе в списку претендентів вдвічі, втричі, вдесятеро приємніше, адже це значить, що я дійсно надихаю бодай когось із вас.Тепер лишилось вам лише віддати свій голос за вашого кандидата. Дуже сподіваюсь, що й цього року цим кандидатом стану саме я ;)Механіка дуже проста:— Заходите на сторінку https://dou.ua/awards-2026/#voting— Знаходите номінацію "Вони надихають";— Довго (або не дуже) скролите, поки не знайдете картку, на якій скромно пише "Сергій Бабіч";— Тицяєте в картку;— Натискаєте кнопку "+ Обрати";— Голосуєте за інших кандидатів та номінації;— Отримуєте від мене безмежну подяку та уявний цьом у лобіка.Нагадаю, що переможців у номінації "Вони надихають" визначає виключно спільнота, тож кожен ваш голос — надзвичайно важливий.Повідомлення, що я таки є в списку кандидатів, заскочило мене сьогодні зненацька (я, між іншим, досі у відпустці). Але це для мене дуже приємне "зненацька". Воно значить для мене дуже багато, і нагадує мені, що те, що я роблю, дійсно важливе для вас.І це мотивує мене ще більше.Тож гарного вам початку тижня, товариство, не забудьте поставити галочку в бюлетені взяти участь в голосуванні, і до зустрічі наступного понеділка!ПРОГОЛОСУВАТИ

#партнерський_дописРинок ІТ зараз турбує багатьох — особливо питання, як у ньому не потонути й усе-таки дійти до офера.Саме про це Вікторія Захарова проведе завтра, 23 грудня, практичний воркшоп на 2–3 години. Буде про конкретні речі:— Як поводитися та як готуватися в процесі пошуку: аналіз ринку, резюме, супровідні листи, профіль в LinkedIn, нетворкінг;— Що робити зі своїми емоціями: звідки взяти дисципліну, як не зневіритися в пошуку а також які софт-скіли взагалі очікуються роботодавцями;— Практичні поради, зведені у воркбук: як ним користуватися, аби були дійсні зміни і як їх контролювати.Якщо коротко — це спроба зібрати цілісну картину пошуку роботи: від старту до офера з урахуванням реалій ринку 2026 року.Корисно буде і тим, хто тільки починає пошук, і тим, хто вже давно в процесі.Зустріч безоплатна, реєстрація тут:https://bit.ly/workshop_strategy2026🗓 Коли: 23 грудня о 19:00📌 Формат: Google Meet + підтримка в Telegram⌛️ Тривалість: 2–3 годиниP.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.

#анонс Товариство, пишемо новий покдаст!Цієї суботи, 20 грудня, о 19:00 відбудеться запис нового випуску подкасту "Подкаст у нас вдома", на якому разом з Уляною Білінською-Шута поговоримо про "Американську мрія: як працює найм в США".Будемо говорити про американський ринок не тому, що туди «обовʼязково треба йти», а тому що саме там найчіткіше видно, як працює зрілий tech-найм. У США довші процеси, вища конкуренція й більша ціна помилки, тому рішення про найм рідко ухвалюють навмання. Цей ринок швидко знімає ілюзії й показує, що компаніям важливо не лише що ти знаєш, а як ти думаєш, говориш і береш відповідальність.Для багатьох українських спеціалістів складність США — не в рівні знань, а в очікуваннях і підході до інтервʼю. Тому ця розмова не про релокацію чи мрію переїзду, а про розуміння системи: як читають кандидатів, чому відмовляють сильним інженерам і які сигнали насправді мають значення. Навіть якщо ви ніколи не плануєте працювати в США, цей досвід допомагає тверезіше дивитись на будь-який зрілий ринок.Моя гостя —Senior Manual Quality Assurance Engineer, ex- Uber,ex- Linkedin. 7 років назад з юристки перевчилась на тестувальницю у Кремнієвій Долині, і з тих пір працює в професії. Також, Уляна — QA Mentor і допомагає як новачкам, так і досвідченим QA рухатися карʼєрною драбиною.Запис відбудеться онлайн, посилання на студію прикріплено до події в календарі. Додавайте собі, буду радий бачити усіх вас!ДОДАТИ ПОДІЮ СОБІ В КАЛЕНДАР@babichdev

#css_in_actionПоставити box-sizing: border-box і забути. Ну якось так сьогодні виглядає перший рядок CSS на проєкті. Але чи всі знають, що це таке та на що впливає? Давайте глянемо.box-sizing визначає, в який спосіб буде розраховано значення розмірів у box model – тобто як бравзер рахує фактичний розмір елемента в макеті. Давайте пригадаємо, з чого складаються фактичні виміри:— content: розміри вмісту всередині елемента;— padding: внутрішні відступи між вмістом та бордером;— border: товщина рамки навколо елемента;Ці три значення й визначають фінальний розмір. А от як саме — визначає та сама box model.За замовчуванням усі блочні елементи використовують content-box, і це означає, що властивість width застосовується до content box, тобто до внутрішньої зони.Таким чином фінальний розмір визначається формулою:total = content + padding + border; де content це значення width або height, залежно від виміру. Саме тому, якщо задати елементу width: 100px, padding: 4px та border-width: 1px ми отримаємо фактичну ширину в 110 пікселів.А що робить border-box? Він змінює підхід до розрахунку. І тепер формула набуває іншого вигляду:content = total - padding - border; Тепер width описує розмір усього елемента, а внутрішній content автоматично підлаштовується.Чому ми надаємо перевагу саме border-box? Причина проста: розміри стають передбачуваними. Якщо ми кажемо, що ширина має бути 100 пікселів, вона й буде 100 пікселів, незалежно від падінгів та бордерів.Але тоді випливає інший неприємний наслідок — місце для вмісту тоді стає помітно тіснішим, що може призводити до візуально неприємного затискання контенту. Очевидно, що це не баг, а цілком очікувана поведінка, тож вважайте.До речі, колись у Firefox існував ще експериментальний padding-box, в якому значення width задавало суму content та padding, лишаючи border поза формулою. Але це не прижилося. Може й на краще.І ще важливо, що margin ніколи не входив, не входить і, сподіваюсь, не входитиме до box-model, адже це не вимір елемента, а його відступ від навколишніх елементів в макеті.border-box у стандарті зʼявився не відразу, перші робочі драфти було опубліковано на початку 00-х. А от широкої підтримки це значення набуло десь так в 2012 році.Цікавий факт: саме така поведінка box model була в IE5-IE6, але не через прогресивне мислення розробників бравзера, а через банальний баг. І багато хто вважав, що така поведінка є інтуїтивнішою, ніж стандартна.Не буду робити висновків, але хто зна, може ми б і не мали border-box взагалі, або мали б його набагато пізніше, якби не цей баг в IE. І вкотре бравзер, який чомусь прийнято гейтити, змінив веброзробку на краще.Що почитатиMDN: box-sizing***@babichdev

#html_in_actionАвтодоповнення списків використовується в користувацьких інтерфейсах давно. Проте в більшості випадків для цього застосовуються кастомні, доволі складні компоненти. Але в HTML5 існує нативний елемент, який забезпечує такий функціонал без JavaScript, виключно засобами HTML.Мова йде про datalist. Це надзвичайно простий елемент, який водночас забезпечує саме те, що від нього очікується — виведення списку підказок при введенні тексту у поле введення.Виглядає це так:<label for="city">Місто</label><input list="cities" name="city" id="city"/><datalist id="cities"> <option value="Київ" /> <option value="Львів" /> <option value="Харків" /> <option value="Одеса" /></datalist> На відміну від select, datalist не обмежує вибір, а лише підказує наявні співпадіння. Користувач же може ввести довільне значення у поле вводу. На валідацію datalist теж не впливає.При виборі елемента списку в інпут буде підставлено значення з атрибуту value і викликано стандартні події поля вводу, тому немає технічної можливості дізнатися, як саме значення було введено.Одним з очевидних недоліків використання datalist є його закрита інтеграція в бравзер: ми не можемо впливати ані на його поведінку, ані на зовнішній вигляд списку підказок, коли він показується. Хоча, дивлячись на те, як цього року реалізували стилізацію нативних селектів, я маю обережний оптимізм і щодо datalist.Перевага ж очевидна — це швидке, нативне рішення, яке не потребує підключення стороннього коду для відображення підказок, і якщо ваша форма не є складною, і для вас головне, щоб вона була максимально простою та ефективною в імплементації — datalist є беззаперечним вибором.Щодо відмінності поведінки в бравзерах, тут, звичайно, доведеться прийняти стан справ як є.Наприклад, Chromium та Webkit бравзери зараз покажуть і значення з атрибуту value, і текст між тегами option у випадайці. А от Firefox покаже лише підпис. Взагалі, саме у Firefox datalist має доволі обмежену імплементацію. До прикладу, логіка пошуку по списку суттєво відрізняється, якщо у option є і атрибут value і текст.Тому треба враховувати, який саме досвід ви хочете надати користувачу: якщо це усі можливі свистілки і перділки, то доведеться тягнути якесь стороннє рішення на купі дівів. Якщо ж мета просто показати список підказок, то datalist задовольняє цю потребу майже на 100%.Ну або вішайте табличку "Найкраще працює в Chrome/Edge", ми це вже проходили.Що почитати:MDN: <datalist>Що почитати душнілам:HTML Living Standard — <datalist>@babichdevP.S. Якщо не поставите вогник чи серденько — я дуже засмучусь. Ви ж не хочете, аби я засмутивсь? Правда? ПРАВДА?