Defenda seus destinos! Posição - aderência ao WebKit

position: sticky é uma nova maneira de posicionar elementos e é conceitualmente semelhante ao position: fixed. A diferença é que um elemento com position: sticky se comporta como position: relative no pai, até que um determinado limite de deslocamento seja atingido na janela de visualização.

Casos de uso

Paráfrase da proposta original de Edward O'Connor para esse recurso:

Conheça o posicionamento fixo

Demonstração fixa

INICIAR DEMONSTRAÇÃO

Ao adicionar position: sticky (prefixado pelo fornecedor), podemos dizer que um elemento seja position: relative até que o usuário role o item (ou o pai) para ficar 15 px da parte de cima:

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

Em top: 15px, o elemento fica fixo.

Para ilustrar esse recurso em um ambiente prático, criei uma DEMONSTRAÇÃO que fixa os títulos do blog conforme você rola a tela.

Abordagem antiga: eventos de rolagem

Até agora, para usar o efeito aderente, os sites configuravam listeners de eventos scroll em JS. Nós também usamos essa técnica nos tutoriais do html5rocks. Em telas menores que 1.200 px, a barra lateral do sumário muda para position: fixed após uma certa rolagem.

Esta é a maneira (agora antiga) de ter um cabeçalho que permanece na parte superior da janela de visualização quando o usuário rola a tela para baixo e volta ao lugar quando o usuário rola para cima:

<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>

Teste: http://output.jsbin.com/omanut/2/

Isso é fácil, mas esse modelo vai ser detalhado rapidamente se você quiser fazer isso para vários nós do DOM, por exemplo, cada título <h1> de um blog à medida que o usuário rola a tela.

Por que o JavaScript não é o ideal

Em geral, gerenciadores de rolagem nunca são uma boa ideia. As pessoas costumam fazer muito trabalho e se perguntar por que a IU é instável.

Outro aspecto a considerar é que cada vez mais navegadores estão implementando a rolagem acelerada por hardware para melhorar o desempenho. O problema é que, quando os gerenciadores de rolagem do JS estão ativos, os navegadores podem voltar ao modo mais lento (software). Agora não estamos mais em execução na GPU. Em vez disso, estamos de volta à CPU. O resultado disso? Os usuários percebem mais instabilidade ao rolar a página.

Portanto, faz muito sentido que esse recurso seja declarativo no CSS.

Suporte

Infelizmente, não existe uma especificação para este caso. Ele foi proposto para o www-style em junho e acabou de chegar no WebKit. Isso significa que não há uma boa documentação para apontar. No entanto, de acordo com esse bug (link em inglês), se left e right forem especificados, left vencerá. Da mesma forma, se top e bottom forem usados ao mesmo tempo, top vencerá.

No momento, o suporte é o Chrome 23.0.1247.0+ (Canário atual) e o WebKit todas as noites.