التزم بعمليات الهبوط! الموضع - هبوط في WebKit

إريك بيدلمان

position: sticky هي طريقة جديدة لتحديد موضع العناصر وتشبه من الناحية النظرية position: fixed. ويتمثّل الاختلاف في أنّ العنصر الذي يتضمّن position: sticky يتصرف مثل position: relative داخل العنصر الرئيسي، حتى يتم استيفاء حد إزاحة معيّن في إطار العرض.

حالات الاستخدام

مقولة من الاقتراح الأصلي لإدوارد أوكونور حول هذه الميزة:

نقدّم لك ميزة تحديد الموضع الثابت

عرض توضيحي ثابت

إطلاق عرض توضيحي

من خلال إضافة position: sticky (بادئة البائع)، يمكننا تحديد العنصر ليكون position: relative إلى أن يمرر المستخدم العنصر (أو عنصره الرئيسي) ليكون 15 بكسل من الأعلى:

.sticky {
    position: -webkit-sticky;
    position: -moz-sticky;
    position: -ms-sticky;
    position: -o-sticky;
    top: 15px;
}

في top: 15px، يصبح العنصر ثابتًا.

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

الأسلوب القديم: أحداث التنقّل

حتى الآن، تعمل المواقع الإلكترونية على إعداد أدوات معالجة أحداث scroll في JavaScript، وذلك لتحقيق التأثير الثابت. نحن في الواقع نستخدم هذا الأسلوب بالإضافة إلى البرامج التعليمية في html5rocks. على الشاشات الأصغر من 1200 بكسل، يتغيّر الشريط الجانبي لجدول المحتويات إلى position: fixed بعد قدر معيّن من التمرير.

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

<div class="header"></div>

<script>
var header = document.querySelector('.header');
var origOffsetY = header.offsetTop;

function onScroll(e) {
    window.scrollY >= origOffsetY ? header.classList.add('sticky') :
                                    header.classList.remove('sticky');
}

document.addEventListener('scroll', onScroll);
</script>

جرِّبه: http://output.jsbin.com/omanut/2/

هذا الإجراء سهل بما فيه الكفاية، ولكن هذا النموذج ينهار سريعًا إذا كنت تريد تنفيذ ذلك لمجموعة من عُقد DOM، مثلاً، كل عنوان <h1> للمدوّنة أثناء انتقال المستخدم في الصفحة.

لماذا لا تُعد لغة JavaScript مثالية

وبوجه عام، لا تُعد معالِجات التمرير فكرة جيدة أبدًا. يميل الفولاذيون إلى القيام بالكثير من الأعمال ويتساءلون عن سبب بطء واجهة المستخدم لديهم.

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

وبالتالي، من المنطقي أن تكون هذه الميزة وصفية في CSS.

الدعم

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

يتوفر الآن Chrome 23.0.1247.0 أو إصدار أحدث (إصدار Canary الحالي) وWebKit كل ليلة.