Re: [css-shapes] Animating <basic-shape>s updated



On 1/15/14, 3:26 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Wed, Jan 15, 2014 at 10:28 AM, Alan Stearns <stearns@adobe.com> wrote:
>> On 1/14/14, 3:36 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>On Mon, Jan 13, 2014 at 4:40 PM, Alan Stearns <stearns@adobe.com> wrote:
>>>> Here’s a bit more detail and some examples on this topic. I’m writing
>>>>out
>>>> what I’ve gleaned from the discussion of computed values and
>>>>serialization
>>>> to see whether I’ve got things right (or if it sparks more debate). I
>>>> think designing complex, multi-valued properties like shape-outside
>>>>and
>>>> border-position may be helped by using some guidelines.
>>>
>>>Yes, everything you write here is great and completely correct, as far
>>>as I can tell!
>>>
>>>I've added it to the wiki at
>>><http://wiki.csswg.org/spec/computed-values> for now to record it for
>>>posterity.
>>
>> OK - so now let's look at these example:
>>
>> Declared value: right 10px
>> Computed value: (100% - 10px), (50% + 0px)
>> getComputedValue result: right 10px
>>
>> Declared value: bottom 50px top 10%
>> Computed value: (10% + 0px), (100% - 50px)
>> getComputedValue result: 10% bottom 50px
>>
>> And talk about what happens during interpolation. You can call
>> getComputedStyle in an intermediate state, so how does the value get
>> serialized then? If we animate between the two declared values above,
>>and
>> sample the value half-way through, the computed value is:
>>
>> (55% - 5px), (75% - 25px)
>>
>> In this case, I think the getComputedValue result is:
>>
>> calc(55% - 5px) calc(75% - 25px)
>>
>> I'm assuming that if the percentages in computed value are 0%, 50% or
>> 100%, then the serialization uses the keywords. But if the percentage is
>> any other value, the serialization needs to use calc().
>
>Gosh, actually writing these out the serialization rules in full is
>more complicated than I thought.

That’s the price of allowing 1,2,3,4-value alternatives, keywords and
omitted values

>
>Categorize each value as "start-centric" if it's a single length or
>percentage, "end-centric" if it has a percentage of 100% and a
>non-zero length, and "complex" otherwise.
>
>* If both values are 50%, use "center".

* Otherwise, if the first (horizontal) value is start-centric or complex,
and the second (vertical) is 50%, use the 1-value form writing out only
the first value. 
* Otherwise, if the first (horizontal) value is 50% and the other
(vertical) is start-centric, use the 2-value form writing out the second
value with a keyword.

* Otherwise, if one value is 50% and the other is end-centric, use the
2-value form writing out only the end-centric value using a keyword.



>* Otherwise, if both values are start-centric or complex, use the
>2-value form.   Write 0%/50%/100% with keywords.
>* Otherwise, use the 3/4 value form, serializing start-centric values
>with left/top and end-centric values with right/bottom.  Write
>0%/50%/100% with just keywords.

There’s some weirdness about ‘center 10px’ as one of the computed values
that my first rule and your second rule run afoul of. It will serialize as
‘calc(50% + 10px)’ or break the n-value form the rule specifies. And I
think there’s an optimization to omit the top/left keyword for a complex
value if the other value is being written out using two values.

Ugh.

Alan

Received on Thursday, 16 January 2014 00:49:41 UTC