W3C home > Mailing lists > Public > www-style@w3.org > November 2009

[CSSWG] Minutes and Resolutions TPAC F2F 2009-11-02: Admin, Transitions, & Transforms

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 12 Nov 2009 15:06:07 -0800
Message-ID: <4AFC94DF.9070909@inkedblade.net>
To: www-style@w3.org

   - Introductions, scheduling agenda items

   - Review our Last Call comments for MathML for CSS
     Bert didn't find much to comment on. Stretchable characters
     is something we might need to look at in the future.
     jdaggett has some comments on font variations vs Unicode

   - Discussed modularization and profiles; the questions raised
     are all answered by the Snapshot. The only complaint was that
     it's not visible enough, which will be solved when the Snapshot
     enters CR.

Transitions, Transformations, and Animations

   - Apple would like a few sample tests in an appropriate format
     to begin writing test suites. dbaron offered to help with that.

   - Reviewed behavior of inherited properties and how inherited
     transitions don't trigger new transitions

   - Discussed effects of batched layout updates and flushing on
     transitions, and the resulting unpredictability in behavior.

   - Expecting another WD soon, then LC afterward for Transitions
     and possibly for 2D Transformations; 3D Transforms and
     Animations both need more work

====== Full minutes below ======

<RRSAgent> logging to http://www.w3.org/2009/11/02-CSS-irc
See also   http://krijnhoetmer.nl/irc-logs/css/20091102

   Tab Atkins (Invited Expert)
   David Baron (Mozilla)
   Bert Bos (W3C Staff)
   Tantek Çelik (Invited Expert)
   Beth Dakin (Apple)
   John Daggett (Mozilla)
   Arron Eicholz (Microsoft)
   Elika Etemad (Invited Expert)
   Simon Fraser (Apple)
   Sylvain Galineau (Microsoft)
   Daniel Glazman (Disruptive Innovations / co-chair)
   Brad Kemper (Invited Expert)
   Chris Lilley (W3C Staff)
   Peter Linss (HP / co-chair)
   Pierre Saslawsky (formerly Netscape / observer)
   David Singer (Apple)
   Steve Zilles (Adobe)

Scribe: Sylvain


   We go around the table and introduce everyone

   Peter Linss, HP.
   Sylvain Galineau, Microsoft, IE team
   Arron Eicholz, Microsoft, IE Team
   Beth and Simon, Apple, WebKit
   David Baron, Mozilla
   <glazou> Pierre Saslawsky
   John Daggett, Mozilla Japan, CSS3 Fonts editor
   Chris Lilley, W3C
   Alex Mogilevsky, Microsoft
   Tab Atkins, Invited Expert
   Brad Kemper, Invited Expert
   fantasai Etemad (fantasai), Invited Expert
   Daniel Glazman, csswg co-chair
   Bert Bos, W3C
   (scribe missed a couple of observers)

Meeting Agenda

   Discussing timing of various items, adding CSS test suite to agenda

LC comments for Math-ML for CSS profile

   bert: largely CSS2.1 to render MathML
   bert: I didn't find anything I would comment on
   bert: in section 12 (default stylesheet), a general comment says 'it would
         be appropriate to extend CSS3 with a few math-specific properties'
   glazou: it would be helpful to know what is intended
   bert: one approach involves additions to the box model for math layout.
         then stretchable characters such as a parenthesis stretching to
         the size of the box next to it
   dbaron: stretchable characters require knowledge of what's being contained
   bert: the stretching character is bound to something; but an additional
         issue is that stretching the height of a character may also impacts
         its width
   bert: these are the general issues that were discussed in the past
   jdaggett: notices variant properties under the math variants section and
             forecasts comments...
   jdaggett: there are Unicode characters for maths outside the BMP
   jdaggett: when you use math characters, things like italics may have a
             semantic meaning i.e. they're not presentation
   <dbaron> Funky Chars
   jdaggett: section 3.3: stretchar ?
   <smfr> http://www.w3.org/TR/MathML2/chapter6.html#chars.BMP-SMP
   <bradk> stretchar is spelled consistently throughout at least.
   <ChrisL> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter7.html#chars.BMP-SMP
   <ChrisL> 7.5 Mathematical Alphanumeric Symbols
   TabAtkins: this section describes both Unicode and alternatives ways to
              specify math characters
   <ChrisL> "Mathematical Alphanumeric Symbol characters should not be used
             for styled text. For example, Mathematical Fraktur A must not be
             used to just select a blackletter font for an uppercase A. Doing
             this sort of thing would create problems for searching, restyling
             (e.g. for accessibility), and many other kinds of processing."
   jdaggett will send comments on document tonight
   Bert will share the WG's answer with MathML
   <ChrisL> also http://www.unicode.org/reports/tr25/tr25-8.html Unicode
            Technical Report #25
   <ChrisL> Unicode Support for Mathematics


   glazou: there are large expectations from the web design community around
           these features
   * plh-webapps wonders if Dave Singer woke up this morning
   glazou: we'd like to move these specifications along: edit the specs,
           test suites...
   smfr: we're committed to moving the specs forward, specifically 2D
         Transforms and Transitions
   smfr: 3D Transforms and Animations will likely take longer
