scroll-container

[Michael Büttner]

there are currently several locations in upcoming implementations were
it's necessary to provide scrolling content. in this context scrolling
means to have some arbitrary content which may be larger than its
enclosing frame and the user should be able to scroll the content by
dragging a scrollbar. some locations where this functionality would be
necessary are for example a) the 24hr views and b) the free/busy control
(timebar and grid).

the first option is of course to use the existing scrollbox tag. the
following list outlines the drawbacks of this approach:

- scrollbox does not inherit the 'flex' attribute, thus its size always
stays fixed.
- several methods of the nsIScrollBoxObject interface are not implemented.
- the layout of the scrollbox and its associated scrollbar is limited
(the scrollbar has always the same size as the scrollbox).
- scrollbox doesn't allow for scrolling tricks (keep content area within
artificial limits, etc.)
- nsIScrollBoxObject interface is only functional if associated
scrollbars are visible.

many of those issues can be considered as major drawbacks of this
approach since it renders even relatively simple situations impossible.
imagine a single scrollbar which would need to drive the content of
several distinct other controls. this would fail miserably by utilizing
a scrollbox. of course there are ways to circumvent this specific
problem but in order to solve all of the above mentioned drawbacks i
came up with the following binding: http://mozilla.pastebin.com/705044

basically this 'scroll-container' is just a box with the overflow-style
set to 'hidden' and allowing for arbitrary content positioning by
changing the margin attributes. this alternative approach circumvents
all the limiting factors of the scrollbox tag. of course there's the
need for some form of driver in order to utilize the scroll-container.
here's an example of how this could be done:
http://mozilla.pastebin.com/705049

I mentioned 'scrolling tricks' in the list of drawbacks, which I feel
needs some further explanation. For example the timebar shown above the
free/busy-grid (see https://bugzilla.mozilla.org/show_bug.cgi?id=324657)
is currently implemented by making some not-so-obvious use of the above
introduced scroll-container. the problem is to show an arbitrary number
of date/time-strings besides each other. the user should be able to
scroll through this list by using a scrollbar. the number of these
strings could range from a dozen to several hundreds. but i didn't want
to create as many tags as there are strings, because it would be a waste
of precious resources (not to mention that this approach would be slow,
of course). the solution is to utilize the above introduced
scroll-container and just create as many xul-tags (xul:text in this
case) as are needed to fill the content area of the enclosing frame,
plus one additional element. in other words, assume 2 strings fit within
the container, 3 strings are created, 2 of them are visible, the last
one of course not. right where the content offset for the
scroll-container will be calculated, the offset gets clipped to the size
of a single element (the width of one string in this case) while
changing the real content (the value of the 3 strings in this case) on
the fly. this allows us to scroll through all the available elements, no
matter how much of them we want to display, without actually creating
all of them. this form of tricks of course can't be utilized by using
the available scrollbox. all of this can already be seen in action,
please refer to the available extension attached to the above mentioned bug.

i would like to hear any comments on this proposal, since my current
intension would be to provide the scroll-container binding for the
calendar base and clearly there are numerous possible refinements to
this proposal i'm currently not aware of.

mickey.

[Mike Beltzner]

On 5/8/06, Michael Büttner <michael....@sun.com> wrote:
> i would like to hear any comments on this proposal, since my current
> intension would be to provide the scroll-container binding for the
> calendar base and clearly there are numerous possible refinements to
> this proposal i'm currently not aware of.

I'm not really qualified to discuss the technical merits, but I like
the user interface implications of what you're saying. You should get
in touch with Neil Deakin (and perhaps repost this to dev.platform or
dev.tech.xul) to get input from some of the deeper-thinking XULers.

cheers,
mike

--
/ mike beltzner / user experience lead / mozilla corporation /

[Michael Büttner]

Mike Beltzner wrote:
> I'm not really qualified to discuss the technical merits, but I like
> the user interface implications of what you're saying. You should get
> in touch with Neil Deakin (and perhaps repost this to dev.platform or
> dev.tech.xul) to get input from some of the deeper-thinking XULers.

thanks for the hint, I'll cross-post it at dev.tech.xul.

mickey.