- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 20:58:04 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Transforms
----------
- RESOLVED: Punt 3d transforms to level 2, turn it into a real
spec, quickly REC Transforms 1.
Variables
---------
- 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
element.
Transitions/Animations
----------------------
- RESOLVED: Move the four transition/animation new events to the
level 1 specs.
- RESOLVED: After edits, publish new WDS of transitions and
animations?
Cascade
-------
- 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
agenda.
- 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
Transforms
==========
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
thought.
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
anymore.
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
browser.
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
again
<gregwhitworth> ^ rendering of control characters 0 and 1
<gregwhitworth> TabAtkins: this is partially the chicken and egg
issue
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
works.
dbaron: Can dino send a URL to the part you want feedback on?
dino: Yes. Not all of it is in the spec now.
Variables
==========
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
properly.
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
serialization.
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
tainting.
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
keywords.
<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
direction,
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
animation.
frremy: If you use something in animation, big red flag to not use
it.
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
much
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
animation
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
globally.
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
issue.
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
Animations
==========
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
well.
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
duration.
birtles: A lot of uses are just dumping to console for no obvious
benefit.
TabAtkins: So the cancels get fired if the transition property is
removed?
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
animations?
<gregwhitworth> I would like to request a FPWD of tables,
hopefully that's short
Cascade
=======
shane: The "revert" keyword is very very expensive to implement
properly.
<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
inheritance.
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
https://drafts.csswg.org/css-cascade-4/issues-cr-2016
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
list.
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
harder.
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:
https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+%22%5Bcss-align%5D%22
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
tests"
<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
boilerplate.
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
them.
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
https://speakerdeck.com/jensimmons/proposal-to-csswg-sept-2016
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?
https://github.com/w3c/csswg-drafts/issues/499
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
classes
Rossen: So 17-21 hits our bill - late April - and avoids Golden
Week.
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