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

Re: [css-background] Animating border-position

From: Bear Travis <betravis@adobe.com>
Date: Mon, 6 Jan 2014 22:45:34 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
Message-ID: <CEF067C0.27139%betravis@adobe.com>
Hi Tab,

Thanks for the reply. I've included comments below.

On 1/6/14, 1:58 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Mon, Jan 6, 2014
>Computed values have nothing to do with serialization.  Serializing
>just takes a value (which can be at *any* value stage) and returns a
>string holding a declared value which will have the same result.

My concern was with this line from the previous thread:

>This makes sense to me, we just have to be careful to specify how
><position> is serialized in getComputedStyle -- that it's not the
>computed value as described above. I don't want background-position
>to serialize differently from object-position, for example, just
>because object-position isn't in the list of 2.1 exceptions.

I was unclear as to whether this meant that getComputedStyle would use a
different computed value, or that the serialization might take a value of
[(top, 50%), (left, 100% - 20px)]
And convert it to the string
"top 50% right 20px" or some other simpler form. It sounds like the latter
is the case.

>Currently undefined, but the obviously correct answer is to only use
>calc()s when necessary.  *Any* value in CSS might be a calc(); that
>doesn't imply that they all have to serialize as calc()s.

I think what I'm having trouble understanding is how the proposed computed
value maps to value(s) in CSS.

>The computed value of a <position> is a set of zero or more
>(direction, offset) pairs, where each axis chooses one direction as
>canonical and an offset is a sum of a percentage and a length.
>Specified directions that are the non-canonical one are converted to
>the canonical one.

This makes it sound like the computed value of <position> is a pair of
keyword + calc expressions, since a calc expression is how you would
express the length / percentage sum.
[(top, 50%), (left, 100% - 20px)] would be
"top calc(50% + 0px) left calc(100% - 20px)" (ignoring any serialization
If these offsets are all calcs, should serialization simplify them where
possible, or should they not? Or am I fixating on a direct mapping between
the computed value and the equivalent CSS?

Received on Monday, 6 January 2014 22:46:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:38 UTC