Вхід і реєстрація
Розробка · 30 жовтня 2023, 15:00 2643
Olexander Smolianinov, frontend director в ZFORT Group

Front-end Digest № 19: AI для веброзробників, CSS @scope може замінити BEM та State of React 2023

Усі статті, обговорення, новини про Front-end — в одному місці. Підписуйтеся на телеграм-канал!

Привіт, колеги. Мене звати Олександр, я займаюся фронтендом в компанії Zfort Group. Маю для вас черговий дайджест з цікавими матеріалами зі світу фронтенда за останній тиждень.

Веброзробка

• Про що думають розробники?
• На дворі 2023 рік, і ось чому ваш вебдизайн — відстій.
• AI для веброзробників: Швидші відповіді з HTTP Streaming
• Граємося з Gamepad API
• JSON неймовірно повільний: ось що швидше!

CSS

• Tailwind CSS vs. Semantic CSS
• Як CSS @scope може замінити BEM
• CSS text-wrap: pretty
• Розв’язано за допомогою CSS Scroll-Driven Animations: стилізуємо елементи на основі активного напрямку прокручування та швидкості прокручування
• CSS prefers-reduced-transparency
• 20 простих способів стилізації HTML-елемента details

JavaScript

• Що скаже нам про JavaScript видалення властивостей об’єкта
• instant.dev — Швидко створюйте API за допомогою JavaScript та Postgres.
• Вебкомпоненти переживуть ваш JavaScript-фреймворк
• Чому я не буду використовувати Next.js
• 17 поширених помилок Node.js та способи їх вирішення
• Вибір найкращого алгоритму сортування на JavaScript для вашого проєкту

Теми: AI, CSS, Front-end, front-end digest, JavaScript, react, tech, Web, web development
👍ПодобаєтьсяСподобалось6
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Alexander M 01.11.2023 21:12

Нарешті нормальна стаття, яка пояснює проблеми Tailwind. Тепер мені не треба витрачати купу часу на пояснення очевидних речей. Дякую.

Також дякую за посилання на статтю про проблеми Next. У нього є своя ніша, але оця любов тягнути його всюди де можна лякає. Особливо, коли бізнесу не потрібен SSR і взагалі він не про блоги та інтернет магазини.

А щодо BEM, то давно вже треба було перейти на SUIT ;)

Відповісти
Підтримати
Ihor Zenich CSS engineer в EPAM 08.11.2023 20:05

MCSS, ECSS, SUIT, AMCSS, OPOR, BEViS, BEMIT... та щє до біса «нових фреймворків» — це просто діалекти, а фактично — конкретні реалізації BEM.
Те саме як казати «ми тут придумали новий аджайл».

Причина їх появи — те, що по BEM с 2007 по 2014 так і не було написано нормальної документації і в результаті той BEM, який ми зараз використовуємо, був переформульований і популяризований взагалі людиною з Великобританії.

Відповісти
Підтримати
Alexander M
Alexander M 11.11.2023 20:05

Так, але що ви хотіли сказати своїм коментарем?

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 13.11.2023 10:03

те що SMACSS, BEM, SUIT і так далі — це одне і теж.

Відповісти
Підтримати
Alexander M
Alexander M 14.11.2023 22:35

Якщо розглядати ці конвеншони з точки зору, що всі вони конвеншони, то так, це одне і теж саме. Але насправді, це різні речі. Особливо, SMACSS, який ще й кодову структуру охоплює. Єдине, про що можна було б посперечатись — різниця між BEM і SUIT, особливо згадуючи те, що автор SUIT узяв за основу BEM.

Але щось мені підказує, що ви своїм коментарем хотіли сказати щось інше.

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 15.11.2023 14:23

Сам автор SMACSS вважає, що SMACSS і BEM — це одне і теж:
— twitter.com/...​RqGlccujogLF1t-_-ixA&s=19
— twitter.com/...​QPM8NremLNgHFvGp5oJg&s=19

І використовує BEM замість свого ж SMACSS у своїй роботі:
twitter.com/...​oiTPRTdtZ-jqHRKSvOJQ&s=19

Відповісти
Підтримати
Alexander M
Alexander M 15.11.2023 20:29

Таке враження, що ви намагаєтесь вмовити мене перейти на BEM, або виправдати свій вибір на користь BEM. І дієте як російська пропаганда, закидаючи різними посиланнями, висловлюваннями, які не дуже то й до теми.

