Якби ж люди ще про нього знали, або вміли користуватися

Нуу, це більше бекендно-фулстекерський підхід. Добре, якщо фронт може зрозуміти, що потенційна є проблема з sql, але це другорядне в цьому випадку. Мені скоріш цікаво, чи здогадається людина подивитися кастомні шрифти. Бо 10 років тому google fonts особливо не юзалися, зато були популярні кастомні шрифти, в TTF форматі на той час. І доволі часто такі шрифти могли важити 2-3мб і були основним блокувальником рендерінгу сторінки. І як вирішувати цей момент можна обговорювати з півгодини ізі

«Дякую за відповідь, наш ейчар зв’яжеться з вами щодо фідбеку»
А якщо серьйозно, то що таке «нормальний проект»? Щось типу корпоративної бездонної адмінки чергового банкінгу, де естімейти надаються типу «4-6 місяців на таск»?
А якщо я роблю крутий анімований лендос для всесвітньо відомого тайтлу, і там доволі жорсткі умови щодо естімейтів та дедлайнів, бо реліз блокбастеру чи гри ось-ось? Чи це є «нормальним проектом», чи таке собі, нормальні пацани таким займатися не будуть? :)

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

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

Також часто проводжу співбесіди і вже мабуть років з 10 надаю перевагу саме story-driven формату. Буває, кандидат готується відповідати про різницю між let та var, а тут такий поворот.
Початок розмови може бути таким: «ПМ прийшов до тебе з таском зробити оптимізацію перформансу на фронті для старого проекту. Це і-комерс проект, який був написаний 10 років тому рендомним індусом на якомусь php фреймворці. На все про все є 10 годин». Від кандидата очікується розуміння приорітетів, бюджету, знання інструментів (як браузерних, так і ні), основних метрик, форматів для різного типу ассетів, технік щодо css, js, зображень, кастомних фонтів, анімацій тощо. А далі все залежить від сеніорності посади, бо навіть про оптимізацію шрифтів можна годину розмовляти при бажанні.
Але, нажаль, зазвичай відповідь зводиться до «еее мініфікация-конкатенація і плагін для кешування».

Гарна стаття — техніки, приклади та оформлення взагалі.
Єдине, з чим би я трохи посперечався — це «Адаптивні font-size значення через CSS-змінні».
Імхо, це трохи переускладнене рішення. Як на мене, класичний The 62.5% Font Size Trick працює плюс мінус схоже, але набагато простіше.

Оце в контесті вищосказаного рекомендую статтю про нативні штуки, там багато цікавих прикладів, які на диво працюють усюди, де треба

Ну, то дивлячись, які таби потрібні. При бажанні можна і в таби трансформувати

Але навіщо магія з радіобатонами для аккордионів, якщо є нативний details? Те ж саме для модалок, є ж хтмл dialog

Оце якби ви кодили десь в умовному codepen, чи після кодінгу шарили там результат, то можливо хтось би додав апгрейдів з поясненнями

А взагалі цікавий формат, особливо початківцям я б рекомендував дивитися і конспектувати.
Поки дивився, спала на думку ідея DLC до відео. Зробити той самий таск, але за допомогою AI. Можна буде порівняти запропоновані машиною рішення з думками м’ясних професіоналів, подивитись, що по часу виконання та кінцевий результат в плані якості. Або невеличкі аддони до віджету, які принесуть підтримку доступності, якусь файну анімацію і може мікроформати, щоб люди не забували про таке

JavaScript не потрібен, оце точно. Моя улюблена активність під час рев’ю когось — залетіти на проект і викинути 30% JS, замінивши на нативну html функціональність (dialogs, popovers, details etc) і переписати частину динамічного функціоналу на CSS. З зеленою підтримкою :has усіма браузерами не використання цієї фічі має прирівнюватися до кримінального правопорушення

Досі пам’ятаю цей пост. Як раз дочитував книгу Еріка..

A couple of weeks before she died, Rebecca informed us that she was about to be a big girl of six years old, and Becca was a baby name. Once she turned six, she wanted everyone (not just me) to call her Rebecca, not Becca.

She made it to six. For almost twelve hours, she was six. So Rebecca it is and must be.

