كيف تكتب CSS رهيبة حقا

يتحدث الجميع عن "نصائح" و "نصائح احترافية" لكتابة CSS رائعة.

هذا جيد ، ولكن ربما ستعطيك رؤية شكل CSS السيئ منظورًا مختلفًا. هيك ، قد يكون لك بعض الخير!

اسمح لي أن آخذك في رحلة حول كيفية كتابة CSS سيئة حقًا.

جاهز؟

ملاحظة: حتى إذا أقسمت بـ CSS-in-JS ولا تحب Vanilla CSS ، فإننا نتفق جميعًا على شيء: لا يزال علينا جميعًا معرفة بعض CSS ...

لذلك ، سواء كنت تكتب CSS ، أو مجموعة شاملة مثل SASS ، أو CSS-in-JS فقط ، فستظل تستفيد من معرفة شكل CSS السيئ بالضبط.

من يكتب التعليقات؟ لا أحد.

من السهل جدًا أن تنزلق إلى هنا بحيث لا تلاحظ بسرعة كبيرة.

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

كم هو ذكي ، أليس كذلك؟

ضع كبريائك جانبًا ، ووفر على نفسك وزملائك في الفريق التوتر.

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

أرض المحددات المعقدة

بلى! لقد تعلمت للتو CSS وتشعر بأنك على قمة العالم. لذا ، حان الوقت لاظهار بعض عضلات المحدد.

حركة سيئة.

من خلال إجراء التحديدات باستخدام عدد كبير جدًا من محددات CSS ، ربما تكون قد نجحت في جعل CSS غير قابل للإدارة للغاية. وهو يعتمد الآن بشكل كبير على بنية HTML لتطبيقك.

إذا تغيرت بنية الترميز بشكل طفيف ، فستحتاج إلى إعادة تشكيل CSS أيضًا. ليس أسهل سير العمل.

ما عليك سوى إضافة فئة إلى العنصر والاستمرار في الحياة!

حتى في السيناريوهات التي تحتاج فيها إلى تأهيل محددات بفئات متعددة ، تفضل دائمًا بالبساطة.

البساطة جيدة ، دائمًا تقريبًا!

أداء؟ تخلص من ذلك!

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

لكن انتظر…

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

من المحتمل أن تقرأ من خلال محدداتك من اليسار إلى اليمين.

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

إذا كنت تعرف هذا ، فمن المحتمل أن تكون أكثر تساهلاً مع المتصفحات. إنهم يستحقون حبك.

بالنظر إلى المثال البياني أعلاه ، سيطابق المتصفح جميع العناصر (*) ويتحقق أيضًا مما إذا كانت من نسل body.

body * { ... } 

لكن لماذا؟ تقريبًا كل عنصر مرئي هو بشكل مثالي سليل لـ dy> element. That’s just a needless inefficient check.

I Suck at Naming Things, so I don’t even bother.

There are only 2 hard things in computer science. Naming things and …

Yeah, I think you already heard that somewhere. Naming things can be hard, but that doesn’t mean you shouldn’t give them some thought, or go completely cryptic.

I doubt there’s any situation where it makes sense to use single letters as class names.

.u { font-size: 60rem;}

And what about super-specific class names?

.former-black-now-red-paragraph { color: red;}

Those don’t do any good, either.

While the name may seem to convey some meaning, you very likely have broken a huge part of the class’s re-usability. Which, by the way, is the primary reason for having classes.

Now, if you wanted to style a regular red the paragraph, the previous name is just so specific, it wouldn’t make sense.

Use meaningful names, but just don’t overdo it.

I Heard Classes were Great. Overuse them!

Classes are great, and everyone loves them. But, as with everything else, too much of something is generally a bad idea.

You see, if a group of classes will mostly be used together, just group them into one class.

When you choose to group these classes is perhaps subjective. If you’re building an atomic library of some sort, you may tend towards this.

If you’re writing a large app, you’re likely better off grouping classes in a meaningful way, as opposed to having a ton of classes on a single element.

When possible, avoid over modularised classes.

I am a CSS Purist. I don’t do SASS, LESS, etc.

You’re a CSS purist, I’m a CSS purist, we’re both purists. Let’s get that out of the way.

Now, to the bone of contention.

There are definitely use cases where just writing vanilla CSS is great! For example, if I’m not using a CSS-in-JS solution for my React projects, I could decide to go the pure CSS route. It doesn’t hurt.

However, if you’re writing a large app with a ton of vanilla CSS flying around, I bet introducing a CSS preprocessor will make your development more interesting and contribute towards a more maintainable CSS codebase.

Again, I’m not saying use preprocessors every single time. I’m saying don’t just close out that option. It could save you!

You’ve got a lot of Important Style there!

I hate CSS. It just never works. So, what’s the fix?

Have a ton of !important all over the place when I need to override any declarations. Haha!

While this sounds like a decent plan to your lazy self, over-using the !important rule will only result in a grossly unmaintainable CSS document.

The next time you need to use !important, be sure you’re not doing so because you’re too lazy to fix your cascade issues.

CSS isn’t that bad. Embrace it.

Want to write Better CSS?

I have created a free CSS guide to get your CSS skills blazing, immediately. Get the free ebook.