Тож давайте розберемо ваші посилання:
1. Автор пише, що SMACSS здебільшого це BEM, а не те саме. І якщо відкрити документацію (ви ж її читали, так?), то стає зрозумілим, що лише Module rules і State rules конвеншона виконують туж саму роль, що й BEM. Не краще, але так. А інші частини конвеншона виконують ту роботу, яка не всім потрібна й тут ми переходимо до третього вашого посилання.
2. Це взагалі якась іронія, яка не має ніякого відношення до теми.
3. Команда Shopify переходить на BEM, що може бути результатом певних архітектурних рішень проєкту. І це абсолютно зрозуміла річ, бо SMACSS не кожному проєкту підходить.

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

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 15.11.2023 23:36

6 років тому я навіть зробив з другом проект, де можна порівняти всі популярні на той момент css-методології «in action», на прикладі верстки примітивного holy-gray-layout сайту. Подивіться, так легше обговорювати різницю: github.com/...​shaOleg/holy-grail-markup

Я не переконую вас ні на що переходити, вас навіть слова автора SMACSS не переконують😅

У порівнянні конвеншенів, якщо цікаво:
— smacss layout == layout-блоки в ранньому bem, 2007 рік, тоді він називався «Незалежні блоки», блоки ділилися на прості та складові, навіть префікс був той самий: l-layout, ще був h-holder. Нагадаю, що SMACSS з’явиться лише через 5 років у 2011 році незалежно, що нормально, люди приходять до одного і того ж і навіть йдуть одним і тим же шляхом, по суті SMACSS = BEM 2007 року.
— smacss module == це і є «прості блоки»,
— smacss state == модифікатори та глобальні модифікатори (g-блоки в раньому bem).
— smacss theme == рівні перевизначення у bem.

Ну і так далі йдемо по доку та бачимо як перевинаходили ті самі ідеї, по розділах:
— Depth of Applicability — елементи,
— Selector Performance — абсолютно незалежні блоки,
— HTML5 and SMACSS — модифікація від контексту,
— Drop the Base — відсутність глобальних стилів (поза блоками) і так далі і так далі...

Як казав класік: «це ж було вже».

Я чому написав ці коменти вам, бо щє років 10 назад я все це бачив, передивився безліч імпементацій, спілкувався з авторами багатьох з них особисто... безумовно це корисно винаходити свій велосипед, але, ну скоро вже 20 років будемо справляти як це вигадали (у 2006-му).

Відповісти
Підтримати
Alexander M
Alexander M 17.11.2023 22:14

На сьогодні BEM описує лише блоки, елементи та модифікатори, а те що колись було на оф сайті Яндекса, то вже історія. Чи ви своїм розробникам кажете, що використовуєте BEM, тільки не той, що зараз, а оригінальний і витрачаєте купу часу на пояснення?

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

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 18.11.2023 01:48

Зрештою, все зводиться до блоків, елементів і модифікаторів — це основа.

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

Види модифікацій (модифікатором, міксом, рівнем перевизначення чи контекстом) — це не історія, там нічого не змінювалося.

Відповісти
Підтримати
Alexander M
Alexander M 19.11.2023 01:21

Ми зараз на друге коло зайдемо. Я вище як раз писав, що SMACSS за блоками й елементами те саме, що й BEM, тільки називаються інакше.

Відповісти
Підтримати
Ihor Zenich
Mykhailo Basiuk Full Stack Developer в Tractor 01.11.2023 03:22

Ізолювати стилі в css неможливо by design, і будь-яка технологія «ізоляції» це bs. BEM це гірше ніж BS, це KS. З тих же міркувань випливає що і веб компоненти це bs технології. Єдино правильний спосіб писати веб це Figma або photoshop макет який втупу переводиться в розмітку.

Відповісти
Підтримати
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 31.10.2023 12:52

Невже ще досі хтось юзає ВЕМ?

Відповісти
Підтримати
Olexander Smolianinov frontend director в ZFORT Group 31.10.2023 15:48

Ваше питання — це те ж саме, що запитати «Невже ще досі хтось не юзає React?».
Хтось юзає, хтось ні. Або гадає, що юзає :) У більшості популярних методологій ідея плюс мінус однакова, різниця тільки в кількості шарів логіки та їх назвах

Відповісти
Підтримати
Sviatoslav Kuzhelev
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 02.11.2023 10:18

Це вже давно стало рудіментом. Ще скажіть хтось на Паскалі пише і має щастя. Треба розуміти сучасні тенденції, та якщо вже зовсім консерватизм, то хоча б дивитися що не застаріває. БЕМ вже давно канув в історію і не треба його тягнути в сучасніть

