تلميحات حول بنية CSS لمواقع الويب الخاصة بالعمل (أو أي منها لهذا الأمر)

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

ما المقصود بالعمارة هنا؟ إنها بنية كود CSS. الطريقة التي تفصل بها إلى ملفات ، والقواعد الكامنة وراء أسماء الفئات ، وعمق المحددات ، والطريقة التي تتتالي بها ، وما هو موروث ، وكيف تقوم بإعداد المكونات والصفحات والعناصر والمعدلات.

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

قم بالبناء باستخدام المكونات وليس الصفحات

هذا هو أحد الأجزاء الرئيسية التي يجب مراعاتها. لا ينبغي لك الأسلوب بناءً على الصفحة التي تتصفحها. لا تقم بعمل أنماط .homepage… {}. إذا كانت صفحتك تحتوي على قسم ، فقم بتصميم القسم. مع ذلك ، يمكنك إعادة استخدامه على صفحات أخرى أيضًا. إذا كان لديك زر ، حدد نمط الزر مثل .button {} وأعد استخدامه في مكان آخر. إنه صالح لجميع الآراء.

هذه هي النصيحة الأكثر شيوعًا وأفضل طريقة أداء (حتى الآن) يمكنك استخدامها.

الآن ، كيف تدير الاختلافات الخاصة بالصفحة؟ لأن هذا هو السبب الأكثر شيوعًا لتصميم كل صفحة؟ حسنًا ، هناك عدة طرق:

استخدم المعدلات.

في "BEM" ، يرمز الحرف "M" إلى المُعدِّل. هذا هو مظهر .block__child-modifier. حتى إذا كنت لا تستخدم BEM ، فإن المعدلات موجودة على أي حال. إذا كان هناك تباين لمكون أو قسم ، فأضف معدلاً له.

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

مكونات نمط الأطفال.

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

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

في هذه الحالة ، يمكنك النمط باستخدام محدد .parent .card {}. سيكون عليك فقط استبدال بعض الخصائص كما تفعل مع معدل. عند القيام بذلك ، لا تضيف البطاقة نفسها مزيدًا من التعقيد إلى أنماطها ، ولكنها ستظل تعمل بشكل صحيح في حالة الحافة المحددة هذه.

عندما تفكر في هذا ، يمكنك أيضًا معرفة كيفية تطبيقه على أساس "لكل صفحة". إذا كانت هناك بعض حالات الحواف الغريبة في التصميم وكانت هناك بعض الاختلافات الطفيفة عن طرق عرض المكونات القياسية (والطريقة التي تتفاعل بها جميعها معًا) ، فيمكنك تصميم ذلك باستخدام محدد الصفحة الرئيسية {}. فقط ضع في اعتبارك أن تستخدم ذلك باعتدال. في تجربتنا ، نادرًا ما تتجاوز هذه الأنماط بضعة أسطر من التعليمات البرمجية.

ملاحظة مهمة يجب إضافتها: لا تُعد الأساليب المتوافقة مع السياق ممارسة جيدة بشكل عام. من الناحية المثالية ، لا يجب عليك حتى ذلك. في معظم الأوقات ، سيكون لديك معدِّلات يجب أن تؤدي المهمة بشكل جيد بما فيه الكفاية. على الرغم من أنها واقعية في بعض البنيات ، إلا أن الغوص بعمق في كود مجردة جيد مع قواعد صارمة قد يكون مكلفًا للغاية.

العمل في الأقسام

تفصل معظم مواقع الويب التجارية (بالإضافة إلى العديد من المواقع الأخرى لهذا الأمر) المحتوى إلى أقسام. كل قسم هو مكون بمفرده مع فئة معدّل تحدد الخصائص المختلفة. أحد الاقتراحات التي يجب اتباعها مع هيكل الفئات هو:

• section.section-container - يمكن أن يكون هذا "اسم المكون" إذا أردت ، والذي يحمل الحشوات / الهوامش المتسقة أو كل ما هو مطلوب.
• section.section-border-top - معدّل. هذا لا يستخدم BEM ، ولكن يمكنك "ترجمته" إلى قسم - حاوية - حدود إذا لزم الأمر.
• section.section-welcome - سيكون اسم القسم.

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

فصل الملفات

على الأرجح ستستخدم Sass أو معالج مسبق آخر مشابه. فيما يتعلق بفصل الملفات ، هناك العديد من الطرق ، لكن الطريقة التي نتبعها تتبع الهيكل العام التالي:

