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

#css_in_actionКористувацькі CSS-функції уже майже за рогом, тож прийшов час поглянути на них дещо ближче.Сучасний CSS дозволяє вирішувати усе складніші задачі, зокрема через певну реактивність, закладену у CSS змінних, себто CSS custom properties, та широкий спектр нативних CSS-функцій на кшталт clamp(), color-mix() та інших. І тепер ми можемо створювати доволі хитромудрі вирази на кшталт:clamp(var(--min), 2vw + 1rem, var(--max)); Проте досі перевикористання таких виразів лишається болючою скалкою в дупі. Ми вимушені писати таку логіку наново в усіх місцях, де вона нам потрібна, що, погодьтеся, дещо незручно. Однак надія є, і вже досить давно в роботі знаходиться специфікація CSS Functions and Mixins Module Level 1, хоча й у статусі Working Draft.Зокрема, цей документ вводить поняття CSS custom functions, які покликані саме для того, аби дати можливість створювати власні функції та перевикористовувати складні математичні формули. А вони в CSS дійсно складні, хоча б через свій синтаксис, але шо тут вже вдієш.Виглядають вони приблизно ось так:@function --fluid-size(--min, --max) { result: clamp(var(--min), 2vw + 1rem, var(--max));}…font-size: --fluid-size(1rem, 3rem); Синтаксис простий:- Оголошуємо через at-rule @function;- Назва має префікс --, як і решта синтаксису для користувацьких властивостей в CSS;- Функція може приймати параметри;- Параметри можуть мати значення за замовчуванням: --fn(--x: 1px) {…};- Параметри можна типізувати: --fn(--clr <color>) {…}- Параметр може бути списком: --fn(--list <length>#), width: --fn({1px, 7px, 2px}) (саме так, з фігурними дужками);- Ключове слово result є, по суті, відповідником нашого улюбленого return;Можна навіть писати досить складну (наскільки це можливо) логіку. Наприклад, створювати проміжні змінні з власними розрахунками чи просто як константи:@function --fluid-size(--min: 1rem, --max: 3rem) { --preferred: calc(2vw + 1rem); --safe-min: max(var(--min), 0.875rem); result: clamp(var(--safe-min), var(--preferred), var(--max));} Ба більше, користувацькі функції підтримують медіа-запити:@function --narrow-wide(--narrow, --wide) { result: var(--wide); @media (width < 700px) { result: var(--narrow); }} та умовну функцію if(), яку варто розібрати окремо.Що по підтримці? Ну, поки трошки сумно. Реалізацію поточного драфту для custom functions викотив Chromium, що означає, що ми можемо спробувати цей синтаксис в Chrome, Edge та решті хроміум-зоопарку.Firefox, як і завжди, певно не спішитиме з імплементацією допоки стандарт не перейде до стабільнішого рівня, а щодо Safari впевненим можна бути лише в одному — що ми не можемо бути в ньому впевненими.Я, насправді, дуже чекаю коли CSS custom functions увійдуть до Baseline, бо це, насправді, дуже зручна можливість. До речі, рука в руку з ними йде й чернетка CSS mixins, на які я теж чекаю. Про міксіни поговоримо згодом, коли до них дійдуть руки хоча б у Chromium, але маю сподівання, що чекати лишилося недовго.Чого я з таким нетерпінням чекаю на момент, коли ці специфікації увійдуть до Baseline? Бо це означатиме початок забуття SCSS та всіляких інших LESS, до яких я відчуваю безпідставну та пекучу неприязнь. А якщо цей допис набере бодай 100 реакцій, то я розповім чому. А як не набере, то не розповім.@babichdev***Що почитати:MDN: @function CSS at-ruleMDN: Using CSS custom functions Що почитати душнілам:W3C: CSS Functions and Mixins ModuleP.S. Товариство, дуже сподіваюсь, що у вас все добре, наскільки це може бути.Росія — кончена країна кончених людей.Тримаймося.

