W3C home > Mailing lists > Public > www-style@w3.org > September 2011

RE: when do transitions occur?

From: Brian Manthos <brianman@microsoft.com>
Date: Wed, 28 Sep 2011 09:39:25 +0000
To: Brian Manthos <brianman@microsoft.com>, Øyvind Stenhaug <oyvinds@opera.com>, Tab Atkins Jr. <jackalmage@gmail.com>, "L. David Baron" <dbaron@dbaron.org>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D17180043@TK5EX14MBXC265.redmond.corp.microsoft.com>
Was there any follow-up on this discussion?

I'm concerned because David's description of the current spec leads me to believe that authors that write CSS3-compatible pages that rely on the text-shadow event firing will be broken if CSS4+ changes text-shadow to a shorthand.  (And likewise for all 'complex', non-shorthand CSS3 properties.)

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of Brian Manthos
> Sent: Friday, September 16, 2011 1:12 PM
> To: Øyvind Stenhaug; Tab Atkins Jr.; L. David Baron
> Cc: www-style@w3.org
> Subject: RE: when do transitions occur?
> 
> Brian:
> > Øyvind:
> > > On Thu, 15 Sep 2011 21:48:43 +0200, Tab Atkins Jr.
> > > <jackalmage@gmail.com>
> > > wrote:
> > >
> > > > On Thu, Sep 15, 2011 at 2:41 AM, Brian Manthos
> > > <brianman@microsoft.com>
> > > > wrote:
> > >
> > > >> Example D (CSS3)
> > > >>        from    { text-shadow: 1px 2px 3px red; }
> > > >>        to      { text-shadow: 1px 2px 3px blue; }
> > > >>
> > > >> Example E (CSSn, where n > 3)
> > > >>        from    { text-shadow: 1px 2px 3px pink; text-shadow-
> color:
> > > red;
> > > >> }
> > > >>        to      { text-shadow: 1px 2px 3px cyan; text-shadow-
> color:
> > > >> blue; }
> > >
> > > >> CSS3 browser - Example D
> > > >> 1. text-shadow event ("1px 2px 3px red" -> "1px 2px 3px blue")
> > > >>
> > > >> CSS3 browser - Example E
> > > >> 1. text-shadow event ("1px 2px 3px pink" -> "1px 2px 3px cyan")
> > > >>
> > > >> CSSn browser - Example D
> > > >> 1. text-shadow event ("1px 2px 3px red" -> "1px 2px 3px blue")
> > > >> 2. text-shadow-color event ("red" -> "blue")
> > > >>
> > > >> CSSn browser - Example E
> > > >> 1. text-shadow event ("1px 2px 3px red" -> "1px 2px 3px blue")
> > > >> 2. text-shadow-color event ("red" -> "blue")
> > > >
> > > > Agreed with all of these - this is the only way I can see it
> > working
> > > > sanely with the possibility of turning properties into shorthands
> > in
> > > > the future.
> > >
> > > So a shorthand value is constructed based on the cascaded longhand
> > > values
> > > (or something like that). What if that's not possible? No event?
> >
> > Definitely not "No event".
> >
> > Look back at my examples.  BOTH the shorthand and the longhand should
> > be sent in CSSn D & E.
> >
> >
> > > E.g.
> > > 	from	{ border: solid; }
> > > 	to	{ border: dotted; border-left-style: none; }
> >
> > Let's call this Example F.  Some shorthand values *can* be
> constructed
> > in this case, just not the border shorthand.  And even though you
> can't
> > construct a border shorthand, an event should fire for it.
> >
> > CSS3 browser - Example F:
> > 1. border event ("solid" -> "")
> > 2. border-top event ("solid" -> "dotted")
> > 3. border-right event ("solid" -> "dotted")
> > 4. border-bottom event ("solid" -> "dotted")
> > 5. border-left event ("solid" -> "none")
> > 6. border-style event ("solid" -> "dotted dotted dotted none")
> > 7. border-top-style event ("solid" -> "dotted")
> > 8. border-right-style event ("solid" -> "dotted")
> > 9. border-bottom-style event ("solid" -> "dotted")
> > 10. border-left-style event ("solid" -> "none")
> >
> > Again, note that the first event's end state of "" is because the
> > shorthand cannot be represented.
> >
> >
> > I think of it in somewhat simple terms.
> >
> 
> Model I:
> > Conceptually...
> > 1. Query all CSS properties (including shorthands) @ the from state
> > 2. Query all CSS properties (including shorthands) @ the to state
> > 3. Diff the results of 1 and 2
> > 4. Any properties (including shorthands) that show differences from
> > step 3 should have an event fire
> >
> >
> > A somewhat simpler border example might make it clearer.
> >
> > Example G
> > 	from	{ border: solid; }
> > 	to	{ border: solid; border-left-style: none; }
> >
> > CSS3 browser - Example G:
> > 1. border event ("solid" -> "")
> > 2. border-left event ("solid" -> "none")
> > 3. border-style event ("solid" -> "solid solid solid none")
> > 4. border-left-style event ("solid" -> "none")
> >
> 
> Model II:
> > So the most concise form that strikes me at the moment is, events
> > should fire for both:
> > A. longhand properties that change
> > B. all shorthand properties that contain entries from A
> 
> One more example...
> 
> Example H
> 	from	{ border: solid; border-left-style: dotted; }
> 	to	{ border: solid; border-left-style: none; }
> 
> CSS3 browser - Example G:
> 1. border event ("" -> "")
> 2. border-left event ("dotted" -> "none")
> 3. border-style event ("solid solid solid dotted" -> "solid solid solid
> none")
> 4. border-left-style event ("dotted" -> "none")
> 
> 
> This example illustrates (in the border event) where Model I and Model
> II are different.  The difference is that Model I suggests basing the
> event set on simple string compares of the computed values, whereas
> Model II suggests a logical compare of longhands with enumeration of
> longhands and related shorthands.
> 
> I think Model II is preferred because it minimizes "author surprise"
> w/r/t firing of shorthands.
Received on Wednesday, 28 September 2011 09:39:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:44 GMT