خطأ الاستعلام عن وسائط CSS الكبير

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

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

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

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

ما الخطأ في استعلامات وسائط CSS

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

1. ليس بديهيًا:

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

 شاشةmedia only و (min-width: 320px) و (max-width: 480px) {
    / ** قواعد CSS تذهب هنا ** /
}

ينطبق الكود أعلاه على منفذ العرض عندما يكون بين 320 و 480 بكسل. ومع ذلك ، ليس الأمر نهائيًا [أو حدسيًا] تمامًا عندما تريد القيام بشيء أكثر تحديدًا ، مثل تطبيق قاعدة نمط عندما يكون الجهاز عبارة عن جهاز لوحي في وضع أفقي. ليس من المستحيل [نوعًا] تعيين استعلام وسائط للقيام بذلك ، لكنه بالتأكيد ليس بديهيًا - أو نهائيًا.

2. المشروطية المحدودة:

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

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

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

3. غير قابل للتوسيع محليًا:

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

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

بالطبع ، هناك طريقة لتوسيع CSS ، لكن عليك أن تعرف JavaScript جيدًا ، وهي ليست عملية عملية لمعظم مصممي الويب.

4. غير مناسب للتعديل التحديثي:

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

لسوء الحظ ، لا تعد استعلامات وسائط CSS خيارًا جيدًا لهذه المهمة. نظرًا لأن مواقع الويب هذه قد تم إنشاؤها قبل أن تكون الأجهزة المحمولة ذات صلة ، فإن الكثير منها يحتوي على عناصر تصميم لا تصلح لتصميم الويب سريع الاستجابة ، مثل الأشرطة الجانبية ، والتخطيطات المستندة إلى الجدول ، والمحتوى المبوب ، وما إلى ذلك أيضًا ، هناك نسبة كبيرة من مواقع الويب هذه. مبني على نظام إدارة محتوى (CMS) مثل WordPress و Drupal و Magento وما إلى ذلك ، ودمج استعلامات وسائط CSS [الواجهة الأمامية] بشكل فعال من النهاية الخلفية يصعب للغاية تنسيقه تقريبًا.

اضطررت إلى تعديل مواقع الويب التي تدعمها Magento Enterprise و WordPress وواحدة تستخدم نظام إدارة محتوى مخصصًا يعتمد على Coldfusion ، وكان من الممكن أن تكون جميع المشاريع مستحيلة تمامًا باستخدام استعلامات وسائط CSS [وهو ما حاول جميع عملائي قبل استخدام بديلنا نهج].

5. ليس رمزًا فعالاً:

يتطلب استخدام استعلامات وسائط CSS لجعل صفحة الويب مستجيبة مضاعفة التعليمات البرمجية على نطاق واسع. نظرًا للطريقة التي تعمل بها هذه التوجيهات [مع نقاط التوقف الخاصة بك] ، يتعين عليك تحديد قواعد النمط الفردية في كل كتلة استعلام عن الوسائط.

 قسم {العرض: 960 بكسل ؛}

/* لوحة */
شاشةmedia only و (min-device-width: 320px) و (max-device-width: 480px) و (-webkit-min-device-pixel-ratio: 2) and (direction: portrait) {
    قسم {العرض: 100٪}
}
/* منظر جمالي */
شاشةmedia only و (min-device-width: 320px) و (max-device-width: 480px) و (-webkit-min-device-pixel-ratio: 2) and (direction: Landscape) {
    قسم {العرض: 100٪ ؛}
}

عند كتابة الكود أعلاه ، كان هدفي الأساسي هو جعل عناصر <section> على صفحتي مرنة [عرض 100٪] في جميع الأجهزة المحمولة. ومع ذلك ، نظرًا لأنني لا أمتلك القدرة الأصلية على اكتشاف الجهاز ، يتعين عليّ التنازل عن قاعدة نمط وتعريفها في كل كتلة استعلام وسائط CSS موجهة للجوّال للتأكد من تطبيق الخاصية الجديدة في جميع السيناريوهات ذات الصلة.

هذا يعني أن الكفاءة الوظيفية لسلسلة ورقة الأنماط ومبادئ التطوير الجيدة لـ Do-not-Repeat-Yourself يجب أن تأخذ مقعدًا خلفيًا.

6. يزيد من تعقيد سير العمل:

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

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

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

7. يسوء الأداء:

نظرًا للطريقة التي تعمل بها استعلامات وسائط CSS ، سينتهي بك الأمر إلى احتياجك إلى الكثير من رموز CSS أكثر من غيرها لجعل موقع الويب الخاص بك مستجيبًا / مناسبًا للجوّال. وفقًا لبيانات من HTTPArchive.org ، زادت أحجام ملفات CSS بنسبة 114٪ خلال السنوات الخمس الماضية. بلغت الزيادة في أحجام ملفات HTML ذروتها عند حوالي 53٪ خلال نفس الفترة.

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

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