Я розпочав карʼєру у веброзробці 2011 року. Здається, це було не так давно, але минуло вже 15 років.Парадокс у тому, що світ тоді не виглядав аж таким далеким від сьогоднішнього: уже був інтернет, смартфони, макбуки й інші звичні нам технологічні радощі. Тому ці півтора десятиліття й не відчуваються як півтора десятиліття — радше як кілька дуже насичених років.Можливо, саме через це розробка досі сприймається як щось дуже нове. Ніби ми живемо ледь не на світанку галузі, а більшість продуктів, якими користуємося, зʼявилися буквально нещодавно.Але іноді дуже цікаво задуматись — а коли зʼявилися ті продукти, програми, якими ми користуємось ледь не щодня, ну або принаймні дуже активно користувалися донедавна.Наприклад, моєю першою роботою, повʼязаною з компʼютерами, був веб дизайн. Очевидно, що тоді (а це плюс-мінус 2006-2011 роки) все малювалося у фотошопі, який я запускав щодня, аби намалювати черговий сайт-візитку. І хіба міг 20-річний я навіть здогадуватися, що мій повсякденний інструмент зʼявився тоді, коли я ходив до радянського дитсадочку?Так-так, саме радянського, бо перша версія Adobe Photoshop зʼявилася у лютому 1990 року. Ба більше, другий їхній продукт, яким я користувався паралельно з фотошопом, взагалі старший за мене на кілька місяців. До вашої уваги — Adobe Illustrator, 19 березня 1987 року.Рухаємося далі. Я не уявляю собі людини, яка за віком може бути моєю колегою по роботі, що в житті не чула про Microsoft Word та Excel. Ці два продукти є де-факто стандартом в багатьох галузях, успішно витримавши конкуренцію як від хмарних продуктів, так і від опенсорсних аналогів. Їх досі викладають в школах. А зʼявилися вони…Excel виходить 1985 року, тоді ж, коли в совєтському союзі розпочинається "пєрєстройка". Яка в свою чергу стала одним з каталізаторів розвалу цієї недоімперії. От би й в 2026 році Microsoft випустили щось, що через сову на глобусі призведе до розпаду Росії…А Microsoft Word побачив світ 1983 року, практично одночасно з підключенням четвертого енергоблоку ЧАЕС до мережі. Гм, у мене починає зʼявлятися думка, що усі ці події якось повʼязані між собою… Але сова чогось не погоджується.Пірнаємо глибше? Тоді зануримося у 70-і роки. Несподівано, так?1979 року, коли мій тато працює на будові і отримує зарплату у віконечку, компанія RSI випускає Oracle V2, що стала першою комерційною SQL-базою даних. Хоча й у нас тоді відбувалися примітні події — до прикладу, вийшла кінострічка "Вавілон ХХ" Івана Миколайчука, яка нині посідає 10 місце у топ-100 українських фільмів у рейтингу "Довженко-Центру".І тут ви такі "ШООООО?! Який такий SQL?!". Ну так. SQL. Першу версію якого, під назвою SEQUEL (а ви думали це прикол такий?), було описано IBM Research 1974 року (повноцінно стандартом SQL став, щоправда, аж у 1986). Що ще цікавого відбулося цього року? Славнозвісний Watergate і відставка Ніксона. Та, були часи, політики йшли у відставку через скандали, уявіть собі таке…Копнути ще разочок? Добре. Але разочок. І цього разу нам доведеться відвідати… Місяць.І тут ви такі "ШООООО?! Який такий Місяць?! Забув таблетки випить?". Таблетки то я забув випить, але поки, дякувати богу, ще не ті. А на Місяць ми з вами летимо разом з екіпажем Apollo 11, члени якого стали першими в історії представниками людства, що ступили на інше небесне тіло. І поки 20 липня 1969 усі, затамувавши подих, слідкували за висадкою астронавтів, у нетрях Bell Labs Кен Томпсон писав перші (а може й не перші) рядки коду операційної системи, яка згодом стала відомою як UNIX.І це я оглянув лише декілька прикладів програмних продуктів, якими ми усі користуємося в тому чи іншому вигляді й досі. Якщо придивитися уважніше, то виявиться, що не так уже й довго лишилося до першого сторіччя першого рядочку коду, написаного високорівневою мовою.Програмування існувало задовго до нас, і, хочеться вірити, існуватиме довго після нас.

