position: sticky
เป็นวิธีใหม่ในการวางองค์ประกอบและมีแนวคิดคล้ายกับ position: fixed
ความแตกต่างคือองค์ประกอบที่มี position: sticky
จะทํางานเหมือน position: relative
ภายในองค์ประกอบหลัก จนกว่าจะถึงเกณฑ์ออฟเซตที่ระบุในวิวพอร์ต
กรณีการใช้งาน
ข้อความต่อไปนี้เป็นข้อความถอดความจากข้อเสนอดั้งเดิมของ Edward O’Connor สำหรับฟีเจอร์นี้
ขอแนะนำการจัดตำแหน่งแบบติดหนึบ
เพียงเพิ่ม position: sticky
(คำนำหน้าของผู้ให้บริการ) เราก็บอกได้ว่าองค์ประกอบเป็น position: relative
จนกว่าผู้ใช้จะเลื่อนรายการ (หรือรายการหลัก) ให้อยู่ห่างจากด้านบน 15 พิกเซล
.sticky {
position: -webkit-sticky;
position: -moz-sticky;
position: -ms-sticky;
position: -o-sticky;
top: 15px;
}
เมื่อถึง top: 15px
องค์ประกอบจะกลายเป็นแบบคงที่
เราได้จัดทำตัวอย่างที่แสดงชื่อบล็อกค้างไว้ขณะเลื่อนเพื่อแสดงให้เห็นถึงฟีเจอร์นี้ในการใช้งานจริง
แนวทางแบบเก่า: เหตุการณ์การเลื่อน
ที่ผ่านมาเว็บไซต์ต้องตั้งค่า scroll
Listener เหตุการณ์ใน JS เพื่อให้เกิดผลแบบติดหนึบ เราใช้เทคนิคนี้ในบทแนะนำของ html5rocks ด้วย ในหน้าจอที่เล็กกว่า 1, 200 พิกเซล แถบด้านข้างของสารบัญจะเปลี่ยนเป็น 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>
ของบล็อกทุกหัวเรื่องเมื่อผู้ใช้เลื่อน
เหตุผลที่ JS ไม่เหมาะ
โดยทั่วไปแล้ว ตัวแฮนเดิลการเลื่อนไม่ใช่ตัวเลือกที่ดี ผู้คนมักจะทํางานมากเกินไปและสงสัยว่าทําไม UI จึงทำงานขัดข้อง
อีกสิ่งหนึ่งที่ควรพิจารณาคือเบราว์เซอร์จํานวนมากขึ้นกําลังใช้การเลื่อนที่เร่งด้วยฮาร์ดแวร์เพื่อปรับปรุงประสิทธิภาพ ปัญหาที่เกิดขึ้นคือเมื่อใช้ตัวแฮนเดิลการเลื่อน JS เบราว์เซอร์อาจกลับไปใช้โหมด (ซอฟต์แวร์) ที่ช้ากว่า ตอนนี้เราไม่ได้ใช้งานบน GPU แล้ว แต่เราจะกลับไปที่ CPU ผลลัพธ์ที่ได้ก็คือ ผู้ใช้รับรู้ถึงความกระตุกมากขึ้นเมื่อเลื่อนหน้าเว็บ
ดังนั้น การมีฟีเจอร์ดังกล่าวใน CSS จึงเป็นเรื่องที่สมเหตุสมผล
การสนับสนุน
ขออภัย รายการนี้ไม่มีข้อมูลจำเพาะ เราได้เสนอใน www-style เมื่อเดือนมิถุนายนที่ผ่านมาและเพิ่งเปิดตัวใน WebKit ซึ่งหมายความว่าไม่มีเอกสารประกอบที่ชัดเจนที่จะชี้ไป อย่างไรก็ตาม โปรดทราบว่าตามข้อบกพร่องนี้ หากมีการระบุทั้ง left
และ right
ระบบจะเลือก left
ในทํานองเดียวกัน หากมีการใช้ top
และ bottom
พร้อมกัน top
จะเป็นผู้ชนะ
ขณะนี้รองรับ Chrome 23.0.1247.0 ขึ้นไป (Canary ปัจจุบัน) และ WebKit เวอร์ชันรายวัน