Re: Maintaining the offset of content relative to its overflow box

Thank you for the feedback! I generally like the simplified proposal but
have some inline comments.

On 9/6/12 2:03 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
>I have a few problems with this proposal.  I suspect that the details
>of your proposal were strongly influenced by the JS library you were
>using; we can do better when we control the language.
>
>1. It's way too specific.  You need to predict what zone of the
>element you'll be inserting things in.  I think we can do this
>automatically.

I'd love to see browsers determine this, but there are some edge cases
that might be better handled by web page authors. One example is a
scrollable box with a fixed/sticky header. When new content is inserted in
the bounds of the scroll area but under the sticky header, scroll
compensation should still be applied.

>2. It's not general enough.  You only cover element insertion.
>Element deletion, or just an element changing size, still causes
>shifting in the scroll area.  We can generalize this and cover those
>cases automatically.

Absolutely! Content pinning/stabilization should certainly apply to those
other cases.

>Here's an alternate proposal:
>
>scroll-adjust: none | stable  (not super happy with the property name,
>but roll with it)

I like the simplicity of this proposal but I'm concerned that page authors
will want more flexibility. The intent behind scroll stabilization is to
pin the content that is at the center of the user's focus. Web pages
generally have a better notion of what that content is (but perhaps not
where it is positioned). I think it would suffice if a page could denote a
reference element in a scroll area and let the user agent apply scroll
stabilization; for example (with inspiration from -moz-element):

..scroll-area {
  scroll-adjust: stable;
  scroll-adjust-reference: element(#post-12345-comment-reply-textarea);
}

One use case this tries to solve is that of a real-time comment thread
with an "Add Comment" text area at the bottom of the thread and visible in
the scrollable viewport. Live updates to the comment thread will push down
the text area, which can be disruptive once the user has started typing a
reply. With "scroll-adjust-reference", however, the user agent can maintain
the text area's visible position.

>The "stable" value adjust the scroll position of an element in some
>circumstances.  Call the element with this property set the
>"stabilized element".  If the stabilized element's children change
>width or height for any reason (used values), and the child's
>head/start edge is outside the current visible scroll area of the
>stabilized element in the head/start direction, adjust the scroll
>position of the stabilized element by the amount the width/height
>changed.

While I've mentioned some edge cases that may need a more granular
property, I do think this heuristic is appropriate for many use cases and
is better than the status quo. I think it would be fine to pursue a more
flexible property in a future level if others agree.

One other point of discussion is whether scroll stabilization should fire
scroll events. I'm inclined to say they should since the
scrollTop/scrollLeft of the scroll area element is altered. (FWIW,
removing the body content of a scrolled page does fire a scroll event on
the document.)

Regards,
James

Received on Sunday, 9 September 2012 06:37:18 UTC