لماذا ما زلنا نستخدم هذا؟

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

تبلغ النسبة المئوية لمواقع الويب التي تستخدم استعلامات وسائط CSS عبر الويب بالكامل حوالي 0.2٪. قارن ذلك مع نسبة المواقع التي تستخدم jQuery بنسبة 18٪. ما يعنيه ذلك هو أنه من المرجح أن تصادفك موقعًا إلكترونيًا مدعومًا من jQuery بنسبة 90 مرة أكثر من كونك موقعًا سريع الاستجابة [لا يشمل المواقع التي تصادف أن تكون كلاهما].

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

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

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

ماهو الحل؟

الحل لكل هذا بسيط جدًا حقًا: JavaScript. الآن ، قبل أن تلتقط مذراة تلك ، أعطني فرصة للشرح.

JavaScript هو المكون الوحيد لثلاثية HTML5 حيث لا تكون القابلية للتوسعة كلمة قذرة. لا يمكنك توسيع ترميز HTML باستخدام المزيد من HTML ، وأنت متأكد من أنه لا يمكنك توسيع CSS أصليًا باستخدام CSS. ومع ذلك ، يمكنك توسيع JavaScript محليًا باستخدام JavaScript ، ويمكنك حتى أن تفعل الشيء نفسه مع CSS.

تتم مناقشة معالجة CSS باستخدام JavaScript على نطاق واسع في منهج معايير الويب الخاص بـ W3C. تتيح لنا واجهة DOM الخاصة بـ document.stylesheets إمكانية الوصول إلى أوراق الأنماط المطبقة على صفحة الويب ، بما في ذلك جميع أوراق الأنماط الخارجية المُشار إليها باستخدام علامة <link> الخاصة بـ HTML. إنه ليس بالأمر السهل ، لكنه ممكن.

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

أرني بعض الكود

على مدار العامين الماضيين أو نحو ذلك ، كنت أعمل على مجموعة أدوات CSS جديدة بمساعدة JavaScript تسمى rKit. كانت الفكرة بأكملها هي بناء أداة صديقة للمصممين ليس فقط لاستبدال استعلامات وسائط CSS لتصميم الويب سريع الاستجابة ، ولكن لمعالجة بعض التحديات المعروفة [وغير المعروفة] التي يواجهها مصممو / ​​مطورو الويب عند إنشاء مواقع الويب وتطبيقات الويب الحديثة.

هناك الكثير للمفهوم ، ولكن إليك مقتطف رمز سريع من CSS لشرح:

 # my-element [rk = "if @ viewport.width بين 320 و 480"] {background-color: # 0000ff؛}

مع rKit ، تبدو قواعد CSS مثل محددات قيمة السمات المعدلة. يمكنك بعد ذلك تحديد تعبير داخل قسم القيمة. تم تصميم بناء جملة هذا التعبير ليكون بسيطًا وبديهيًا.

ملاحظة : rk هو معرف سمة ثابت.

الكود أعلاه مكافئ وظيفيًا لاستعلام وسائط CSS أدناه:

 شاشةmedia only و (min-device-width: 320px) و (max-device-width: 480px) {
    # عنصري {background-color: # 0000ff؛}
}

ومع ذلك ، هناك الكثير الذي يمكنك فعله باستخدام rKit. إليك مثال سريع آخر:

 # my-element [rk = "if @ self.width بين 320 و 480"] {background-color: # 00ff00؛}

بمجرد تغيير مرجع الكيان من @viewport إلى @self ، قمنا بشكل أساسي بإعداد ما يشار إليه عادةً باسم استعلام العنصر. ما يحدث الآن هو أنه عندما يكون عرض #my-element بين 320 و 480 بكسل ، فسيتم تطبيق التصريح المعطى [ background-color: #00ff00 ].

يمكنك أيضًا استخدام الفئات بدلاً من الإعلانات البحتة:

 # my-element [rk = "if @ self.width بين 320 و 480 ثم addClass (c_mobile_320)"] {}
.c_mobile_320 {background-color: # 00ff00؛}

هذا مجرد غيض من فيض بالرغم من ذلك. باستخدام rKit ، يمكنك القيام ببعض الأشياء الرائعة مثل إدارة الأحداث ، ومراقبة الطفرات ، والاستعلامات الكمية ، والتوجيه ، وربط البيانات [حتى 7 طرق] ، ومجموعة من الأشياء الرائعة الأخرى ، وكل ذلك باستخدام كود CSS خالص ، وبدون كتابة سطر واحد من JavaScript.

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

لقد استغرق الأمر وقتًا طويلاً لوضع هذا معًا ، ولكنه سيكون هنا قريبًا [بالتأكيد قبل Godot] ، وأنا مهتم حقًا بمعرفة ما يمكن لمصممي الويب [والمطورين] فعله به.

خاتمة

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

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

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

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