W3C home > Mailing lists > Public > public-houdini@w3.org > April 2015

Re: Custom Layout and Inadvertent Style Updates

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 8 Apr 2015 14:31:02 -0700
Message-ID: <CAAWBYDBtJw94yHF60Xhg+P1LgQb0OPwgeR_OFwQe6RXuuRP9SA@mail.gmail.com>
To: Elliott Sprehn <esprehn@chromium.org>
Cc: François REMY <francois.remy.dev@outlook.com>, "public-houdini@w3.org" <public-houdini@w3.org>
On Wed, Apr 8, 2015 at 2:17 PM, Elliott Sprehn <esprehn@chromium.org> wrote:
> On Wed, Apr 8, 2015 at 2:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Apr 8, 2015 at 7:43 AM, François REMY
>> <francois.remy.dev@outlook.com> wrote:
>> > A workaround to this problem would be “transition: {
>> > properties=all-even-unanimatable: duration=0s; delay=33ms }” which would
>> > give some time to the polyfill to fixup things before the changes go
>> > live,
>> > but this would be horribly hacky, I agree. We can definitely do better.
>> To be clear for those following along at home, this hack forces the
>> property to not *actually* update until the delay is satisfied, 33ms
>> later.  The intent here is to give François' library about 30ms (1-2
>> frames) to do fix-up work before the style changes take effect "for
>> real".
> Why do you need time to do fixup? Using MutationObserver and
> requestAnimationFrame you should never miss a frame.

Don't pay too much attention to specifics here; François is just
talking about hacks that are currently necessary to watch for layout
changes and respond in a timely manner.

> A custom property should be able to define if changing it dirties layout or
> paint. Then changing such a property on a child will mark it for layout,
> which will then cause the parent to do a layout. You don't need to listen
> for actual changes on your children, the engine does it.

Yeah, you're right, this actually comes for free.  Changing 'display'
on the child will dirty its layout, which'll dirty its parent's
layout, etc.  We'll then do a layout sweep, during which the parent
gets to do whatever work it needs to do, now that its child is
visible.  Only *then*, after all that, will we actually paint a frame.
This means that nothing special needs to be done to make this use-case
work correctly.

(You still need to be able to take over children's property values so
that you can, as in the example I provided, blockify their 'display'
value, etc.  But that's separate.)

Received on Wednesday, 8 April 2015 21:31:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:23 UTC