[css3-transitions] spec edited, plus proposals for resolving issues

I just edited css3-transitions to reflect two resolutions from TPAC
recorded in
http://lists.w3.org/Archives/Public/www-style/2012Nov/0262.html .

I also added the description of the "length, percentage, or calc"
animatability that I *think* we previously discussed, updated the
table of properties to use it, and made it clearer what it means for
an entry in the table of properties to list more than one type
(which is now the case only for 'line-height').


Furthermore, I've gone through the remaining issues listed in the
spec, and I propose we dispose of these issues in the following
ways:

> SPEC ISSUE 1:  We may ultimately want to support a keypath syntax
> for this property. A keypath syntax would enable different
> transitions to be specified for components of a property. For
> example the blur of a shadow could have a different transition
> than the color of a shadow.

I propose we defer this to the next level.

> SPEC ISSUE 2:  An alternative proposal is to accept the font
> shorthand approach of using a "/" character between the values of
> the same type. e.g. 2s/4s would mean a duration of 2 seconds and a
> delay of 4 seconds. 

I think it's far too late for this in terms of compatibility.

> SPEC ISSUE 3: Issue: This introduces the concept of reversing a
> timing function, which the spec has otherwise resisted doing, and
> also introduces a discontinuity between transitions that have
> almost completed (which get automatically reversed and thus have
> their timing function reversed) and transitions that have fully
> completed (where the reversal doesn't lead to the timing function
> being reversed). An alternative proposal that avoids this is to
> follow the normal timing function algorithm, except multiply the
> duration (and also shorten any negative delay) by the (output)
> value of the transition timing function of the incomplete
> transition at the time it was interrupted, and, to account for
> multiple reverses in sequence, to divide by the shortening applied
> to the transition being interrupted. For more details see this
> thread: November 2009 part, December 2009 part, January 2010 part.

This is waiting on Tab to write some simulations in JavaScript per
a previous meeting, I believe.

> SPEC ISSUE 4: Should new events being created still have
> init*Event methods?

Seems like the conclusion is no, and css3-animations has been edited to
reflect this.  So this just needs editing, in line with animations.

> SPEC ISSUE 5: Does adding this additional argument create any
> compatibility problems?

This is moot, per issue 5.  (The change for issue 4 is a bigger
compatibility risk, and subsumes this.)

> SPEC ISSUE 6: This floor behavior is inconsistent with SMIL
> Animation / SVG Animation.
> SPEC ISSUE 7: This round-to-nearest behavior is inconsistent with
> the floor behavior used for integer types, but probably should be
> consistent (one way or the other).

I sort of thought we'd resolved these, but I can't find any record
of discussing them since the meeting where we created them:
http://lists.w3.org/Archives/Public/www-style/2012Mar/0655.html

I think this probably requires further discussion.

> SPEC ISSUE 8: css3-content will likely advance slower than this
> specification, in which case this definition should move there

I propose we drop listing of 'crop' and put the animatability rules
for it in css3-content.  This will mean the table lists only
properties in CSS Level 2, and all Level 3 modules will have to have
"Animatable:" lines.

> SPEC ISSUE 9:  This list omits the following properties that Gecko
> can animate, and which likely should be included: background-size,
> border-*-radius, box-shadow, column-count, column-gap,
> column-rule-color, column-rule-width, column-width,
> font-size-adjust, font-stretch, marker-offset,
> text-decoration-color, transform, transform-origin. 

I propose this spec should define animatability of font-size-adjust and
marker-offset, since those were in CSS 2.0.  Other properties should be
defined in their respective modules (which requires edits to
css3-multicol, css3-fonts, css3-text-decor, css3-transforms; I don't
think editing any of these should be a problem).

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Monday, 4 February 2013 07:19:04 UTC