Фреймворк-абізянство — це такий особливий спосіб мислення, коли навіть hover робиться через setState. І так, я цей приклад не вигадав, я бачив такий код в проді.А от як назвати протилежне мислення, я ще не знаю. Суть його полягає в тому, що замість робити ВСЕ на умовному реакті, спочатку треба трошки подумати — "а може HTML/CSS/JS вже самі таке вміють?".Дивіться, я тут останнім часом ношусь і з dialog, popover, @layout, @scope, всякими приколами з Browser API, що аж примудрився зібрати цілком собі робочий застосунок чисто на нативці. І поки я робив ту альфа-версію, усе частіше ловив себе на думці, що величезну кількість речей ми досі робимо максимально складно. Просто за звичкою.Я якось сів і почав прикидати, що можна теоретично викинути або зробити по іншому в будь-якій бібліотеці компонент. І перше, що спадає на думку — усілякі тултипи, таби, закривайки-випадайки і тому подібний дрібʼязок чудово робляться за доповогою нативних елементів.А що не дуже робиться, то для того є Custom Elements. Готуючись до доповіді на fwdays, я зрозумів одну цікаву річ — коли мова йде про нативні вебкомпоненти, усі думають про страшний Shadow DOM, з усіма його ізоляціями, інкапсуляціями, шаблонами та іншими страхіттями. Хтось просто боїться класів. Ну але то таке.Річ у тім, що нам геть не обовʼязково використовувати Shadow DOM і мудохатися з ізоляцією стилів. Custom Elements чудово себе почувають в так званому Light DOM (неофіційна назва), коли вони виступають просто такою собі обгорткою для відкритого фрагменту дерева.Так от. Custom Elements виявились дуже зручними для невеличких "тупих" компонентів, задачею яких є якийсь простенький функціонал, наприклад, перемикання активного елемента всередині в залежності від значення атрибуту. Чи той же collapse/expand, але з зовнішнім керуванням. У мене взагалі є компонентик, який просто показує поточний слайд у вигляді "7/8", склеюючи два значення докупи.В чому ж, на мою думку, вигода? По-перше, Custom Elements підтримуються сьогодні будь-яким відром. По-друге — сумісність. Ваш фреймворк не зможе відрендерити Custom Element лише в одному випадку — він не вміє рендерити усі інші теги. По-третє — зменшення залежності на внутрішні приколи вашого стеку, кастомні елементи залежать тільки на вебстандарти і бравзери. По-четверте — якщо засукати рукави і перенести всі банальні й прості рішення з фреймворку на Custom Elements, то можна нічогенько так скоротити фінальний розмір бандлу.Загалом, ідея цього допису полягає в тому, щоб за нагоди почати практикувати таку собі трирівневу систему прийняття рішень при створенні нового компонента:1. Чи вміє це HTML/CSS/JS?Ви будете приємно здивовані тим, скільки всього сьогодні вміє платформа. Я й сам час від часу роблю для себе приємні відкриття, буду відвертим. Загалом, якщо вам треба щось просте, спочатку пошукайте, чи нема такого вже в бравзері.2. Чи треба мені для цього мій фреймворк?Нативна платформа, хоч і вміє вже багато, усе ж дає нам радше кубики з леґо аніж готові рішення. І часто рішення треба зібрати самим. Але тут теж є певний простір для маневру — часто певні рішення цілком собі складаються докупи без залучення додаткової складності. Ті самі Custom Elements — це той шар, який дозволяє зібрати певний функціонал, надаючи вам і реактивність, і інструменти для DOM, і події, і команди, і ще купу всього просто з коробки.3. Чи можу я не все зробити з фреймворком?Тут більше задача на декомпозицію. Часто, дійсно, новий компонент може видаватися складним, залежним на глобальні стани, завʼязаним на інші компоненти і так далі. Але, якщо подихати носом і подивитися зі сторони, можна побачити як страшна велика задача розкладається на оберемок маленьких нестрашних. І тоді ми можемо спокійно повертатись до питання №1.Я би радив спробувати розглядати ваш фреймворк як такий собі оркестратор, який відповідає за складні композитні задачі, а прості речі він віддає на відкуп бравзеру і вашим знанням платформи.Якщо спробувати зібрати це все в один афоризм — не сапайте вазони комбайнами.@babichdev

