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:02:14 -0700
Message-ID: <CAAWBYDB4504j3zGu35nYZd27haqoyRMaW298tPSQd+49Kiwaow@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: "public-houdini@w3.org" <public-houdini@w3.org>
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".

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

~TJ
Received on Wednesday, 8 April 2015 21:03:01 UTC

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