RE: [css3-transitions] shorthand/longhand handling in transition property

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, October 25, 2010 3:32 PM
> To: Sylvain Galineau
> Cc: Simon Fraser; www-style list
> Subject: Re: [css3-transitions] shorthand/longhand handling in
> transition property
> 
> On Mon, Oct 25, 2010 at 3:15 PM, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> >> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> >> Sent: Monday, October 25, 2010 2:57 PM
> >> To: Sylvain Galineau
> >> Cc: Simon Fraser; www-style list
> >> Subject: Re: [css3-transitions] shorthand/longhand handling in
> >> transition property
> >>
> >> On Mon, Oct 25, 2010 at 2:47 PM, Sylvain Galineau
> >> <sylvaing@microsoft.com> wrote:
> >> > Tab Atkins wrote:
> >> >> (b) is certainly how I expect this to work.
> >> >
> >> > It seems David and I agree that your expectation is contrary to
> the
> >> current
> >> > spec prose which actually calls for a) :
> >> >
> >> > # If a property is specified multiple times in the value of
> >> ‘transition-property’
> >> > # (either on its own or via a shorthand that contains it), then
> the
> >> transition that
> >> > # starts uses the duration, delay, and timing function at the
> index
> >> corresponding to
> >> > # the last occurrence of the property.
> >> >
> >> > Note the "(either on its own or via a shorthand that contains it)"
> >> clause. This is what
> >> > WebKit does today afaict.
> >>
> >> I don't understand.  Dbaron is saying that the current spec text
> >> suggests (b).  I am supporting the same thing that dbaron appears to
> >> be.
> >
> > What dbaron and I are saying is that the spec effectively says you
> should:
> > expand the shorthands in transition-property then apply the duplicate
> > handling rule.
> >
> > This is not what b) is about at all.
> >
> >> > The problem with b) is that we're saying two transitions may be
> >> running on the same
> >> > shorthand but I very much doubt that's desirable. I don't think we
> >> can or should
> >> > collapse duplicates in some cases and not others.
> >>
> >> I'm sorry, but I can't understand this paragraph at all.
> >
> > Look at b) again. What it means to say is that if you don't handle
> > the two border-right-widths as duplicates - i.e. one of them 'wins' -
> > then you have both the shorthand and the longhand transitioning the
> same
> > property, possibly at different speeds. That's not good.
> >
> > I think we want to resolve duplicates before transitioning, whether
> > the duplication is explicit - the authors wrote it that way - or
> > implicit through the use of shorthands+longhands or a keyword like
> 'all'.
> 
> Oh, I *completely* misunderstood what you were trying to communicate
> with your examples, and I'm certain that dbaron did as well.  Your
> example (b), if actually typed by an author, has identical behavior to
> (a), so neither of us really understood what distinction you were
> trying to make, and just went for the one that was more technically
> correct, where the shorthand was fully expanded.
> 
> I never suspected you were trying to assert something different, that
> (b) implied that border-right-width was being transitioned twice by
> the same rule.  I don't even know what that would *mean*.

From his latest clarification, I think David understood it but that's
not the issue. The important point is that yes, a) is what is specified
and makes sense but not all implementations agree. 

For an idea of what that could mean, hover on the box in the attached 
testcase in Chrome 7. Observe how the short border-right-width transition
is triggered several times throughout the much longer border-width
transition. If you don't collapse duplicates I'd definitely expect something
like this to happen.

I have no honest idea why anyone would want this behavior but it's good
to know it's not just me :)