Mobile-First CSS: هل حان الوقت لإعادة التفكير؟

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

حسنا، ليس بالضرورة. يعتمد تطوير CSS الكلاسيكي للجوال أولاً على مبدأ الكتابة فوق إعلانات الأنماط: حيث تبدأ CSS الخاص بك بإعلانات الأنماط الافتراضية، وتستبدل و/أو تضيف أنماطًا جديدة عندما تضيف نقاط توقف باستخدام min-width استعلامات الوسائط لإطارات العرض الأكبر حجمًا (للحصول على نظرة عامة جيدة، راجع “ما هو Mobile First CSS ولماذا يتأرجح؟”). لكن كل هذه الاستثناءات تخلق التعقيد وعدم الكفاءة، الأمر الذي يمكن أن يؤدي بدوره إلى زيادة جهد الاختبار وقاعدة التعليمات البرمجية التي يصعب الحفاظ عليها. أعترف بذلك – كم منا يريد ذلك عن طيب خاطر؟

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

مزايا الهاتف المحمول أولاً

بعض الأشياء التي تعجبك في تطوير CSS للجوال أولاً – ولماذا كانت منهجية التطوير الفعلية لفترة طويلة – منطقية جدًا:

التسلسل الهرمي للتنمية. شيء واحد تحصل عليه بلا شك من الهاتف المحمول أولاً هو التسلسل الهرمي الجيد للتطوير – ما عليك سوى التركيز على عرض الهاتف المحمول والبدء في التطوير.

تمت تجربتها واختبارها. إنها منهجية مجربة ومختبرة وقد نجحت لسنوات لسبب ما: إنها تحل المشكلة بشكل جيد حقًا.

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

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

مساوئ الهاتف المحمول أولا

يمكن أن يؤدي تعيين إعلانات النمط ثم الكتابة فوقها عند نقاط توقف أعلى إلى نتائج غير مرغوب فيها:

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

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

يتطلب المزيد من اختبار الانحدار. تتطلب التغييرات التي يتم إجراؤها على CSS في العرض السفلي (مثل إضافة نمط جديد) اختبار الانحدار لجميع نقاط التوقف الأعلى.

لا يمكن للمتصفح تحديد أولوية تنزيلات CSS. في نقاط توقف أوسع، الهاتف المحمول الكلاسيكي أولاً min-width لا تستفيد استعلامات الوسائط من قدرة المتصفح على تنزيل ملفات CSS بترتيب الأولوية.

مشكلة تجاوز قيمة الممتلكات

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

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

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

على الرغم من أن هذا النهج لن يناسب الجميع، إلا أنني أشجعك على تجربته. هناك الكثير من الأدوات المتوفرة للمساعدة في التطوير المتزامن، مثل Responsively App وBlisk وغيرها الكثير.

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

نطاقات استعلام الوسائط المغلقة في الممارسة العملية

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

• أصغر من 768
• من 768 إلى أقل من 1024
• 1024 وأي شيء أكبر

خذ مثالاً بسيطًا حيث يكون لعنصر مستوى الكتلة قيمة افتراضية padding “20px”، والتي يتم استبدالها على الجهاز اللوحي لتصبح “40px” ويتم ضبطها مرة أخرى على “20px” على سطح المكتب.

.my-block {
  padding: 20px;
  @media (min-width: 768px) {
    padding: 40px;
  }
  @media (min-width: 1024px) {
    padding: 20px;
  }
}

.my-block {
  padding: 20px;
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

The subtle difference is that the mobile-first example sets the default padding to “20px” and then overwrites it at each breakpoint, setting it three times in total. In contrast, the second example sets the default padding to “20px” and only overrides it at the relevant breakpoint where it isn’t the default value (in this instance, tablet is the exception).

The goal is to: 

• Only set styles when needed. 
• Not set them with the expectation of overwriting them later on, again and again. 

To this end, closed media query ranges are our best friend. If we need to make a change to any given view, we make it in the CSS media query range that applies to the specific breakpoint. We’ll be much less likely to introduce unwanted alterations, and our regression testing only needs to focus on the breakpoint we have actually edited. 

Taking the above example, if we find that .my-block spacing on desktop is already accounted for by the margin at that breakpoint, and since we want to remove the padding altogether, we could do this by setting the mobile padding in a closed media query range.

.my-block {
  @media (max-width: 767.98px) {
    padding: 20px;
  }
  @media (min-width: 768px) and (max-width: 1023.98px) {
    padding: 40px;
  }
}

المتصفح الافتراضي padding بالنسبة للكتلة الخاصة بنا هي "0"، لذا بدلاً من إضافة استعلام وسائط سطح المكتب واستخدامه unset أو "0" ل padding القيمة (التي نحتاجها مع الهاتف المحمول أولاً)، يمكننا تغليف الهاتف المحمول padding في استعلام وسائط مغلق (نظرًا لأنه أصبح الآن استثناءً أيضًا) لذلك لن يتم التقاطه عند نقاط توقف أوسع. عند نقطة توقف سطح المكتب، لن نحتاج إلى تعيين أي منها padding style، لأننا نريد القيمة الافتراضية للمتصفح.

التجميع مقابل فصل CSS

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

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

ما هو إصدار HTTP الذي تستخدمه؟

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

ملاحظة: لعرض البروتوكول في أدوات التطوير الخاصة بالمتصفح الخاص بك، انتقل إلى شبكة علامة التبويب، أعد تحميل صفحتك، ثم انقر بزر الماوس الأيمن فوق أي رأس عمود (على سبيل المثال، اسم)، والتحقق من بروتوكول عمود.

وأيضًا، إذا كان موقعك لا يزال يستخدم HTTP/1...لماذا؟!! ماذا تنتظر؟ يوجد دعم مستخدم ممتاز لـ HTTP/2.

تقسيم CSS

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

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

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

ستختلف استعلامات الوسائط وعدد ملفات CSS المنفصلة من مشروع إلى آخر بناءً على متطلبات المشروع، ولكنها قد تبدو مشابهة للمثال أدناه.

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

المضي قدمًا

كان استيعاب CSS للجوال أولاً علامة فارقة مهمة في تطوير الويب؛ لقد ساعدت مطوري الواجهة الأمامية على التركيز على تطبيقات الويب المحمولة، بدلاً من تطوير المواقع على سطح المكتب ثم محاولة تحديثها للعمل على الأجهزة الأخرى.

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

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