Київ, булочка з маком і Карпати.Люблю життя за непередбачуваність. Цього року обставини складалися так, що я не мав бути присутнім на DOU DAY взагалі. А склалися таким чином, що я мало того, що був, то ще й обидва дні мав місце в програмі.Мені подобаються події від DOU не самим розмахом (хоча за це їм окрема повага), а радше розмаїттям можливостей до спілкування, до нових несподіваних знайомств, до неочікуваних зустрічей. До речі, саме так я познайомився з прекрасними людьми з Headway, Appflame, Obrio, Universe та іншими, завдяки яким мій ютуб настільки змінився за останній рік. Це так, до слова.Так, я їжджу на DOU в першу чергу за новими знайомствами. Не за контактами, а саме за знайомствами. І мені дуже імпонує, що DOU збирають в одному місці настільки різних людей з різних галузей. Взагалі, я на конференції раджу усім ходити в першу чергу заради нетворкінгу та нових знайомств.А ще мені дуже подобається, що там є величезна купа людей, які в упор не знають, хто я такий. Воно трохи приземляє, знаєте ) Корисно для таких мікрознаменитостей, як я )В перший день я робив, не знаю, воркшоп — не воркшоп, лекцію — не лекцію, в общім намагався розказати про один маленький, але дуже гордий проєктик, який я написав ось цими самими руками без всяких ваших фреймворків. Там було і про Custom Elements, і про всякі нові й не дуже приколи CSS та JS, і про Browser API, і про усілякі цікаві трюки. І якщо перед цим воркшопом я жартував, що мені на нього треба шість годин, а не півтори, то під час нього я зрозумів, що це був геть не жарт. Мені реально не вистачило часу бодай поверхнево розповісти про усе, що я хотів. Тому думаю тепер, як це його зібратися докупи і якісь статті написати, чи шо.А в суботу я записував подкаст з Вірою Ткаченко, CTIO в MacPaw. Я міг би говорити з нею про іновації, про ШІ, про ще якісь "гарячі" теми, але вирішив розмовляти про те, що цікаво мені. А цікаво мені було дізнатися більше не про CTIO, а про людину за цією посадою. І вийшло дуже цікаво й душевно. Зокрема говорили про жінок в ІТ, і для мене, як батька двох дочок, такі теми є дуже важливими. А ще дуже важливим є те, щоб в кожній галузі для них були такі приклади для наслідування, як Віра.Запис, до речі, вийде на ютубі свого часу.А ввечері був концерт Жадана і всілякі розваги, проте я на них не потрапив. Чому? Тому, що конференції конференціями, популярність популярністю, але якщо я пообіцяв сину поїхати з ним в шкільну поїздку в Карпати — значить я маю їхати в шкільну поїздку в Карпати. Навіть якщо для цього треба міняти квитки і їхати пів дня в Інтерсіті, аби бути ввечері вдома.Бо посеред усього двіжу, посеред постійної метушні, посеред постійних зйомок, мітапів, конференцій та інших атракцій надзвичайно важливо памʼятати, що насправді важливе лише те, що ми робимо для своїх близьких.P.S. А булочка з маком — це єдине, на що я мав сили й натхнення з'їсти на вечерю після першого дня DOU DAY, настільки я був втомлений )))

