[CSSWG] Minutes Lisbon F2F 2016-09-19 Part V: Transforms, Variables, Transitions/Animations, Cascade, CR Plan, January Meeting [css-transforms] [css-variables] [css-transitions] [css-animations] [css-cascade]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Punt 3d transforms to level 2, turn it into a real
              spec, quickly REC Transforms 1.


  - RESOLVED: Custom properties must preserve their input exactly
              for serialization.
  - RESOLVED: var() function works in keyframes, pulls its value
              from the animated value of the custom property on the


  - RESOLVED: Move the four transition/animation new events to the
              level 1 specs.
  - RESOLVED: After edits, publish new WDS of transitions and


  - RESOLVED: republish Cascade 4 as CR, with the additional note
              that inheritance isn't affected by "revert".

CR Plan

  - Grid, Selectors, Box Alignment, Media Queries 4 should be in CR
      before the publication freeze at the end of the year.
      - Any open items for them will be prioritized on tomorrow's
  - RESOLVED: Publish Tables as FPWD.

January Meeting

  - Seattle F2F for Jan 11-13 is confirmed, just waiting to see if
      it's in Seattle proper or in Redmond.
  - Looking further, Japan is provisionally the week of 17 April,
      but may not be held if it's decided the group could just have
      three F2Fs next week (Seattle, summer, TPAC).

===== FULL MINUTES BELOW =======

Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

Scribe: TabAtkins


  shane: translate/rotate/scale are in a L2 delta spec.
  shane: We did that because Transforms 1 was gonna be stable Real
         Soon Now©
  shane: So asking if we can move them to L1.
  * fantasai suggests someone just finish Transforms 1

  dbaron: How many implementations?
  shane: We have one behind a flag.
  dbaron: We had someone working on it, but it was harder than I
  dbaron: To do animation, it needs to be plumbed all the way thru
          the compositor. Seemed like too much effort.
  shane: I think our implementation doesn't plumb; it pulls
         animations back to the main thread if you animate one of
         the properties.
  shane: Not a long-term plan, but there's a growing list of
         properties that need the same treatment. offset-* stuff too.
  shane: So our intention was to do everything in one blast.
  shane: Pulling things to compositor isn't particularly expensive
  dbaron: I was concerned about the cost of new code needing to be
          written, not performance.
  shane: I'd just say that an increased gamut of compositable
         properties is coming anyway. We're deferring that cost as
         well, but we'll have to go back and pay it too.

  dino: So question is whether to put them into Transforms 1.
  dino: What's wrong with keeping it in level 2?
  TabAtkins: CSSWG policy is to not ship publicly until it's stable;
             delta specs aren't.
  dino: Problem remaining is some 3d issues, multiple
        implementations that all disagree a bit.
  ChrisL: How are people using 3d if browsers disagree?
  shane: There's just a lot of content that works in only one
  ChrisL: So there's gonna be compat issues anyway?
  shane: Yeah.
  dino: I think Simon proposed something that required some tweaking
        from everyone. We were waiting for Roc, but that drove him
        from Mozilla. ;)
  TabAtkins: So split it back into 2d-transforms and 3d-transforms.
  <gregwhitworth> based on the hand wringing I had to do to get all
                  of the browsers to implement control characters -
                  not entirely sure it's going to be easy to "break"
                  everything together. But I think it's worth trying
  <gregwhitworth> ^ rendering of control characters 0 and 1
  <gregwhitworth> TabAtkins: this is partially the chicken and egg

  Rossen: So thoughts?
  fantasai: If 2d transforms is done, it can sail thru, then we do
            the translate/rotate/scale in level 2, + 3d transforms.
  fantasai: Tab can cut a version and make a DoC.
  Rossen: Option 1 is do what Shane is asking, pull translate rotate
          scale into level 1.
  Rossen: Option 2 is split 3d transforms into level 2, and send 2d
          transforms to Rec.
  Rossen: Option 3 is do nothing.

  <leaverou> how is Option 1 different than Option 3?
  shane: I like option 2 better
  * fantasai too
  dbaron: This feels like make-work without an editor.
  TabAtkins: I can do it. Just mechanical shifts.

  RESOLVED: Punt 3d transforms to level 2, turn it into a real spec,
            quickly REC Transforms 1.

  Action Tab to do the Transforms split/reform.
  <trackbot> Created ACTION-792

  dino: If we don't want to have this discussion again in 7 years, I
        recommend browsers read the 3d stuff and figure out how 3d
  dbaron: Can dino send a URL to the part you want feedback on?
  dino: Yes. Not all of it is in the spec now.

  Scribe: fantasai

  TabAtkins: Easiest to hardest order..

