عند تعلم مبادئ CSS الأساسية، يتم تعليم المرء كتابة أنماط معيارية وقابلة لإعادة الاستخدام ووصفية لضمان قابلية الصيانة. ولكن عندما ينخرط المطورون في تطبيقات العالم الحقيقي، غالبًا ما يكون من المستحيل إضافة ميزات واجهة المستخدم دون تسرب الأنماط إلى مناطق غير مقصودة. غالبًا ما تتحول هذه المشكلة إلى حلقة مفرغة من ذاتها؛ تبدأ الأنماط التي يتم تحديد نطاقها نظريًا لعنصر أو فئة واحدة في الظهور في المكان الذي لا تنتمي إليه. وهذا يفرض على المطور إنشاء محددات أكثر تحديدًا لتجاوز الأنماط المسربة، والتي تقوم بعد ذلك بتجاوز الأنماط العامة عن طريق الخطأ، وما إلى ذلك. تعد اصطلاحات أسماء الفئات الصلبة، مثل BEM، أحد الحلول النظرية لهذه المشكلة. تعد منهجية BEM (Block، Element، Modifier) طريقة منهجية لتسمية فئات CSS لضمان إمكانية إعادة الاستخدام والبنية داخل ملفات CSS. يمكن أن تؤدي اصطلاحات التسمية مثل هذه إلى تقليل الحمل المعرفي من خلال الاستفادة من لغة المجال لوصف العناصر وحالتها، وإذا تم تنفيذها بشكل صحيح، فيمكن أن تجعل أنماط التطبيقات الكبيرة أسهل في الصيانة. لكن في العالم الحقيقي، لا يسير الأمر دائمًا على هذا النحو. يمكن أن تتغير الأولويات، ومع التغيير يصبح التنفيذ غير متسق. يمكن أن تتطلب التغييرات الصغيرة في بنية HTML العديد من مراجعات أسماء فئات CSS. مع تطبيقات الواجهة الأمامية التفاعلية للغاية، يمكن أن تصبح أسماء الفئات التي تتبع نمط BEM طويلة وغير عملية (على سبيل المثال، app-user-overview__status--is-authenticating)، وعدم الالتزام الكامل بقواعد التسمية يكسر بنية النظام، وبالتالي يلغي فوائده. نظرًا لهذه التحديات، فلا عجب أن يلجأ المطورون إلى أطر العمل، حيث أن Tailwind هو إطار عمل CSS الأكثر شيوعًا. بدلاً من محاولة خوض ما يبدو وكأنه حرب خصوصية لا يمكن الفوز بها بين الأنماط، فمن الأسهل التخلي عن CSS Cascade واستخدام الأدوات التي تضمن العزلة الكاملة. يعتمد المطورون أكثر على المرافق كيف نعرف أن بعض المطورين حريصون على تجنب الأنماط المتتالية؟ إنه ظهور الأدوات الأمامية "الحديثة" - مثل أطر عمل CSS-in-JS - المصممة خصيصًا لهذا الغرض. قد يبدو العمل باستخدام أنماط معزولة تم تحديد نطاقها بإحكام لمكونات محددة بمثابة نسمة من الهواء النقي. إنه يلغي الحاجة إلى تسمية الأشياء - التي لا تزال واحدة من أكثر المهام الأمامية المكروهة والمستهلكة للوقت - ويسمح للمطورين بأن يكونوا منتجين دون الفهم الكامل لفوائد وراثة CSS أو الاستفادة منها. لكن التخلص من CSS Cascade يأتي بمشاكله الخاصة. على سبيل المثال، يتطلب إنشاء الأنماط في JavaScript تكوينات بناء ثقيلة وغالبًا ما يؤدي إلى تداخل الأنماط بشكل غريب مع ترميز المكونات أو HTML. بدلاً من اصطلاحات التسمية المدروسة بعناية، نسمح لأدوات البناء بإنشاء المحددات والمعرفات تلقائيًا لنا (على سبيل المثال، .jsx-3130221066)، مما يتطلب من المطورين مواكبة لغة زائفة أخرى في حد ذاتها. (كما لو أن العبء المعرفي لفهم ما تفعله تأثيرات الاستخدام الخاصة بالمكون الخاص بك لم يكن كافيًا بالفعل!) إن تجريد مهمة تسمية الفئات إلى الأدوات بشكل أكبر يعني أن تصحيح الأخطاء الأساسي غالبًا ما يكون مقيدًا بإصدارات تطبيقات محددة تم تجميعها للتطوير، بدلاً من الاستفادة من ميزات المتصفح الأصلية التي تدعم تصحيح الأخطاء المباشر، مثل أدوات المطور. يبدو الأمر كما لو أننا بحاجة إلى تطوير أدوات لتصحيح الأخطاء التي نستخدمها لاستخلاص ما يوفره الويب بالفعل - كل ذلك من أجل الهروب من "ألم" كتابة CSS القياسية. لحسن الحظ، ميزات CSS الحديثة لا تجعل كتابة CSS القياسية أكثر مرونة فحسب، بل تمنح المطورين أمثالنا أيضًا قدرًا أكبر من القوة لإدارة التتالي وجعله يعمل لصالحنا. تعد طبقات CSS المتتالية مثالًا رائعًا، ولكن هناك ميزة أخرى تحظى بنقص مفاجئ في الاهتمام - على الرغم من أن هذا يتغير الآن بعد أن أصبحت متوافقة مع Baseline مؤخرًا. CSS @scope At-Rule أنا أعتبر أن قاعدة CSS @scope هي علاج محتمل لهذا النوع من القلق الناجم عن تسرب الأسلوب الذي قمنا بتغطيته، وهو علاج لا يجبرنا على التنازل عن مزايا الويب الأصلية للتجريد وأدوات البناء الإضافية. "تمكّنك قاعدة @scope CSS من تحديد عناصر في أشجار فرعية محددة من DOM، واستهداف العناصر بدقة دون كتابة محددات محددة بشكل مفرط يصعب تجاوزها، ودون ربط محدداتك بإحكام شديد ببنية DOM." - MDN
بمعنى آخر، يمكننا العمل باستخدام أنماط معزولة في حالات محددة دون التضحية بالوراثة أو التعاقب أو حتى الفصل الأساسي بين الاهتماماتلقد كان هذا مبدأ توجيهيًا طويل الأمد لتطوير الواجهة الأمامية. بالإضافة إلى ذلك، فهو يتمتع بتغطية متصفح ممتازة. في الواقع، أضاف Firefox 146 دعمًا لـscope في ديسمبر، مما يجعله متوافقًا مع Baseline لأول مرة. فيما يلي مقارنة بسيطة بين زر يستخدم نمط BEM مقابل قاعدة @scope: <زر فئة = "زر زر--أساسي">
<نمط> .button .button__text { /* أنماط نص الزر */ } .button .button__icon { /* أنماط أيقونة الزر */ } .button--primary { أنماط الزر الأساسي */ }
<زر فئة = "الزر الأساسي"> انقر فوقي ←
<نمط> @النطاق (.الزر الأساسي) { فترة:الطفل الأول { /* أنماط نص الزر */ } Span:last-child { /* أنماط أيقونة الزر */ } }
تسمح قاعدة @scope بالدقة مع تعقيد أقل. لم يعد المطور بحاجة إلى إنشاء حدود باستخدام أسماء الفئات، مما يسمح له بدوره بكتابة محددات بناءً على عناصر HTML الأصلية، وبالتالي يلغي الحاجة إلى أنماط أسماء فئات CSS الإرشادية. بمجرد إزالة الحاجة إلى إدارة اسم الفئة، يمكن لـscope أن يخفف من المخاوف المرتبطة بـ CSS في المشاريع الكبيرة.
الاستخدام الأساسي
للبدء، أضف قاعدة @scope إلى CSS الخاص بك وأدخل محددًا جذريًا للأنماط التي سيتم تحديد نطاقها:
@النطاق (<المحدد>) {
/* الأنماط المحددة للمحدد
لذلك، على سبيل المثال، إذا أردنا تحديد نطاق الأنماط لعنصر
@النطاق (الملاحة) { a { /* أنماط الارتباط ضمن نطاق التنقل */ }
a:active { /* أنماط الارتباط النشطة */ }
a:active::before { /* رابط نشط مع عنصر زائف لمزيد من التصميم */ }
@media (أقصى عرض: 768 بكسل) { أ { /* التعديلات المستجيبة */ } } }
وهذه، في حد ذاتها، ليست ميزة رائدة. ومع ذلك، يمكن إضافة وسيطة ثانية إلى النطاق لإنشاء حد أدنى، وتحديد نقاط البداية والنهاية للنطاق بشكل فعال.
/* أي عنصر داخل ul لن يتم تطبيق الأنماط عليه */ @النطاق (التنقل) إلى (ul) { أ { حجم الخط: 14 بكسل؛ } }
تُسمى هذه الممارسة نطاق الدونات، وهناك العديد من الأساليب التي يمكن استخدامها، بما في ذلك سلسلة من المحددات المماثلة والمحددة للغاية والمقترنة بإحكام ببنية DOM، أو محدد غير زائف، أو تعيين أسماء فئات محددة لعناصر داخل
الاستنتاج تعمل أطر عمل CSS ذات الأداة المساعدة الأولى، مثل Tailwind، بشكل جيد مع النماذج الأولية والمشاريع الصغيرة. ومع ذلك، فإن فوائدها تتضاءل سريعًا عند استخدامها في مشاريع أكبر تضم أكثر من اثنين من المطورين. لقد أصبح تطوير الواجهة الأمامية معقدًا بشكل متزايد في السنوات القليلة الماضية، وCSS ليس استثناءً. على الرغم من أن قاعدة @scope ليست علاجًا شاملاً، إلا أنها يمكن أن تقلل الحاجة إلى أدوات معقدة. عند استخدامه بدلاً من تسمية الفئة الإستراتيجية أو بجانبها، يمكن أن يجعل @scope كتابة CSS قابلة للصيانة أسهل وأكثر متعة. مزيد من القراءة
CSS @النطاق (MDN) "CSS @scope"، خوان دييغو رودريغيز (CSS-Tricks) ملاحظات إصدار Firefox 146 (فايرفوكس) دعم المتصفح (CanIUse) أطر عمل CSS الشائعة (حالة CSS 2024) ""C" في CSS: Cascade"، توماس ييب (CSS-Tricks) مقدمة BEM (احصل على BEM)
