- From: Brian Manthos <brianman@microsoft.com>
- Date: Fri, 16 Sep 2011 20:11:41 +0000
- To: Ø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>
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 Friday, 16 September 2011 20:12:12 UTC