#думки_вголосЧи можна на співбесіді відповідати "Я не знаю"?Можна. Але.Я б не радив на цьому завершувати відповідь. Будь-яке питання на співбесіді — нагода для вас або проявити свою експертизу, або ж скерувати розмову у вигідному для вас напрямку. І як же це зробити, якщо ви не знаєте, що відповідати?Замість просто "Я не знаю" кажіть "Я не стикався/не працював/не маю достатньо досвіду з цим. Але мені було б дуже цікаво дізнатися, як саме це використовується у вас в проєкті". І тоді, замість зупинити розмову незручною тишею, ви натомість можете перехопити ініціативу і змусити вже інтервʼюєра стати активним учасником діалогу.В такий спосіб можна проявити одразу кілька моментів: ви чітко розумієте межі своїх знань, водночас виявляєте інтерес до нових знань і показуєте справжній інтерес до проєкту, а не просто намагаєтесь проскочити співбесіду.Сама по собі відповідь "Я не знаю" певною мірою шкідлива, якщо звучить саме так. Хоч це і й цілком собі нормальна відповідь. Намагання вгадати чи, боронь боже, вигадати відповідь може вас просто-напросто закопати на таку глибину, що у вас зʼявляється непримарний шанс знайти рештки динозавра.Повірте, досвідчений інтервʼюєр знає, коли ви не знаєте. І знає, коли ви знаєте, але не можете зібрати відповідь докупи. Ось тут, до речі, порада саме інтервʼюєрам — слухайте уважно, аналізуйте резюме і пробуйте робити висновки не лише з прямих відповідей, а й з дотичних.У мене в практиці було не раз, коли кандидат казав "Я не знаю", але я ж то розумів, що знає! В цьому випадку я намагаюсь підштовхнути людину до відповіді, задаю навідні питання, нагадую про минулі відповіді, які дали мені підказку. Кандидат може знати відповідь, практикувати якісь підходи, просто не знаючи, що це саме те, про що ви питаєте. Я й сам дійшов до багатьох речей самотужки, емпірично, і просто можу не знати, що ось саме це має саме таку назву.Тому дуже важливо вміти визначити отакі сигнали і направити кандидата в правильному напрямку, аби він врешті сам склав два й два і дійшов висновку, що насправді знає ту саму правильну відповідь. Це, до речі, один з моїх улюблених моментів на співбесіді, коли я бачу, як загоряються очі в людини, до якої щойно прийшо усвідомлення, що вона насправді знає.Тому я й раджу постійно не спішити з відповіддю, а уважно дослухати питання, взяти кілька секунд павзи на обробку запиту, і обовʼязково поставити уточнюючі запитання. Особливо, якщо у вас є чуєчка, що воно щось знайоме, але ви не можете сходу сформулювати відповідь.До речі, маю ще одну пораду, яка дозволить вам не панікувати і не вклякати, коли ви чуєте питання, на яке ви не можете дати відповідь. Так от, перед співбесідою проаналізуйте свій досвід і знання, підготуйте таку собі рамку комфортних тем.Це потрібно для того, щоб ви чітко знали — ось це я знаю достатньо аби плюс-мінус вести розмову, а усе, що сюди не влучає, автоматично потрапляє до категорії "Я цього не знаю, але було б цікаво дізнатись". В такий спосіб ви вже наперед приберете невизначеність, якої ми й боїмося на співбесідах."А що, як мене спитають Х?" і є частою причиною страху й хвилювання, які можуть вас завалити на співбесіді навіть без активної участі інтервʼюєра. А от коли чи знаєте, як поводитись в такому випадку, оця страшна невизначеність просто зникає, бо ви тепер маєте чіткий сценарій, як діяти.Не знати — нормально і очікувано. Питання лише в тому, чи можете ви перетворити це на вашу сильну сторону, показавши, що незнання для вас не перепона, а чи це стає для вас бетонною стіною у вашому професійному розвитку[email protected]. Товариство, збір на РЕБ для 115 ОМБр триває, і ми суттєво відстаємо від графіка. Лишилося 65 000 гривень і усього 5 днів.Нагадую, що можна виграти квиток на AI Javascript fwdays'26 за донат усього від 200 гривень. Ну або можна просто задонатити.Дякую за кожну гривню!

