Re: Sticky Positioning

On Jun 28, 2012, at 8:01 PM, Alexandre Elias <aelias@chromium.org> wrote:

> It may help to reduce the vertical screen resolution in the developer tools panel as it seems to be sensitive to that.  But it sounds like you are visualizing it properly anyway.
> 
> > This means that every <h1> in the document will "stick" 10 pixels from
> > the viewport top when things scroll such that the <h1> would have been
> > partially off-screen. When the viewport has scrolled such that the
> > visible portion of the <h1>'s containing box is too small to fit the
> > <h1>, it should stop at the containing box's edge and only be partially
> > displayed.
> 
> Is it correct to say that this is equivalent to specifying "position: fixed; position-contain: parent" in the alternate proposal?  I.e. the <h1> is always fixed at 10px from the top of the viewport, unless that would bring it outside the bounds of its containing box, in which case its position is clamped to the containing box's edge.  In that case, I agree it addresses the google.com map example.

To the best of my understanding, given that both proposals are somewhat vague:

(1) I believe position: sticky with the appropriate other style rules (for margins or position) will do what you suggest.
(2) It's not *exactly* equivalent to "position: fixed; position-contain: parent", as I understand it, because it leaves a placeholder behind, like relative positioning, rather than taking the element completely out of flow, like fixed positioning. So with the position-contains solution, you would have to manually insert a placeholder in the containing box, while with position: sticky that is provided for you.

More generally, it seems to me that position: sticky handles a lot of different use cases, including ones previously not anticipated. Meanwhile, Tab's more elaborate proposal cannot replicate the exact behavior of position: sticky as written. And we don't have evidence of a real-world use case that can only be handled with a more elaborate proposal. Therefore, I would ask:

(A) Am I wrong, and can position-contains fully replicate the proposed position: sticky behavior in some way? Or is there a natural extension that would enable it to do so?
(B) Are there common real-world use cases that require the more complex proposal to be doable at all?

Regards,
Maciej

> 
> 
> 
> On Thu, Jun 28, 2012 at 2:25 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 
> On Jun 28, 2012, at 1:52 PM, Alexandre Elias <aelias@chromium.org> wrote:
> 
>> Sorry about that, looks like the behavior is currently restricted to Android.
>> 
>> You can simulate an Android browser in desktop Chrome (I tested the following using version 20 beta) by doing the following:
>> - Visit http://google.com/
>> - Click "Developer tools", then the small gear at the bottom right of the panel.
>> - Click "Override User Agent" and select "Android 2.3 - Nexus S" (not Galaxy Nexus as the high resolution somehow breaks the behavior I'm describing in this desktop simulation mode -- though it does happen on a real Galaxy Nexus)
>> - Reload the page to see the mobile version, then click "Restaurants" as before.
>> 
>> You should see the map is sticky, then appears to reach a limit and gradually falls out of view if you scroll down to the bottom of the page.
> 
> With these steps, I'm not able to replicate the behavior you describe. I see the map sticking, but not disappearing close to the bottom. I do see it tracking its container until it hits the top. What I see can definitely be replicated with position: sticky as proposed. I think the more complex behavior you describe can also be replicated with position: sticky, but I'm hesitant to say definitively without seeing the behavior first. Specifically, I think that if you make the sticky element's containing block stop short of the bottom of the page, you will get the described behavior. Again, I'm not 100% sure as I can't see it for myself yet.
> 
> Cheers,
> Maciej
> 
>