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

Hi all,

We now have issues working in github, so I've filed an issue there for each
one that I called out in this thread.

Cheers,
    -Shane

On Mon, Jun 15, 2015 at 2:11 PM Shane Stephens <shans@google.com> wrote:

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