- From: François REMY <francois.remy.dev@outlook.com>
- Date: Wed, 8 Apr 2015 16:43:04 +0200
- To: <public-houdini@w3.org>
- Message-ID: <DUB405-EAS123372721AB02F1C9ACD178A5FC0@phx.gbl>
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