W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-containment] For what problems is CSS Containment the best solution?

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 18 Feb 2014 20:13:10 -0800
Message-ID: <CALRQH78ijgZw4Rh3AptKhoFY-spubSet6X0t6Rf6kgf9xBuYng@mail.gmail.com>
To: robert@ocallahan.org
Cc: www-style <www-style@w3.org>
On Tue, Feb 18, 2014 at 12:34 PM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> I was thinking about the best way to implement CSS rendering of large data
> sets and wrote my thoughts down in blog (and demo) form:
> http://robert.ocallahan.org/2014/02/implementing-virtual-widgets-on-web.html
> In summary, for maximum scalability you want to dynamically create and
> recycle DOM elements so that the size of your DOM is proportional to the
> amount of visible data, not the amount of data available. This can be
> implemented reasonably well on the Web platform, though there are a couple
> of small API extensions that would make it work better. If you take this
> approach, CSS Containment is not needed or even particularly helpful.
>
> So, for what use-cases is CSS Containment a better solution than such
> DOM-recycling techniques? I don't know.
>

If to speak about problem of virtual lists, ones that use sliding
window / buffer
of DOM elements then, indeed, there are solutions already available.

Here is an idea for lists with items of fixed height (A):
http://terrainformatica.com/w3/vlist-idea.png
scrollbar there reflects total pixel height of items. This
works reasonably well, check http://sergimansilla.com/blog/virtual-scrolling/

But if you have collection of items of variable height (B)
(example: http://www.terrainformatica.com/wp-content/uploads/2012/03/2.0.0.16.png
)
that approach does not work. I was experimenting on this
while ago and here is requirements to the platform that I've got:

1. overflow:hidden elements shall be programmatically scrollable
    so it should be able to use vlist.scrollTo(x,y);
    This way you can change visual position of sliding buffer
    without need of changing [absolute] positions items (that's quite heavy
    and does not play quite well if you need kinetic scroll).
2. If scrollbar is required then it should be some way to create "detached"
    scrollbar, something like overflow:hidden-scrollbar.
    On such element scrollbar will not reflect content size/position -
    but scrollbar values (max/min/page/position) shall be driven by code.
    In this case it (scrollbar) will reflect position of sliding buffer inside
    the list (record set).
3. As an alternative to #2 HTML should provide something like
    <input type=scrollbar orientation=vertical>, that
   will allow to achieve Windows alike scrollbars but not
   scroll indicators a la iOS.
4. It should be a way to declare overflow:hidden
    as "positioning root" - any positioned element
    inside it shall be contained in container's box and clipped by
    element's boundaries.

I've made experiments implementing "B" virtual list by
adding support of 1,3 and 4 in Sciter
(sciter-sdk/sdk/samples/ideas/virtual-list/vertical.htm)
and it works really well. Having flexible scroll mechanism
is significantly more "GPU friendly" for the purpose
of virtual lists then that 'contain' property.

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Wednesday, 19 February 2014 04:13:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC