RE: Custom Layout and Inadvertent Style Updates

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

Interesting. Is that specced anywhere? I'm having issues in IE for instance with that model.
Also, sometimes changes do not happen as a result of a DOM Mutation (like :hover in the quoted example) making things harder.

In addition, javascript layout (like the CSS Regions polyfill) can be quite
slow and breaking it across frames may help keep the site responsive
on slower devices like smartphones.

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

Sure, once we have a "custom layout event", we won't need that part, I agree with you. Still...
(If your polyfill waits for a real layout, how do you keep up with multiple polyfills acting one after another? That seems hard to me.)


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

Yes, exactly. The "StyleTransitionController" also acts as a Runtime Style for the element. We want to get the browser to continue to resolve style while, at the same time, setting up a different style for layout/rendering purposes. Like I said, a huge challenge for polyfills would be to compose because, right now, two instances of my polyfills wouldn't see eachother style and would likely clash. 

The idea of the StyleTransitionController is to provide you the following things:
- The browser resolves the style as usual, gives you an event when it changes
- You can override that style (without affecting any stylesheet, or the element's style)
- Finally, once you're happy with the style, you pass it along to the next polyfill (if any) -- this would allow a flexbox polyfill to transform the layout into a grid layout, and have that grid layout transformed to an absolute-position layout by another polyfill
- Repeat until the last polyfill has made the tweaks he wanted, then let the browser use that style for layout/rendering.

The fact you are not forced to transition the style synchronously is just a nice to have, the fact you can listen for arbitrary changes and go through a polyfill chain is more important, actually.


Does that clarify the intent a little more?

Received on Wednesday, 8 April 2015 22:22:16 UTC