Відповісти
Підтримати
Olexander Smolianinov
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 08.11.2023 22:48

Думаю це питання риторичне, тим паче раджу поглянути на CSS Modules або якщо більш хочеться хіпстерського підходу Styled Components

Відповісти
Підтримати
amigo
Olexander Smolianinov frontend director в ZFORT Group 08.11.2023 23:02

В контексті умовного реакту воно може і непогано працює, але поза JS стеком є нюанси

Відповісти
Підтримати
Sviatoslav Kuzhelev
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 09.11.2023 14:28

Якщо вам ще досі доводиться писати на ванілі або сапортити проєкти без Вебпаку та допоміжних фреймів в 2023 році то мені шкода за вас :(

Відповісти
Підтримати
Olexander Smolianinov
Olexander Smolianinov frontend director в ZFORT Group 09.11.2023 16:19

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

Відповісти
Підтримати
Sviatoslav Kuzhelev
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 10.11.2023 09:22

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

Відповісти
Підтримати
Olexander Smolianinov
Olexander Smolianinov frontend director в ZFORT Group 10.11.2023 12:14

Світ фронтенду набагато ширший, і мова тут не про фреймворки чи ванілу, а про реальний стан справ. Дам трохи контексту з реального світу.
Для початку, треба зрозуміти відсоток поширення технологій на теперешній момент. Існує багато сервісів та агенцій, які збирають таку інфу. Наприклад, з останнього докладу w3techs можна побачити, що React market share — це 4.2%, VueJS — 1%, і так далі. Вони юзать інфу з CrUX, alexa, та інших актуальний джерел, тому статистика наразі релеватна. Інший ресурс з трохи відмінною методологією вказує, що у реакта близько 5%, але не більше. При цьому, jQuery досі домінує з мінімумом 70%. Це відбувається в тому числі через те, що найбільш популярна в світі CMS — WordPress, досі тягне jquery в своєму корі.
Другий момент з мого власного досвіду. Останні років 10 я проводжу більше сотні співбесід фронтів на рік, останні три роки в більшості це люди з Європи, Латинської Америки та іноді з Азії. За моєю персональною статистикою, з них не більше 20% тих, кто більш менш шарить в JS, а тих хто володіє нормально «сучасними рішеннями» — одиниці. Але так чи інакше, вони усі мали роботу і не мали проблем з її пошуком.
Ну і третій момент, щодо прикладів. Наразі мій основний тип проектів — це креативні сайти з просунутою анімацією (ви такі могли зутрічати на awwwards та аналогічних платформах). Основний акцент йде на GSAP, threeJS, ванільний жс, сучасний CSS, перформанс та максимальну оптимізацію для пошукових систем. Для такого типу проектів жс фреймворки не тільки не допомагають, але іноді і шкодять (були моменти з SEO).
Якось так

Відповісти
Підтримати
Sviatoslav Kuzhelev
Sviatoslav Kuzhelev Lead Frontend Engineer в Currently lookig for a job 10.11.2023 13:55

Тепер зрозуміло. Якщо мова про ленди то з цього і треба починати. Абсолютно згідний що тут не треба наворотів. І ваніли стане і БЕМу якщо робиш якийсь сінгелтон про який більше і не згадаєш. Проте питання ж не про знання людей і як довести що людина з мізками а не з запакованим курсом по реакту пришла на інтервью. Та не про статистику у виправдання легасі. Діалог на самперед про сучасні технології та іх вплив на якість та швидкість розробки. Тому в більшості своєму БЕМ вже давно втратив якість і не несе користі. Саме як і не зовсім зрозуміло як квері та БЕМ «розширює» кругозір та можливості написання високонавантажених проєктів. Як його можно скелити в умовах хардкорного моноліта або маштабного саас продукту? Це якщо вже і живе в проєкті то час задуматися над цим.

P.S.
Доречі якось проводив експеримент коли мені попався ленд з купою анімування. Скажу відверто написання на creat-react-app дало на 3 дні швидший результат і поясню чому: готові архитектура та тулзи для роботи. Готовий компілятор та мініфікатор. Модульна інтеграція що дозволяє писати ті самі модуль на льоту. Та і СЕО чому б страждало? На виході чиста статика.

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

Відповісти
Підтримати
Olexander Smolianinov
Alexander M 11.11.2023 20:03

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

Відповісти
Підтримати
Sviatoslav Kuzhelev
Mykhailo Basiuk Full Stack Developer в Tractor 15.11.2023 00:19

Дайте визначення ізольованому стилю

Відповісти
Підтримати
Alexander M
Alexander M 15.11.2023 20:06

Бачив ваш коментар про Фігму, у вас якась гіпер фіксація на проблемі ізоляції стилів.

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

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 15.11.2023 22:44

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

Відповісти
Підтримати
Alexander M
Alexander M 17.11.2023 22:20

Неймінг конвеншони лише пояснюють те, як іменувати селектори і не мають відношення до наявності макетів.

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 18.11.2023 00:21

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

Відповісти
Підтримати
Alexander M
Alexander M 19.11.2023 01:17

Так, тільки під ізоляцією мається на увазі певне відокремлення імен селекторів у всьому DOM. А самі стилі й ізольовувати не треба, вони й так живуть у рамках певного селектора.

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 19.11.2023 01:53

Типовий bait and switch, нічого нового. Ми вже визначились що таке ізоляція і як мають працювати компоненти в нормальному розумінні.

Відповісти
Підтримати
Alexander M
Alexander M 19.11.2023 22:50

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

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

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 20.11.2023 02:09
Коли всі ці конвеншони створювались, то в розробників була проблема, яку ці конвеншони й вирішували.

Не зовсім так, мати конвеншени в css це приємний бонус. Але давайте пройдемось як приймаються рішення в IT.
1) Є реальна практична проблема
2) Багато практиків і теоретиків бачать проблему і її обговорюють, і діляться своїм баченням для рішення.
3) Хороші рішення знаходять гарні відгуки, це оформлюється в якусь обгортку і презентується ширшій удиторії на конференціях і форумах
4) Далі може іти хайп, експерти продають це рішення як проривне, що допоможе їх бізнесу, і далі бізнес створює пропозицію — шукають розробників які знайомі з новою мегатехнологіїєю, або методологією.
5) Далі купа людей іде на доу і клеймить що є така технологія і я в ній експерт, ось тут і тут вона корисна.

