كتابة لغة CSS جيدة

أحاول دائمًا تعلم أشياء جديدة. ومع ذلك ، أحاول أيضًا تعلم طرق لتحسين الطريقة التي أفعل بها الأشياء بالفعل. في كل من عملي بدوام كامل وفي المشاريع الجانبية للعملاء ، كان الشيء الذي كنت أرغب دائمًا في تحسينه هو CSS الخاص بي. لطالما شعرت أنني بحالة جيدة جدًا عندما يتعلق الأمر بـ CSS ، لكنني دائمًا ما أجد صعوبة في القراءة ، وغالبًا ما يصعب الحفاظ عليها.

ما كنت أحاول القيام به هو معرفة ما يجعل CSS جيدة وقابلة للقراءة ويمكن صيانتها. أعتقد أنني توصلت (ووجدت) بعض الطرق لجعل كل هذا ممكنًا.

المشكلات

هناك العديد من الأشياء التي تزعجني بشأن CSS. أكثر مضايقاتي شيوعًا هي:

• تكرار الكود المشترك
• بادئات المتصفح
• قلة التعليقات
• على المحددات المؤهلة
• أسماء الطبقة الفقيرة

عندما يتعلق الأمر بمشاريعي الشخصية ، أتحمل المسؤولية الكاملة عن الكود الخاص بي. نادرًا ما أعلق على CSS الخاص بي ، وغالبًا ما أتعامل معه على أنه فكرة لاحقة. هذا مجرد خطأ.

لفترة طويلة كنت أحسب أن أسماء صفي "دلالية" وأنا فقط أقوم بأشياء ، لذلك ليست هناك حاجة لشرح الكود ، أو القليل من "الاختراقات" ، أو أي شيء.

العودة إلى الكود في مشروع طويل الأمد يثبت بسرعة أن هذه النظرية خاطئة جدًا .

عندما يتعلق الأمر بالكود في العمل ، لا يمكنني تحمل كل اللوم. في الواقع ، جزء من المشكلة هو عدد الأشخاص الذين وضعوا أيديهم هناك. يضم فريقنا حاليًا سبعة منا ممن كتبوا في وقت ما CSS لمواقعنا ، مع 6-8 آخرين جاءوا وذهبوا سنوات. يتمتع كل عضو في الفريق بمستويات مختلفة من المعرفة والقدرة فيما يتعلق بـ CSS.

بالإضافة إلى ذلك ، كما هو الحال غالبًا مع المشروعات طويلة الأمد ، فإن بعض التعليمات البرمجية قديمة . الكثير منها قبل CSS3 ، أو ما قبل أي اتجاه كان رائعًا قبل 5 سنوات. في كلتا الحالتين ، غالبًا ما كانت هناك طرق مختلفة للقيام بالأشياء في وقت كتابتها ، وفي بعض الحالات ، نقص طبيعي في المعرفة.

لقد تعلمت أيضًا أن بعض المبرمجين سيصرون على أن شفرتهم "توثق ذاتيًا". إذا لم تكن معتادًا على هذا المصطلح ، فسيتم ترجمته إلى "لا تحتوي التعليمات البرمجية الخاصة بي على تعليقات".

حلول

بينما لا يوجد شيء مثالي ، أعتقد أن هناك أشياء يمكننا القيام بها لتحسين الكود الخاص بنا. لقد اكتشفت إرشادات CSS بواسطة Harry Roberts منذ فترة. إنه يتوافق مع الوعد بتقديم "نصائح وإرشادات رفيعة المستوى لكتابة CSS عاقلة وقابلة للإدارة وقابلة للتطوير".

تعليقات

بينما تقدم إرشادات CSS تفاصيل حول أنماط التعليقات ، فأنا شخصياً أحاول فقط وضع شيء ما لأخبرني في المستقبل بما كنت أفكر فيه. أبدأ كل مكون بتعليق يمثل العنوان ، وتفاصيل عن الغرض من المكون.

عند استخدام المعالج المسبق ، أقوم بتصميم تعليقات محددة إما لتضمينها في CSS ، أو يتم تخطيها بواسطة المعالج المسبق. ما زلت أعمل على هذا الجزء ، وأحاول التعود على وضع شيء ما ، أي شيء .

اتجاه الكائن

توجيه الكائن هو نموذج برمجة يقسم الأشياء الكبيرة إلى أشياء صغيرة. من ويكيبيديا:

