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

Custom Layout and Inadvertent Style Updates

From: François REMY <francois.remy.dev@outlook.com>
Date: Wed, 8 Apr 2015 16:43:04 +0200
Message-ID: <DUB405-EAS123372721AB02F1C9ACD178A5FC0@phx.gbl>
To: <public-houdini@w3.org>
Welcome back to the Houdini’s black magic discussions,

Today, let me present you a case I believe is relevant to this working group
:

 

<grid>

    <grid-item class=a />

    <grid-item class=a />

    <grid-item class=b />

    <grid-item class=b />

</grid>

 

<style>

    grid > .b { display: none; }

    grid:hover > .b { display: block }

</style>

 

Let’s imagine a polyfill detects the grid, and set up the layout of all grid
items the appropriate way.

To achieve this effect, the polyfill will override the style of the grid
items in some way (style attribute, custom stylesheet, static animation,
whatever).

 

Now, as the mouse moves over the grid, the browser will make items “b”
appear but those will completely break the layout of the grid for a few
milliseconds before the polyfill can detect the change and react to it (make
the elements absolutely positioned, reorder the grid with automatic
placement, change its size, etc…). 

 

 

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. This
would also not work for the cases when you have to override the property to
achieve the layout you want (like setting a definite width/height as a way
to resolve ‘auto’).

 

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

 

In practice, the grid polyfill would setup a StyleTransitionControlller on
the grid element, and would ask that the style of any children of this
element would also go through this transition controller. That way, when the
cascaded value of “display” on the “.b” elements should be updated, the
effect is gated by the controller asynchronously accepting the change and
adapting the whole style at the same time to make sure things stay
consistent. This would make transitions and animations noticeably more
sluggish than native ones (though not more than with the current polyfills
for which the issue is very hard to solve) but if we can ask to control the
transitions of only a subset of all the properties, we could make things
like “opacity” and “transform” work seamlessly as they don’t directly impact
layout/rendering (in most cases).

 

An advantage of this over the current approach is that multiple
StyleTransitionController could be put after each other (composition) and
play nicely with each other, provided their operations do not conflict. 

 

 

What do you think? Do you have any better proposal that would solve this
problem, or ideas which could change the perspective I took on this issue?

 

Best regards,

François
Received on Wednesday, 8 April 2015 14:43:36 UTC

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