• عام - بشكل عام يتكون عادةً من رمز الإعداد مثل عمل شبكة وأنماط لعلامات HTML وإعادة التعيين / المعياري وبعض الأنماط الخاصة بـ CMS وما شابه.
• الصفحات - أنماط الصفحة كما هو موضح أعلاه. من الناحية المثالية ، يجب أن تحتفظ بالقليل جدًا من التعليمات البرمجية هنا.
• المكونات - جوهر البناء - المكونات المختلفة موجودة هنا. نصيحة واحدة هي أنه يمكن أن يكون لديك "عناصر" أو "متنوع" من شأنها أن تلائم أجزاء أصغر من المكونات في ملف واحد بدلاً من 80 ملفًا. الأكبر بالطبع يجب أن يوضع في ملفات منفصلة.
• التخطيط - الأنماط العامة ، على سبيل المثال ، في الرأس والتذييل ثم تخطيطات الصفحة ومعدلات الشبكة وما إلى ذلك.
• الإضافات - أي شيء خارجي يتم إنشاؤه من ملحق أو ملحق أو أي شيء آخر. من الجيد فصلها حيث يمكنك إعادة استخدامها في مشاريع أخرى.

حافظ على نظافة المحددات

من العلامات الجيدة على الكود النظيف مدى بساطته. لا توجد خصائص غريبة ، كل شيء له غرضه ، هناك مسافة بادئة منخفضة. المحددات "التي تبدو ذكية" عندما لا تكون ضرورية لا تجعل شفرتك "رائعة". إذا كان بإمكانك استبدال شيء مثل #container> .row div [rel = ”something”] بـ .rel-something (تخيل أن هذا هو اسم فئة ذي معنى) ، فعليك فقط تحديث الترميز قليلاً. الهدف من ذلك هو إبقاء كل شيء أبسط.

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

.entry {...}
.عنوان الإدخال { ... }

تأكد من أنه لا توجد حاجة فعليًا إلى وضع مسافة بادئة لعنوان .entry داخل .entry. في وقت لاحق ، عندما تضيف معدلاً إلى أسفل الملف ، يمكنك الحصول على .entry-modifier {} و .entry-modifier .entry-title {}

مع هذا النهج ، فإن الكتابة فوق الأنماط في المستقبل أسهل بكثير. دعنا نلقي نظرة على مثال شائع آخر: لديك ترميز nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

الآن ، كل ما تحتاجه هو:

.site-nav {} - المكون 1

.list-menu {} - المكون 2
.list-menu .list-item {}
.list-menu a {}

إذا كان لديك المزيد من المكونات بالداخل ، مثل القوائم المنسدلة الإضافية ، فيمكنك تضمينها مباشرة داخل قائمة .list. ليس عليك كتابة .site-nav .list-menu .list-item .dropdown {} (4 مستويات عميقة) عندما يكون لديك مستويين من .list-menu .dropdown {}

اكتب المزيد من أسماء الفئات المجردة للمعدِّلات

هذا واحد يذهب للصيانة. من الأمثلة الشائعة التي قد تجدها في المنشورات المماثلة عدم تعيين متغير اللون على $ red ، بل يمكنك بدلاً من ذلك تعيينه على $ أساسي أو $ ثانوي.

والسبب هو أنه عند الحاجة إلى تغيير أسفل الخط ، فإن المتغير $ red سينتج اللون الأزرق. من المنطقي أنك تريد تغيير لونك الأساسي ، وليس لونك الأحمر ، أليس كذلك؟

ينطبق الشيء نفسه على أنواع أخرى من الألوان والخصائص. لنفترض أن لديك أسطرًا تفصل بين بعض المحتويات (مثل علامة <hr>). سمّيت ذلك. line-dash لأنه متقطع. يجعل الشعور بالكمال. ولكن بعد ذلك يأتي التغيير ويجب أن تكون منقطة. هل تذهب وتعيد تسميته إلى .line-dotted؟ هذا ليس معدلا ، هذا هو المكون. بدلاً من ذلك ، يمكنك تسميته باسم فاصل الأسطر. وبعد ذلك ، إذا كنت تريد أن تكون محددًا ، يمكنك إضافة مُعدِّل لـ. منقط أو. غالبًا ما يستغرق هذا النوع من التسمية معظم الوقت عند إنشاء موقع.

باختصار

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

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

الاستثمار في الأساسيات الجيدة سينتج عنه تقليل وقت الذهاب والعودة لمشاريعك وأي تغييرات مستقبلية يجب أن تحدث ستكون أسهل في التنفيذ.