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

On Sun, Aug 17, 2014 at 11:53 AM, Arthur Stolyar <> 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

> 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.


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