כאשר לומדים את העקרונות של CSS בסיסי, מלמדים לכתוב סגנונות מודולריים, ניתנים לשימוש חוזר ותיאוריים כדי להבטיח תחזוקה. אבל כאשר מפתחים מתערבים ביישומים מהעולם האמיתי, לעתים קרובות זה מרגיש בלתי אפשרי להוסיף תכונות ממשק משתמש מבלי שסגנונות ידלפו לאזורים לא מכוונים. נושא זה הופך לעתים קרובות לכדור שלג ללופ המגשימה את עצמה; סגנונות המוגדרים תיאורטית לרכיב או מחלקה אחד מתחילים להופיע היכן שהם לא שייכים. זה מאלץ את המפתח ליצור בוררים ספציפיים עוד יותר כדי לעקוף את הסגנונות שדלפו, ואז בטעות יעקפו סגנונות גלובליים, וכן הלאה. מוסכמות שמות מחלקות נוקשות, כגון BEM, הן פתרון תיאורטי אחד לבעיה זו. מתודולוגיית BEM (Block, Element, Modifier) היא דרך שיטתית למתן שמות למחלקות CSS כדי להבטיח שימוש חוזר ומבנה בתוך קובצי CSS. מתן שמות למוסכמות כמו זה יכול להפחית עומס קוגניטיבי על ידי מינוף שפת התחום לתיאור אלמנטים ומצבם, ואם מיושמים נכון, יכול להפוך סגנונות ליישומים גדולים לקלים יותר לתחזוקה. בעולם האמיתי, לעומת זאת, זה לא תמיד עובד ככה. סדרי עדיפויות יכולים להשתנות, ועם השינוי, היישום הופך לבלתי עקבי. שינויים קטנים במבנה ה-HTML עשויים לדרוש גרסאות רבות של שם מחלקות CSS. עם יישומי קצה אינטראקטיביים במיוחד, שמות מחלקות העוקבים אחר דפוס BEM עלולים להפוך לארוכים ומסורבלים (למשל, app-user-overview__status--מאמת), ואי הקפדה מלאה על כללי השמות שוברת את מבנה המערכת, ובכך שוללת את היתרונות שלה. בהתחשב באתגרים הללו, אין זה פלא שמפתחים פנו למסגרת, Tailwind היא מסגרת ה-CSS הפופולרית ביותר. במקום לנסות להילחם במה שנראה כמו מלחמת ספציפיות בלתי ניתנת לניצחון בין סגנונות, קל יותר לוותר על Cascade CSS ולהשתמש בכלים המבטיחים בידוד מוחלט. מפתחים נשענים יותר על כלי עזר איך אנחנו יודעים שחלק מהמפתחים מעוניינים להימנע מסגנונות מדורגים? זוהי עלייתם של כלי עבודה קדמיים "מודרניים" - כמו מסגרות CSS-in-JS - שתוכננו במיוחד למטרה זו. עבודה עם סגנונות מבודדים המותאמים היטב לרכיבים ספציפיים יכולה להיראות כמו משב רוח צח. זה מסיר את הצורך בשמות דברים - עדיין אחת המשימות החזיתיות השנואות והגוזלות זמן - ומאפשר למפתחים להיות פרודוקטיביים מבלי להבין או למנף את היתרונות של הורשת CSS. אבל ביטול ה-CSS Cascade מגיע עם בעיות משלו. לדוגמה, חיבור סגנונות ב-JavaScript דורש תצורות בנייה כבדות ולעיתים קרובות מוביל לסגנונות המתערבבים בצורה מביכה עם סימון רכיבים או HTML. במקום מוסכמות שמות שנשקלו בקפידה, אנו מאפשרים לבנות כלים ליצירה אוטומטית של בוררים ומזהים עבורנו (למשל, .jsx-3130221066), מה שמחייב מפתחים להתעדכן בעוד פסאודו-שפה בפני עצמה. (כאילו העומס הקוגניטיבי של הבנת מה כל השפעות השימוש של הרכיב שלך לא הספיק כבר!) הפשטה נוספת של העבודה של מתן שמות למחלקות לכלים פירושה שניפוי באגים בסיסי מוגבל לרוב לגרסאות יישומים ספציפיות שנערכו לפיתוח, במקום למנף את תכונות הדפדפן המקוריות התומכות באגים חי, כגון כלים למפתחים. זה כמעט כמו שאנחנו צריכים לפתח כלים כדי לנפות באגים בכלים שבהם אנחנו משתמשים כדי להפשט את מה שהרשת כבר מספקת - הכל כדי לברוח מה"כאב" של כתיבת CSS סטנדרטי. למרבה המזל, תכונות ה-CSS המודרניות לא רק הופכות את כתיבת ה-CSS הסטנדרטי לגמיש יותר אלא גם נותנות למפתחים כמונו הרבה יותר כוח לנהל את המפל ולגרום לו לעבוד עבורנו. שכבות CSS Cascade הן דוגמה מצוינת, אבל יש עוד תכונה שזוכה לחוסר תשומת לב מפתיע - למרות שזה משתנה עכשיו, לאחר שהיא הפכה לאחרונה לתואמת Baseline. ה-CSS @scope At-Rule אני מחשיב את ה-CSS @scope at-rule כתרופה פוטנציאלית לסוג החרדה הנגרמת על ידי דליפת סגנון שכיסינו, כזו שאינה מאלצת אותנו להתפשר על יתרונות האינטרנט המקוריים להפשטות וכלי בנייה נוספים. "ה-@scope CSS at-rule מאפשר לך לבחור אלמנטים בתתי עצי DOM ספציפיים, למקד לאלמנטים בדיוק מבלי לכתוב בוררים ספציפיים מדי שקשה לעקוף, ומבלי לחבר את הבוררים שלך בצורה הדוקה מדי למבנה ה-DOM."- MDN
במילים אחרות, אנו יכולים לעבוד עם סגנונות מבודדים במקרים ספציפיים מבלי לוותר על ירושה, מדורג או אפילו הפרדה בסיסית של חששותזה היה עיקרון מנחה ארוך טווח של פיתוח חזיתי. בנוסף, יש לו כיסוי דפדפן מעולה. למעשה, Firefox 146 הוסיף תמיכה ב-@scope בדצמבר, מה שהפך אותו ל-Baseline תואם לראשונה. הנה השוואה פשוטה בין כפתור המשתמש בתבנית BEM לעומת הכלל @scope:
<סגנון> .button .button__text { /* סגנונות טקסט של כפתור */ } .button .button__icon { /* סגנונות סמל כפתור */ } .button--primary { סגנונות לחצן ראשי */ }
<סגנון> @scope (.primary-button) { span:first-child { /* סגנונות טקסט של כפתור */ } span:last-child { /* סגנונות סמל כפתור */ } }
הכלל @scope מאפשר דיוק עם פחות מורכבות. המפתח כבר לא צריך ליצור גבולות באמצעות שמות מחלקות, אשר, בתורו, מאפשר להם לכתוב בוררים המבוססים על אלמנטים מקוריים של HTML, ובכך מבטל את הצורך בדפוסי שמות מחלקות של CSS. פשוט על ידי הסרת הצורך בניהול שמות כיתה, @scope יכול להקל על הפחד הקשור ל-CSS בפרויקטים גדולים.
שימוש בסיסי
כדי להתחיל, הוסף את הכלל @scope ל-CSS שלך והכנס בורר שורש שאליו יקפו סגנונות:
@scope (
אז, למשל, אם היינו מרחיקים סגנונות לאלמנט
@scope (nav) { a { /* סגנונות קישור בתוך טווח ניווט */ }
a:active { /* סגנונות קישור פעילים */ }
a:active::before { /* קישור פעיל עם פסאודו-אלמנט לעיצוב נוסף */ }
@media (מקסימום רוחב: 768px) { a { /* התאמות רספונסיביות */ } } }
זה, כשלעצמו, אינו תכונה פורצת דרך. עם זאת, ניתן להוסיף ארגומנט שני להיקף כדי ליצור גבול תחתון, המגדיר למעשה את נקודות ההתחלה והסיום של ההיקף.
/* כל רכיב בתוך ul לא יחולו את הסגנונות */ @scope (nav) to (ul) { a { גודל גופן: 14px; } }
תרגול זה נקרא דונאט scoping, וישנן מספר גישות שניתן להשתמש בהן, כולל סדרה של בוררים דומים, ספציפיים מאוד, המחוברים באופן הדוק למבנה ה-DOM, :not pseudo-selector, או הקצאת שמות מחלקות ספציפיים לאלמנטים בתוך
מסקנה מסגרות CSS ראשונות בתוכנית השירות, כגון Tailwind, עובדות היטב עבור אב טיפוס ופרויקטים קטנים יותר. היתרונות שלהם פוחתים במהירות, עם זאת, כאשר משתמשים בהם בפרויקטים גדולים יותר הכוללים יותר מכמה מפתחים. פיתוח חזיתי הפך להיות מסובך יותר ויותר בשנים האחרונות, ו-CSS אינו יוצא דופן. למרות שכלל @scope אינו מרפא הכל, הוא יכול להפחית את הצורך בכלי עבודה מורכבים. בשימוש במקום, או לצד שמות מחלקות אסטרטגיות, @scope יכול להקל ומהנה יותר לכתוב CSS בר תחזוקה. קריאה נוספת
CSS @scope (MDN) "CSS @scope", חואן דייגו רודריגז (CSS-Tricks) הערות גרסה של Firefox 146 (Firefox) תמיכה בדפדפן (CanIUse) מסגרות CSS פופולריות (State of CSS 2024) "ה-C" ב-CSS: Cascade, תומאס ייפ (CSS-Tricks) מבוא BEM (קבל BEM)