البرمجة الشيئية (OOP) هي نموذج برمجة يمثل مفهوم "الكائنات" [...] والتي تكون عادةً حالات للفئات ، [و] تُستخدم للتفاعل مع بعضها البعض لتصميم التطبيقات وبرامج الكمبيوتر.

عندما يتعلق الأمر بـ CSS ، فإننا نطلق على هذا CSS الموجه للكائنات أو OOCSS . المفهوم الأساسي يكسر بنية العنصر ، من جلد العنصر. هذا يعني أنه يمكننا بسهولة إعادة استخدام أي أنماط تصميم متكررة ، دون الحاجة بالضرورة إلى إعادة استخدام تفاصيل التنفيذ المحددة في نفس الوقت. يركز OOCSS بشكل كبير على إعادة استخدام الكود ، مما يجعلنا أسرع ، ويمكن أن يحافظ على حجم قاعدة الكود لدينا منخفضة.

أفكر في الجوانب الهيكلية مثل الهياكل العظمية. الإطارات الشائعة التي تعطي بنيات تعرف باسم الكائن . هذه الأشياء عبارة عن أنماط تصميم بسيطة خالية من أي مستحضرات تجميل. نقوم بتجريد الهيكل من مجموعة من المكونات من أجل الحصول على كائن عام.

ثم نضيف طبقة "الجلد" اختياريًا إلى بنيتنا حتى نتمكن من إعطاء التجريدات مظهرًا وإحساسًا محددًا. على سبيل المثال (مأخوذ من إرشادات CSS):

 / **
 * كائن زر بسيط وخالي من التصميم. تمديد هذا الكائن بسطح ".btn - *`
 * صف دراسي.
 * /
.btn {
    عرض: مضمنة كتلة ؛
    الحشو: 1em 2em ؛
    محاذاة عمودية: وسط ؛
}

/ **
 * جلد الأزرار الإيجابية. يمتد `.btn`.
 * /
.btn - إيجابي {
    لون الخلفية: أخضر ؛
    اللون الابيض؛
}

/ **
 * جلد الأزرار السلبية. يمتد `.btn`.
 * /
.btn - سلبي {
    لون الخلفية: أحمر؛
    اللون الابيض؛
}

نرى هنا كيف أن فئة .btn توفر ببساطة بنية لعنصر ، ولكن ليس لها أي شيء يتعلق بمستحضرات التجميل. يمكننا تمديد .btn ثانية ، مثل .btn--positve لمنح هذا العنصر تصميمًا أكثر تحديدًا:

 <button class = "btn btn - إيجابي"> موافق </ زر>

أفضل استخدام فئات متعددة في HTML الخاص بي ، على استخدام شيء مثل @extend في المعالج المسبق. يمنحني هذا مزيدًا من الوضوح في HTML الخاص بي مما يسمح لي برؤية الفئات التي يتم تطبيقها على العنصر الخاص بي بسرعة. هذا يعني أيضًا أن فصولي ليست مرتبطة ارتباطًا وثيقًا بالأنماط الأخرى في CSS الخاص بي. إنه نوع من يساعد OOCSS على اتباع مفاهيم التغليف .

BEM

BEM ( Block ، Element ، Modifier ) ​​هي منهجية للواجهة الأمامية تم تطويرها في Yandex. BEM هو في الواقع منهجية كاملة للغاية ، وأنا بصراحة لم أتعمق في كل التفاصيل ، ولكن ما يهمني هو ببساطة اصطلاح التسمية.

أنا أستخدم BEM- مثل اصطلاحات التسمية. المفهوم هو نفسه ، لكن التركيب الدقيق قد يختلف قليلاً.

يضع BEM الفصول في ثلاث مجموعات:

1. الكتلة: جذر أو قاعدة المكون
2. العنصر: مكون داخل الكتلة
3. المعدل: تغيير أو امتداد للكتلة

تشبيه أساسي للغاية ( ليس كمثال):

 .كلب {}
.dog__tail {}
.dog - صغير {}

يتم تحديد العناصر بشرطتين (__) ، والمعدلات محددة بشرطتين (-).

في القياس أعلاه ، نرى أن .dog هو الكتلة ، جذر العنصر. إذن ، .dog__tail هو عنصر ، وهو جزء أصغر من كتلة .dog . أخيرًا ، .dog--small هو المعدل ، وهو شكل مختلف من .dog Block. يمكنك أيضًا تطبيق المعدِّلات على Elements. على dog__tail المثال ، يمكن أن يكون .dog__tail--short .