класична трійка — помаранчевий щит для html5, синій для css3 та жовтий для js де-факто стали стандартом в свій час. але офіційно їх ніхто не апрувив

Дивно, що в Україні так мало користувачів Claude. В моїй щоденній практиці він вирішує поточні задачі краще ChatGPT. Codeium також непогано працює саме для кодінгу. MS Copilot та Gemini для розробки не дуже, але для задач, пов’язаних з імейлами, перекладом, зобреженнями — в принципі норм

“margin-inline: auto” тоді вже

І то вірно. Просто декілька коментів в око потрапило, а далі все як в тумані

align-content: center

Оце зараз буду зараз тут критикувати усіх, готуйтеся.

Почну з деяких коментаторів, які захищають divарею головного мозку, бо «семантика нікому не потрібна», а якщо і потрібна, то точно не в публічній адмінці з мільйоном дашбордів і форм. Інколи складається враження, що є великий прошарок «фронтендерів», які швиденько вічили умовний реакт, додатково щось базове в css, ну а html взагалі скіпнули. Це враження підсилюється на співбесідах, але то інша пісня.
Якщо ти знаєш html, то що заважає юзати одразу семантичні теги? Навіть якщо ти не розумієш технічно сенсу, то просто сприймай, як факт, що розробники стандартів і браузерів рекомендують саме семантичне використання тегів. Просто дотримуйся рекомендацій, as simple as that. Ну, а якщо ти боїшся за візуальні відмінності рендеру в різних браузерах, ти взагалі впевнений, що ти фронтендер?

І так, нехай на СЕО багатьом по барабану. Але це і не єдина роль семантичності тегів (якщо не брати до уваги H1-6 заголовки). Як мінімум ще є доступність, себто accessibility. Навіть якщо у вас не публічний сайт і вам пофіг на закони типу ADA compliance, то все одно залишаються багато юзерів, яким доступність важлива. Так, скрінрідери мало хто юзає, але юзерів з keyboard-only користуванням доволі багато. І одна з фішок семантичних тегів полягає в тому, що вони максимально доступні. В HTML компоненти типу details, summary, button, table, label та інші вже з коробки закладено все що потрібно. Звичайно, увесь потрібний функціонал можна відтворити на базі дів, але навіщо це збочення?

І тут у мене вже претензії до автора статті, якого я безмежно поважаю (та навіть колись виступали на одній конфі в Харкові). Оці приклади з header, nav, article.. Оті чуваки, які працювали над семантикою «html5» трохи не впоралися зі своєю роботою. Вони як ООН — за все хороше, проти всього поганого. Ось вам мільйон правил і спек доків, розбирайтеся. А якщо хтось буде робити не по спекам, то що поробиш — висловимо глибоку занепокоєність, але ніяких санкцій не буде. З’явилося мільйон статей, як же правильно юзати ті нові теги. Там виявилося стільки нюансів і розмитості, що більшість забило, а не більшість — максимально спростило. Бо той же < Header > по спекам — це не той єдиний хедер в шапці сайту, а це й ще шапка в < article >. А < article > - це self-contained composition in a document, page, application, or site. І розумій як хочеш.

Я це все до чого.
Я можу пережити, якщо там <div class="section-block"> замість < article >, але у мене очі наливаються кров’ю, коли я бачу <div> з onClick замість кнопки чи ссилки, або нескладну таблицю на дівах, або форму на суцільних дівах без розуміння того, як має виглядати і працювати класична форма.
Тому я б додав таких прикладів до статті, бо одна справа дискутувати про доцільність семантики в деяких випадках, а інша — вважайте помилки в html структурі, які можуть впливати на UX кінцевого юзера.

Та й банальне. Уявимо, вас закидують на не ваш проект, розробник якого захворів, а вам треба швиденько зробити фікс. Правильна семантика банально допоможе вам швидше візуально зрозуміти структуру лейаутів, ніж мільйон вкладених дівів. І це ще добре, коли той розробних дотримувався якоїсь методології і назви класів адекватні. А якщо ні і там якась позашлюбна дитина обфускованого tailwind і atomic css? от вам і семантичні maintenance особливості..