How to store custom property values?

  TabAtkins: How to store/serialize custom property values
  TabAtkins: Specifically, when putting non-CSSy syntaxes into a
             custom property, e.g. SVG path syntax
  <TabAtkins> --path: m40.0,20.0;
  TabAtkins: This is a single move command.
  TabAtkins: From SVG perspective, this is an "m", a 40.0, a comma,
             and a 20.0
  TabAtkins: From CSS perspective, this is an ident m40, a number
             .0, a comma, and a number.
  <TabAtkins> --path: m40/**/0.0,20.0;
  TabAtkins: ...
  ChrisL: Can't you just put a space there?
  TabAtkins: In this particular case, yeah.
  TabAtkins: We don't keep around the original information.
  TabAtkins: So when we re-serialize it, can parse out differently
             (see above)

  SimonSapin: What about having property as a single string?
  TabAtkins: Suggestion is to carry the value as a single string,
             and then parse it into tokens when it is used.
  leaverou: What is advantage of parsing it as a token stream?
  TabAtkins: Simpler 'cuz it just parses in as CSS.
  TabAtkins: To parse it in as a string, would need to cross
             tokenization/parser levels.
  dbaron: In Gecko and Servo, stores it as a string.
  Rossen: Observable through white space as well.
  shane: I think there's a strong author concern, to write in
         something that looks like an SVG path and get out a thing
         with a CSS comment in it.
  <ChrisL> yeah the unexpected blank comment is really unexpected
           and crufty
  TabAtkins: CSS Syntax technically handles this by keeping around
             the original representation, but nobody does it anyway.
  TabAtkins: I would have to do some fixes to make this all work
  SimonSapin: Could also punch a hole in the abstraction and say
              this is just a string.

  <AmeliaBR> Re SVG path notation: I prefer to keep it as a string
             from CSS perspective, so that authors can still copy &
             paste SVG path data created by existing visual editors.
             But I also want to add functions to concatenate
             multiple path strings.

  TabAtkins: I don't know how to write that in specese.
  SimonSapin: Just specify normatively that it's parsed as a string.
  fantasai: Spec is written in English. You can spec normatively
            anything you can explain to us.
  TabAtkins: So parse in as a string.
  SimonSapin: Then preserve comments in the string?
  TabAtkins: Eh, I guess I'll try to spec this and then seen how it
             comes out.
  TabAtkins: Guess there's no objection to this, since y'all
             implement it already.

  leaverou: Does this make it harder to have interpolable
            (animatable) values later?
  TabAtkins: No, because that's for typed values anyway.
  leaverou: You don't want to just say "This is a color", want to be
            able to say "this is a color then a length then a number"
  TabAtkins: I think we just give a string in the OM atm.

  RESOLVED: Custom properties must preserve their input exactly for

