Ще шість донатів не вистачає до нового допису. Маєте часу до вечора )

UPD: Вніс передоплату в 70000 грн.
Тепер маємо 40 днів на те, щоб зібрати залишок. Квитанція в коментарях

UPD2: Допис закінчив пізно, тому буде вже зранку )

#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-style
MDN: allow-discrete

***
@babichdev

Я так і не навчився вайбкодити.
Увесь вайб зникає вмить, щойно у мене зʼявляється думка — "гм, а шо воно там нагенерувало?".

Знаєте, є приказка "деякі двері краще не відкривати"? У випадку з LLM її можна переробити на "деякі файли краще не відкривати". Або навіть "всі файли".

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

До речі, другий шлях мені подобається більше. Я дивлюсь на цей код, відзначаю, що я б зробив по-іншому і… роблю по-іншому.

Чому для мене цей шлях кращий? Бо я впертий як віслюк в своїй недовірі до LLM, і через це постійно шукаю кращі, на мою думку, шляхи зробити те чи інше. Чи то інший архітектурний підхід, чи то використання іншого бравзерного API, чи моє улюблене "це вміє CSS".

Певною мірою я можу сказати, що для мене вайбкодинг є потужним поштовхом для самовдосконалення, адже піддаючи сумніву кожне рішення LLM, я здобуваю нові знання.

Проблема LLM в тому, що вони генерують усереднений код. Не такий, що підходить під цю конкретну задачу, а такий, яким в середньому є увесь той код, на якому LLM вчилась. А людство, в середньому, не є наймудрішою колективною свідомістю, будьмо відверті.

Відмовляючись приймати посередність, я прагну знайти досконалість через нові знання. І часто це призводить до цікавих відкриттів.

І нагадаю вкотре — я чітко розділяю вайбкодинг та AI assisted розробку. Радити в цьому випадку будувати пайплайни з агентів, створювати безліч скілів і будувати knowledge-wiki для маленького проєкту-досліду це усе одно, що радити рибалці, що сидить на березі ставка з однією вудкою, обовʼязково придбати 800 спінінгів і авіаносець для виходу у відкритий океан.

Товариство, останнє нагадування!
Svitla Systems розігрує бананку і крутяцьку парасольку просто за те, що ви дасте відповідь на запитання у формі.

Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до кінця сьогоднішнього дня!

І ще — якщо зберемо достатньо відповідей, то окрім бананки й парасольки, ми розіграємо персональну консультацію від мене особисто. Скільки це достатньо? Ну явно більше, ніж є зараз ;)

Чекаємо на ваші відповіді на "Питання від партнера"!

https://forms.gle/rqHKzisACJxDsSCp9

Це тому шо Svitla Systems партнер відео "Що робить ENGINEERING MANAGER", якшо шо.

Як вдало розпочати новий робочий тиждень?
Правильно — з перегляду нового відео!
https://youtu.be/Fds47q02RNQ

Не забувайте про вподобайки, коментарі та поширення.

Ще раз: ВПОДОБАЙКИ, КОМЕНТАРІ ТА ПОШИРЕННЯ

Так, ну а хто вже подивився відео, з вас по десять гривень.
Бо збір на РЕБ для 115 ОМБр триває.

Зібрано: 8 065 грн
Мета: 230 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

Товариство, цього тижня знову маю трошки справ, тому на нові тексти нема особливо часу.
Тому:

а) Не забуваємо про збір
б) Пишемо побажання щодо наступних тем

Всім цьом у лобіка, а хто закине бодай пару гривень на збір — два цьома у лобіка.

P.S. Дякую за всі відписки )))

Товариство! 9 травня відбудеться зйомка нового випуску формату "Одне питання — три відповіді" у Львові.

Шукаю одного джуніора, одного мідла і одного синьйора аби ставити їм різні хитрі запитання зі співбесід і потім душно розбирати кожну відповідь.

Хочете потрапити в телевізор? Залишайте заявку ось тут: https://forms.gle/nTk163B1KEJ7qeRG9

Або пишіть мені особисто, це може суттєво підвищити ваші шанси потрапити в число учасників ;)

Зйомка відбудеться за підтримки компанії appflame.

*обіжено сопе*
Це шо, ніхто не хоче в телевізор?
https://forms.gle/nTk163B1KEJ7qeRG9

Я знайшов найгірше резюме веброзробника.

І, що найжахливіше, воно — моє.

Якщо за сьогодні зберемо 10 000 грн на РЕБ для 115 ОМБр, зроблю відеоогляд і розбір чому воно абсолютно жахливе зі сторони технічного інтервʼюєра.

Зібрано: 25 693 грн
Мета: 230 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

P.S. У нас зʼявився дедлайн по збору — 19 травня.

Шоб не знімати нове відео знімав нове відео

Шоб не знімати нове відео готую на завтра старе відео

Чи можна відправити форму без 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

#нове_відео
"Співбесіда на сцені №2" нарешті вийшла!
Чи можливо мати достатньо досвіду й знань, аби вважатися справжнім техлідом в 22 роки? Я ніколи в це не вірив, але Давид Касумов насмілився кинути виклик моїм упередженням. Чи вдалося йому мене переконати?

Дізнаєтесь лише з нового відео!

З вас вподобайка, обовʼязковий коментар під відео та поширення серед друзів, колег та родичів.
Приємного перегляду!

https://youtu.be/XCPPTNBNKB4

Товариство, офіційний анонс!

Відкриваю продаж квитків на зйомку нового випуску "Одне питання — три відповіді"!

Зйомка відбудеться 9 травня в пабі "Христофор" у Львові. Двері відкриваємо о 12:00.

Буде цікаво, весело, а головне корисно й пізнавально.

