position: sticky
is een nieuwe manier om elementen te positioneren en is conceptueel vergelijkbaar met position: fixed
. Het verschil is dat een element met position: sticky
zich gedraagt als position: relative
binnen zijn bovenliggende element, totdat een bepaalde offsetdrempel wordt bereikt in de viewport.
Gebruiksgevallen
Parafraseren van het oorspronkelijke voorstel van Edward O'Connor voor deze functie:
Maak kennis met sticky positionering
Door eenvoudigweg position: sticky
(leverancier voorafgegaan) toe te voegen, kunnen we vertellen dat een element position: relative
totdat de gebruiker door het item (of het bovenliggende item) scrolt zodat het 15px vanaf de bovenkant staat:
.sticky {
position: -webkit-sticky;
position: -moz-sticky;
position: -ms-sticky;
position: -o-sticky;
top: 15px;
}
top: 15px
, het element wordt vast.
Om deze functie in een praktische setting te illustreren, heb ik een DEMO samengesteld die blogtitels vasthoudt terwijl je scrollt.
Oude aanpak: scrollgebeurtenissen
Om het plakkerige effect te bereiken, stelden sites tot nu toe scroll
-gebeurtenislisteners in JS in. We gebruiken deze techniek ook in html5rocks-tutorials. Op schermen kleiner dan 1200 px verandert onze zijbalk met de inhoudsopgave van position: fixed
na een bepaalde hoeveelheid scrollen.
Hier is de (nu oude manier) om een koptekst te hebben die aan de bovenkant van de viewport blijft hangen wanneer de gebruiker naar beneden scrolt, en weer op zijn plaats valt wanneer de gebruiker naar boven scrolt:
<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>
Try it: http://output.jsbin.com/omanut/2/
Dit is eenvoudig genoeg, maar dit model faalt snel als je dit voor een aantal DOM-knooppunten wilt doen, bijvoorbeeld elke <h1>
titel van een blog terwijl de gebruiker scrollt.
Waarom JS niet ideaal is
Over het algemeen zijn scroll-handlers nooit een goed idee. Mensen hebben de neiging om te veel werk te doen en vragen zich af waarom hun gebruikersinterface janky is.
Iets anders om te overwegen is dat steeds meer browsers hardwareversneld scrollen implementeren om de prestaties te verbeteren. Het probleem hiermee is dat op JS scroll-handlers in het spel zijn, browsers kunnen terugvallen in een langzamere (software) modus. Nu draaien we niet meer op de GPU. In plaats daarvan zijn we weer terug bij de CPU. Het resultaat? Gebruikers merken meer jank wanneer ze op uw pagina scrollen.
Het is dus heel logisch om een dergelijke functie declaratief te hebben in CSS.
Steun
Helaas is er geen specificatie voor deze. Het werd in juni voorgesteld op www-style en is zojuist in WebKit beland . Dat betekent dat er geen goede documentatie is om naar te verwijzen. Er is echter één ding om op te merken: volgens deze bug wint left
als zowel left
als right
zijn opgegeven. Op dezelfde manier, als top
en bottom
tegelijkertijd worden gebruikt, wint top
.
Ondersteuning op dit moment is Chrome 23.0.1247.0+ (huidig Canary) en WebKit nightly.