Value-tainting and allowing var() in keyframes

  TabAtkins: In order to avoid weird behavior loops, if you use a
             var() in a keyframes rule, we taint it so you can't use
             it in an animation-* property.
  TabAtkins: Tainting applies globally, so if different libraries
             using same name in different parts of the subtree,
             still tainted.
  TabAtkins: However, (Shane can give more detail), we've
             experimented with just tainting values directly
  TabAtkins: And apparently this is extremely easy.
  TabAtkins: Would like to, if possible, do value-based tainting
             instead of weird name-based tainting.

  birtles: Does this also cover the display property?
  birtles: Could you use a custom property to also animate display?
  TabAtkins: Only to go from none to block.
  TabAtkins: Shouldn't bring up new issues.
  TabAtkins: Only 'display: none' has special animation behavior.

  <frremy> --foo: abc;
           animation: var(--foo);
           @keyframes abc { to { --foo: def } }
  dbaron: I agree that fremy's case is an issue
  TabAtkins: This ties into the next issue, which is about using
             var() in @keyframes
  TabAtkins: Several engines allow var() in @keyframes even though I
             didn't spec it that way.
  TabAtkins: Need to define doing var() substitutions twice for this.
  TabAtkins: In this example, need to substitute var(foo) in the
             animation, get the abc value.
  TabAtkins: Then run the keyframe, would transition to def value.
  TabAtkins: At which point you redo your variable substitutions,
             but not in the keyframes.
  dbaron: That's painful for dynamic changes.
  dbaron: If there's a dynamic change, need to go back to the
          original one...
  dbaron: Or keep 2 sets of selectors for each element
  shane: You need to do that anyway.
  TabAtkins: Not generally, but if you are doing var in keyframes,
             which apparently you do.
  TabAtkins: Then you do.

  dbaron: I'm not sure we did it intentionally.
  TabAtkins: var() in keyframes takes the value from the element the
             animation is running on.
  TabAtkins: To do that properly, need to do that once, then
             resolve, then resubstitute.
  TabAtkins: Or just do it once and animate a property that doesn't
             get reflected, very weird.
  dbaron: I feel like you're crossing var() in keyframes and
          --custom-prop in keyframes.
  dbaron: Problem you described is problem with having custom-prop
          in keyframes, not having var()
  TabAtkins: It's a problem with having custom properties in
             keyframes that affect animations, currently handled by
  TabAtkins: In ideal non-problematic case, have custom property
             defined for element, animation of that property on
             keyframes rule
  TabAtkins: var substitution should reflect the running animation,
             not the base value.
  dbaron: Animations make you compute style.

  fantasai: How do you animate a string?
  TabAtkins: flip at 50%
  * fantasai doesn't think this is useful
  fantasai: what's the use case for animating custom properties?
  TabAtkins: Adding ability to type custom properties in Houdini.
  TabAtkins: Lea also has some examples where it's useful to animate

  <birtles> problem with display property:
            --foo: block;
            animation: yer 1s;
            display: var(--foo)
            @keyframes yer { from, to { --foo: none } }

  dbaron: How does the global tainting work?
  TabAtkins: If a custom property is animated in any keyframe
  TabAtkins: That name is tainted, and becomes an invalid reference
             in an animation-* property.
  dbaron: I think global tainting is less disruptive cuz affects
          less stuff.
  shane: Can be bad because blow a way a bunch of rules unexpectedly.

  dbaron: Can you do the other tainting in both directions?
  dbaron: Such that if you use a custom property in a keyframe then
          you taint the value and it can't be used in an animation
          and... that's harder though.
  dbaron: To solve frremy's case, need to also taint in other
  shane: For frremy's case
  shane: You apply your static style
  shane: That might trigger some animations
  shane: And then you apply your animated style after that.
  shane: Don't update var() references in animation properties.
  dbaron: As long as we don't send AnimationStart and AnimationEnd
          events each time.
  shane: You don't update animation-* properties EVER as a result of
         animated styles.
  dbaron: That's actually really hard for us.
  dbaron: When we apply the animation style, we create a new style
          context with a different rule, and the old one is gone now.
  dbaron: We're relying on the way cascading works that it has the
          same animation values
  dbaron: And this would mean sometimes they don't.
  TabAtkins: Don't update them.
  dbaron: How do we not update them?
  shane: You...
  dbaron: We recompute the variable references because we created a
          new style context.
  Rossen: Our impl is fairly similar in that respect.

  frremy: You cannot animate custom properties that are used in
  frremy: If you use something in animation, big red flag to not use
  TabAtkins: One component might be using animation name for
             animation, another using it for something completely
             different. They could be in different subtrees, b/c
             this is global.
  shane: Could maybe look into subtree-scoping... but need to
         inherit that down...
  dbaron: I guess we could do it by keeping the pre-animation style
          around and get the non-animation properties from that.
  dbaron: Not that crazy.
  dbaron: We'd then end up... I just don't want to use that trick
  dbaron: Each time we use that trick, it's another power of 2 in
          memory... already using it for :visited stuff.
  fantasai: power of 2 for whole tree?
  dbaron: No just that element, but also adds lots of complexity.

  TabAtkins: Relatedly, I would love to note any idea you have wrt
             handling var in keyframes today.
  TabAtkins: For that still need these multiple phases.
  TabAtkins: Do need to run var substitution once to know what
             you're animating
  TabAtkins: And then need to ...
  dbaron: We're just computing style twice
  TabAtkins: That works, that's multi-phase -- but nobody needs to
             remember what the old style was in that case.
  dbaron: We're only doing it twice when you initially do the
  dbaron: Or when keyframes applied are changed.
  dbaron: Otherwise we have right animation the first time through.
  dbaron: But also have the keyframes the first time through.

  TabAtkins: Ok, I would like to at least just keep an issue on the
             name-tainting that we should try to figure out
             something better.
  TabAtkins: Works well for our impl, not so much for y'alls. Would
             like something cleaner and safer.
  dbaron: I guess your proposal isn't that horrible, just need to
          have the other style around.
  dbaron: Might even be able to get away without it.

  TabAtkins: Alternative is to not allow var() in animations ever.
  TabAtkins: Don't know what uses show up right now. But could
             restrict it entirely.
  birtles: Common to use variable for animation durations, to set it
  TabAtkins: Makes sense.
  <leaverou> TabAtkins, I recently used var() in animation
             properties. The animation was simulating typing by
             animating width with steps(), so I used var(--length)
             in both steps(), and in animation-duration (multiplied
             by .2s)

  TabAtkins: So, dbaron, how much "not that horrible" do you feel
             this is.
  TabAtkins: Should we switch the spec to value-tainting, or as an
  dbaron: Would prefer to keep as an issue until someone implements.
  gregwhitworth: Raised issue because we want to know what to do.
  TabAtkins: var in keyframes is a separate issue.
  TabAtkins: This was just about animation-tainting.

  TabAtkins: Let's talk about that issue.
  TabAtkins: Proposed resolution is the var() function works in
             @keyframes rules, and pulls its values from the element
             being animated.
  TabAtkins: Specifically, from the before-animations-run value.
  Rossen: Any objections?
  leaverou: If you use --foo in a keyframe, and var() in a keyframe,
            does it take its value from the element or the keyframe?
  TabAtkins: From the base value. You set up the animation keyframes
             first, and then ????
  TabAtkins: Everything else uses the animated value.
  [Everyone is confused]
  leaverou: var(--foo) will reflect the base value in the animation
            but not elsewhere? what?
  TabAtkins: It'll work like Lea wants, where var() will be replaced
             based on custom property in the keyframe.
  fantasai: Which is not what you said in the beginning.
  TabAtkins: It is not.
  <gregwhitworth> and I'm assuming that the --foo inside of the
                  keyframe will update the values outside of the
                  @keyframe correct?

  TabAtkins: Objections to proposed resolution?
  TabAtkins: Proposed resolution: var() function works in keyframes,
             pulls its value from the animated value of the custom
             property on the element

  RESOLVED: var() function works in keyframes, pulls its value from
            the animated value of the custom property on the element.

  SimonSapin: So any cycles are resolved the usual way?
  TabAtkins: Yeah
  TabAtkins: Only remaining issue is, don't change
             animation-tainting yet, but may want to change to
             value-tainting but too expensive atm.
  dbaron: Might want to describe what value-tainting is in that note.
  fantasai: Add an issue or a note

  birtles: The display issue.
  TabAtkins: That's a separate issue. Please file it.
  TabAtkins: Always been an issue.
  dbaron: ... been an issue since we added ability for keyframes to
          set non-animatable properties

  Scribe: TabAtkins

  birtles: We have level 2 specs for animations and transitions,
           delta specs.
  birtles: They define some extra events - animationcancel,
           transitioncancel, transitionstart (Edge and IE10 ship).
  birtles: I went to ship in Firefox, but spec and IE differ in
           delay. After some discussion, I added transitionrun as
  birtles: Lets us tell if a transition actually fired or not.
  birtles: transitionstart in Edge fires at the end of the delay,
           matching animationstart. Want to make the spec match.
  birtles: Then add transitionrun, which fires when a transition is
           applied, even if it's in a delay period.
  birtles: So we were thinking that since Edge ships we can just
           implement that, and do transitionrun at the same time.
           And then might as well do the cancels.
  birtles: So should we go for it?

  birtles: Issue is the elapsedTime member, a little complicated.
  birtles: elapsedTime wasn't clear, behavior or use-case. Was it
           for syncing animations?
  birtles: The way it's specced doesn't let you do that. It gives
           you the ideal time of when the event was fired, not the
           actual time.
  birtles: But all browsers are consistent, and spec says that. I've
           left it as it is.
  birtles: So should cancel events use the same thing - time when
           animation was canceled? Or zero?
  SimonSapin: If you're making it 0, does it need to be there at all?
  birtles: It's on the interface they all share.
  birtles: It's used enough in GitHub that we can't just remove it.
  <birtles> https://github.com/w3c/csswg-drafts/issues/68
  TabAtkins: Is it used in a way that would break things if we just
             made it 0 all the time?
  dino: Useful in iteration events, to know what iteration you're in.
  TabAtkins: Maybe we can cheat and just return multiple of duration
             in the iteration event, zero elsewhere?
  birtles: The start/end events do so too, so you can just divide by
  birtles: A lot of uses are just dumping to console for no obvious

  TabAtkins: So the cancels get fired if the transition property is
  birtles: Yeah.
  TabAtkins: Or if the target-value is changed? We cancel the
             current, start a new transition?
  birtles: Yeah.
  TabAtkins: Okay, then we probably do want the elapsedTime, to know
             whether we were nearly done with the transition or near
             the beginning.
  TabAtkins: So we need a resolution - do we want to bless these
             four events as shippable?
  SimonSapin: Should we move them to the level 1 spec?
  TabAtkins: What level is Transitions/Animations at? WD?
  [looks, they're both 2013 WDs]

  RESOLVED: Move the four transition/animation new events to the
            level 1 specs.
  RESOLVED: After edits, publish new WDS of transitions and

  <gregwhitworth> I would like to request a FPWD of tables,
                  hopefully that's short


  shane: The "revert" keyword is very very expensive to implement
  <fantasai> https://www.w3.org/TR/css-cascade-4/#valdef-all-revert
  <TabAtkins> https://drafts.csswg.org/indexes/
  shane: Apple's impl isn't correct as far as we can tell.
  shane: It's supposed to set the property to what it would be if
         there were no author stylesheets.
  shane: To do that you have to recompute the entire path from the
         root to the node, because of inheritance.
  fantasai: That's not right, the spec shouldn't be affecting
  fantasai: It only blows away declarations from the cascade; it
            doesn't touch inheritance. It's okay for the inherited
            value to be set by author-level rules.
  shane: If that's the case, then this is easy, never mind.

  RESOLVED: Republish Cascade 4 as CR, with the additional note that
            inheritance isn't affected by "revert".

  <fantasai> shane, is there a URL for your revert issue?
  <shane> fantasai: no, sorry
  SimonSapin: The definition of "revert" says "author-level". Does
              this mean "author origin"? And what about animations?
  TabAtkins: Think the point is that everything from an author-level
             stylesheet, so animations may fall into that.
  dbaron: Should just clear out animations/transitions entirely,
          always treat them as author-level.
  <dbaron> and override

  <ChrisL> is that the only change and have there been other
           comments on Cascade that need a DoC?
  <fantasai> ChrisL, Cascade 4 is ready for publication
             with one editorial issue resolved and fixed.
  <fantasai> ChrisL, can you get it published? :)
  <ChrisL> fantasai, I asked about the DoC for Cascade
  <fantasai> ChrisL, ? Link above?
  <ChrisL> oh right
  <ChrisL> excellent!
  <ChrisL> fantasai, seems we could get a transition request for
           Cascading & Inheritance fairly quickly with that tiny DoC

