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

Hi,

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

That 'll be good.
Thanks for answer and clarifications.


2014-08-18 17:51 GMT+03:00 Tab Atkins Jr. <jackalmage@gmail.com>:

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



-- 
@nekrtemplar <https://twitter.com/nekrtemplar>