Нічого такого коли технологія дійсно проривна, наприклад OOP, FP, CSS3, Android, Figma, jQuery, JS, Java, C#, C++, Bootstrap;

Проблеми починаються коли підключається бізнес який аналізує цей флов і починає просувати свої технології починаючи з 4) і 5) без ключового — 1) відсутність реальної практичної проблеми, або 2) відсутності розуміння першопричини і зрорової дискусії з пошуку оптимального рішення, або хоча б рішення яке не робить прямо протилежне для вирішення заявленої проблеми.

Приклади таких BS технологій: BEM, Webpack, Docker, Microservices, CQRS;

Тобто для прикладу BEM який просувався яндексом рекламувався як технології ізоляції для всіх включаючи менеджерів і розробників з backend background які не розуміють що таке css.

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

В сценарії з двома «компонентами» найближча аналогія це множинне наслідування — від двох батьків, яке не підтримується більшістю мов. Селектор з правилом ближче до OOP класу ніж до проперті

Відповісти
Підтримати
Alexander M
Ihor Zenich CSS engineer в EPAM 20.11.2023 22:17

BEM ніколи не просувався як технологія ізоляції. Та тим більше не просунувся як рішення для тих хто не вміє у css.

Взагалі там настільки було пох на хайп, що вони навіть документацію написали тільки через 9 років(!).

Те, що весь світ зараз знає як BEM — це те, як Harry Roberts зрозумів це в 2013 і нарешті переказав англійською.

Яндексу на «продаж рішення» було настільки покласти, що сторонні люди навіть зробили короткий простий сайт з азами методології (getbem), тому що офіційний був по суті внутрішньою документацією прикладної реалізації.

Почитайте статті та доповіді Віталія Харісова про 2006-2009 роки, які були проблеми та як вони шукали рішення, як, чому і до чого дійшли.

А після цього — Harry Roberts та Jonathan Snook, як вони вирішували ту саму проблему і до чого прийшли.

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 20.11.2023 22:21

Перший результат в гуглі:

BEM — is a methodology that helps you to create reusable components and code sharing in front‑end development

Відповісти
Підтримати
Ihor Zenich
Mykhailo Basiuk Full Stack Developer в Tractor 20.11.2023 23:05

Для новачків / менеджерів / бекенд розробників підсумок:
Не намагайтесь реюзати html і css, а якщо і намагаєтесь маєте розуміти базові обмеження чого це дуже складно.

