W3C home > Mailing lists > Public > www-style@w3.org > January 2014

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

From: Alan Stearns <stearns@adobe.com>
Date: Tue, 21 Jan 2014 23:34:19 +0000
To: Alan Stearns <stearns@adobe.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CF043DB4.365F1%stearns@adobe.com>
So I believe the steps below are the correct ones to use when serializing
a <position> computed value, including when it’s in the middle of a
transition. But I’m not sure this list of steps is what we need to put in
the specification(s).

I’d much rather define something that covered values like <position> with
multiple valid expressions, where the steps below could be inferred from
general requirements. CSS Images 4 [1] has something like this, which I
had copied for CSS Shapes [2]. I’ve updated the Shapes version to account
for some of the steps below. It now reads:

----
To serialize the <basic-shape> functions,
	serialize as per their individual grammars,
	in the order the grammars are written in,
	avoiding calc() expressions where possible,   (new)
	using keywords where possible,                (new)
	omitting components when possible without changing the meaning,
	joining space-separated tokens with a single space,
	and following each serialized comma with a single space.
----


I think this covers all of the steps below that are particular to
<position> serialization, but also works for the rest of the <basic-shape>
functions and the functions in CSS Image. Can we use this more generally
for values like <position> and functions?

Thanks,

Alan

[1] http://dev.w3.org/csswg/css-images/#serialization

[2] http://dev.w3.org/csswg/css-shapes/#basic-shape-serialization


On 1/17/14, 5:04 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>On 1/15/14, 5:00 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>
>>On 1/15/14, 4:34 PM, "Alan Stearns" <stearns@adobe.com> wrote:
>>
>>>
>>>
>>>On 1/15/14, 3:26 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>>
>>>>Gosh, actually writing these out the serialization rules in full is
>>>>more complicated than I thought.
>>
>>How about this:
>>
>>1. Start with the two components from the computed value as (percentage,
>>length), (percentage, length)
>>2. Replace 0%/50%/100% percentages with their keywords
>
>For some reason I was thinking that center could take an offset. So this
>should actually be:
>
>2a. Replace 0%/100% with their keywords.
>2b. Replace 50% with ‘center’ if the length is zero.
>
>And then end-centric offsets change sign, as the edge they are offset from
>just flipped:
>
>2c. If a component uses the ‘bottom’ or ‘right’ keyword, flip the sign on
>the length.
>
>>3. If a length is zero, omit this offset
>>4. If either component still consists of (percentage, length) convert
>>those components to calc(percentage + length)
>>5. If either component consists of (top, length) or (left, length) omit
>>top and/or left
>>6. If one component consists of (center) and the other contains a
>>keyword,
>>omit one (center) component
>>7. Write out the values that remain as a space-separated list
>>
>>
>
>

Received on Tuesday, 21 January 2014 23:34:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 21 January 2014 23:34:52 UTC