Re: [css-props-vals] First iteration of L1 spec

> Given the order in which polyfills are going to be executed can be defined
> as the order in which they register (see notes later), and given that this
> order can be freely altered by the author of the webpage, I don’t see any
> reason to believe an user-level framework can do anything which cannot be
> provided by the browser, in this case. Enforcing a framework for the sake
> of enforcing a framework looks sad to me.
>
> Moreoever, requiring the use of a user-level framework (like my own
> Parallia) at the spec level is something I want to discourage strongly. If
> polyfills have to cooperate at the user level, it’s pretty clear that the
> author of the most popular polyfills will somehow force others to use the
> same framework and this framework will become a requirements for years to
> come. I, for once, don’t want my polyfill framework to becomes the next
> JQuery in 10 years, which everyone seems forced to use because plugins
> depend on it, but it actually provides no value except providing a
> legacy-inspired interface to technologies the browser provide natively. I
> want people to be able to innovate in this sector, and by requiring a
> common user-level framework we clearly are not helping people to innovate.
>
You're assuming that all that is required is ordering, done by the author.
Multiple other domains have the exact same requirement, and are causing
problems right now.

One that springs to mind it requestAnimationFrame. Specifically, if the
things that needed to sense layout position registered first or last, then
web pages would perform markedly better than they do (no spurious recalcs).
Because of the nature of the web (mashups, loading third-party code, etc.)
this is pretty much impossible to make happen.

Why are these areas causing problems, if all that is required is a global
author-provided order?

This is the coordination problem in a nutshell, and it is *hard*. When you
control all the source, you can do things like decorators; but as soon as
you're relying on third parties (including polyfills) all of that goes out
the window.


>  Finally, dealing with other people’s plugins is something that doesn’t
> look much harder to me than supporting new native additions to the
> platform. Many plugins or components you’ll find on the web today assume
> “box-sizing: content-box” to work properly. Adding any new property that
> affects layout will probably make it harder for polyfills to work properly;
> whether it’s a native property or a polyfilled one doesn’t make it any
> different. That’s fine, it’s just a limitation of polyfills that they often
> can’t work properly with things they didn’t know about when they were made.
> It’s still possible to use them in contexts that will not trigger these
> issues, or to adapt the polyfill. After all, you have the source code.
>
You're explicitly suggesting that we publish APIs through the CSSWG,
encourage people to use them, then break the web by releasing new features
that cause those APIs to stop working on existing pages. We can't do that :)

> There’s a trick here. If you look at the steps I propose again, you’ll see
> that the registration I talk about is a DOMString registration (aka
> “StyleTransitionController’s types”). As such, this registration should not
> be done by the polyfill itself but by a script on the page that registers
> all the polyfills in order and at once [*]. The actual implementation is
> only created much later, when it’s actually needed. You could potentially
> require a StyleTransitionController type and find out it isn’t needed on
> the page so skip its loading.
>
So polyfills can never just register themselves? And every web page
requires, on every landing point, a list of polyfills that need to be
loaded, in the right order, declared inline (or loaded synchronously)?

If you want that, it's trivial to recreate it on your own page using the
current spec (just monkey-patch apply). However, from my point of view this
seems to be making simple things hard without solving the hard cases.

<snip>

> As you noted, if I want to animate the location of an object on the
> screen, I can use “transform” which transitions perfectly fine. The issue
> is that the “apply” hook will be run *after* transitions already took
> place. So, any change I’ll make to “transform” in the hook cannot possibly
> rely on the “transition” property to animate.
>
Unless the changes are themselves driven by a transition, in which case
everything should work fine because apply will be called on each frame.

> That’s my issue at this point. You’ve also no way to know a transition is
> in progress, and use this info to precompute the next frames while the
> browser is idle, for instance.
>
I don't think this is a use case we should be striving for.

> Like Tab said, it will be necessary to provide some insight about
> transitions anyway to the “apply” hook, which is why I call it a
> “StyleTransitionController”.
>
The use case was that you wanted a flag flip to cause a transition. This
doesn't match existing transition behavior anywhere else and I don't yet
agree that it's an important use case for version 1. Once we have compute
hooks (which are independently useful) then they can convert the flip into
a smooth transition.

The specific use case that you talked about (moving things around in a grid
layout) is unworkable with just custom properties - grid layout is not even
computed until after style computation is well and truly finished.

> Also, polyfills will want to allow transitions from/to “auto” or “none”
> values, which is why I believe since we have to provide the
> “StyleTransitionController” with “from/to/currentTransitionPoint” for all
> properties which have been updated or are transitionning.
>
Again, this is not currently possible with CSS for architectural reasons
(often because 'auto' implies 'calculate during layout').  When 'auto' can
compute to an animatable value, compute hooks will solve this problem too.

> Here’s something else I might want to do: a lightweight multiline layout
> with fixed-height variable-width boxes which relies on a
> “StyleTransitionController”, “position: absolute” and “transform” to work.
> Some custom properties controls the visibility state of items, and when the
> position of an element changes, I want to be able to initiate a transition
> between the original location and final location of the items, following
> the “transition” property normally % the “transform” property (so it may be
> ‘none’ for no transition, or ‘ease-in 3s’, or anything else). If I initiate
> some transition, I want a polyfill further down the road to be able to see
> the transition going on and interpret it (so if I set a transition between
> “20px” and “auto”, the second polyfill may actually map this to a
> transition from “20px” to “50px” by precomputing the auto value.
>
I don't think this is possible with custom properties alone - you really
need to be able to hook layout to do this. Particularly, it looks like you
want 'auto' to compute to a known pixel position - this just doesn't happen
during style computation.

Cheers,
    -Shane