מפתחים אוהבים ניצחונות מהירים. כשכרטיס המשימה אומר "הוסף מצב כהה", הנתיב בעל ההתנגדות הנמוכה ביותר נראה מובן מאליו: כתיבת light.css, כתיבת dark.css, ומעבר ביניהם. זה מרגיש נקי. זה יוצא מהר. עבור פרויקט צד קטן עם שלושה רכיבים, זה אולי אפילו יעבוד. אבל ברגע שהאפליקציה שלך גדלה מעבר לכמה מודולים, הקובץ השני מפסיק להיות נכס והופך לנטל שאתה נאלץ לתחזק בכפילות.
מלכודת שני הקבצים
הלוגיקה נראית הגיונית במבט ראשון. הפרדת תחומי אחריות, נכון? דברים בהירים כאן, דברים כהים שם. אתה פותח שני buffers בעורך שלך. אתה מעתיק את סגנונות הכרטיס (card) מהקובץ הבהיר לקובץ הכהה, מחליף את #ffffff ב-#1a1a1a, ומסיים את היום.
הבעיה היא לא בשבוע הראשון. הבעיה היא בחודש השישי, כשמעצב מבקש רדיוס פינה (border radius) מעט שונה לכפתור הראשי, או כשצוות המוצר רוצה מצב אזהרה חדש בטופס התשלום. אתה מעדכן את גיליון העיצוב הבהיר. אתה מביט בעין בגיליון העיצוב הכהה. אולי אתה זוכר להעתיק את השינוי. אולי לא. הפער הזה הוא המקום שבו האיכות מתה. אתה כבר לא מתחזק ממשק אחד. אתה מתחזק שני ממשקים מקבילים שפשוט חולקים את אותו שלד HTML.
Theme Drift הוא בלתי נמנע
לפער הזה יש שם שצוותי פרונטנד מתחילים להכיר: theme drift. זה קורה כששני גיליונות העיצוב שלך מתפתחים במהירויות שונות. התאמת padding כאן. שינוי קטן בצל שם. הקובץ הכהה הופך לאח המקופח. או גרוע מכך, הוא הופך למקור של פחד. מפתחים מתחילים להימנע משינויים כי נגיעה בתמה אחת פירושה חיפוש בתוך קובץ אחר כדי לשכפל את העבודה.
העומס הקוגניטיבי מצטבר במהירות. רצית לכתוב CSS פעם אחת. במקום זאת כתבת אותו פעמיים, ועכשיו אתה משלם ריבית על החוב הזה בכל פעם שמערכת העיצוב (design system) משתנה. האייקונים לא מיושרים במצב כהה כי מישהו עדכן flex gap בקובץ הבהיר ושכח לשקף זאת. טבעות הפוקוס (focus rings) נעלמות כי כלל נגישות חדש הגיע רק לגיליון אחד. ה-UI לא רק נראה לא נכון. הוא מתחיל להרגיש שבור.
השתמשו בטוקנים סמנטיים (Semantic Tokens)
הפתרון הוא לא כלי diff טוב יותר או סקירת קוד (code review) קפדנית יותר. הפתרון הוא דרך חשיבה שונה על צבע. הפסיקו לארגן את הסגנונות שלכם לפי המראה המילולי שלהם והתחילו לארגן אותם לפי המטרה שלהם. כאן נכנסים לתמונה טוקנים סמנטיים.
במקום להקצות לכרטיס רקע לבן, הקצו לו רקע מסוג surface. במקום לבחור בין שחור ללבן-אפרפר עבור טקסט, בחרו צבע טקסט. הרכיב לא יודע או אכפת לו אם המשתמש מעדיף מצב בהיר או כהה. הוא פשוט מבקש את הטוקן שמתאים לתפקיד שלו.
חשבו על כפתור סטנדרטי. בעולם של שני קבצים, .btn חי בגיליון העיצוב הבהיר עם רקע לבן וגבול כהה. התאום שלו חי בגיליון העיצוב הכהה עם רקע כמעט שחור וגבול בהיר יותר. זה פי שניים קוד עבור כפתור אחד. עם טוקנים, ל-.btn יש הצהרה אחת: הרקע הוא var(--color-surface-secondary) והגבול הוא var(--color-border-default). הערכים עצמם נמצאים ב-root. כשהאתר במצב בהיר, --color-surface-secondary מתורגם למשהו כמו #f8f9fa. במצב כהה, אותו טוקן מתורגם ל-#2d2d2d. רכיב הכפתור לעולם לא משתנה. רק הנתונים שמתחתיו משתנים.
ההבחנה הזו בין מבנה לנתונים היא עדינה אך עוצמתית. רכיב הכרטיס שלכם מגדיר פריסה (layout), ריווח (spacing), טיפוגרפיה ו-elevation פעם אחת. שכבת התמה שלכם מגדירה את הפלטה. ההפרדה הזו היא בדיוק עבור מה ש-CSS custom properties נבנו.
איך הארכיטקטורה משתנה
הגישה הזו משנה מהיסוד את האופן שבו אתם כותבים סגנונות.
הדרך הישנה נראית בדרך כלל כך:
- גיליון עיצוב כרטיס בהיר המגדיר padding, radius, background, צבע טקסט וצל.
- גיליון עיצוב כרטיס כהה שמגדיר מחדש את רוב אותן תכונות רק כדי להפוך צבעים.
- שכבת לוגיקה שמחליטה איזה גיליון עיצוב לטעון או איזו class להפעיל על ה-body.
הדרך החדשה נראית כך:
- גיליון עיצוב כרטיס אחד המגדיר פריסה ומקצה טוקנים סמנטיים.
- קובץ תמה אחד המגדיר מה הטוקנים הללו אומרים בהקשר בהיר.
- קובץ תמה אחד, או פשוט בלוק באותו קובץ, המגדיר מה הטוקנים הללו אומרים בהקשר כהה.
- החלפת attribute אחת שמשנה את שכבת הערכים מבלי לגעת בשכבת הרכיב.
You keep the setup stable. You only change the data. When the designer wants to introduce a third theme, maybe a high-contrast mode or a midnight blue variant, you do not rewrite the card. You add one more assignment to the token map. The component stays dumb and happy. It still wants a surface color. The theme tells it which surface color to use.
The Data Attribute Switch
Implementation can stay simple and readable. Apply a data attribute to your HTML tag, something like data-theme="dark", and let your token definitions scope under it.
Set your defaults on :root for the light experience so the page renders correctly before JavaScript runs. Then override the token values under [data-theme="dark"]. A tiny script watches for a toggle click, updates the attribute, and every component on the page responds instantly. No class thrashing on individual elements. No importing an entirely separate stylesheet mid-render. The browser already has the variables in memory; it just repaints with new values.
This keeps your code clean in a very practical sense. You do not have to grep across two directories to find every instance of .card. You do not have to worry about specificity wars between competing theme classes stacked on the same node. Your HTML stays readable. Your CSS stays centralized and searchable.
It Is About Values, Not Versions
Dark mode is about values. It is not a second version of your UI. The corners of your card do not get rounder at night. Your grid does not collapse into a different shape. Your type scale does not need a new rhythm. Only the colors shift, and sometimes the shadows breathe a little deeper. Treating darkness as a full reskin is over-engineering that creates maintenance nightmares.
The teams that get this right treat their design system like a database. Components query for properties by name. Themes provide the records. Switching from light to dark is a query parameter change, not a schema rewrite.
That mindset is what saves you from theme drift. One card. One button. One source of truth for spacing and sizing. The palette lives in one place, logically mapped, ready for whatever environment the user prefers.
The Real Takeaway
If you are maintaining two CSS files for light and dark, you are not theming. You are cloning. Move to semantic tokens, scope them with a root-level data attribute, and let your components ask for roles instead of hardcoding appearances. The initial refactor takes effort, but the alternative is an endless game of whack-a-mole across parallel stylesheets. Life is too short to write the same card twice.