#думки_вголосДля мене величезною загадкою залишається те, чому досі існують матричні співбесіди.З огляду на увесь мій досвід проведення й проходження інтервʼю, я вважаю цей метод найнееффективнішим, ба більше — шкідливим. На мою думку усе, що здатна перевірити так звана "матриця компетенцій" — це здатність людини до дослівного запамʼятовування тексту. Надзвичайно корисна навичка, коли ти у третьому класі, але коли ти доросла людина — далеко не основна.Звичайно, можна сперечатися про доцільність матриць, про те, що не все так однозначно, але погляньмо правді у вічі — в переважній більшості випадків така співбесіда зводиться до замальовування клітинок.Мені здається, що співбесіда має усе-таки перевіряти навички, максимально корисні в робочих задачах. Звичайно, якщо в посадові обовʼязки входитиме декламування напамʼять визначення івент-лупа, то шо ж, це співбесіда і має перевірити.Але якщо на роботі треба робити роботу, то й питання мають бути відповідні. Щоб розкривали ваше вміння працювати з невизначеністю, зі складністю, перевіряли вашу клепку. Про івент-луп завжди можна встигнути поговорити, але розмова має підводити вас до пояснення яому саме івент-луп вам тут треба, і як ви обґрунтуєте ваше рішення.Що ще показово, майже усі, хто потрапив у пастку матричних співбесід, практично в один голос кажуть про незалученість і апатичність саме інтвервʼюєрів. Ну тобто людина сидить, ставить питання зі списку, чекає єдино вірну відповідь, ставить галочку і так далі по колу. Енергія мокрої макароніни, як то кажуть за кордоном.Зазвичай це дуже показово, бо така "співбесіда" не вимагає ніяких навичок проведення інтервʼю, окрім читання з листка і здатності на слух визначити чи достатньо точно було процитовано визначення з MDN. Зустрічаються з різних дві самотності, так би мовити — незацікавленість і неможливість проявити себе. Результат тут очікуваний та очевидний.Для мене особисто матрична співбесіда сигналізує про багато речей всередині компанії. Наприклад те, що компанія не здатна адаптувати свої процеси найми під реалії ринку і досі вважає, що живе в 2010-х роках. А ще це мені каже про те, що компанія абсолютно не має уявлення, кого саме вони шукають. Портрет ідеального кандидата тут — це рішення японського кросворду, а не живий фахівець, який буде здатний розвивати продукт.Я часто раджу сприймати технічну співбесіду як найкраще, що з вами в принципі станеться в цій компанії. І якщо "найкраще" це оце, то у мене невтішні новини — буде гірше. Співбесіда це ваша перша взаємодія з майбутніми колегами, це віконце, через яке видно ваш майбутній проєкт. Але якщо це віконце завішане десятирічної давности газетою з затертим сканвордом — то й в кімнатку з проєктом теж навряд чи часто пробивається сонце.Коли я проводжу консультації щодо співбесід, для матричних інтервʼю у мене лише одна порада — відбудьте її, а там вже як складеться. Якщо ви не цікаві компанії як інженер, а лише як заповнена гугл-форма, то чому вона має бути цікава вам? Поважайте себе і свій час.А до тих, кому доводиться проводити співбесіди, я маю маленьке прохання — практикуйте усі інші види інтервʼю: лайвкодинг, системний дизайн, поведінкові, ситуативні, сценарні, які там ще. А матричні за можливості не практикуйте.Бо матричні співбесіди породжують матричних синьйорів. А матричні синйьори нічого хорошого вже не породжують.Поважайте себе і свій час.Всім цьом у лобіка, починайте срач в коментарях ;)

Чи можна відправити форму без JavaScript?Так. Ба більше, форми зʼявилися до JavaScript. І призначалися якраз для відправки даних на сервер. Але чому ми настільки звикли до обробки форм за допомогою JS, що це питання взагалі виникає? Не будемо вдаватися в глибокий історичний аналіз і зійдемося на тому, що потреби інтерфейсів змінювалися набагато швидше, ніж стандарти HTML.Та сама валідація (точніш, її історична відсутність), певні особливості перетворення форми на структуровані дані (чекбокси як масив, ага), не надто зручний UX для відправки файлів і так далі.Все це виправлялося усе новими й новими JS-бібліотеками, і врешті витіснило з колективної свідомості той факт, що форми, взагалі-то, і самі непогано вміють відправлятися. Щоправда, так само з перезавантаженням сторінки, але шо ж.Найпростіша поведінка за замовчуванням — це відправка GET-запиту на сервер.<form> <input name="username" /> <input name="password" /> …</form> перетворюється на ?username=шпігун&password=нескажу.Якщо ж вказати <form method="POST">, то дані підуть не в URL, а в тіло запиту як application/x-www-form-urlencoded.Пункт призначення задається через атрибут action, в якому можна вказати потрібний ендпоїнт.Файли. Форми вміють відправляти файли. Десь так року з 1995-го.Для цього достатньо вказати enctype="multipart/form-data", і бравзер відправлятиме вашу форму у вигляді так званого multipart message, тобто кожне поле — окрема частина, файл — теж окрема частина, зі своїми header, filename, content type і binary body.Тєлєк, духовка, два крісла Що ще нам для щастя треба?Наприклад, декларативно задавати різні сценарії відправки форми. <form action="/article" method="post"> … <button formaction="/article/publish">Publish</button> <button formmethod="get" formaction="/article/preview">Preview</button></form> Як бачите, сама кнопка може перевизначати як метод відправки, так і призначення.Про валідацію перед відправкою всі вже, певно знаю, але згадаю побіжно: так, форми вміють у валідацію. Не таку супернаворочену, як із бібліотеками, але більшість випадків покриває. З цікавого — CSS нині має купу селекторів за валідністю значень в полі введення, як то :valid, :invalid, :required, :optional, :in-range, :out-of-range, що разом з іншими можливостями на кшталт :has відкриває майже безкрайнє поле можливостей зіпсувати ваш UX через стилі.disabled поля у валідації участі не беруть (та й не відправляються взагалі), а readonly не блокує відправку, навіть якщо воно required і при цьому пусте. Ну бо користувач не може змінити його значення. І так, перезавантаження сторінки неминуче. Відправки форми завжди ініціює навігацію. Це вже інше питання, як її обробляє сервер, але для користувача сторінка оновиться в будь-якому випадку.Чи ні? Існує певний, кхм, хак, який дозволяє уникнути цього сценарію за допомогою старого доброго iframe. Усі ж люблять хаки з iframe, правда?<iframe name="result" hidden></iframe><form action="/upload" method="post" target="result"> <input name="title"> <button>Send</button></form> Тут нюанс в тому, що якщо щось піде не так з обробкою форми, то про це знатиме тільки iframe, а не ми. Ніхто не казав, що буде легко, це ж хак, а не best practice.А, ще форму можна сабмітити в межах сторінки тепер за допомогою dialog:<dialog id="confirmDialog"> <form method="dialog"> … <button value="cancel">Cancel</button> <button value="confirm">Delete</button> </form></dialog> dialog.addEventListener('close', () => { console.log(dialog.returnValue);}); Насправді, базових можливостей форми без JS вистачає аби покрити переважну більшість випадків, просто ми вже звикли якось все переускладнювати. Якщо у вас не монструозна форма на десять екранів зі складними залежностями, швидше за все, вам цілком вистачить простого method="POST". Спробуйте.@babichdev

