- From: Corey Ford <cford@mozilla.com>
- Date: Fri, 12 Jul 2013 16:48:36 -0700
- To: www-style@w3.org
- CC: Robert O'Callahan <robert@ocallahan.org>
Some clarifications (having discussed this with roc today): On 7/12/13 9:37 AM, Corey Ford wrote: > For any of 'top', 'bottom', 'left', and 'right' that are not 'auto', > if the box's normal position would cause that edge of its margin box > to be less than the specified distance within that paddingedge of its > scrolling container, the box is repositioned to that distance from the > edge, such that the box doesnot move while the container scrolls. The > distance the box is repositioned is limited such that the element's > margin box never crosses the oppositeedge of the content box of its > containing block, with the effect thatthe element starts scrolling > with its container again when it reaches the end of its containing block. For sticky elements that generate multiple boxes, there are several options for what exactly to keep contained inside the containing block / viewport. WebKit appears to keep the farthest edges in each direction contained, which seems sensible (similar to how the containing block for position:center is established in the current css3-positioning draft). > Note: Sticky positioned elements are considered 'positioned', so are > z-ordered according to the same rules asrelatively positioned > elements, and establish the containing block of absolutely positioned > descendants. A sticky positioned element always creates a new stacking context. Corey Ford
Received on Friday, 12 July 2013 23:49:04 UTC