Опитування!
Tailwind — ви за чи проти?
Голосуйте донатами та вказуйте в примітках на чиїй ви стороні. Один голос — 5 гривень.
Завтра спробую підбити підсумки.
https://send.monobank.ua/jar/AeXQ6YRf2X
P.S. Донати йдуть на збір на Mavic для 184 навчального центру.
Tailwind — ви за чи проти?
Голосуйте донатами та вказуйте в примітках на чиїй ви стороні. Один голос — 5 гривень.
Завтра спробую підбити підсумки.
https://send.monobank.ua/jar/AeXQ6YRf2X
P.S. Донати йдуть на збір на Mavic для 184 навчального центру.
🔥36
Ох, вже ті новачки з шилом в дупі!
В команді зʼявляється новий колега, дивиться на процеси, код, підходи і каже що це все лайно собаче, а робити треба так, як скаже він, інакше щастя більше не буде. Знайомо? Точно знайомо. Бо якщо це не був новий колега в команді, то, швидше за все, це були саме ви.
Це нормально. Нам краще в комфортних умовах, і для нової людини комфортні умови це саме ті, в яких вона працювала раніше. І абсолютно природнім для неї буде спробувати відтворити ці умови на новому місці, аби мінімізувати стрес від переходу, від адаптації до нових порядків. Бо якщо натомість завести свої порядки, то й адаптуватися не треба.
Але те, що це нормальна поведінка людини в таких ситуаціях, не означає, що вона правильна. Радше навіть шкідлива. Тому давайте поміркуємо, як можна цього уникнути.
По-перше, в команді має бути нормальний онбординг. Я не говорю зараз про те, коли вам видають ноутбук, пароль до корпоративної пошти і роблять один дзвінок з HR на пів години на тему "шо ти голова".
Я говорю про командний онбординг, під час якого людина якраз має адаптуватися до процесів. Коли вона знайомиться з кодовою базою, з процесами код ревʼю, з загальними підходами до розробки і стилю коду. І в цій ситуації дуже помічним буде мати це все в задокументованому вигляді. Складно ламати те, що викарбувано в слові, а з іншої сторони — якщо воно зафіксовано "на папері", а не на чесному слові, то з тим і знайомитись легше, і дотримуватись.
По-друге, ніхто не забороняє вам вносити пропозиції. Саме так — вносити пропозиції. Не вриватися з бойовим криком "Міша, всьо хуйня, по новой давай!", а аргументовано запропонувати зміни. Так, я знаю, це набагато складніше, ніж плодити купу ПР, які розходяться з командними правилами бо "мені так зручніше". Ну і це не так захопливо, як сваритися на дейліках з тімлідом, визнаю.
Якщо вам не подобається якийсь аспект, розберіться в питанні. Можливо, є причини окрім "так історично склалося". А можливо й ні. А тоді наведіть аргументи проти. Але ґрунтовні. А тоді запропонуйте інший підхід. Так само з ґрунтовними аргументами "за". Якщо це дійсно варте уваги, то команда, як мінімум, це питання обговорить і якісь зерна сумніву вже впадуть до їхніх голів. А якщо це дійсно слушна пропозиція, то й візьме в практику.
Команда теж має бути відкрита до таких пропозицій. Не варто будувати робочі процеси за принципом "мій дід надвір ходив, то й ми будем". Якщо ви не хочете бути завалені "законодавчим спамом", визначте чіткі правила для таких випадків: який формат пропозала, яка аргументація, за і проти. І розглядайте не для галочки, а дійсно сприймайте це як потенційні покращення.
Ці поради я даю з власного досвіду. Коли я тільки прийшов до нинішньої компанії, мені надзвичайно не сподобався стиль написання коду. Однак цього разу замість відразу підіймати кіпіш, я під час одного з дзвінків запропонував внести пропозицію, промацав ґрунт, так би мовити. І коли команда погодилась, я засів за створення монументального документу, де детально розписав недоліки (на мій погляд) поточного стану справ та переваги (на мою думку) іншого підходу, зачепивши не просто сам код, а й, до прикладу, вплив на підходи в тестуванні.
Як наслідок, ми трошки ще пообговорювали цю ініціативу, внесли певні правки до документа, а потім команда почала потрошки вводити це все в практику. І от зараз я вже в іншій команді, а попередня пише код за моїми настановами. Що, звичайно, дуже приємно.
Тож, любі мої читачі, проявляйте ініціативу, коли маєте таке бажання. Навчіться аргументовано викладати свою думку, і тоді побачите, як зміниться ставлення до неї з "господи, ну шо тобі знову не так" на "а це інтересна пропозиція".
А відповідальним за прийняття рішень скажу наступне: давайте право голосу новачкам в команді, будь то джуни чи синьйори, неважливо. Не сприймайте в штики ініціативність, дуже ймовірно, що в цьому є певна істина. Головне її побачити, а не закриватися і досі бігати за мамонтом з камʼяною сокирою в епоху штучного інтелекту. Як мінімум тому, що мамонти вимерли давно, почнім бігати за кимось іншим хоча б.
@babichdev
В команді зʼявляється новий колега, дивиться на процеси, код, підходи і каже що це все лайно собаче, а робити треба так, як скаже він, інакше щастя більше не буде. Знайомо? Точно знайомо. Бо якщо це не був новий колега в команді, то, швидше за все, це були саме ви.
Це нормально. Нам краще в комфортних умовах, і для нової людини комфортні умови це саме ті, в яких вона працювала раніше. І абсолютно природнім для неї буде спробувати відтворити ці умови на новому місці, аби мінімізувати стрес від переходу, від адаптації до нових порядків. Бо якщо натомість завести свої порядки, то й адаптуватися не треба.
Але те, що це нормальна поведінка людини в таких ситуаціях, не означає, що вона правильна. Радше навіть шкідлива. Тому давайте поміркуємо, як можна цього уникнути.
По-перше, в команді має бути нормальний онбординг. Я не говорю зараз про те, коли вам видають ноутбук, пароль до корпоративної пошти і роблять один дзвінок з HR на пів години на тему "шо ти голова".
Я говорю про командний онбординг, під час якого людина якраз має адаптуватися до процесів. Коли вона знайомиться з кодовою базою, з процесами код ревʼю, з загальними підходами до розробки і стилю коду. І в цій ситуації дуже помічним буде мати це все в задокументованому вигляді. Складно ламати те, що викарбувано в слові, а з іншої сторони — якщо воно зафіксовано "на папері", а не на чесному слові, то з тим і знайомитись легше, і дотримуватись.
По-друге, ніхто не забороняє вам вносити пропозиції. Саме так — вносити пропозиції. Не вриватися з бойовим криком "Міша, всьо хуйня, по новой давай!", а аргументовано запропонувати зміни. Так, я знаю, це набагато складніше, ніж плодити купу ПР, які розходяться з командними правилами бо "мені так зручніше". Ну і це не так захопливо, як сваритися на дейліках з тімлідом, визнаю.
Якщо вам не подобається якийсь аспект, розберіться в питанні. Можливо, є причини окрім "так історично склалося". А можливо й ні. А тоді наведіть аргументи проти. Але ґрунтовні. А тоді запропонуйте інший підхід. Так само з ґрунтовними аргументами "за". Якщо це дійсно варте уваги, то команда, як мінімум, це питання обговорить і якісь зерна сумніву вже впадуть до їхніх голів. А якщо це дійсно слушна пропозиція, то й візьме в практику.
Команда теж має бути відкрита до таких пропозицій. Не варто будувати робочі процеси за принципом "мій дід надвір ходив, то й ми будем". Якщо ви не хочете бути завалені "законодавчим спамом", визначте чіткі правила для таких випадків: який формат пропозала, яка аргументація, за і проти. І розглядайте не для галочки, а дійсно сприймайте це як потенційні покращення.
Ці поради я даю з власного досвіду. Коли я тільки прийшов до нинішньої компанії, мені надзвичайно не сподобався стиль написання коду. Однак цього разу замість відразу підіймати кіпіш, я під час одного з дзвінків запропонував внести пропозицію, промацав ґрунт, так би мовити. І коли команда погодилась, я засів за створення монументального документу, де детально розписав недоліки (на мій погляд) поточного стану справ та переваги (на мою думку) іншого підходу, зачепивши не просто сам код, а й, до прикладу, вплив на підходи в тестуванні.
Як наслідок, ми трошки ще пообговорювали цю ініціативу, внесли певні правки до документа, а потім команда почала потрошки вводити це все в практику. І от зараз я вже в іншій команді, а попередня пише код за моїми настановами. Що, звичайно, дуже приємно.
Тож, любі мої читачі, проявляйте ініціативу, коли маєте таке бажання. Навчіться аргументовано викладати свою думку, і тоді побачите, як зміниться ставлення до неї з "господи, ну шо тобі знову не так" на "а це інтересна пропозиція".
А відповідальним за прийняття рішень скажу наступне: давайте право голосу новачкам в команді, будь то джуни чи синьйори, неважливо. Не сприймайте в штики ініціативність, дуже ймовірно, що в цьому є певна істина. Головне її побачити, а не закриватися і досі бігати за мамонтом з камʼяною сокирою в епоху штучного інтелекту. Як мінімум тому, що мамонти вимерли давно, почнім бігати за кимось іншим хоча б.
@babichdev
❤56🔥16
Товариство, все забуваю нагадати, що при каналі діє чат, в якому можна розводити срачики, не чекаючи на новий допис.
Це той самий чат, в якому ви коменти лишаєте, якшо шо.
@babichdevchat
Долучайтеся.
Це той самий чат, в якому ви коменти лишаєте, якшо шо.
@babichdevchat
Долучайтеся.
🔥3
Співбесіда з трейні наживо вже за кілька хвилин!
Готуйте пиво, чай, чи що кому до смаку і гайда до перегляду!
https://youtube.com/live/nRf43EVT2Ow
Готуйте пиво, чай, чи що кому до смаку і гайда до перегляду!
https://youtube.com/live/nRf43EVT2Ow
Youtube
- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
🔥28❤6
Що ж, за підсумками учорашньої співбесіди було прийнято рішення зробити рубрику "Бабіч знов спозоривсь на ютубі" регулярною, і вже в понеділок чекайте на детальний розбір теми "Приведення типів та оператор + в JavaScript "
❤54👏8🔥4🤔1
Багатогранний плюс.
Що ж, як і обіцяв, рубрика "Бабіч спозоривсь на ютубі" продовжується, і сьогодні ми поглянемо до простого на перший погляд оператора +. Чому на перший погляд? Бо якщо копнути глибше, виявиться, що там не все так однозначно.
Коли ми використовуємо
Однак цікаві досліди починаються, коли ми спробуємо змішати у виразі числові і нечислові значення, або ж пододавати між собою не числа. Відразу на думку спаде "додавання" рядочків. Тільки, насправді, це не додавання, а операція конкатенації — злиття послідовних рядків в один.
І тоді оператор
І ось ми підійшли до моменту, в якому я заплутався на етері. Річ у тому, що коли у виразі хоча б один операнд є рядком, другий операнд буде примусово приведено до рядка. У мене ж в голові звідкись сплило, що порядок операндів може вплинути на поведінку оператора. Насправді це не відповідає дійсності, і на поведінку операторів вплинуть лише типи операндів.
Хоча є один трюк, який може призвести до такого хибного висновку. Увівши в консолі наступні вирази, ми отримаємо такі результати:
Виглядає цілком переконливо. Але є нюанс.
Якщо ж ви цей же вираз присвоїте змінній, усе встане на свої місця:
Поки ви геть не заплутались, хто кому куди плюсує, втуліть вподобайку цьому допису, не зволікайте
А що це за вираз такий
Я ж просто познайомлю вас з цим дивовижним явищем. Отже, перше поверхневе припущення може звучати так: "Рядок може бути приведеним до числа, якщо він містить лише цифри, ʼ+ʼ, ʼ-ʼ і десятковий роздільник, та не містить літер". Логічно.
Але, насправді, ми можемо привести до числа рядки, що містять літери! Не усі, правда — лише визначені, і лише якщо вони знаходяться на певних позиціях. Бо тоді ми дивимось не просто на рядок, а на запис числа в певній нотації:
Глибше в ці нотації я також занурюватись не буду, залишу це задоволення вам для самостійного опанування.
Ви помітили, що при початку пояснення унарного плюса я в прикладі написав пробіл після плюса, а потім вже ні? Так от, обидва записи рівноцінні: "+ 1" і "+1".
І саме цю особливість використовують в іншому прикладі "сМіШнОгО jS", створюючи банан з допомогою барана:
Причина криється саме в поведінці оператора +, а саме в цьому фрагменті:
Вираз тепер набуде виду
Ну і хто тепер баpнан, ненависники JavaScript, га?
Товариство, а ви як, дивуєтесь плюсу, чи знаєте усі його нюанси назубок? ;)
@babichdev
Що ж, як і обіцяв, рубрика "Бабіч спозоривсь на ютубі" продовжується, і сьогодні ми поглянемо до простого на перший погляд оператора +. Чому на перший погляд? Бо якщо копнути глибше, виявиться, що там не все так однозначно.
Коли ми використовуємо
+ з числовими типами, він поводиться рівно так, як ми й очікуємо ще зі школи — додає два значення, продукує суму. Є, щоправда, маленький нюанс з BigInt, той занадто гордий, аби товаришувати з іншими типами і займається арифметикою лише з іншими BigInt.Однак цікаві досліди починаються, коли ми спробуємо змішати у виразі числові і нечислові значення, або ж пододавати між собою не числа. Відразу на думку спаде "додавання" рядочків. Тільки, насправді, це не додавання, а операція конкатенації — злиття послідовних рядків в один.
І тоді оператор
+, не змінюючи вигляду, змінює роль — він перетворюється з оператора арифметичного додавання на оператор конкатенації.І ось ми підійшли до моменту, в якому я заплутався на етері. Річ у тому, що коли у виразі хоча б один операнд є рядком, другий операнд буде примусово приведено до рядка. У мене ж в голові звідкись сплило, що порядок операндів може вплинути на поведінку оператора. Насправді це не відповідає дійсності, і на поведінку операторів вплинуть лише типи операндів.
Хоча є один трюк, який може призвести до такого хибного висновку. Увівши в консолі наступні вирази, ми отримаємо такі результати:
{} + 1 // 1
1 + {} // 1[object Object]Виглядає цілком переконливо. Але є нюанс.
{} на першому рядочку не сприймається інтерпретатором як літерал обʼєкта. Знаходячись на початку рядка, {} сприймається як пустий блок коду. І в цьому випадку вираз перетворюється на + 1, що й дає в результаті одиницю.Якщо ж ви цей же вираз присвоїте змінній, усе встане на свої місця:
let x = {} + 1 // [object Object]1А що це за вираз такий
+ 1, і чому він валідний? Все просто — в такому записі оператор + робить ще одне перевтілення, і стає унарним плюсом. В такій іпостасі оператор намагається перетворити операнд на число. З перемінним успіхом, звичайно, якщо ваш рядок не є репрезентацією числа. І тут би пасувало глибше розібратися, що таке ця "репрезентація числа", але мені б хотілося, аби для вас це зробили більш глибоко обізнані в цій темі люди. Я ж просто познайомлю вас з цим дивовижним явищем. Отже, перше поверхневе припущення може звучати так: "Рядок може бути приведеним до числа, якщо він містить лише цифри, ʼ+ʼ, ʼ-ʼ і десятковий роздільник, та не містить літер". Логічно.
+"1000" // 1000
+"43.5" // 43.5
Але, насправді, ми можемо привести до числа рядки, що містять літери! Не усі, правда — лише визначені, і лише якщо вони знаходяться на певних позиціях. Бо тоді ми дивимось не просто на рядок, а на запис числа в певній нотації:
+"0x10" // Шістандцяткове 16
+"0b1010"; // Двійкове 10
+"0o16" // Вісімкове 14
+"10e2" // Науковий запис 1_000
// але
+"1n" // NaN, хоча 1n це BigInt
Глибше в ці нотації я також занурюватись не буду, залишу це задоволення вам для самостійного опанування.
Ви помітили, що при початку пояснення унарного плюса я в прикладі написав пробіл після плюса, а потім вже ні? Так от, обидва записи рівноцінні: "+ 1" і "+1".
І саме цю особливість використовують в іншому прикладі "сМіШнОгО jS", створюючи банан з допомогою барана:
("b" + "a" + + "a" + "a").toLowerCase()
> "banana"Причина криється саме в поведінці оператора +, а саме в цьому фрагменті:
+ + "a". Хоч він і записується з пробілом, але обробляється ось так: + +"a", де вже унарний плюс спробує привести рядок "a" до числа, в чому зазнає невдачі і поверне той самий NaN.Вираз тепер набуде виду
"b" + "a" + "NaN" + "a" і спокійнісінько конкатенується в baNaNa, який потім майстерно приховають з .toLowerCase.Ну і хто тепер ба
Товариство, а ви як, дивуєтесь плюсу, чи знаєте усі його нюанси назубок? ;)
@babichdev
❤98🔥22👏9🤔2
#коштозбір
Товариство, яка ситуація з мавіком для 184 навчального центру — завтра ми вносимо заставу в 1 000$, і матимемо два тижні, аби дозібрати та внести ще 850$.
А тепер увага, чому цей мавік суперважливий.
Військовослужбовці будуть тренуватися з ним уникати скидів. Тобто це не для того, щоб одним оком побачити як це бути дронщиком, а для того, щоб навчитися реагувати на ворожі дрони зі скидом. Сподіваюся, ви розумієте усю важливість цього мавіка.
Тому я буду неймовірно та надзвичайно вдячний кожнісінькій гривні, яку ви задонатите. І що швидше ми закриємо цей збір, тим швидше врятуємо чиєсь життя.
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
Цьом вам у лобіка.
Товариство, яка ситуація з мавіком для 184 навчального центру — завтра ми вносимо заставу в 1 000$, і матимемо два тижні, аби дозібрати та внести ще 850$.
А тепер увага, чому цей мавік суперважливий.
Військовослужбовці будуть тренуватися з ним уникати скидів. Тобто це не для того, щоб одним оком побачити як це бути дронщиком, а для того, щоб навчитися реагувати на ворожі дрони зі скидом. Сподіваюся, ви розумієте усю важливість цього мавіка.
Тому я буду неймовірно та надзвичайно вдячний кожнісінькій гривні, яку ви задонатите. І що швидше ми закриємо цей збір, тим швидше врятуємо чиєсь життя.
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
Цьом вам у лобіка.
❤16
"…Я повільно додаю в DOM новий елемент. Потім ще один. І ще один. Мене вже не зупинити — один за одним нові вузли додаються, змушуючи DOM здригатися та щоразу перезапускати reflow на кожен дотик мого нескінченного циклу. "Досить!" — закричав би він, якби міг кричати, але натомість лише покірно раз за разом перебудовує layout, сповільнюючись усе сильніше, та врешті решт, досягнувши найвищої точки завантажености, просто зависає…"
Такий сценарій чудово б підійшов для еротичної новели, якби історії про інтим з програмними системами приваблювали широкого читача. Проте нас із вами цікавить протилежний розвиток подій, а саме — мінімізувати кількість взаємодій із DOM до фізично можливого мінімуму, бажано до нуля.
І в цій невдячній справі нам стане в нагоді
Так, DocumentFragment ініціює лише один цикл repaint/reflow незалежно від того, скільки вузлів та елементів в ньому зараз знаходиться.
Звичайно, це не означає, що бравзер однаково швидко опрацює вставку одного елемента і десяти тисяч елементів через фрагмент. Але вважайте, що саме reflow може суттєво вдарити по вашій швидкодії. І чим менше ми його ініціюємо, тим краще.
При вставці в DOM фрагмент поводиться як желатинова капсула — і розчиняється, коли бравзер "ковтає" її, випускаючи в реальне дерево лише свій вміст. В самому DOM фрагмент не представлено жодним чином.
Взагалі, DocumentFragment — це саме DOM Node, а не DOM Element. Це означає, що він має appendChild, querySelector, cloneNode, але не має innerHtml, classList, id, style. Іноді і я про це забуваю, марно намагаючись щось там учудити з innerHtml.
До речі, fragment.parentNode === null, бо він не є частиною DOM.
З цікавих особливостей також можна відмітити, що при вставці фрагменту в DOM його дочірні вузли переміщаються в реальне дерево, а не копіюються.
А взагалі ця поведінка притаманна саме методам append та appendChild, а не самому фрагменту.
Так, ну й властивість
Ще варто відмітити, що позаяк фрагмент не може бути частиною DOM, то поки вміст знаходиться в ньому, той не наслідує стилі документа. Такий елемент може мати лише явно присвоєні стилі, або через inline style, або через властивість style DOM-обʼєкта. Але тут є ще одне але. Якщо це стилі блочні — розміри, відступи, оце все, то вони не впливатимуть на елемент, і той же
Також фрагмент можна вставляти в інший фрагмент, і ніхто вам за це нічого не зробить. Тож можете бавитись в композицію і тут.
Взагалі, фрагмент надзвичайно зручно використовувати тоді, коли нам треба зробити багато маніпуляцій над DOM-вузлами. Наприклад, ви їх можете "висмикнути" з реального дерева, помістити у фрагмент, поробити усе, що вам треба: додати мільйон event listeners, позмінювати усі атрибути на світі, повпихувати в усі вузли новий контент, а потім просто одним махом вставити усе назад. І це вартуватиме вас лише одного циклу reflow.
🌐 MDN: DocumentFragment
🔥 Було цікаво? Тисніть вподобайку, поширюйте сей допис, а за це вам від мене величезна подяка і цьом у лобіка.
@babichdev
Такий сценарій чудово б підійшов для еротичної новели, якби історії про інтим з програмними системами приваблювали широкого читача. Проте нас із вами цікавить протилежний розвиток подій, а саме — мінімізувати кількість взаємодій із DOM до фізично можливого мінімуму, бажано до нуля.
І в цій невдячній справі нам стане в нагоді
DocumentFragment. Це такий собі віртуальний контейнер, який існує лише в памʼяті, що дозволяє проводити різні маніпуляції зі своїм вмістом за допомогою DOM API, а потім безболісно вставляти цей вміст в реальний DOM за одну ітерацію.Так, DocumentFragment ініціює лише один цикл repaint/reflow незалежно від того, скільки вузлів та елементів в ньому зараз знаходиться.
const fragment = document.createDocumentFragment();
// а хоч 10 000 юзерів
for (const user of users) {
const li = document.createElement('li');
li.textContent = user.name;
fragment.appendChild(li);
}
document
.querySelector('ul')
.appendChild(fragment);
Звичайно, це не означає, що бравзер однаково швидко опрацює вставку одного елемента і десяти тисяч елементів через фрагмент. Але вважайте, що саме reflow може суттєво вдарити по вашій швидкодії. І чим менше ми його ініціюємо, тим краще.
При вставці в DOM фрагмент поводиться як желатинова капсула — і розчиняється, коли бравзер "ковтає" її, випускаючи в реальне дерево лише свій вміст. В самому DOM фрагмент не представлено жодним чином.
Взагалі, DocumentFragment — це саме DOM Node, а не DOM Element. Це означає, що він має appendChild, querySelector, cloneNode, але не має innerHtml, classList, id, style. Іноді і я про це забуваю, марно намагаючись щось там учудити з innerHtml.
До речі, fragment.parentNode === null, бо він не є частиною DOM.
З цікавих особливостей також можна відмітити, що при вставці фрагменту в DOM його дочірні вузли переміщаються в реальне дерево, а не копіюються.
childNodes.length === 0 і робіть що хочете. Однак якщо ви використаєте cloneNode(true) на фрагменті, то отримаєте повноцінну копію без втрати вмісту цього фрагмента. Тож, якщо ви захочете вставити фрагмент в декілька місць, клонування — ваш вибір.А взагалі ця поведінка притаманна саме методам append та appendChild, а не самому фрагменту.
Так, ну й властивість
.content template-елемента вже є DocumentFragment, саме через це скрізь рекомендують спочатку склонувати його вміст, а потім уже з ним працювати. Інакше попсуєте оригінал.Ще варто відмітити, що позаяк фрагмент не може бути частиною DOM, то поки вміст знаходиться в ньому, той не наслідує стилі документа. Такий елемент може мати лише явно присвоєні стилі, або через inline style, або через властивість style DOM-обʼєкта. Але тут є ще одне але. Якщо це стилі блочні — розміри, відступи, оце все, то вони не впливатимуть на елемент, і той же
getBoundingClientRect поверне всі нулі. Причина проста — елемент не в реальному DOM, і не пройшов layout-фазу.Також фрагмент можна вставляти в інший фрагмент, і ніхто вам за це нічого не зробить. Тож можете бавитись в композицію і тут.
Взагалі, фрагмент надзвичайно зручно використовувати тоді, коли нам треба зробити багато маніпуляцій над DOM-вузлами. Наприклад, ви їх можете "висмикнути" з реального дерева, помістити у фрагмент, поробити усе, що вам треба: додати мільйон event listeners, позмінювати усі атрибути на світі, повпихувати в усі вузли новий контент, а потім просто одним махом вставити усе назад. І це вартуватиме вас лише одного циклу reflow.
@babichdev
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥89❤26
Товариство, знову завтра у Львові здибанка!
Приходьте від 19 години до пабу "Горобець", що за адресою Театральна 23, та й поспілкуємось!
Беріть з собою хороший настрій, друзів та колег.
До зустрічі!
https://news.1rj.ru/str/it_lampa/14
Приходьте від 19 години до пабу "Горобець", що за адресою Театральна 23, та й поспілкуємось!
Беріть з собою хороший настрій, друзів та колег.
До зустрічі!
https://news.1rj.ru/str/it_lampa/14
Telegram
ІТ спільнота ЛАМПА
Товариство, ну то якшо ви всі так нетерпляче чекаєте на зустріч, то хто ми такі, аби вам відмовляти в цьому задоволенні?
Приходьте цього четверга, 7 серпня, від 19 години до пабу "Горобець", що за адресою Театральна 23, поспілкуємось!
Беріть з собою хороший…
Приходьте цього четверга, 7 серпня, від 19 години до пабу "Горобець", що за адресою Театральна 23, поспілкуємось!
Беріть з собою хороший…
❤22
Пропоную наступний челендж:
1. Прочитати статтю: https://blog.logrocket.com/css-if-function-conditional-styling.
2. Охрініти.
3. Вихрінити.
4. Задонатити кілька гривень на Mavic для 184 навчального центру.
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
1. Прочитати статтю: https://blog.logrocket.com/css-if-function-conditional-styling.
2. Охрініти.
3. Вихрінити.
4. Задонатити кілька гривень на Mavic для 184 навчального центру.
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
LogRocket Blog
Should you use if() functions in CSS? - LogRocket Blog
It’s 2025, and CSS finally thinks logically. The if() function brings real conditional styling — no hacks, no JS workarounds. Here’s how to use it right.
🔥23❤1
#думки_вголос
Вчора на ламповій тусовці очікувано мова зайшла про вайбкодинг, якість коду і місце людей серед усього цього балагану.
І там прозвучала дуже цікава думка, що однією з проблем нинішньої ІТ-освіти є те, що людей не вчать читати код. Саме читати. Мені ця теза дуже сподобалась, тож вирішив трошки розвинути її.
Зараз код писати може будь-яка більш-менш нормальні модель. Однак саме писати. ШІ може згенерувати працюючий код, але не передбачить і не пояснить наслідки цього коду для проєкту. Він може пояснити як код працює, але як впливає — це вже на межі фантастики.
Вміння читати код, саме читати, а не пробігатися по назвах функцій і змінних — це, фактично, єдиний достовірний спосіб розуміння архітектури продукту. Створювати код нині це рідкісна розкіш, зазвичай ми входимо в уже написане.
Ба більше, не володіючи цією навичкою, ви втратите розуміння навіть своїх рішень. Недарма кажуть, що ваш код, написаний пів року тому, вже чужий код.
А тепер додайте сюди вайбкодинг. Невміння читати рішення ШІ, розуміти їх глибше ніж свої власні, призводить до того, що модель може підсовувати вам якісь геть чудернацькі рішення, які можна сприйняти на віру і протягнути в проєкт якусь відверту дичину. Ну бо воно ж схоже на щосб розумне, чому ні?
А потім будуть вилазити такі бока, що на переробку цих "рішень" витрачатиметься в рази більше часу, ніж на створення.
Вміти читати чужий код, розбиратися в ньому, відчувати й бачити можливі негативні й позитивні наслідки, стає, певно, важливішою навичкою, аніж власне його створювати.
Бо саме створювати його стає усе легше й легше, і через це може виникати ілюзія того, що ШІ "все робить за вас". Але є багато але, і результат залежить від багатьох чинників, до того ж величезна кількість цих чинників не те, що від вас не залежить, ви просто не в курсі їхнього існування.
Так, код створювати легше, а от контролювати його якість стає важче, якраз через оту ілюзію "якісних рішень від ШІ". Ми маємо ще ретельніше переглядати ці рішення. Ще прискіпливіше переглядати кожен рядок. Аналізувати. Передбачати.
Треба припинити бачити свою роль як кодогенератора. Натомість варто потихеньку (а може й швидше вже) качати свої компетенції в сторону "контролера коду". Розбиратися в архітектурі та патернах. Розуміти як і що працює, особливо під капотом. Так, навіть джунам.
Все змінюється, і суть розробки теж. Якщо ви хочете ефективно використовувати ШІ, то варто перестати йому довіряти, тим паче в питанні генерації коду. Ви маєте стати найдушнішими ревʼюверами коду на світі.
Вчіться читати чужий код. Не просто очима, а пропускати його через фільтри недовіри, сумнівів, скепсису та власної технічної і не тільки експертизи. І тоді ніякий ШІ нікого не замінить.
До речі, а ви що думаєте з цього приводу?
@babichdev
Вчора на ламповій тусовці очікувано мова зайшла про вайбкодинг, якість коду і місце людей серед усього цього балагану.
І там прозвучала дуже цікава думка, що однією з проблем нинішньої ІТ-освіти є те, що людей не вчать читати код. Саме читати. Мені ця теза дуже сподобалась, тож вирішив трошки розвинути її.
Зараз код писати може будь-яка більш-менш нормальні модель. Однак саме писати. ШІ може згенерувати працюючий код, але не передбачить і не пояснить наслідки цього коду для проєкту. Він може пояснити як код працює, але як впливає — це вже на межі фантастики.
Вміння читати код, саме читати, а не пробігатися по назвах функцій і змінних — це, фактично, єдиний достовірний спосіб розуміння архітектури продукту. Створювати код нині це рідкісна розкіш, зазвичай ми входимо в уже написане.
Ба більше, не володіючи цією навичкою, ви втратите розуміння навіть своїх рішень. Недарма кажуть, що ваш код, написаний пів року тому, вже чужий код.
А тепер додайте сюди вайбкодинг. Невміння читати рішення ШІ, розуміти їх глибше ніж свої власні, призводить до того, що модель може підсовувати вам якісь геть чудернацькі рішення, які можна сприйняти на віру і протягнути в проєкт якусь відверту дичину. Ну бо воно ж схоже на щосб розумне, чому ні?
А потім будуть вилазити такі бока, що на переробку цих "рішень" витрачатиметься в рази більше часу, ніж на створення.
Вміти читати чужий код, розбиратися в ньому, відчувати й бачити можливі негативні й позитивні наслідки, стає, певно, важливішою навичкою, аніж власне його створювати.
Бо саме створювати його стає усе легше й легше, і через це може виникати ілюзія того, що ШІ "все робить за вас". Але є багато але, і результат залежить від багатьох чинників, до того ж величезна кількість цих чинників не те, що від вас не залежить, ви просто не в курсі їхнього існування.
Так, код створювати легше, а от контролювати його якість стає важче, якраз через оту ілюзію "якісних рішень від ШІ". Ми маємо ще ретельніше переглядати ці рішення. Ще прискіпливіше переглядати кожен рядок. Аналізувати. Передбачати.
Треба припинити бачити свою роль як кодогенератора. Натомість варто потихеньку (а може й швидше вже) качати свої компетенції в сторону "контролера коду". Розбиратися в архітектурі та патернах. Розуміти як і що працює, особливо під капотом. Так, навіть джунам.
Все змінюється, і суть розробки теж. Якщо ви хочете ефективно використовувати ШІ, то варто перестати йому довіряти, тим паче в питанні генерації коду. Ви маєте стати найдушнішими ревʼюверами коду на світі.
Вчіться читати чужий код. Не просто очима, а пропускати його через фільтри недовіри, сумнівів, скепсису та власної технічної і не тільки експертизи. І тоді ніякий ШІ нікого не замінить.
До речі, а ви що думаєте з цього приводу?
@babichdev
❤78🔥13👏9
Товариство, вітаю вас з початком нового тижня, а себе — з початком відпустки.
Цим доводжу до вашого відома, що тематичних дописів цього тижня не буде, я відпочиваю, займаюсь здоров'ям, ходжу на риболовлю і святкую день народження. Наразі це всі плани на найближчі дні.
Хіба завтра ще заскочу, бо буде нагода, а так — наснаги вам, сил та натхнення на цей тиждень.
З прекрасним настроєм
Цьом вам у лобіка.
Ваш Бабіч.
Цим доводжу до вашого відома, що тематичних дописів цього тижня не буде, я відпочиваю, займаюсь здоров'ям, ходжу на риболовлю і святкую день народження. Наразі це всі плани на найближчі дні.
Хіба завтра ще заскочу, бо буде нагода, а так — наснаги вам, сил та натхнення на цей тиждень.
З прекрасним настроєм
Цьом вам у лобіка.
Ваш Бабіч.
❤89🔥9🤔2
З днем народження мене! Ну а шо, без мене цього каналу б не було )
Надзвичайно вдячний долі, що маю нагоду святкувати своє 38-річчя, та ще й в такій достойній компанії!
Неймовірно круто й водночас дивно усвідомлювати, де я зараз є, і як моє життя до цього привело, але мати поряд таку спільноту, як ви — це один з найкращих подарунків. Важливо розуміти, що те, що я роблю — не намарно, і приносить користь та задоволення не лише мені.
Тож дякую вам за вас, товариство, і прямую стрімголов в новий рік життя! Побачимо, на які здобутки він нас із вами надихне ;)
Якщо ж ви відчуваєте бажання привітати мене зі святом, ви можете зробити це донатом на Mavic 3 для 184 навчального центру. Можна 38 гривень, можна 12, можна 8, можна 1208, можна 1987, можна й 2025 ) Буду вдячний за кожну гривню!
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
Надзвичайно вдячний долі, що маю нагоду святкувати своє 38-річчя, та ще й в такій достойній компанії!
Неймовірно круто й водночас дивно усвідомлювати, де я зараз є, і як моє життя до цього привело, але мати поряд таку спільноту, як ви — це один з найкращих подарунків. Важливо розуміти, що те, що я роблю — не намарно, і приносить користь та задоволення не лише мені.
Тож дякую вам за вас, товариство, і прямую стрімголов в новий рік життя! Побачимо, на які здобутки він нас із вами надихне ;)
Якщо ж ви відчуваєте бажання привітати мене зі святом, ви можете зробити це донатом на Mavic 3 для 184 навчального центру. Можна 38 гривень, можна 12, можна 8, можна 1208, можна 1987, можна й 2025 ) Буду вдячний за кожну гривню!
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
❤118🔥29👏12
Колись дуже давно, коли я ще працював в офісі, в одній з компаній переговорні кімнати називалися географічними назвами. І серед них була "Аляска". Я тепер розумію чому, бо там також відбувалися аналогічні за важливістю, сенсом та змістовністю розмови.
😁85❤5🔥3
JavaScript це найкраща мова для веброзробки, а кому він не подобається — той [object Object]
@babichdev
@babichdev
😁152❤11🔥2👏2
Так, товариство, у мене до вас дуже серйозна розмова.
У мене є сценарій до відео. Він називається "5 помилок на співбесіді, що можуть вартувати тобі офера". І у мене є величезне бажання його записать. Але майже нульова внутрішня батарейка.
Бо щоразу, як подумаю, шо його ж ото треба взять, записать, змонтувать, оце все, то у мене зразу пече в спині і начинає боліть голова.
Тому давайте так: з вас до ранку більше ста вогників, а я завтра ж сідаю і записую.
Домовились?
У мене є сценарій до відео. Він називається "5 помилок на співбесіді, що можуть вартувати тобі офера". І у мене є величезне бажання його записать. Але майже нульова внутрішня батарейка.
Бо щоразу, як подумаю, шо його ж ото треба взять, записать, змонтувать, оце все, то у мене зразу пече в спині і начинає боліть голова.
Тому давайте так: з вас до ранку більше ста вогників, а я завтра ж сідаю і записую.
Домовились?
🔥330❤3
16 серпня 1995 року, рівно 30 років тому, світ побачила перша версія бравзера, що докорінно змінить світ веброзробки, стане домінуючим на роки, а згодом впаде в стагнацію, стане посміховиськом і зрештою порине в забуття. Але внесок його у розвиток вебу назавжди залишиться визначним та таким, що сформує світ Всесвітньої павутини на багато років.
Мова про Internet Explorer. Так, так, той самий IE, про який багато з вас знає лише з жартів про "бравзер для скачування Chrome". Але колись він міцною хваткою тримав ринок.
Саме в IE3.0 зʼявилася повноцінна (на той час) підтримка CSS, без якого сучасна веброзробка навіть не уявляється. І саме завдяки IE ця технологія набула такого поширення та популярности.
До речі, тривалий час саме IE був "тим самим" бравзером для MacOS, про що я вже свого часу писав. Ну й годі казати, що для мільйонів користувачів Microsoft Windows він був єдиним бравзером. Не через те, що інших не було, а через надзвичайно вдале рішення — інтегрувати його в систему. Навіщо тобі щось інше, коли віконце у дивовижний світ Всесвітньої Павутини вже тут, ось, працює, і майже весь Інтернет "найкраще працює в IE"?
Беззаперечний переможець Перших Бравзерних Воєн, він спочивав на лаврах, однак час не стояв на місці, і доволі швидко учорашній переможець, що тріумфально витіснив Netscape Navigator, опинився в ролі аутсайдера.
Не тому, що був поганим бравзером, а через спірні й, на сьогоднішній погляд, відверто безглузді рішення керівництва, що, будучи впевненим в повному домінуванні, заморозило розробку на довгі роки.
А коли стало зрозуміло, що відставання вже занадто критичне, було вже пізно. На ринку зʼявилися нові гравці, молоді, зухвалі, що не боялися експериментувати, швидкі, рішучі. І корпоративна машина виявилася просто не в змозі наздогнати цей потяг.
Однак не варто забувати і його здобутки. Без XHR та innerHTML ми б не мали динамічних сторінок та AJAX, що стали підґрунтям для буму SPA. Без ContentEditable ми б не отримали Google Docs та Notion. Та й перша робоча імплементація CSS Grid зʼявилася теж в IE, а саме в IE10.
Однак, попри стрімке падіння на ринку популярних бравзерів, IE продовжував своє життя, хоч і без розвитку на мільйонах корпоративних компʼютерів, ба більше, неймовірна кількість спеціалізованого софту, наприклад банківського, була написана в повній інтеграції з тим же ІЕ6 через інтеграцію з ActiveX.
Офіційною датою смерті ІЕ вважається 15 червня 2022 року, коли Microsoft припинила підтримку IE11.
І хай там як, цей бравзер заслужив своє місце у залі слави Інтернет. Хтось памʼятає його як першого провідника до світу вебу, хтось як нестерпний біль, на який треба було постійно зважати та підтримувати в буремні 2010-і, хтось — як бравзер, завдяки якому доступ до інтернету став відкрився для мільйонів та мільйонів користувачів.
А хтось дивитиметься глибше і розумітиме, що без нього сучасна веброзробка була б геть зовсім іншим явищем. Кращим? Гіршим? Нам того не знати. Але подякувати Internet Explorer усе-таки варто. Бо і його здобутки, і його помилки крок за кроком, цеглинка за цеглинкою збудували для нас цей дивовижний світ веброзробки.
@babichdev
Мова про Internet Explorer. Так, так, той самий IE, про який багато з вас знає лише з жартів про "бравзер для скачування Chrome". Але колись він міцною хваткою тримав ринок.
Саме в IE3.0 зʼявилася повноцінна (на той час) підтримка CSS, без якого сучасна веброзробка навіть не уявляється. І саме завдяки IE ця технологія набула такого поширення та популярности.
До речі, тривалий час саме IE був "тим самим" бравзером для MacOS, про що я вже свого часу писав. Ну й годі казати, що для мільйонів користувачів Microsoft Windows він був єдиним бравзером. Не через те, що інших не було, а через надзвичайно вдале рішення — інтегрувати його в систему. Навіщо тобі щось інше, коли віконце у дивовижний світ Всесвітньої Павутини вже тут, ось, працює, і майже весь Інтернет "найкраще працює в IE"?
Беззаперечний переможець Перших Бравзерних Воєн, він спочивав на лаврах, однак час не стояв на місці, і доволі швидко учорашній переможець, що тріумфально витіснив Netscape Navigator, опинився в ролі аутсайдера.
Не тому, що був поганим бравзером, а через спірні й, на сьогоднішній погляд, відверто безглузді рішення керівництва, що, будучи впевненим в повному домінуванні, заморозило розробку на довгі роки.
А коли стало зрозуміло, що відставання вже занадто критичне, було вже пізно. На ринку зʼявилися нові гравці, молоді, зухвалі, що не боялися експериментувати, швидкі, рішучі. І корпоративна машина виявилася просто не в змозі наздогнати цей потяг.
Однак не варто забувати і його здобутки. Без XHR та innerHTML ми б не мали динамічних сторінок та AJAX, що стали підґрунтям для буму SPA. Без ContentEditable ми б не отримали Google Docs та Notion. Та й перша робоча імплементація CSS Grid зʼявилася теж в IE, а саме в IE10.
Однак, попри стрімке падіння на ринку популярних бравзерів, IE продовжував своє життя, хоч і без розвитку на мільйонах корпоративних компʼютерів, ба більше, неймовірна кількість спеціалізованого софту, наприклад банківського, була написана в повній інтеграції з тим же ІЕ6 через інтеграцію з ActiveX.
Офіційною датою смерті ІЕ вважається 15 червня 2022 року, коли Microsoft припинила підтримку IE11.
І хай там як, цей бравзер заслужив своє місце у залі слави Інтернет. Хтось памʼятає його як першого провідника до світу вебу, хтось як нестерпний біль, на який треба було постійно зважати та підтримувати в буремні 2010-і, хтось — як бравзер, завдяки якому доступ до інтернету став відкрився для мільйонів та мільйонів користувачів.
А хтось дивитиметься глибше і розумітиме, що без нього сучасна веброзробка була б геть зовсім іншим явищем. Кращим? Гіршим? Нам того не знати. Але подякувати Internet Explorer усе-таки варто. Бо і його здобутки, і його помилки крок за кроком, цеглинка за цеглинкою збудували для нас цей дивовижний світ веброзробки.
@babichdev
🔥65❤28
Товариство, маленьке оголошення!
26 серпня я буду в Києві, в якості запрошеної абізянки на IT StandUp: Fails Night — благодійному вечорі, організованому компанією Brainstack, де відверто і з дуже серйозними писками поговоримо про те, що пішло не за планом.
Будем ділитися там своїми шляпами і провтиками, а ще буде відкритий мікрофон, тому ви теж матимете нагоду ще разочок опозоритись з вашим факапом.
В програмі:
• Жонглери!
• Цікаві факап-історії!
• Фокусники!
• Професійний нетворк та знайомства!
• Стрептиз!
• Аукціон та чаріті-лотерея!
• Донати — на підтримку збору «Мережа Трійки» від DOU!
26 серпня, 18:00
Kooperativ Rooftop
Квитки — за донат
https://eventmate.app/events/share/it-standup-failsnight
До зустрічі!
26 серпня я буду в Києві, в якості запрошеної абізянки на IT StandUp: Fails Night — благодійному вечорі, організованому компанією Brainstack, де відверто і з дуже серйозними писками поговоримо про те, що пішло не за планом.
Будем ділитися там своїми шляпами і провтиками, а ще буде відкритий мікрофон, тому ви теж матимете нагоду ще разочок опозоритись з вашим факапом.
В програмі:
26 серпня, 18:00
Kooperativ Rooftop
Квитки — за донат
https://eventmate.app/events/share/it-standup-failsnight
До зустрічі!
❤19🔥7👏3
Хто з нас може сходу відповісти що таке каскадність в CSS? Мало хто. Ба більше, я впевнений, що більшість не розрізняє поняття CSS та стилів. Але не переживайте, я сьогодні не буду вас за це соромити, бо й сам тривалий час не приділяв цьому відповідної уваги. Натомість давайте краще разом в цьому розберемось.
В першу чергу варто зафіксувати, що Україна не Росія, а CSS не стилі. А інструмент для структурованого їх опису. Стилі ж — це безпосередньо правила, які застосовуються до елементів. Тобто CSS це те, що ми пишемо, стилі — те, що бравзер мастить на DOM.
CSS це не лише мова, а й певні концепції, і найголовніша з яких, про яку усі чомусь забувають — це, власне, каскадність. Якщо коротко, то каскадність — це правила, за якими визначається пріоритетність застосування стилів до елемента, і враховує вона не лише специфічність.
Найперше, що береться до уваги — походження. Бравзери розрізняють три головні джерела стилів: вбудовані бравзерні, користувацькі та авторські.
З вбудованими все ясно — це стилі за замовчуванням, які вшиті в сам бравзер. Користувацькі — це налаштування, задані користувачем через бравзер, або через плагіни, наприклад, для покращення доступності. Ну а авторські стилі пишуть, власне, розробники сайтів.
І найперше каскад бере до уваги саме походження: спершу бравзерні стилі, далі користувацькі, і наприкінець авторські.
До речі, чому саме каскад? Якщо уявити собі цю схему як водоспадик, то виглядатиме вона так:
І в такій ієрархії пріоритет надається стилям, що знаходяться нижче за каскадом. Така собі спадна ієрархія.
Добре, з походженням розібрались. Далі йде специфічність селектора. Вона працює тільки всередині одного походження, тож більш специфічне правило нижчого походження програє менш специфічному вищого походження. Як у житті.
І вже аж потім, якщо раптом у нас є декілька декларацій з однаковою специфічністю, використовується правило "хто останній, той ітато молодець". Тобто яка декларація описана пізніше в коді, та й виграє боротьбу за правило стилю.
Якщо ви досі не поставили вогник і не поширили цей допис, знайте — я на вас образився.
А чого ж я вжив вираз "класична модель"? Бо тепер у нас є ще один нюанс, на який треба звертати увагу, і це надзвичайно потужний інструмент для керування каскадом саме нами, розробниками.
Мова йде про
В цьому випадку текст
Таким чином можна дуже тонко налаштовувати каскадність, не переживаючи за те, що треба буде перебивати специфічність якогось селектора вручну, достатньо просто правильно організувати порядок цих шарів.
Я особливо оцінив цей підхід у дизайн-системах: стилі легко розбивати на логічні групи — tokens, base, typography, components, overrides. І завжди зрозуміло, в якому порядку вони застосуються, без страху, що десь у глибині з’явиться монстр-селектор на десяток класів і ID, згенерований JavaScript, і доведеться з ним воювати.
***
Специфікації W3C
CSS Cascading and Inheritance Level 4 — Cascading Order
CSS Cascading and Inheritance Level 5 — Cascade Layers
Документація MDN
Cascade and inheritance
Cascade layers
Статті людською мовою
Getting Started With CSS Cascade Layers
CSS Cascade Layers
***
А ви як, пробували вже, використовували? Чи чуєте вперше, і вже не можете дочекатися, аби запушити це в прод? Розказуйте.
@babichdev
В першу чергу варто зафіксувати, що Україна не Росія, а CSS не стилі. А інструмент для структурованого їх опису. Стилі ж — це безпосередньо правила, які застосовуються до елементів. Тобто CSS це те, що ми пишемо, стилі — те, що бравзер мастить на DOM.
CSS це не лише мова, а й певні концепції, і найголовніша з яких, про яку усі чомусь забувають — це, власне, каскадність. Якщо коротко, то каскадність — це правила, за якими визначається пріоритетність застосування стилів до елемента, і враховує вона не лише специфічність.
Найперше, що береться до уваги — походження. Бравзери розрізняють три головні джерела стилів: вбудовані бравзерні, користувацькі та авторські.
З вбудованими все ясно — це стилі за замовчуванням, які вшиті в сам бравзер. Користувацькі — це налаштування, задані користувачем через бравзер, або через плагіни, наприклад, для покращення доступності. Ну а авторські стилі пишуть, власне, розробники сайтів.
І найперше каскад бере до уваги саме походження: спершу бравзерні стилі, далі користувацькі, і наприкінець авторські.
До речі, чому саме каскад? Якщо уявити собі цю схему як водоспадик, то виглядатиме вона так:
[user-agent styles]
↳[user styles]
↳[author styles]
І в такій ієрархії пріоритет надається стилям, що знаходяться нижче за каскадом. Така собі спадна ієрархія.
Дуже важлива ремарка: це класична модель без !important. З ним user styles важливіші за author styles. Але я це не розглядаю детальніше, бо за !important треба звільняти з доганою і відбирати назавжди ліцензію на написання CSS.
Добре, з походженням розібрались. Далі йде специфічність селектора. Вона працює тільки всередині одного походження, тож більш специфічне правило нижчого походження програє менш специфічному вищого походження. Як у житті.
І вже аж потім, якщо раптом у нас є декілька декларацій з однаковою специфічністю, використовується правило "хто останній, той і
А чого ж я вжив вираз "класична модель"? Бо тепер у нас є ще один нюанс, на який треба звертати увагу, і це надзвичайно потужний інструмент для керування каскадом саме нами, розробниками.
Мова йде про
@layer. По суті, це ще один рівень в межах origin, який дозволяє нам точніше групувати визначення і, що найголовніше, керувати порядком застосування цих груп. Що важливо, специфічність в шарах також ізольована, тому важкий селектор з одного шару може бути дуже легко перебитий легеньким селектором з іншого:@layer base, override;
@layer override {
p { color: red; }
}
@layer base {
#foo { color: lime; }
}
В цьому випадку текст
<p id="foo">hello</p> буде не зелений, а червоний, хоча, як ми знаємо, id набагато важчий за селектор тега.Таким чином можна дуже тонко налаштовувати каскадність, не переживаючи за те, що треба буде перебивати специфічність якогось селектора вручну, достатньо просто правильно організувати порядок цих шарів.
Я особливо оцінив цей підхід у дизайн-системах: стилі легко розбивати на логічні групи — tokens, base, typography, components, overrides. І завжди зрозуміло, в якому порядку вони застосуються, без страху, що десь у глибині з’явиться монстр-селектор на десяток класів і ID, згенерований JavaScript, і доведеться з ним воювати.
***
Специфікації W3C
CSS Cascading and Inheritance Level 4 — Cascading Order
CSS Cascading and Inheritance Level 5 — Cascade Layers
Документація MDN
Cascade and inheritance
Cascade layers
Статті людською мовою
Getting Started With CSS Cascade Layers
CSS Cascade Layers
***
А ви як, пробували вже, використовували? Чи чуєте вперше, і вже не можете дочекатися, аби запушити це в прод? Розказуйте.
@babichdev
🔥121❤16👍1😁1🤔1
Так, товариство, якщо б хто хотів зустрітися наживо у Львові, то сьогодні від 19 години буду в пабі "Горобець", що за адресою Театральна 23.
Там буде чергова лампова тусовка, тож підходьте, буду радий бачити!
Там буде чергова лампова тусовка, тож підходьте, буду радий бачити!
❤28🔥4🤔2