[CSSWG] Minutes and Resolutions Telecon 2012-02-29

Summary:

   - RESOLVED: Publish Flexbox as WD.
   - RESOLVED: Postpone the items listed as postpone in
               http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
   - RESOLVED: transition-* lists are aligned just like background-*,
               using transition-property as the master
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=14604
   - RESOLVED: reverse animations deferred from Transitions L1;
               but add example of how effect can be achieved now
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=14611
   - RESOLVED: Remove mention of 'grid' and 'zoom' properties from
               Transitions spec
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=14618
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=14626
   - RESOLVED: vertical-align keywords are not animatable
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=14988
   - RESOLVED: No transition (no transition events fire) when
               transition-delay and transition-duration are zero
               https://www.w3.org/Bugs/Public/show_bug.cgi?id=15838
   - RESOLVED: transform spec should make intersection behavior a MUST
   - Discussed some concerns with migration to Mercurial for specs
   - CSS3 Images Disposition of Comments has been drafted, please review
     changes and proposed resolutions:
       http://dev.w3.org/csswg/css3-images/issues-lc-2012
   - RESOLVED: Add after "Relative units in media queries are based on the
               initial value" a clarification that units are never based
               on the results of declarations, instead of adding 'rem'
               example.
   - RESOLVED: move editors of MQ who are no longer active to "Former editor"
   - Will shift Media Queries to PR next week, once implementation
     reports / testsuite are ready.
   - RESOLVED: drop comma between attribute name and type in attr()
   - RESOLVED: publish last call of css3-values

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

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Kimberly Blessing
   Bert Bos
   Tantek Çelik (via IRC)
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Divya Manian
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Dirk Shulze
   Alan Stearns
   David Storey
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/02/29-css-irc
Scribe: glenn
Chair: glazou