Я так і не навчився вайбкодити.Увесь вайб зникає вмить, щойно у мене зʼявляється думка — "гм, а шо воно там нагенерувало?".Знаєте, є приказка "деякі двері краще не відкривати"? У випадку з LLM її можна переробити на "деякі файли краще не відкривати". Або навіть "всі файли".Я постійно заглядаю в ці файли, і в результаті або це перестає бути вайбкодингом, коли я починаю робити вже серйозний сетап зі скілами, вікі та іншими правилами, або ж я дякую за напрямок і починаю писати сам.До речі, другий шлях мені подобається більше. Я дивлюсь на цей код, відзначаю, що я б зробив по-іншому і… роблю по-іншому.Чому для мене цей шлях кращий? Бо я впертий як віслюк в своїй недовірі до LLM, і через це постійно шукаю кращі, на мою думку, шляхи зробити те чи інше. Чи то інший архітектурний підхід, чи то використання іншого бравзерного API, чи моє улюблене "це вміє CSS".Певною мірою я можу сказати, що для мене вайбкодинг є потужним поштовхом для самовдосконалення, адже піддаючи сумніву кожне рішення LLM, я здобуваю нові знання.Проблема LLM в тому, що вони генерують усереднений код. Не такий, що підходить під цю конкретну задачу, а такий, яким в середньому є увесь той код, на якому LLM вчилась. А людство, в середньому, не є наймудрішою колективною свідомістю, будьмо відверті.Відмовляючись приймати посередність, я прагну знайти досконалість через нові знання. І часто це призводить до цікавих відкриттів.І нагадаю вкотре — я чітко розділяю вайбкодинг та AI assisted розробку. Радити в цьому випадку будувати пайплайни з агентів, створювати безліч скілів і будувати knowledge-wiki для маленького проєкту-досліду це усе одно, що радити рибалці, що сидить на березі ставка з однією вудкою, обовʼязково придбати 800 спінінгів і авіаносець для виходу у відкритий океан.

