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, 14 Jan 2014 00:40:39 +0000
To: www-style list <www-style@w3.org>
Message-ID: <CEF9BEED.35D6F%stearns@adobe.com>
On 1/3/14, 5:23 PM, "Alan Stearns" <stearns@adobe.com> wrote:

>Hey all,
>
>Since the computed value of <position> in background-position has been
>updated [1], I have updated the computed value of <position> in the
><basic-shape> functions that use it. This required adding two new sections
>to CSS Shapes - Computed Values of Basic Shapes [2] and Serialization of
>Basic Shapes [3] (the latter bit seems like something that should
>eventually go into a CSSOM level).
>
>p.s. According to [1], serialization of background-position still needs to
>be specified.

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.

Computed Value (the concept in the propdef table) is a UA-internal
representation of a property mainly meant for supporting animations. It’s
necessary for animatable properties to produce interpolable computed
values. Inferred values (such as with various <position> variants, or
single-value border-radius-* values) will likely need to be added to the
computed value to produce an interpolable result. Even if a property is
not animatable, it’s probably useful to design the computed value such
that it could support interpolation.

Serialization (such as the result from getComputedStyle) is a valid CSS
string representation that might only have a tenuous connection to the
computed value representation. Its main characteristic is that it must
‘round-trip’ with parsing. Inferred values can be omitted here. If a
grammar allows ordering options, the serialized value should prefer an
order (usually what’s presented in the grammar).


Here are some examples using background-position:

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

Declared value: center center
Computed value: (50% + 0px), (50% + 0px)
getComputedValue result: center

And some examples using shape-outside

Declared value: circle(10px, bottom 50px top 10%)
Computed value: indication of a circle function with values 10px, (10% +
0px), (100% - 50px)
getComputedValue result: circle(10px 10% bottom 50px)


Declared value: circle()
Computed value: indication of a circle function with values closest-side,
(50% + 0px), (50% + 0px)
getComputedValue result: circle()

Declared value: inset(10px)
Computed value: indication of an inset function with values 10px, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0
getComputedValue result: inset(10px)


(the computed value of inset fills in all of the optional insets and
border-radii)

>
>[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0388.html

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

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

>

Received on Tuesday, 14 January 2014 00:41:11 UTC

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