CSS և design system-ներ

01Գաղափարը. որոշումներ, ոչ թե արժեքներ

Design system-ը պատկերացրեք որպես բրենդի կանոնագիրք։ #0f62fe-ի նման «հում» արժեքը ոչինչ չի ասում, իսկ --color-accent-ի նման token-ը ասում է, թե ինչի համար է այն։ Token-ները սովորաբար լինում են երկու շերտով։ Primitive token-ները նկարագրում են պալիտրան (--blue-600, --gray-100)։ Semantic token-ները նկարագրում են նպատակը (--color-accent, --color-surface, --color-text-muted) և հղում են primitive-ներին։ Կոմպոնենտներն օգտագործում են միայն semantic token-ներ։ Հենց այս մեկ կանոնն է թեմավորումն ու redesign-ները էժանացնում. փոխում եք, թե ինչին է հղում --color-surface-ը, և յուրաքանչյուր card, modal և input հետևում է դրան։ Token-ները միայն գույնը չեն ընդգրկում. spacing-ը, տառաչափերը, line height-ները, radius-ները, ստվերները, z-index շերտերը, տևողություններն ու easing-ները նույնպես նույն ֆայլում են։

1:root {
2  /* primitives */
3  --gray-50: #f7f7f8;
4  --gray-900: #16161a;
5  --blue-600: #2952e3;
6 
7  /* semantic: components use only these */
8  --color-bg: var(--gray-50);
9  --color-text: var(--gray-900);
10  --color-accent: var(--blue-600);
11  --radius-md: 0.5rem;
12  --duration-fast: 150ms;
13}

02Spacing-ի և տառատեսակի սանդղակներ

Սանդղակը թույլատրված չափերի կարճ, ֆիքսված ցուցակ է։ Այստեղ 13px, այնտեղ 15px գրելու փոխարեն ընտրում եք քայլեր, օրինակ՝ 4, 8, 12, 16, 24, 32, 48, 64 spacing-ի համար, և modular ratio (օրինակ՝ 1.2 կամ 1.25) տառաչափերի համար։ Քիչ տարբերակները նշանակում են ավելի արագ որոշումներ և տեսանելի ռիթմ։ Fluid type-ը օգտագործում է clamp(), որպեսզի վերնագրերը սահուն մեծանան նվազագույնի և առավելագույնի միջև՝ առանց breakpoint-ների. clamp(2rem, 1.2rem + 3vw, 3.5rem)։ Տառաչափերի համար օգտագործեք rem, որպեսզի օգտատիրոջ բրաուզերի տառաչափի կարգավորումը հարգվի, իսկ line-height-ը պահեք առանց միավորի (1.5՝ տեքստի համար, 1.1-ից 1.2՝ մեծ վերնագրերի համար)։

• Spacing. 4px կամ 8px բազային grid՝ --space-1-ից --space-10 անուններով։
• Տառատեսակ. 6-ից 8 քայլը բավարար է պրոդուկտների մեծ մասի համար։
• Fluid. clamp(min, preferred, max) վերնագրերի և section-ների padding-ի համար։
• Երբեք թույլ մի տվեք կոմպոնենտին հորինել չափ, որը սանդղակում չկա։

03Թեմավորում. light, dark և բրենդներ

Քանի որ կոմպոնենտները կարդում են semantic token-ներ, թեման պարզապես նույն անունների համար արժեքների այլ հավաքածու է։ Dark mode-ը կարող է հետևել օպերացիոն համակարգին prefers-color-scheme-ի միջոցով կամ օգտատիրոջ ընտրությանը, որը պահվում է html էլեմենտի data-theme ատրիբուտում։ Ժամանակակից CSS-ն ունի նաև light-dark() ֆունկցիան, որը color-scheme property-ից ելնելով ընտրում է երկու արժեքից մեկը, այնպես որ շատ token-ներ կարելի է գրել մեկ անգամ։ White-label պրոդուկտների համար յուրաքանչյուր բրենդ token-ների ևս մեկ հավաքածու է, որը բեռնվում է root-ում։ Թեմայի ատրիբուտը դրեք սերվերում կամ փոքրիկ inline script-ով՝ մինչև paint-ը, այլապես օգտատերերը կտեսնեն սխալ թեմայի «բռնկում»։