#css_in_actionАнімуючи небуттяМи усі звикли до анімацій в CSS. Зокрема я зараз говоритиму про transition: воно змінює значення від початкового до кінцевого в залежності від часової функції на заданому часовому проміжку.І тут важливо згадати про дві умови: анімація не може відбутися, якщо немає так званого before-change style — попереднього відрендереного стану, від якого анімація може стартувати, а також якщо значення, яке ми намагаємося "оживити", не може мати проміжних станів, тобто є дискретним.В CSS обидві умови можна зламати, просто використавши display: none. Тривалий час задача "показати/сховати елемент і додати анімацію появи/зникнення" покладалась на JavaScript та його ненадійні таймери. Згодом зʼявилася дещо надійніші події на кшталт transitionend, але вони вирішували лише частину проблеми.Але сьогодні ця задача більше не є проблемою. CSS надає нам дуже цікаві інструменти, що дозволяють дещо більше, ніж просто "анімувати `display:none`".Мова про @starting-style та allow-discrete.Коли елемент переходить від display: none до "видимого" значення, за замовчуванням усі кінцеві значення властивостей застосовуються одразу, навіть попри transition-duration. Чому? Бо у елемента немає *початкового стану*, на основі якого можна розрахувати перий кадр анімації. Чому? Бо він на момент початку переходу просто ніколи не був *відмальований*. Це якщо ми говоримо про видиму зміну стану. ПриміткаЕлемент може не мати відмальованого стану з кількох причин. Наприклад, display: none означає, що елемент взагалі не бере участі в рендерингу, а от visibility: hidden значить, що елемент невидимий, але займає місце в макеті. Так от, тут в нагоді нам стає @starting-style. Це @-правило дозволяє "допомогти" бравзеру створити той самий перший кадр, від якого він уже буде спроможний розрахувати анімацію. Тобто сама суть не в тому, що бравзер не може інтерполювати певні значення, а в тому, що він просто не розуміє, як має виглядати перший кадр.element { transition: 1s; display: none; &.visible { display: block; opacity: 1; @starting-style { & { opacity: 0; } } }} Таким чином можна додати анімацію не лише до display: none -> block, а й при вставці нового елементу в DOM. Тож, якщо коротко: @starting-style це шпаргалка, яку ми надаємо бравзеру, аби він зміг зрозуміти, як намалювати перший кадр анімації для елементу, у якого не було відмальованого (rendered) стану до того.Наступна проблема — анімація від видимого стану до "невідмальованого", і полягає вона в абсолютно іншому механізмі: оскільки дискретні значення анімувати неможливо, бравзер за замовчуванням просто "перемикає" їх на *початку переходу*. І саме тому намагаючись "анімувати" елемент в небуття від display: block до display: none ми не бачимо переходу, а лише миттєве зникнення.Це можна було б вирішити, якби можна було "відкласти" перемикання на потрібний нам час замість миттєвої зміни. І от якраз це раніше можна було вирішити виключно за допомогою JavaScript: або ставити таймери, або слухати події завершення анімації, і вже тоді "клацати перемикач" вручну.І, нарешті, цей механізм є і в CSS. Це значення allow-discrete для властивості transition-behavior. Він робить рівно те, що необхідно: дозволяє відкласти перемикання дискретної властивості на потрібний час.element { transition: opacity 1s, display 1s allow-discrete; display: none; opacity: 0;}element.visible { display: block; opacity: 1;} Якщо ми приберемо .visible з елементу, то спочатку побачимо, як той поступово "зникає", і лише в кінці, коли opacity досягне нуля, display набуде значення none.Якщо коротко, то allow-discrete дозволяє визначити для перемикання значення дискретної властивості певну точку на часовій шкалі анімації, але з купою виключень, звісно. Які я вам пропоную дослідити самим.MDN: @starting-styleMDN: allow-discrete***@babichdev

Громадо! 2 квітня робимо чергову лампову, і вже знаємо, що буде гаряче.Двоє спікерів, обидва з темами про ШІ — але не з тими, де “ой які ми всі молодці, живемо в майбутньому”. А з тими, де чесно і в лоб.Мирослав Танцюра розкаже, чому ШІ пише фігню — і чому це не його провина (спойлер: це наша).Марк Абрагамович підніме тему, яку всі бояться обговорювати вголос — що відбувається з нашими навичками, поки ми радісно делегуємо все штучному інтелекту.Формат як завжди — ніякого “сиди тихо і слухай”. Хочеш перебити — перебивай. Хочеш челенджити спікера — будь ласка, тільки будь готовий, що тобі теж прилетить. Без образ, але й без дипломатії.І так — на цій зустрічі ми анонсуємо наступну лампу. Нова локація, новий формат, спонсори, подарунки, афтепаті на свіжому повітрі. Коротше, ми трохи підросли і хочемо показати, що з цього вийшло.📅 2 квітня, двері о 18:00📍 Львів, офіс Sigma SoftwareПриходь, якщо не боїшся думати вголос. Ну і якщо боїшся — тим більше приходь, ми тебе розговоримо.Реєструйся ось тут за ціну менше смузі