Якщо хочете зберегти час і мати нормальний дизайн методологія така:
1) Використовуєте тулу яка не модифікує каскадом дочірні елементи. Фотошоп або фігма, або щось подібне і малюєте там як все має бути
2) Імлементите в css. Важливо писати css від parent до child. Спочатку html, body, container і т.д. Намагайтесь не модифікувати parent елементи, якщо не хочете перевіряти все по кругу. В ООП аналогом є зміни в parent класу.
3) уникайте використання разом css компонентів які не тестувались разом, наприклад від різних вендорів. Уникайте намагання реюзати css код — засунути те що зробили в компоненту і потім десь переюзати — не вийде. Якщо хтось намагається змусити вас реюзати його «компоненти», розповідає про беми, що це реально — ідіть до менеджера і покажіть цей коментар. Менеджеру: не потрібно так робити. Перевикористання коду на UI тільки через шаблони дизайнера і через протестовані компоненти 3-rd party вендорів. Ніколи через компоненти всередині команди яка робить конкретну імплементацію.

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 20.11.2023 23:59

До чого тут Photoshop/Figma до каскаду в CSS?

Яка різниця де у вас намальований дизайн? CSS — каскадний by design.

Повторення dom-дерева в css — це те, як писали 20 років тому, коли інших способів ізоляції стилів (не каскаду!) не було.

Не використовувати компоненти та не реюзати код тк ви вважаєте що це не працює? Це якийсь жарт чи що?

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 22.11.2023 00:54

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

Відповісти
Підтримати
Ihor Zenich
Alexander M 29.11.2023 22:16

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

Відповісти
Підтримати
Mykhailo Basiuk
Ihor Zenich CSS engineer в EPAM 31.10.2023 08:57

@scope — лише один із способів ізоляції стилів. Їх існує безліч:
— Web Components (Angular)
— CSS Modules
— all:initial
— CSS containment
— CSS scope
— Inline styles (Tailwind)
— ... зрештою можна писати високоспецифічні селектори повторюючи dom.

Ці речі не замінюють одна одну, а доповнюють. Адже навіть всередині ангуляр-компонента треба писати акуратний код та декомпозувати.

Відповісти
Підтримати
Mykhailo Basiuk Full Stack Developer в Tractor 15.11.2023 00:19

Можете дати визначення ізольованого стилю?

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 15.11.2023 23:59

під ізоляцією зазвичай дві речі розуміють (не завжди одночасно):
1) на стиль не діють стилі, що приходять з каскаду;
2) стиль не конфліктує з іншими стилями.

У різних випадках потрібне різне.

До речі, ви мені нагадали, ще два пункти треба занести до списку способів ізоляції:
— css cascade layers
— та sass namespace

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 16.11.2023 00:34

Згоден з 1) з 2) не зовсім, так як в css є документовані правила за якими визначається фінальний результат. Тобто для css engine ніяких конфліктів не буває, вони бувають тільки в голові розробника якому лінь запам‘ятовувати ці правила, і якщо очікування розробника не співпадають з тим як конкретно розраховується стиль, то це більше проблема самого розробника. Можете дати приклад як зможе наприклад sass namespace ізолювати стиль який приходить з каскаду. Ось я напишу в якійсь депенденсі body line-height : 1.3em; font-family: serif; Як ви думаєте багато компонентів написані в цими компонентами залишаться ізольованими

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 16.11.2023 01:10

Ну основна причина конфліктів — це підключення стороннього коду/об’єднання роботи кількох команд, etc.

Sass namespace допоможе тільки з конфліктами sass-змінних/міксинів тощо.

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 16.11.2023 04:00

ну тобто реальних окремих технологій для ізоляцій стилів не існує, за визначенням ізоляції. той костиль що робить web components \ CSS Modules це просто жесть, і не допомагає в дуже простих випадках, як-от в прикладі коли line-height потрібно поміняти на parent елементі.
Цікаво що далеко не всі команди роблять висновки з базових знань про css, і організовують процеси розробки UI на основі уявних технологій «ізоляції», «компонентів», і витрачають купу сил на регресії, по вуха в UI-багах з пропущеними дедлайнами, і купою обмежень і виправдань.
А без жодних ізоляцій заімплементити figma/ps -шаблончик не дозволяє релігія.

Відповісти
Підтримати
Ihor Zenich
Ihor Zenich CSS engineer в EPAM 16.11.2023 23:47

ну як мінімум є `all: initial`

Відповісти
Підтримати
Mykhailo Basiuk
Mykhailo Basiuk Full Stack Developer в Tractor 17.11.2023 00:01

Ок, можеш нагадати як працює top і left? І це один з прикладів

Відповісти
Підтримати
Ihor Zenich

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.