Administrative
--------------

   Florian: like to talk about MQ
   <Zakim> + +8521616aabb
   alex: can we publish WD of Flexbox?
   <Zakim> + +47.23.69.aaee
   <Zakim> +??P78
   Sylvain: gradients on agenda?
   glazou: only normative reference on agenda ... yes if possible
   alex: discussed LC on flexbox
   Florian: would like a WD
   alex: will publish by tuesday
   chrisl: WD or what?
   RESOLVED: Publish Flexbox as WD.
   ACTION: ChrisL to publish flexbox wd
   <trackbot> Created ACTION-453
   <tantek> TabAtkins, do you have a URL/webpage example of the new
            flexbox syntax/functionality/algorithm that shows it
            "working" (even prefixed) in 2+ implementations? (just
            curious what state of spec vs implementation is.

Transitions
-----------

   <smfr> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html
   glazou: post msg from david with list of issues
   dbaron: [summarizes items listed to defer]
   <ChrisL> I agree with all the ones in the postpone category, having read
            through them
   <sylvaing> ChrisL, +1
   <tantek> dbaron's clustering of issues postpone/easy/medium/hard is a
            good approach for helping advance these specs quickly.

   Florian: what is meant by defer?
   florian: impls free to do what they want?
   Tab: people will depend on whatever the implementations do, no matter what
        the spec says
   smfr: webkit has cross fade
   smfr: will do transitions using cross fade, agrees should be undefined
         how accomplished
   * fantasai agrees with florian
   dbaron: I think WebKit is implementing the newer spec
   Florian: should not have normative statement if will soon override
   ChrisL: what is wrong with saying undefined?
   ChrisL: worried if you say can't animate, or if you say can animate
           but not what happens
   fantasai: should specify that whether and how it's animated is undefined
   fantasai: then mention that it will be defined in future spec
   chrisl: if spec says you should not animate this, will have tests asserting
           that it doesn't animate, which will fail in implementations of the
           newer spec. If you leave it undefined, there will be no tests.
   dbaron: css1/2 have said ignore props not defined in spec, yet css3 is
           defining new props
   dbaron: I think that's fine
   * sylvaing thinks we're spending a lot of time figuring out what not to do
   <stearns> we know what not do to, we're figuring out how not to do it
   <florianr> This level of css does not expect XXX to animate. Different
              modules or later levels may define how to animate them.
   <smfr> I'm fine with florianr's wording
   ???: such and such is not expected to animate, but different ? will
        defines how this works
   dbaron: are we talking just about images/gradients or everything not
           animatable?
   dbaron: think we're talking about everything, concerned about putting
           in a big loop hole by making it undefined
   chrisl: There are three categories of things
   chrisl: (1) not animatable
           (2) animatable, but don't know how to animate,
           (3) not sure
   ???: is it clear on (2) vs (3)? Rather be specific when possible.
   dbaron: ok if we have statement about limited set of props
   dbaron: should i take an action to write that statement?
   dbaron: most of the rest aren't properties
   glazou: would like a decision
   <smfr> i agree
   chrisl: agrees with entire list of things to postpone
   ... to which sylviang agreed

   <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14609
   dbaron: issue on transitioning value types you can't interpolate
   dbaorn: things would animate that people aren't expecting to animate
   Tab: can define special timing model for discrete things, and only
        include those properties if the animate
   chrisl: in SVG discrete changes interpolate
   dbaron: are people not worried about this?
   dbaron: will put constraints on what we can do
   tab: if transitions immediately after non-zero, then should work
   <smfr> transition: all 2s 2s;
   tab: find with leaving or fixing, simple to fix
   smfr: thinks not simple to fix
   tab: shouldn't have transition all
   Florian: suggests postponing
   dbaron: Given the common use of transitions already, we probably
           should work within constraints anyway. Ok with postponing
   <smfr> i'm ok with postponing
   RESOLVED: Postpone the items listed as postpone in
             http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html

   <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15844
   tab: can't having impls doing different things...
   dbaron: don't want webkit behavior
   smfr: WebKit treats 'auto' as '0'
   dbaron: That's a bug and should be fixed.
   <Bert> (Animating from 'top' to 'bottom' makes sense, but doesn't
           seem needed.)

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14604
   dbaron: how to match lists of different lengths
   dbaron: in transition-* properties
   dbaron: For backgrounds, it's the length of background-image that matters
   dbaron: suggest we do the same, using transition-property
   dbaron: if other properties have more values, use beginning of list
           and ignore the rest
   <ChrisL> agree with the truncated/repeated proposal
   dbaron: Proposed to copy behavior of background properties
   RESOLVED: resolve bug 14604 as proposed

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14611
   dbaron: next, reverse animation using opposite timing function, people
           ask for feature
   dbaron: Sugest postponing such a feature, but adding an example to show
           how it can be used now
   dbaron: a little confusing at first, but not too hard
   glazou: good compromise
   RESOLVED: resolve bug 14611 as proposed

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14618
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14626
   dbaron: spec mentions grid and zoom props
   dbaron: grid isn't any spec, zoom is non-standard; propose removing refs
   <ChrisL> agreed
   tab: agree
   RESOLVED: resolve bug 14618 and 14626 as proposed

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=14988
   dbaron: vertical align is animatable (according to spec), but what
           does animating keywords mean?
   <smfr> agreed
   Florian: should we say "no keywords" or just enumerate the subset of
            what can animate?
   RESOLVED: resolve bug 14988 as proposed

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=15838
   dbaron: last of easy items
   dbaron: no transition when both transition-delay and transition-duration
           are zero seconds
   <ChrisL> agree on the zero transition
   dbaron: nothing says it
   tab: doesn't like because it is discontinuous behavior
   dbaron: the default is transition-property: all
   tab: ok, need to make not a transition
   florianr: does the spec say this?
   smfr: implication of transition not occurring is that no events fire?
   tab: oh, we default to transition-property: all; and transition-duration
        / transition-delay to zero
   bert: Spec says no animation in that case
   Florian: does the spec say that?
   <Bert> "By default the value is ‘0s’, meaning that the transition is
           immediate (i.e. there will be no animation)."
   <TabAtkins> Specifically, the current "no transitions" default is
               implemention with a property of "all" and a delay/duration
               of "0".
   tab: events are important part
   fantasai: why do we have default of all/zero?
   smfr: [explained the original reasoning between the current defaults
          vs defaulting to a property of 'none' and some default duration:
          authors could transition the properties they were changing by
          making a single statement adding transition-duration]
   smfr: [there are usability reasons for defaults of 'all' and '0s']
   <smfr> i approve
   RESOLVED: resolve bug 15838 as proposed

Z-Axis intersection for transforms
----------------------------------

   glazou: moving to Z-axis intersection issue for transforms
   glazou: is dirk here?
   <smfr> http://lists.w3.org/Archives/Public/www-style/2012Feb/1202.html

   Florian: opera does not have impl of 3d transforms
   Florian: in favor of saying do intersection in spec
   Florian: not in favor of saying should
   dbaron: talked to Robert O'Callahan, and he agreed the correct behavior
           (plane splitting) is obvious but we don't do it correctly now,
           but we should
   tab: would like to do correctly, though impl is tricky
   RESOLVED: transform spec should make intersection behavior a MUST

Mercurial Migration
-------------------

   jdaggett: possible problem with mirroring specs
   jdaggett: there were concerns about dvcs.w3.org not being able to
             use Apache configs.
   jdaggett: proposal was to host specs on csswg.org, but I think that's
             a bad idea
   jdaggett: means ... all editor's drafts have to point to csswg.org
   jdaggett: I don't see that using Apache is necessary. We can use
             <meta> to do redirection.
   jdaggett: Not ideal, but better than having csswg.org be a point of failure
   jdaggett: Not necessary to use .htaccess facilities
   <tantek> I agree, I'd rather delay the source control transition if
            it means we can avoid one or more temporary places for specs.
   plinss: timing to be finalized today
   plinss: infrastructure already in place
   plinss: we wanted better docs, but working on them today
   plinss: no addl burden on editors
   <tantek> I have not had time to retry the hg instructions again to
            see where I get stuck next btw.

   jdaggett: question using URLs to refer to csswg.org host
   plinss: We could ask sysreq to set up a reverse proxy on dev.w3.org
   bert: pretty sure its possible
   <dbaron> (Why do a reverse proxy on a w3c server if we could just do
             a checkout on a w3c server?)
   <tantek> exactly, what dbaron said
   plinss: this is just a stop gap, i.e., using csswg.org
   jdaggett: doesn't see need for interim step
   <tantek> can we delay transition and avoid stopgaps?
   <tantek> what's the rush?
   * smfr wonders if this is better resolved offline
   <tantek> I agree with the concerns that jdaggett has raised.
   plinss: if we use reverse proxy, nobody will know
   ... will start with proxy on dev.w3.org to csswg.org
   jdaggett: doesn't like having csswg.org as a point of failure
   plinss: only for a few weeks/months
   jdaggett: doesn't see this step as necessary
   <dbaron> If there's a chance we can make this happen in a matter of
            days, I think we should try to get that to happen.
   <dbaron> I think it's preferable to have the editors drafts have
            w3.org URLs
   plinss: They'll be served from dev.w3.org URLs
   plinss: I'm volunteering to do all the admin work
   plinss: what's the big deal?
   jdaggett: sounds like extra work for nothing
   jdaggett: had breakage previously
   plinss: That was because the test copy of the repository isn't synced
   * fantasai thinks this discussion should be over now
   <going in loops here... glazou?>
   * sylvaing lost track of what we're talking about
   glazou: pls take to email or irc after call

CSS3 Images
-----------

   fantasai: DoC but won't get through them today
   <dbaron> http://dev.w3.org/csswg/css3-images/issues-lc-2012
            is the thing to review?
   fantasai: all should review DoC and discuss issues during next telecon
   glazou: refs need review
   fantasai: all are pretty tricky
   tab: need other people looking at them
   glazou: action on all to review DoC and comment

   fantasai suggests discussing Values and Units LC instead, since
   we won't get through DoC today

* fantasai wants to get to LC for css3-values, if possible
<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JanMar/0309.html

Media Queries
-------------

   florianr: like to go back to MQ
   Florian: current TS is not latest version
   fantasai: already have an action item to do this
   florianr: will write results for opera
   ... also some editorial changes, should republish
   ... question about when
   <florianr> http://my.opera.com/desktopteam/blog/2012/02/28/precision-engine
   fantasai: suggests passing (opera) build first
   fantasai: go to LC then hopefully PR
   fantasai: or are they only editorial changes?
   florianr: Borderline
   florianr: Not changing what they say, just what people understand
             them to say

   florianr: There's a request on ML for example of using 'rem'
   fantasai: no opinion
   * fantasai read the thread
   * sylvaing is not clear on what we resolved on MQ
   florianr: suggest not adding this specific example because it refers
             to feature not referenced
   glazou: think is not needed
   dbaron: but may help to clarify spec text, that units never based on
           results of declarations
   dbaron: Then it's unambiguous that rem behaves same way
   <dbaron> Add to "Relative units in media queries are based on the
            initial value."
   florianr: sounds good, will edit and republish
   <is there a resolution? pls someone type into irc>
   RESOLVED: Add after "Relative units in media queries are based on the
             initial value" a clarification that units are never based
             on the results of declarations, instead of adding 'rem'
             example.

   dbaron: btw, previous version link in draft is obsolete/previous version:
           link in draft points to previous previous version

   chrisl: if all editorial, don't need another LC
   chrisl: or is proposal to go to PR?
   dbaron: possible in one week
   dbaron: depends on impl reports
   florianr: can have IRs tomorrow
   fantasai: agreed
   dbaron: mozilla passes all the tests in the repo

   florianr: should we list previous editors as current editors or previous?
   florian: currently listed as previous
   <jdaggett> previous editors seems fine
   glazou: no opinion
   tab: list as previous
   stevez: long tradition
   RESOLVED: move editors of MQ who are no longer active to "Former editor"
   <dbaron> though sometimes the "previous editors" is editors for a
            previous level of the spec, which is sort of different...

Values and Units
----------------

   fantasai: Everybody ok with removing the comma between attribute name
             and type in the attr() function?
   glazou: not fair to ask this now at end of call
   <Bert> (I don't like it without the comma, but can live with it.)
   peterl: We discussed it at f2f, and howcome was only dissenter.
   peterl: And howcome just said he's ok with it.
   fantasai: Murakami-san said he's ok with it, too.
   RESOLVED: drop comma between attribute name and type in attr()
   RESOLVED: publish last call of css3-values

<RRSAgent> http://www.w3.org/2012/02/29-css-minutes.html


<florianr> dbaron: I am not sure if the minutes have the exact wording
            you proposed for MQ. Here is what I have, is that what you
            proposed: "Relative units in media queries are based on the
            initial value, and units are never based on results of
            declarations."
<dbaron> florianr, how about changing ", and" to ", which means that" ?
<florianr> that's better.

Received on Thursday, 1 March 2012 02:31:18 UTC