+David Singer (Apple)
   smfr: we have tests we need to move to the W3C format
   fantasai: we have both stand-alone testcases and reftests
   fantasai: if we need another test format for transitions, that's
   dbaron: some of these tests will have to scripted and we should be ok
           with that
   smfr: some of the functionality needed to test transitions may need
         to be specified as well
   dsinger: if we had agreement on a template testcase, it would help get
            us going
   dbaron: I'd be willing to help edit Transitions

   dbaron: for the inheritance processing model issue, I think we decided
           that if you have 4 elements A, B, C in an ancestor-descendant
   dbaron: and you specify a transition on color in B and C and a dynamic
           color property change occurs, what happens to C's transition ?
   dbaron: we decided that C's transition does not happen but it doesn't
           inherit B's animated values
   <ChrisL> its just a case of being clear when the values are grabbed to
            compute the transition, and whether they can be changed during
            a transition.
   dbaron: C's transition would only be triggered when C is updated
   dbaron: if C was already in a transition, that would not be affected
   smfr: Webkit does not currently handle transitions on inherited properties
         and we haven't seen any issues from it
   glazou: are web designers going to understand this ?
   szilles: this is the most understandable solution yet
   <TabAtkins> a { transition: none; color: blue; }
               a:hover { color: red; }
               b { transition: color 1s; }
               <-- If I hover <a>, should <b> transition?  Does it currently?
   <bradk> A>B
   <TabAtkins> b>c { transition: color 2s } <-- Given the previous rules,
               now <c> does *not* transition when I hover <a>, but it does
               inherit <b>'s colors as <b> transitions.
   dbaron: the answer to Tab's first case was that B does transition as the
           inherited color value is not animated
   smfr: transitioning visibility is an area we have thought of making changes
         to create fading effects vs. the current specified behavior where all
         non-1 values result in visibility:hidden
   pierres: regarding the inheritance discussion, does this mean that the
            result will be different depending on the sequence in which I
            trigger my transitions through script ?
   <TabAtkins> Example: <script> $foo.css("color","red");
               $foo.css("transition","color 1s");</script>
               <-- Does the color transition?  Does it not?
                 Is this impl-dependent currently?

   dbaron: transitions do complicate the model in that dynamic property updates
           were effectively simultaneous but now we still have residual effects
           from older values
   <fantasai> smfr describes a case where the author turns off transitions,
              sets an intermediate value, sets transitions back on, and then
              sets another value
   <fantasai> various browser optimizations may cause that intermediate value
              to not be used, in which case the transition transitions from
              the wrong start point
   TabAtkins: there was talk about grouping transitions together to happen as
              an atomic unit i.e. setting a number of transitions together
              without any one starting ahead of the others
   dbaron: we already batch these things
   plinss: the point is that the author can control when the batching start
           and stops
   dbaron: the problem with such an API is that we will do more frequent flushing
   dbaron: the browser has to flush right before the "don't flush here" call
   dbaron: as well as at the "flush here" call
   dbaron: and if someone calls "don't flush here" in a loop to try to optimize,
           it'll cause lots of flushes and actually degrade perf
   smfr: I think this issue requires a note in the spec
   ACTION smfr Add implementation note in the spec about style update batches
               and their effect on transitions
   sgalineau: pseudo-elements and transitions ?
   smfr: Dean Jackson updated the spec so that they can transition
   dbaron: only :before and :after transition.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jun/0121.html
            and http://lists.w3.org/Archives/Public/www-style/2009Jul/0050.html
            are the messages about the inheritance issue we discussed earlier

   ChrisL: are we aiming to move this specification to LC ?
   glazou: it depends on the editorial stability of the document
   <TabAtkins> a { color: yellow; }
               <script>a.color="red"; a.transition="color 1s";
               <-- So the proposal is just to say "Hey authors, watch out
                   for this!"?
   smfr: the spec has been edited over the w-e
   fantasai: you will have less to do during LC if you put out another WD
             first with all your changes
   Bert: I agree this is a likely path for transitions; I disagree that 2D
         transforms is as close to LC
   <dbaron> I probably need to send a bunch of comments on the "Animation
            of property types" section...

   <tantek> greetings everyone
   tantek suggests an FAQ to answer 'When do we add a property?
   ' following a long discussion of this topic around 2D Transforms and all
     the other things we are adding to CSS
   glazou agrees
   ACTION Bert Draft an FAQ on when the CSS WG adds a new property
   <TabAtkins> Got a transition issue.  Check out
               First, the transitions trigger on *pageload*, which is weird.
               Second, "baz" doesn't start transitioning until after "bar" is
               done, when it *should* just inherit "bar"'s color as "bar"