1:root {
2  color-scheme: light dark;
3  --color-bg: light-dark(#ffffff, #121214);
4  --color-text: light-dark(#16161a, #ececf1);
5}
6 
7/* explicit user choice wins over the OS setting */
8[data-theme="dark"] { color-scheme: dark; }
9[data-theme="light"] { color-scheme: light; }

04CSS Modules, styled-components, թե՞ Tailwind

Երեքն էլ կարող են լավ design system կառուցել. տարբերվում են նրանով, թե որտեղ են ապրում ոճերը և ինչ է աշխատում runtime-ում։ CSS Modules-ը սովորական CSS ֆայլեր են՝ լոկալ scope ունեցող class անուններով, որոնք կոմպիլացվում են build-ի ժամանակ, զրո runtime արժեքով և React Server Components-ի լիարժեք աջակցությամբ։ styled-components-ը CSS-in-JS է. ոճերն ապրում են կոմպոնենտի ներսում և կարող են արձագանքել props-ին, բայց ոճերը գեներացվում են բրաուզերում և հենվում են React context-ի վրա, ուստի Next.js App Router-ում դրանց պետք են client կոմպոնենտներ և style registry՝ SSR-ի համար։ Նախագիծը 2025-ից maintenance mode-ում է և լավ default չէ նոր RSC նախագծերի համար։ Tailwind-ը utility-first է. markup-ում հավաքում եք px-4 text-sm-ի նման class-ներ։ 4-րդ տարբերակը token-ները սահմանում է CSS-ում @theme-ով, գեներացնում է միայն այն class-ները, որոնք օգտագործում եք, և հիանալի աշխատում է server կոմպոնենտների հետ։

• CSS Modules. իսկական CSS, զրո runtime, RSC-ի համար անվտանգ. անունները ինքներդ եք տալիս։
• styled-components. դինամիկ props և co-location. runtime արժեք, RSC-ում՝ միայն client։
• Tailwind. շատ արագ է կառուցել, փոքրիկ CSS output, RSC-ի համար անվտանգ. class-ների երկար ցուցակները կարգապահություն են պահանջում։
• Zero-runtime CSS-in-JS-ը (vanilla-extract, Panda, StyleX) գտնվում է դրանց միջև։

05Կոմպոնենտային գրադարաններ

Ձեր token ֆայլը հիմքն է, իսկ կոմպոնենտային գրադարանը դրա վրա կառուցված տունը։ Սկսեք ձանձրալի, բայց ամենաշատ օգտագործվող մասերից՝ Button, Input, Select, Checkbox, Modal, Toast, Card, Stack և Grid layout primitive-ներ։ Յուրաքանչյուր կոմպոնենտ պետք է ունենա փոքր, տիպավորված API (variant, size, disabled)՝ կամայական ոճեր ընդունելու փոխարեն, որպեսզի համակարգը մնա համահունչ։ Բարդ ինտերակտիվ widget-ների (dialog-ներ, menu-ներ, combobox-ներ) համար կառուցեք headless, accessible primitive-ների վրա, ինչպիսիք են Radix-ը, React Aria-ն կամ Ark UI-ը, այլ ոչ թե ինքներդ գրեք focus trap-եր և ստեղնաշարի մշակում։ Յուրաքանչյուր կոմպոնենտ փաստաթղթավորեք իրական օրինակներով, իսկ ընդհանուր փաթեթներին տվեք semantic versioning, որպեսզի button-ի breaking change-ը անակնկալ չլինի այն օգտագործող տասը հավելվածների համար։

1// Button/index.tsx - a small, closed API
2import s from "./style.module.css";
3 
4type Props = {
5  variant?: "primary" | "ghost";
6  size?: "sm" | "md";
7} & React.ButtonHTMLAttributes<HTMLButtonElement>;
8 
9export function Button({ variant = "primary", size = "md", className, ...rest }: Props) {
10  const cls = [s.button, s[variant], s[size], className].filter(Boolean).join(" ");
11  return <button className={cls} {...rest} />;
12}

06Responsive ռազմավարություն և container query-ներ

Ընտրեք breakpoint-ների մեկ ցուցակ, պահեք այն մեկ տեղում և օգտագործեք ամենուր։ Mobile-first (min-width), թե desktop-first (max-width) եք գնում, ավելի քիչ է կարևոր, քան հետևողական լինելը։ Media query-ները պատասխանում են «որքա՞ն լայն է էկրանը» հարցին։ Container query-ները կոմպոնենտների համար պատասխանում են ավելի լավ հարցի՝ «որքա՞ն լայն է այն տուփը, որի մեջ ես եմ»։ Ապրանքի card-ը կարող է իրար տակ դասավորությունից անցնել հորիզոնականի, երբ իր container-ը բավականաչափ լայն է՝ անկախ նրանից, sidebar-ում է այն, թե ամբողջ լայնությամբ grid-ում։ Container query-ները և cqi միավորը աջակցվում են բոլոր ժամանակակից բրաուզերներում։ Օգտագործեք նաև intrinsic layout-ներ. grid-ը repeat(auto-fill, minmax(16rem, 1fr))-ով հաճախ ընդհանրապես վերացնում է breakpoint-ների կարիքը։

1.cardWrap {
2  container-type: inline-size;
3}
4 
5.card {
6  display: grid;
7  gap: var(--space-3);
8}
9 
10@container (min-width: 28rem) {
11  .card { grid-template-columns: 10rem 1fr; }
12}

07Խորհուրդներ production-ի համար

Համակարգը պաշտպանեք գործիքներով, ոչ թե հիշողությամբ։ Stylelint-ը կարող է արգելել «հում» hex գույները և px արժեքները token ֆայլից դուրս։ Cascade layer-ները (@layer reset, tokens, components, utilities) specificity-ն դարձնում են կանխատեսելի, այնպես որ երբեք !important պետք չի լինի։ Token-ների փոփոխությունները պահեք additive. token-ի վերանվանումը կամ ջնջումը breaking change է, ուստի ներմուծեք նորը, միգրացիա արեք, հետո հեռացրեք հինը։ Կոմպոնենտները թեստավորեք ձեր իրական breakpoint-ներում և երկար թարգմանված տողերով, որովհետև գերմաներեն, ռուսերեն կամ հայերեն տեքստը կոտրում է layout-ներ, որոնք անգլերենով լավ են երևում։ Վերջապես, ստուգեք կոնտրաստը տեքստի և ֆոնի token-ների յուրաքանչյուր զույգի համար երկու թեմաներում էլ։

• Lint կանոն. ոչ մի hex, ոչ մի px token-ներից դուրս։
• !important-ի փոխարեն օգտագործեք @layer։
• Նախ ավելացրեք token-ները, միգրացիա արեք, հետո ջնջեք։
• Թեստավորեք ամենաերկար locale-ով և յուրաքանչյուր breakpoint-ում։

08Cascade layers՝ specificity-ի ճարտարապետություն

Cascade layers-ը (@layer) որոշում է, թե ոճերի որ խումբն է հաղթում, դեռ մինչև specificity-ի համեմատությունը։ Դուք մեկ անգամ հայտարարում եք հերթականությունը, օրինակ՝ reset, vendor, tokens, base, components, utilities, և ավելի ուշ շերտի ցանկացած կանոն հաղթում է ավելի վաղ շերտի ցանկացած կանոնին՝ անկախ նրանից, թե որքան սպեցիֆիկ է դրա selector-ը։ Սա վերջ է դնում ավելի երկար selector-ների և !important-ի մրցավազքին։ Երեք մանրուք հաճախ է մարդկանց շփոթեցնում։ Որևէ շերտից դուրս գտնվող ոճերը հաղթում են բոլոր շերտավորված ոճերին, ուստի այն CSS-ը, որը դուք չեք վերահսկում, պետք է ներմուծել ցածր շերտ՝ @import url(...) layer(vendor)-ով, այլապես այն լուռ կհաղթի։ !important-ը շրջում է հերթականությունը. վաղ շերտի important հայտարարությունը հաղթում է ավելի ուշ շերտի important հայտարարությանը, ինչը թույլ է տալիս reset-ին պաշտպանել accessibility-ի կանոնները։ Եվ հերթականությունը ֆիքսվում է այն պահին, երբ շերտի անունն առաջին անգամ հայտնվում է, ուստի ամբողջ ցուցակը հայտարարեք մուտքային stylesheet-ի հենց վերևում՝ ցանկացած import-ից առաջ։

1@layer reset, vendor, tokens, base, components, utilities;
2 
3@import url("datepicker.css") layer(vendor);
4 
5@layer components {
6  .button { background: var(--color-accent); }
7  .card .button.primary { background: var(--color-accent-strong); }
8}
9 
10@layer utilities {
11  /* wins over both rules above, despite lower specificity */
12  .bg-surface { background: var(--color-surface); }
13}

09Գույն, որը կարելի է հաշվարկել՝ OKLCH, color-mix() և relative colours

Hex-ն ու HSL-ը վատ են հարմարված սանդղակներ կառուցելու համար։ Նույն lightness արժեքով երկու HSL գույն կարող են պայծառությամբ շատ տարբեր տեսք ունենալ, ուստի գեներացված երանգները անկանխատեսելիորեն չեն անցնում contrast-ի ստուգումը։ OKLCH-ը գույնը նկարագրում է որպես ընկալվող lightness, chroma (գունագեղություն) և hue, ուստի lightness-ը 0.95-ից մինչև 0.25 քայլերով իջեցնելը տալիս է հավասարաչափ տեսք ունեցող սանդղակ և հեշտացնում contrast-ի մասին դատողությունը։ Ժամանակակից CSS-ը կարող է գույներ ստանալ նաև հենց բրաուզերում։ color-mix(in oklch, var(--brand), black 15%)-ը ցանկացած բրենդային գույնից hover երանգ է ստեղծում, իսկ relative colour syntax-ը՝ oklch(from var(--brand) l c h), թույլ է տալիս փոխել մեկ ալիք և պահել մնացածը։ Այս ամենն աշխատում է հիմնական բրաուզերների ընթացիկ տարբերակներում։ Գործնական օգուտը white-label-ն է. tenant-ը տալիս է մեկ կամ երկու բրենդային գույն, և համակարգը հաշվարկում է hover, pressed, subtle background և border վիճակները։ Հաշվարկված գույները մեկնարկային կետ են, ոչ թե երաշխիք, ուստի միևնույն է ստուգեք տեքստի և ֆոնի յուրաքանչյուր զույգը WCAG contrast-ով։

1:root {
2  --brand: oklch(0.58 0.17 255);
3 
4  --color-accent: var(--brand);
5  --color-accent-hover: color-mix(in oklch, var(--brand), black 15%);
6  --color-accent-subtle: oklch(from var(--brand) 0.95 calc(c * 0.3) h);
7  --color-accent-border: oklch(from var(--brand) calc(l + 0.15) c h);
8  --color-on-accent: oklch(0.99 0 0);
9}
10 
11[data-brand="b"] {
12  --brand: oklch(0.62 0.19 25); /* the only value a new brand changes */
13}

10Token-ները որպես pipeline, ոչ թե ֆայլ

Մեկ հավելվածում մեկ tokens.css ֆայլը բավական է։ Մի քանի վեբ հավելվածի, native մոբայլ հավելվածի և դիզայն գործիքի դեպքում token-ները դառնում են արտադրանք՝ իր սպառողներով։ Ճշմարտության աղբյուրն այդ դեպքում JSON ֆայլ է W3C Design Tokens Community Group-ի (DTCG) ֆորմատով, որը հրապարակել է իր առաջին կայուն տարբերակը՝ 2025.10, և որը հասկանում են Figma plugin-ները և build գործիքները։ Style Dictionary-ի նման transformer-ը այդ աղբյուրը վերածում է CSS custom properties-ի, autocompletion-ի համար typed TypeScript օբյեկտի և մոբայլի համար Swift կամ Kotlin հաստատունների։ Վերաբերվեք package-ին ինչպես ցանկացած հանրային API-ի՝ semantic versioning, changelog և deprecation-ներ, որոնք հին անունը պահում են որպես alias մեկ major տարբերակի ընթացքում, մինչ lint կանոնը զգուշացնում է դրա մասին։ Յուրաքանչյուր token փոփոխության ժամանակ գործարկեք screenshot թեստեր (օրինակ՝ Storybook visual diff ծառայությամբ), որովհետև մեկ արժեքը կարող է միանգամից տեղաշարժել հարյուրավոր կոմպոնենտներ։

1{
2  "color": {
3    "blue-600": {
4      "$type": "color",
5      "$value": { "colorSpace": "srgb", "components": [0.145, 0.388, 0.922], "hex": "#2563eb" }
6    },
7    "accent": { "$type": "color", "$value": "{color.blue-600}" }
8  },
9  "space": {
10    "4": { "$type": "dimension", "$value": { "value": 1, "unit": "rem" } }
11  }
12}

11CSS-ի runtime արժեքը մեծ մասշտաբում

CSS-ի արտադրողականությունը հազվադեպ է կարևոր, քանի դեռ էջում հազարավոր էլեմենտներ չկան. այդ դեպքում մի քանի բան իրական ժամանակ է խլում։ Style recalculation. :root-ի վրա custom property փոխելը, օրինակ՝ թեմայի փոխարկման ժամանակ, անվավեր է դարձնում ոճերը յուրաքանչյուր էլեմենտի համար, որը ժառանգում է այն։ Մեկ կտտոցի համար մեկ անգամը նորմալ է, բայց root փոփոխականն ամեն frame անիմացիա անելը՝ ոչ, ուստի անիմացվող փոփոխականները սահմանափակեք այն էլեմենտով, որն օգտագործում է դրանք։ Գրանցեք անիմացվող փոփոխականները @property-ով և inherits: false-ով. դա նրանց տալիս է իրական տիպ, թույլ է տալիս սահուն interpolate լինել և կանգնեցնում է փոփոխության տարածումը ծառի միջով։ Չօգտագործված CSS. գլոբալ stylesheet-ը միայն մեծանում է, ուստի նախընտրեք կոմպոնենտային CSS (CSS Modules կամ Tailwind, որը գեներացնում է միայն իր գտած class-ները) և ստուգեք DevTools-ի Coverage վահանակը։ Էկրանից դուրս աշխատանք. content-visibility: auto-ն contain-intrinsic-size-ի հետ թույլ է տալիս բրաուզերին բաց թողնել layout-ն ու paint-ը fold-ից ներքև գտնվող երկար բաժինների համար։ Selector matching-ը հազվադեպ է խցան. նախքան selector-ները վերաշարադրելը չափեք Performance վահանակի selector stats-ով։

1@property --progress {
2  syntax: "<percentage>";
3  inherits: false;
4  initial-value: 0%;
5}
6 
7.meter {
8  background: linear-gradient(90deg, var(--color-accent) var(--progress), transparent 0);
9  transition: --progress 300ms ease-out;
10}
11 
12.long-section {
13  content-visibility: auto;
14  contain-intrinsic-size: auto 800px;
15}