[css-properties-values-api] Consider moving output property conflict resolution to apply time rather than at register time. about css-houdini-drafts HOT 1 OPEN

Hi Shane, I thought more about this exact topic in the past few weeks but didn't want to start the discussion, but now we're talking about it anyway, I would like to share with you my own thoughts, and I'm interested by your honest opinion on it.

Firstly, I like this new proposal much more already than the current one. My initial plan was not to allow such conflict to happen at all, though.

I know we discussed how hard it was to define an actually useful ordering for layout librairies during last meeting and why it would be impossible to rely on registration order. I still share your opinion on these matters. My take has always been, however, that some declarative ordering was achievable, and this is where we could not agree with each other, if I remember correctly. My proposal back then didn't seem flexible enough to you and you believed it was pushing unrealistic constraints on the users of layout librairies. I took that feedback in consideration and would like to come to you with another proposal.

The idea would be to rely on a set of css properties to define the ordering of the ApplyHooks. Here's an example:

* {
    priority-of-bootstrap: 1000;
    priority-of-bootstrap-aspect-ratio: bootstrap 50;
    priority-of-bootstrap-height: bootstrap 60;
}

Now, let's imagine a css framework called "bootstrap" has two prollyfilled properties "--bootstrap-aspect-ratio" and "--bootstrap-width" running the ApplyHooks named "bootstrap-aspect-ratio" and "bootstrap-height" respectively, and possibly both outputting the "height" property, their execution order would be define on any element of the page as COMPUTED => BOOTSTRAP-HEIGHT => BOOTSTRAP-ASPECT-RATIO => POST-COMPUTED because (1000, 50, 0, 0, ...) < (1000, 60, 0, 0, ...)

Then, if you somehow need to inverse this ordering for an element, the fix is as simple as:

.special-case {
    priority-of-bootstrap-height: bootstrap 40;
}

Now, for this element, the ordering will be inverted, as (1000, 40) < (1000, 50).

The point of using tuples of numbers is that you can subdivide a framework at will whenever required, and tie the ordering of logically-grouped properties coherent by putting them under the same umbrella:

* { priority-of-bootstrap-aspect-ratio: bootstrap bootstrap-core 20 }

This is useful to reorder frameworks as a whole, for instance:

* { priority-of-bootstrap: 999; priority-of-layifram: 1001; }

Even more interesting, an apply hook could potentially be allowed to modify the ordering of the apply hooks that are still pending by writing the "priority-of-..." properties. When they do so, this only affects the ordering of apply hooks which have not run already, of course, but this could be useful if a framework/property-umbrella requires an automatic but dynamic ordering of its properties. Another option would be to make priority-properties read-only or just ignore any such update during the apply-hook phase.

Another neat thing is that, the author of the page remains in total control of the ordering because he can certainly write new css rules which will override the default ordering if required, or insert a custom apply hook anywhere required in a toolchain simply by doing priority-of-my-thing: bootstrap-aspect-ratio -1 since (1000, 60, -1, 0, ...) < (1000, 60, 0, 0, ...).

My proposal to break ties (when priority-vectors are equals) would be to use alphabetical order of the apply-hook name. This is predictable, at least, though authors should of course rely on the priority vectors instead whenever possible.

So, what do you think of this proposal? Do you think it would make you reconsider your opinion that declarative ordering could not be made to work, or do you think this proposal is a good base to achieve some form of agreement?

from css-houdini-drafts.