<br />

   <smfr> TabAtkins, your testcase looks like a webkit bug with transitions
          of inherited properties
   <smfr> TabAtkins, what does FF do?
   <TabAtkins> smfr, Notice also that it transitions on page load from black
               to red.  That doesn't seem to make sense.
   <smfr> sounds like a bug
   smfr: transitions: we will publish another WD then aim for LC in early 2010

   glazou: 2D transforms; what about the rotated table header scenario esp.
           not overlapping preceding content ?
   fantasai: this is difficult as the table header borders also need to be
             properly rotated
   dbaron: there was a long discussion and proposal around this topic in
           the past (Beijing)

CSS3 Animations

   smfr: we think animations are useful. There are things you can do with
         animations you can't with transitions such as moving objects
         through intermediate points
   smfr: 3D Tranforms needs more work e.g. detailing the 3D hiearchy of elements
   glazou: let's move transitions and 2d transforms forward
   dbaron: I think transform-origin is interesting as in 3d the value requires
           extra input vs. 2d. (the latter is exactly like background-position)
   sylvaing: what about the note at the top of 2d transforms re: transforming
             fixed positioned descendants ?
   smfr: dave hyatt made this note; we think this is the most desirable behavior
   dbaron: we do this as well
   smfr: for fixed backgrounds, we have already noted that the transformed
         element will act like a porthole. we don't do this yet but will fix it
   <smfr> i didn't say we'll fix it :)
   * sylvaing oops
   * fantasai sylvaing, if you want a break let me know
   * fantasai thinks you have been doing a lot of minuting today :)
   * sylvaing i like to make up apple claims though

Modularization and how to write a CSS profile

   szilles: ideally profiles should refer to RECs. if not, breaking circularity
            can be achieved by referring to a snapshot
   fantasai: or a module such as CSS3 Multicolumn can refer to CSS2.1 but if
             an implementor supports CSS3 Color, the latter's definition of
             <color> then applies
   szilles: then the profile should state this
   fantasai reads from http://www.w3.org/TR/css-beijing/#css3 + the next section
   quick discussion of when one can be conformant with no vendor prefix;
   answer: one a module reaches CR
   szilles: we hope that conformance would be claimed against the snapshot
   szilles: if I don't know what a snapshot is, I won't find the information
            I need
   fantasai: the /TR reference for CSS3 will point to the snapshot
   fantasai: Also the css3-roadmap URL will redirect to the snapshot
   fantasai: we can update the snapshot as soon as Selectors moves to CR or PR
   <szilles> Note, that under current rules, an implementation is still
             conforming if it implements features, like CSS3 color, that
             are in CR, using the CSS property names rather than having
             a vendor prefix
Received on Thursday, 12 November 2009 23:06:58 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:41 UTC