Ще будуть донати, розіграші за донати, подарунки від спонсора та інші приємності. Не проґавте!

Вартість першої хвилі квитків — усього 150 грн.

https://secure.wayforpay.com/payment/record_3

Усі кошти з події підуть на потреби ЗСУ.

***
Партнер цього випуску — appflame, українська продуктова ІТ-компанія, яка створює продукти світового рівня: Hily, Taimi, AdConnect, Mailkeeper та інші.

НА DOU DAY усього за 500 гривень?
Так. Якшо повезе.
В общім — розігрую один PRO квиток на DOU DAY 2026 за донат в 500 гривень.

Збір все той же — на РЕБ для 115 ОМБр.
Кожні 500 гривень вашого донату — додатковий шанс на виграш.

Спеціальна банка цього розіграшу:
https://send.monobank.ua/jar/9XKkqycnoU

Розіграю квиток в понеділок, 4 травня.

А як хто не вірить в удачу, то от вам промокод на 15% — BABICHSS15

#думки_вголос
Для мене величезною загадкою залишається те, чому досі існують матричні співбесіди.

З огляду на увесь мій досвід проведення й проходження інтервʼю, я вважаю цей метод найнееффективнішим, ба більше — шкідливим. На мою думку усе, що здатна перевірити так звана "матриця компетенцій" — це здатність людини до дослівного запамʼятовування тексту. Надзвичайно корисна навичка, коли ти у третьому класі, але коли ти доросла людина — далеко не основна.

Звичайно, можна сперечатися про доцільність матриць, про те, що не все так однозначно, але погляньмо правді у вічі — в переважній більшості випадків така співбесіда зводиться до замальовування клітинок.

Мені здається, що співбесіда має усе-таки перевіряти навички, максимально корисні в робочих задачах. Звичайно, якщо в посадові обовʼязки входитиме декламування напамʼять визначення івент-лупа, то шо ж, це співбесіда і має перевірити.

Але якщо на роботі треба робити роботу, то й питання мають бути відповідні. Щоб розкривали ваше вміння працювати з невизначеністю, зі складністю, перевіряли вашу клепку. Про івент-луп завжди можна встигнути поговорити, але розмова має підводити вас до пояснення яому саме івент-луп вам тут треба, і як ви обґрунтуєте ваше рішення.

Що ще показово, майже усі, хто потрапив у пастку матричних співбесід, практично в один голос кажуть про незалученість і апатичність саме інтвервʼюєрів. Ну тобто людина сидить, ставить питання зі списку, чекає єдино вірну відповідь, ставить галочку і так далі по колу. Енергія мокрої макароніни, як то кажуть за кордоном.

Зазвичай це дуже показово, бо така "співбесіда" не вимагає ніяких навичок проведення інтервʼю, окрім читання з листка і здатності на слух визначити чи достатньо точно було процитовано визначення з MDN. Зустрічаються з різних дві самотності, так би мовити — незацікавленість і неможливість проявити себе. Результат тут очікуваний та очевидний.

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

Я часто раджу сприймати технічну співбесіду як найкраще, що з вами в принципі станеться в цій компанії. І якщо "найкраще" це оце, то у мене невтішні новини — буде гірше. Співбесіда це ваша перша взаємодія з майбутніми колегами, це віконце, через яке видно ваш майбутній проєкт. Але якщо це віконце завішане десятирічної давности газетою з затертим сканвордом — то й в кімнатку з проєктом теж навряд чи часто пробивається сонце.

Коли я проводжу консультації щодо співбесід, для матричних інтервʼю у мене лише одна порада — відбудьте її, а там вже як складеться. Якщо ви не цікаві компанії як інженер, а лише як заповнена гугл-форма, то чому вона має бути цікава вам? Поважайте себе і свій час.

А до тих, кому доводиться проводити співбесіди, я маю маленьке прохання — практикуйте усі інші види інтервʼю: лайвкодинг, системний дизайн, поведінкові, ситуативні, сценарні, які там ще. А матричні за можливості не практикуйте.

Бо матричні співбесіди породжують матричних синьйорів. А матричні синйьори нічого хорошого вже не породжують.

Поважайте себе і свій час.

Всім цьом у лобіка, починайте срач в коментарях ;)

Товариство, нагадую, що вже завтра ввечері розіграю PRO квиток на DOU DAY 2026.

Участь в розіграші проста як дрова — донат від 500 гривень на РЕБ для 115 ОМБр (банка саме в цитованому дописі), і ви вже в списку потенційних переможців.

До речі, це мав бути мій особистий квиток, як відвідувача, але так склалося, що я буду в програмі. І не просто так, а ще й обидва дні.

Що саме я буду там робити — розповім згодом. А поки чекаю на ваші донати і бажаю вам удачі ;)

Вітаю, товариство!
Цього тижня я знову пожалкую, що ввʼязався в ці ваші ютуби, бо матиму аж дві зйомки, але ви можете прийти і підтримати мене морально. Ну і подушнити з глядацької зали.

Тому нагадую, що 9 травня, в суботу, чекаю на вас на зйомці формату "Одне питання — три відповіді" у Львові. В цьому форматі я ставлю одне й те саме питання джуніору, мідлу та синьйору і вголос аналізую їхні відповіді.

Квитки поки шо по 200 грн, всі кошти з івенту йдуть на потреби ЗСУ.
https://secure.wayforpay.com/payment/record_3

Ну і принагідно нагадую, що ввечері розіграю PRO квиток на DOU DAY 2026.

Цей тиждень я буду зайнятий підготовкою до зйомок, тому покладаюся на вас і на вашу активність. Бо я з величезним задоволенням проведу запис і з одним глядачем, але потім мені ніхто грошів на зйомку не дасть, бо авдиторія скучна ;) Тому забирайте квитки, поки є!