Re: [css-will-change] Value 'contents'

On Sun, Aug 17, 2014 at 11:53 AM, Arthur Stolyar <nekr.fabula@gmail.com> wrote:
> Hello,
>
> As a Front-end developer I have few questions about will-change: contents;
> value because in my mind it's more complicated than others.
>
> Specification says:
>> Indicates that the author expects to animate or change something about the
>> element’s contents in the near future.
> | For example, browsers often “cache” rendering of elements over time,
> because most things don’t change very often, or only change their position.
> However, if an element does change its contents regularly, producing and
> maintaining this cache is a waste of time. A browser might take this value
> as a signal to cache less aggressively on the element, or avoid caching at
> all and just continually re-render the element from scratch. |
>
> But it does not really tells to developer when usage of this property is
> more positive or negative (just because many did not know how really works
> browser rendering cache).
>
> Please, consider few examples:
>
> 1. Webapp
>
> <div class="app">
>   <div class="screen"></div>
> </div>
>
> First example is about building webapp. We have one container named 'app'
> and one child represented current screen of app. Time to time screen in app
> changes to another screen (user navigates). So we can say we expect to
> change content of 'app' and want to use will-change: contents;, But in the
> same time, we do not want to loose cache (if it exists) of particular
> 'screen' inside the 'app'.
>
> Does it 'll works like I described or in this case developer should avoid
> use of will-change: contents; property?

The kinds of optimizations I expect and describe for "contents" means
that you shouldn't use it here - it'll treat the "contents" element as
a leaf node in the painting cache tree, and not save any of its
children.

> 2. Chat
>
> <div class="chat-messages">
>   <div class="chat-message"></div>
>   <div class="chat-message"></div>
>   <div class="chat-message"></div>
>   <div class="chat-message"></div>
> </div>
>
> In second example we want to build some chat. Again, we have one container
> which contains all of messages, but for now there in the same time may be
> more than one element inside the container (more than one 'chat-message').
> Time to time to container we add 'chat-message' blocks (users chatting) and
> probably remove very older messages (for example those what exited limit of
> 100). For this example again, we can say that we 'll change the content of
> 'chat-message', therefore want to use will-change: contents;. But absolutely
> we do not want to loose cache of particular 'chat-message' block because
> most of then still exists on the screen/inside the container. How browser
> 'll behave in this situation?

Same deal - don't do it on container elements that contain complex
cacheable content.

More importantly, though, occasionally adding or removing chat
messages is not nearly enough to consider it "changing regularly".

I'll see if I can make this value clearer with examples.

> There not a lot of articles about browser rendering caching, especially for
> web developers, hence sorry me if I ask obvious things.
>
> And main questions of this post:
> Did will-change: contents; property means that browser 'll not cache entire
> render tree of given element or it means that browser 'll not compute one
> bitmap from all children, but 'll keep cache for individual child elements
> and on render signal 'll combine them?

It probably means the former. The latter is more or less what happens
now anyway, with some dynamicism in the way it works.

~TJ

Received on Monday, 18 August 2014 14:51:56 UTC