Re: Custom Layout and Inadvertent Style Updates

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.


> > While I don’t argue it’s the best/simplest/most adequate one, a better
> > solution to this problem would be a more advanced version of the
> > StyleMutationObserver I proposed to the list before (reminder: it would
> ping
> > you every time a property  is updated on an element). This evolution,
> called
> > the StyleTransitionController, would provide you with the same behavior,
> in
> > addition to let you surimpress your values on the top of what the
> browsers
> > thinks is the current value of the property. In effect, this would act
> as a
> > post-processing to the cascaded style (i.e. you can perform any arbitrary
> > operation on the cascaded style before it is used by the browser for
> > layout/rendering purposes).
>
> Yeah, I think something like this is gonna be part of the necessary
> custom-property improvements we need for custom layout.  Obviously a
> lot of custom layout will be driven by custom properties, which don't
> have any effect until you give them one, but I think we want to allow
> you to "take over" an existing property and control it in the same
> way, at least for some values and some elements.  I know there's been
> some private discussion between me and the Sydney googlers in the past
> about a very similar use-case to what you're presenting here.
>
> In this case, you'd take over the 'display' property children of your
> custom layout element; attempted changes to the value would alert you,
> just like changes to any registered custom properties, so you could do
> what you needed to do before setting the value for real.  (As a more
> general example, you might need to blockify the 'display' values of
> any children.)
>
>
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.

- E