CR timing

  tantek: CR deadline for this year is basically tomorrow.
  tantek: But also, editors should speak up if they think their
          specs are near CR.
  fantasai: Grid! I need some response from Mats and then we're done.

  tantek: So this is our last f2f.
  tantek: This year.
  tantek: And there's a pub moratorium sometime in Dec, need a staff
          contact to tell us when it is.
  <liam> [ December 19 - Jan 1 ]
  <Bert> (Dec 14 = deadline for pub request)

  Florian: If we don't have a plan, I'd like to put MQ4 on the CR
  Florian: Lots of things we want to punt from it.
  tantek: Want to suggest Selectors 4.
  TabAtkins: Can punt some stuff.
  fantasai: There's some selectors interpretation issues that are
  tantek: Another is Box Align.
  fantasai: Almost done - baseline is the big stuff.
  tantek: I'm picking these because the issue list is small and the
          feature set seems frozen.
  fantasai: Yeah, Box Align should definitely be on the list.
  fantasai: Tomorrow we can sort out a syntax issue and do the
            baseline issues.
  dbaron: Were my issues about property interaction resolved?
  TabAtkins: I think so.
  <tantek> Box Align issues:

  Rossen: So we have Grid, Selectors, Box Align, MQ.
  Florian: Text 3?
  fantasai: It's in Last Call, I'm working on it.
  skk: What about Ruby?
  fantasai: That still has a lot to do, unfortunately.
  fantasai: I'm working on Text 3 in my spare time.
  fantasai: The Text 3 issues aren't super-complicated /
            interconnected. They're nice and independent.
  fantasai: Got some i18n issues, and then probably just push things
            to telecons.
  fantasai: There is a complete DoC, we just have to work thru it.
  tantek: So for these, can you look thru these and make sure all
          issues are raised.
  fantasai: And Scroll Snap is ready.
  tantek: Now how many are gated on two people?
  TabAtkins: Florian is on some of them.

  ChrisL: During the rechartering, got requests to say real status -
          "this is gonna wait for 4 years because it's complicated"
          or "this has X issues" or something.
  ChrisL: Not huge detail, but better than "expect CR".
  tantek: For those four or five specs, we can say "2016 Q4" and
          publicly commit.
  Florian: When we wrote the charter, we focused on Rec, as it
           seemed to be a process requirement.
  Florian: but the AC review seemed to show it's not - just put
           dates on what can be predicted.
  Florian: If we can predict CR but not Rec, just put that.
  Florian: Some people still want Rec dates, but idea that it needs
           Rec dates isn't valid.
  Florian: So next charter we can just put "Rec, unknown date, needs
  <ChrisL> https://www.w3.org/Style/CSS/current-work.en.html
  tantek: So having CR dates is valuable - we got that feedback.
  tantek: There's nothing between CR and PR - we're not
          communicating when we have no idea about the test suite.
  tantek: We should be transparent about that.
  astearns: Maybe Bikeshed can track it?
  TabAtkins: File me an issue?
  fantasai: This should be the custom status, instead of the stupid

  tantek: So for tomorrow's items - a lot that don't need to be in
          CR. If there are CR-blocking items, I'd like to prioritize
  Florian: We have some MQ4 and 5 issues; the 5 are on the agenda.
  tantek: So look thru MQ4 issues and see if any need to be raised.
  Rossen: If you're an editor of one of those CR-ready specs, and
          you do or don't have agenda items for tomorrow, bring it
          now or email us and we'll make sure they're addressed
          tomorrow. Otherwise we'll do the agenda as stated.
  tantek: And ask for horizontal review for these CR-ready specs?
  fantasai: We've sent those out months ago.
  tantek: So can we make an action to make sure those 5 specs have
          horizontal reviews?
  Rossen: Yes.

  gregwhitworth: I'd like to ask for an FPWD on Tables.

  RESOLVED: Publish Tables as FPWD.

  dbaron: Make sure it's marked as not ready for implementation yet.
  TabAtkins: In Bikeshed, use "Warning: not ready".
  tantek: Speaking of, what about Filter Effects 2?
  dino: No idea yet.
  tantek: I'll ask later again in January.