في بعض الحالات ، قد أريد كلمات متعددة للكتل أو العناصر أو المعدلات. على أي حال ، يتم فصلها بشرطة واحدة (-) ، ويتم كتابة الفئات دائمًا بأحرف صغيرة .

المعالجات

لقد أمضيت وقتًا في العمل مع معالجات CSS المسبقة في تدفق عملي ، وحتى الآن ، كانت قيمة للغاية. تأخذ معالجات CSS المسبقة التعليمات البرمجية المكتوبة بلغة مُعالجة مسبقًا وتحويلها إلى CSS قديمة جيدة. إنها ليست CSS ، مما يعني أنها ليست ملزمة بنفس القواعد والقيود الخاصة بـ CSS. على الرغم من أن CSS رائعة ، إلا أنها لا تسمح لنا دائمًا بالقيام بالأشياء التي نرغب في القيام بها بسهولة.

على سبيل المثال ، الشيء الوحيد الذي سيكون رائعًا حقًا في CSS هو المتغيرات . ربما تريد أن يكون الهامش الأيسر لعنصر ما مساويًا لعرض عنصر آخر ، وفجأة يقرر أحدهم أن هذه الأرقام بحاجة إلى التغيير. نظرًا لأنهم نفس الرقم ، وقد يعتمد التخطيط الخاص بك على هذا الرقم ، يجب عليك تغييره أكثر من مكان واحد. ولكن مع المتغير يمكنك تغييره في مكان واحد فقط وجعله ينعكس في التخطيط بالكامل. بالطبع ، هناك الكثير من المعالجات المسبقة أكثر من مجرد المتغيرات ، ولكن هذه بداية!

من الواضح أنك لست مضطرًا إلى استخدام معالج مسبق ، لكنني أعتقد أنك ستجد معظم الأشخاص الذين يفعلون ذلك ، لن يعودوا. أعلم أنني لن أفعل. لا يمكنني التخلي عن اكتساب المرونة وإمكانية القراءة المتزايدة. يكفي ببساطة أن تكون قادرًا على استخدام المتغيرات والخلطات لإبقائي مدمن مخدرات.

هناك العديد من المعالجات التمهيدية المتاحة ، ولكن المعالجات الوحيدة التي نظرت إليها واستخدمتها على الإطلاق هما LESS و SASS . يرجى إلقاء نظرة ، والنظر في إضافة واحدة من هؤلاء إلى سير العمل الخاص بك ، فلن تنظر إلى الوراء.

خاتمة

نقطتي الحقيقية هنا هي أن CSS يمكن أن تكون أفضل. كل شيء يمكن أن يكون أفضل. أخبرني أحدهم مؤخرًا في تعليق على منشور على Reddit أن "CSS لا تحتوي على دلالات". أنا أعارض بصدق. CSS 100٪ ، بدون أدنى شك يمكن أن تكون دلالية.

في الواقع ، يمنح استخدام OOCSS و BEM CSS معنى دلاليًا للغاية. هذا لا يعني أنه من السهل القيام به فورًا ، لكنه يستحق الاستكشاف. قم بدمج ذلك مع معالجات CSS الأولية ، وستكون لديك القدرة على الحصول على CSS سهل القراءة للغاية ، ويمكن صيانته ، وقابل للتطوير .

أود أيضًا أن أشير إلى أن هذا لا يجعل CSS الخاص بك (معالج مسبقًا أم لا) أكثر قابلية للقراءة فحسب ، بل يجعل HTML أيضًا أكثر قابلية للقراءة ، من خلال تطبيق أسماء الفئات الدلالية على العناصر.

TL ؛ DR

حسنًا ، ربما كان هذا كثيرًا - للتلخيص ، اكتب CSS أفضل من خلال القيام بذلك:

كائن المنحى CSS :

• كل فصل يفعل شيئًا واحدًا - إنه يفعله جيدًا ، إنه يفعله بشكل صحيح

أسماء فئات نمط Block ، Element ، Modifier (BEM) :

• الحظر: .grid
• العنصر: .grid__item (2 شرطة سفلية)
• المعدل: .grid--wide (2 واصلتين)

المعالجات الأولية رائعة :

• تحقق منها: أقل - ساس
• أو ابحث عن آخرين: 8 معالجات CSS أولية لتسريع وقت التطوير