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

Again I'm going to mark some issues here until we have an issue tracker up
and running.


> A few additions I would like to see added to the allowed types are :
> - "<length-and-percentage>" (accepts "50px", "50%" and "calc(50px + 50%)")
> - "<ident>" (any custom identifier)
> - "<ident>(auto, none)" (a list of possible idents which the property does
> accept)
> - "*" (any input, much like a unregistered custom property)
>

ISSUE: Add the above types to the spec.


> It should also probably be flushed somewhere in the sepc that the
> "initialValue" should match the given "syntax", of course.
>

ISSUE: add this somewhere

====================================
> [1] It creates a toxic environment
> ====================================
>
> Let's say I create a polyfill for the "size" property which is a shorthand
> for both "width" and "height". That means that no other polyfill can touch
> those two essential properties anymore. Ditto for any polyfill which wants
> to handle "transform". Polyfills are going to conflict with each other all
> the time, making them unusable outside contained demos. That's not
> sustainable.
>

Yes. It's precisely this that led us to propose 'apply'. Consider the
problem from this perspective: how can polyfill authors create new custom
properties without having to know about every other intersecting property
in the world?

As a simple example, take '--extra-margin', which does:
width += --extra-margin

And '--tile-width', which wants to do:
width = --tile-width

Depending on the order in which these are registered, you get very
different results.

It's impossible for us to solve this problem for all time, baked into the
browser. Instead we need to make it possible for framework authors to solve
subsets of the problem and be flexible into the future.

'apply' exists not to prevent properties from working together, but to
force the existence of user-level frameworks that can mediate property
conflicts like this. A framework can provide their own registration
functionality that takes the functions and converts them into a single
coherent per-native-property apply function.

I'm not sure why you state the polyfills are unlikely to modify native
> properties. Polyfills have literally no other option than setting the value
> of native properties to have an effect on the page, I expect most polyfills
> to actually work this way, and not by going the full Custom Layout road.


Nobody stated this. In fact, all of the examples in the draft we wrote
explicitly modify native properties. I think you misread Florian's email,
where he proposed an additional stage and stated that writing to native
properties *in his new stage* was unlikely.

====================================
> [2] It is insufficient to mimick css properties
> ====================================
>
> Florian's 2.1:
> > 2.1) For some properties, but not all, the computed value depends not
> > only on the computed value of other properties on the same element (as
> > expressed by inputProperties), but also on the parent element.
>
> To restate Florian's 2.1, a fair amount of usefule css properties don't
> live on their own. Sure, on one hand, a lot of those are affected by the
> layout phase (which we could arguably leave to Custom Layout), but on the
> other hand, even properties which do not have a "layout-computed used
> value" can depend at computation-time on parent state in a non-"inherit"
> way. Think, for instance, about "justify-self": the ‘auto’ keyword computes
> to [...] the computed value of ‘justify-items’ on the parent [...] or
> ‘start’ if the box has no parent.
>

Access to parent styles isn't forbidden in the draft specification.
Florian's question was about whether to force authors to specify that they
want to access parent styles before enabling it.


> ====================================
> [3] Transitions seem to conflict with the model
> ====================================
>


> Let's say we have a hook computing "--both-numbers" to the sum of
> "--first-number" and "--second-number" (if both are specified) or computing
> "--first-number"/"--second-number" from "--both-numbers" (if one of them is
> missing)). Now, imagine that a transition starts on hover:
>
>     element { --first-number: 0; --second-number: 1; transition:
> really-all 1s; }
>     element:hover { --first-number: 0; --second-number: 2; }
>
> Since the css engine cannot know how "--both-numbers" is computed, he has
> to call the "apply" model on every step of the transition.
>
> How will the css engine know whether the computed value for
> "--both-numbers" should or should not transition normally after the "apply"
> model is run? I may be wrong, but it seems impossible to know, which means
> it won't transition (however, since "--first-number" and "--second-number"
> do transition and the "apply" logic is called again at every step, it will
> looks in this specific case like it does transition, which is great).
>

One of the following must be true:
(1) --both-numbers is a typed, declared custom property using the new
draft. In this case it should transition as the system knows how to
transition it, and also knows to track its computed value for changes
(which is precisely how native properties transition). However, things are
going to look terrible because you're transitioning both the property and
the things that the property is calculated from. Don't do that :)
(2) --both-numbers is a Custom Properties level 1 style property. It
doesn't transition because it can't.
(3) --both-numbers isn't a property at all, but an internal abstraction.
Obviously it can't transition in this case either.

But I also have to ask what --both-numbers is supposed to be for? Given the
current model, it can't effect anything (you can't set up chains of action
using apply).


> Now, the issue happens when you need to handle the real final value of the
> properties to compute the final value of the computed property, and you
> want this property to transition normally between those two extremes. This
> is the case for instance, you set a flag that changes the meaning of some
> other property, but want the effect of this flag switch to happen gradually
> (example: a grid where items would move from their old to their new grid
> area in a transitioned way and not directly like we do now). Since you
> don't know how far you are in the transition, that's not possible.
>

The only way you can control the position of things with this approach is
by controlling their top/left, or their transform. Both have wonderful
transition behavior already.

Please note, by the way, that this is just level 1. We need a minimum
viable subset that solves some real problems now, and is also extensible.

-----------------------

It's not clear to me what your proposed model is trying to solve. Can you
provide some clear examples of things that your model would enable which
can't be supported by the current approach? We could start with the
--first-number / --second-number example above, but we need:
* some kind of effect (what does --both-numbers exist for and what does it
control?)
* an example script showing how this would be supported using your model
* one or more example timelines of inputs and outputs that you think aren't
achievable using the current draft.

Cheers,
    -Shane