<jensimmons> hi all — I just updated the slides at
             to include the things I wrote up, but didn’t present
             — comparing my proposal to current Regions proposal,
             and comparing it to Slots, etc. Those slides are at
             the very end.
<astearns> jensimmons: add a link here as well?

January Meeting

  Rossen: So we've penciled down Seattle f2f for Jan 11-13.
  Rossen: Which is mid-week - Wed-Fri.
  Rossen: I'm working on getting Seattle space, so we don't have to
          do it in Redmond (by popular demand).
  Rossen: So feel free to book flights. In a week or two I'll have
          the destination for your hotels.
  Rossen: Might be a 1-day Houdini meeting on Jan 10 Tuesday.
  Rossen: We have late April in Japan.

  skk: I heard AC meeting in April is held 23-25.
  dbaron: In Beijing, yes.
  skk: And Tokyo is near. So I'd like to get our meeting before or
       after that.
  Florian: After is about to hit Golden Week.
  skk: Right, so maybe before is better. In the 17-21 week?
  dbaron: Who's going to the AC Meeting?

  <dbaron> How many people not based in East Asia would go to both
           the AC and CSS meetings?
  Florian: dbaron, and maybe me?
  dbaron: You're in Asia, ignore you.
  <fantasai> dbaron, last day of exams is May 10th, so I could do
             Wed-Fri that week or anytime after without missing
  Rossen: So 17-21 hits our bill - late April - and avoids Golden
  Rossen: Hiroshi might not be able to host in May in Tokyo.

  gsnedders: What about moving it earlier in April? Any easier?
  fantasai: No idea right now. Right now it's 2 weeks before end of
            classes. We'll make it work somehow.
  gsnedders: Note that April 16 is Easter.
  dbaron: And if you celebrate it, a 19-21 meeting means you have no
          jetlag day - you leave Monday and land Tuesday.
  dbaron: If we do a Houdini day before, you have to leave on Easter.

  [tons of unminuted discussion about spring/summer meetings]
  [ Rough conclusion - Japan in April 17-21 week is *provisional*.
      We might skip it; we'll decide in the next month. We might
      just do two meetings + TPAC, in which case we cancel Japan,
      and the second meeting will be sometime in Summer and is
      undecided right now.]

  <Rossen> adjourned

Received on Wednesday, 16 November 2016 01:59:08 UTC