/irc-logs / w3c / #css / 2014-01-27 / end

Options:

# Session Start: Mon Jan 27 00:00:00 2014
# Session Ident: #css
# [00:12] * Joins: florian (~Adium@public.cloak)
# [00:20] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [00:42] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [00:43] * Joins: koji (~koji@public.cloak)
# [00:45] * Joins: koji_ (~koji@public.cloak)
# [00:45] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [01:00] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:00] * Joins: dwim (~dwim@public.cloak)
# [01:26] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [01:26] * Joins: dwim (~dwim@public.cloak)
# [01:27] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [01:39] * Joins: smfr (~smfr@public.cloak)
# [01:41] * Joins: sgalineau (~sgalineau@public.cloak)
# [01:51] * Joins: florian (~Adium@public.cloak)
# [01:51] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [01:57] * Joins: florian (~Adium@public.cloak)
# [02:03] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [02:08] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [02:12] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:28] * Quits: koji_ (~koji@public.cloak) (Client closed connection)
# [02:28] * Joins: koji (~koji@public.cloak)
# [02:33] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [02:34] * Joins: koji (~koji@public.cloak)
# [02:35] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [02:35] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [02:35] * Joins: dwim (~dwim@public.cloak)
# [02:36] * Joins: koji (~koji@public.cloak)
# [02:52] * Quits: smfr (~smfr@public.cloak) (smfr)
# [02:55] * Joins: smfr (~smfr@public.cloak)
# [03:12] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [03:13] * Joins: koji (~koji@public.cloak)
# [03:20] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:30] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [03:30] * Joins: dwim (~dwim@public.cloak)
# [03:32] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [03:32] * Joins: dwim (~dwim@public.cloak)
# [03:37] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [03:40] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [03:40] * Quits: smfr (~smfr@public.cloak) (smfr)
# [03:46] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [03:49] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [04:38] * Joins: dauwhe (~dauwhe@public.cloak)
# [04:43] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [04:45] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [04:58] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:00] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [05:00] * Joins: dwim (~dwim@public.cloak)
# [05:03] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [05:04] * Joins: dwim (~dwim@public.cloak)
# [05:17] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [05:52] * Joins: jcraig (~jcraig@public.cloak)
# [05:58] * Parts: jcraig (~jcraig@public.cloak) (jcraig)
# [06:17] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:24] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [06:29] * Joins: dbaron (~dbaron@public.cloak)
# [06:37] <dbaron> I'm in the hotel in Seattle.
# [06:39] * Joins: dbaron_ (~dbaron@public.cloak)
# [06:42] * Joins: zcorpan (~zcorpan@public.cloak)
# [06:44] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [06:46] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [06:49] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [06:51] * Quits: otherliam (liam@public.cloak) (Client closed connection)
# [06:53] * Joins: liam (liam@public.cloak)
# [07:01] * Joins: zcorpan (~zcorpan@public.cloak)
# [07:01] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [07:10] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [07:15] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [07:17] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:30] * Joins: smfr (~smfr@public.cloak)
# [07:34] * Joins: shepazu (schepers@public.cloak)
# [07:41] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [07:42] * Joins: dwim (~dwim@public.cloak)
# [07:44] * Joins: florian (~Adium@public.cloak)
# [07:44] * Quits: smfr (~smfr@public.cloak) (smfr)
# [07:52] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [08:00] * Quits: lmcliste_ (~lmclister@public.cloak) ("")
# [08:06] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [08:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:47] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [08:59] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:16] * Quits: dbaron_ (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [09:25] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [09:25] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:26] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [09:26] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [09:27] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:27] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [09:34] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [09:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [09:49] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [09:56] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:57] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [09:57] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:07] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [10:07] * Joins: dwim (~dwim@public.cloak)
# [10:35] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:39] * Quits: dwim (~dwim@public.cloak) (Client closed connection)
# [10:39] * Joins: dwim (~dwim@public.cloak)
# [10:42] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:49] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [10:53] * Joins: darktears (~darktears@public.cloak)
# [11:04] * Joins: sarasou (~sarasou@public.cloak)
# [11:05] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [11:09] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [11:09] * nvdbleek3 is now known as nvdbleek
# [11:11] * Quits: sarasou (~sarasou@public.cloak) (Ping timeout: 180 seconds)
# [11:28] * Joins: zcorpan (~zcorpan@public.cloak)
# [11:35] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [11:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:49] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:23] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [12:29] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:36] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:45] * Joins: plh (plehegar@public.cloak)
# [12:50] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:11] * Joins: koji (~koji@public.cloak)
# [13:29] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:36] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [13:43] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:47] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [13:50] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [13:54] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [14:30] * Joins: zcorpan (~zcorpan@public.cloak)
# [14:37] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [14:39] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [14:40] * Joins: koji (~koji@public.cloak)
# [14:47] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [14:55] * Joins: koji (~koji@public.cloak)
# [15:05] * Joins: eliezerb (~Eliezer@public.cloak)
# [15:14] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:21] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [15:22] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:30] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [15:30] * Joins: koji (~koji@public.cloak)
# [15:31] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:37] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [15:37] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [15:37] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [15:38] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [15:38] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [15:45] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [15:45] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [15:53] * Joins: koji (~koji@public.cloak)
# [16:05] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:06] * Joins: florian (~Adium@public.cloak)
# [16:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:19] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:34] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [16:46] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [16:47] * Joins: florian (~Adium@public.cloak)
# [16:48] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [16:49] * Joins: koji (~koji@public.cloak)
# [16:56] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [16:56] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [16:58] * Joins: koji (~koji@public.cloak)
# [17:16] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [17:22] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [17:22] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:29] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:36] * Joins: AdobeSeattle (~AdobeSeattle@public.cloak)
# [17:38] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [17:39] * Joins: koji (~koji@public.cloak)
# [17:40] * Joins: Henke37 (~Henrik@public.cloak)
# [17:40] * Joins: Zakim (zakim@public.cloak)
# [17:40] <plinss> zakim, this will be style
# [17:40] <Zakim> I do not see a conference matching that name scheduled within the next hour, plinss
# [17:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:41] <plinss> zakim, remind us in 10 hours to go home
# [17:41] <Zakim> ok, plinss
# [17:41] <Ms2ger> A meeting?
# [17:42] * plinss changes topic to 'http://wiki.csswg.org/planning/seattle-2014'
# [17:42] * Joins: glazou (~glazou@public.cloak)
# [17:46] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [17:47] * Joins: glenn (~gadams@public.cloak)
# [17:56] * Quits: cabanier_ (~sid15093@public.cloak) (Client closed connection)
# [17:56] * Joins: cabanier_ (~sid15093@public.cloak)
# [17:56] * Quits: astearns (~sid15080@public.cloak) (Client closed connection)
# [17:57] * Joins: astearns (~sid15080@public.cloak)
# [18:00] * Joins: smfr (~smfr@public.cloak)
# [18:02] * Joins: lmcliste_ (~lmclister@public.cloak)
# [18:07] <glenn> dial-in status?
# [18:07] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:13] <glazou> sylvain is out of the room for a few minutes, I will ask him ASAP, glenn
# [18:13] <glenn> tnx; i'm on call, but sylvain has not activated it yet
# [18:14] <glazou> ok
# [18:16] * Joins: yamamoto (~yamamoto@public.cloak)
# [18:17] * Joins: koji (~koji@public.cloak)
# [18:17] * Joins: smfr (~smfr@public.cloak)
# [18:18] <smfr> glenn: we haven't started yet
# [18:18] <smfr> glenn: there is a polycom tho
# [18:19] <glenn> ok; i'm on hold, waiting on the conf to start on the dial-in posted in the planning page; is there a scheduled start time? i thought it was 9am
# [18:20] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [18:21] <dauwhe> Sylvain is dialing now...
# [18:24] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [18:24] * Joins: florian (~Adium@public.cloak)
# [18:24] * Joins: israelh (~israelh@public.cloak)
# [18:26] <glazou> http://wiki.csswg.org/planning/seattle-2014
# [18:26] <fantasai> Topic: Agenda
# [18:26] * Quits: darktears (~darktears@public.cloak) ("Linkinus - http://linkinus.com")
# [18:26] <fantasai> Scribenick: fantasai
# [18:26] * Joins: dbaron (~dbaron@public.cloak)
# [18:27] <fantasai> fantasai: I'll be flying out 1pm on Wed, so anything you want me here for, don't schedule for then
# [18:27] * Joins: SteveZ_ (~SteveZ@public.cloak)
# [18:27] * Joins: ChrisL (clilley@public.cloak)
# [18:28] <fantasai> various other ppl leaving early on Wed, but not that early
# [18:28] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:28] <fantasai> glazou: Some items LC/CR
# [18:29] <fantasai> glazou: masking, shapes, syntax, variables...
# [18:29] <fantasai> glazou: Maybe start with that
# [18:29] * Joins: leif (~lastorset@public.cloak)
# [18:29] * Joins: plh (plehegar@public.cloak)
# [18:29] <fantasai> glazou: Dedicate this morning to this document?
# [18:29] <fantasai> krit: Some masking stuff has to be wed, but maybe 45min for today
# [18:30] <fantasai> astearns: shapes, 15-20min
# [18:30] * Joins: zmike (~zmike@public.cloak)
# [18:30] <fantasai> fantasai: flexbox, maybe 20-30 min now, then discuss min-size issue later... that might take awhile, and benefit from discussion over lunch
# [18:31] <fantasai> TabAtkins: No comments for Variables, so really quick
# [18:32] * Joins: shepazu (schepers@public.cloak)
# [18:32] <fantasai> glazou: Elements as regions tomorrow afternoon
# [18:32] * Joins: kawabata2 (~kawabata@public.cloak)
# [18:32] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:32] * Joins: sgalineau (~sgalineau@public.cloak)
# [18:32] <fantasai> fantasai: merging animatable / computed value lines for this afternoon?
# [18:32] <fantasai> fantasai, tab: estimate 30min
# [18:32] <dbaron> I don't understand the proposal, btw.
# [18:33] * Joins: darktears (~darktears@public.cloak)
# [18:33] * Joins: adenilson (~anonymous@public.cloak)
# [18:33] <fantasai> fantasai: grid probably also half an hour, but can put anywhere
# [18:33] <fantasai> glazou: update on TTA this afternoon?
# [18:33] <fantasai> fantasai: That sounds like a good idea
# [18:33] <fantasai> florian: I propos MQ for tomorrow
# [18:33] <fantasai> florian: Would encourage people to review edits beforehand
# [18:34] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [18:34] * TabAtkins dbaron, we can discuss over lunch.
# [18:34] <fantasai> fantasai: estimate 1-1.5 hr
# [18:34] <fantasai> s/fantasai/florian/
# [18:34] <fantasai> glazou: :has()
# [18:34] <fantasai> fantasai: tomorrow?
# [18:34] <fantasai> glazou: 45min probably
# [18:35] <fantasai> fantasai: who put baseline grid on it?
# [18:35] <fantasai> astearns: Have some examples to show, doesn't necessarily need f2f time
# [18:35] <fantasai> glazou: 15min?
# [18:35] <fantasai> astearns: sure
# [18:36] <fantasai> glazou: css3-color?
# [18:36] <fantasai> fantasai: need to check on status of tests, implementations, etc.
# [18:36] <fantasai> glazou: 15-20min then?
# [18:36] <fantasai> glazou: reverse lists is an interesting topic
# [18:36] <fantasai> glazou: estimate 30min, for tuesday morning
# [18:37] <fantasai> glazou: Tuesday afternoon. Fragmentation?
# [18:37] <fantasai> fantasai: sure
# [18:37] <fantasai> glazou: hour?
# [18:37] <fantasai> florian: sure
# [18:38] <fantasai> glazou: display spec?
# [18:38] <fantasai> TabAtkins: 45min for that
# [18:38] <fantasai> glazou: -webkit-color-adjust ?
# [18:38] <fantasai> florian: Not much time, I hope
# [18:39] <fantasai> glazou: End of Tuesday morning for that, if we have time
# [18:39] <fantasai> glazou: page selectors?
# [18:39] <fantasai> dave: 15 min maybe
# [18:39] <fantasai> glazou: wed morning maybe
# [18:40] <fantasai> glazou: will-change
# [18:40] * ChrisL -webkit-color-adjust is a spectacularly uninformative name
# [18:40] <fantasai> fantasai proposes Wed
# [18:40] <fantasai> glazou: 45min
# [18:40] <fantasai> TabAtkins: also grouping of perf things
# [18:40] * plh ... and print-color-adjust seems nasty "user's print settings are overridden."
# [18:40] * ChrisL css3-gofaster
# [18:41] <fantasai> glazou: Simplify object size of replaced elements
# [18:41] * TabAtkins ChrisL It's a spectacularly generic ability, since it just shuts off things that use up too much ink.
# [18:41] <fantasai> glazou: wed morning, short
# [18:41] <fantasai> glazou: scroll snap points
# [18:41] * ChrisL so -webkit-ink-saving then
# [18:41] <fantasai> ?: half hour?
# [18:41] <fantasai> glazou: ok, wed morning
# [18:42] * TabAtkins ChrisL We can bikeshed during the slot, or during lunch/dinner before. ^_^
# [18:42] <fantasai> dbaron: will-change and scroll snap points really important, I think. Fine with Wed, as long as we get to them
# [18:43] <fantasai> fantasai: ruby should be on 15m, only one issue on agenda
# [18:43] <fantasai> SteveZ: can we put shadow dom with regions?
# [18:44] <fantasai> TabAtkins: not really realaed
# [18:44] <fantasai> SteveZ_: kinda related
# [18:44] <fantasai> SteveZ_: would like shadow DOM update before regions
# [18:44] <fantasai> TabAtkins: should be 15min update
# [18:44] <fantasai> glazou: OK, will slip in Tuesday afternoon, probably after Fragmentation
# [18:44] <fantasai> glazou: issue tracking?
# [18:45] <fantasai> dbaron: Might want that before TTA
# [18:45] * Quits: shepazu (schepers@public.cloak) ("is probably traveling...")
# [18:45] <fantasai> dbaron: because one of obstacles to getting them done
# [18:45] <fantasai> glazou: ok, insert before TTA
# [18:46] <fantasai> plinss: @import to Cascade?
# [18:46] <fantasai> fantasai: 10min, put anywhere
# [18:46] <fantasai> Topic: CSS Variables CR
# [18:46] <fantasai> TabAtkins: Got no comments during 6 months LC period
# [18:46] * Joins: koji (~koji@public.cloak)
# [18:46] <fantasai> TabAtkins: so propose going to CR
# [18:46] <fantasai> ChrisL: After changing all the names
# [18:46] <fantasai> plh: Implementation status?
# [18:47] <fantasai> TabAtkins: Mozilla is working on impl by heycam
# [18:47] <fantasai> TabAtkins: We had an impl, abandoned 'cuz engineer left, but have someone planning to pick up
# [18:47] <fantasai> dbaron: Mozilla impl is done, heycam is working on other things. We're just waiting for the spec to go to CR
# [18:47] <dbaron> s/done/done as far as we know/
# [18:47] <fantasai> ...
# [18:48] <fantasai> plh: tests?
# [18:48] <fantasai> dbaron: I believe we even contributed a bunch
# [18:48] <fantasai> dbaron: do have tests
# [18:48] <fantasai> plh: please drop a link to them
# [18:48] <fantasai> plh: 10 months at least for CR phase
# [18:48] <astearns> http://test.csswg.org/shepherd/search/spec/css-variables-1/
# [18:48] <astearns> 168 tests in shepherd
# [18:48] <fantasai> dbaron: we have 179 files of tests, contributed
# [18:48] * Joins: shepazu (schepers@public.cloak)
# [18:49] <fantasai> plh: so, they need review?
# [18:49] <fantasai> plh: Ask guy implementing at google to review them?
# [18:49] <dbaron> tests in contributors/mozilla/submitted/mozilla-central-reftests/variables and contributors/mozilla/submitted/css-variables
# [18:49] <fantasai> glazou: Do you think they represent a complete test suite?
# [18:49] <fantasai> dbaron: probably not, but don't know
# [18:49] <fantasai> TabAtkins: seems a little sparse, but not too far off. Would estimate a few hundred tests
# [18:49] <fantasai> glazou: Have question for next level of variables
# [18:50] <fantasai> glazou: Got a question wrt using variables inside MQ
# [18:50] <fantasai> TabAtkins: have a proposal for MQ variables
# [18:50] <fantasai> fantasai: It would have to be a completely separate mechanism
# [18:51] <fantasai> fantasai: Do we have an owner for Variables test suite?
# [18:51] <fantasai> glazou proposes Tab
# [18:51] <fantasai> fantasai: I don't think that's going to work, cuz not actually going to happen
# [18:51] <fantasai> glazou: Any objection to moving Variables to CR?
# [18:51] <fantasai> SimonSapin: One issue left in the spec wrt animation
# [18:51] <SimonSapin> s/SimonSapin/???
# [18:51] <fantasai> TabAtkins: Oh, we decided on that. Haven't edited it in
# [18:52] <fantasai> s/???/smfr/
# [18:53] <fantasai> discussion of remaining edits
# [18:53] <fantasai> RESOLVED: Publish Variables as CR once Tab has completed edits on remaining issue.
# [18:53] <fantasai> ChrisL: Is there a DoC?
# [18:54] <fantasai> no issues, so that's easy
# [18:54] <fantasai> ChrisL: need an explanation of why no comments, i.e. not because nobody readit
# [18:54] * Joins: emalasky (~Adium@public.cloak)
# [18:54] <fantasai> fantasai: Because it's a processing spec. Tend to have way fewer issues than layout ones
# [18:54] <dauwhe> s/readit/read it/
# [18:55] <fantasai> ACTION ChrisL to work on CR publication
# [18:55] * trackbot is creating a new ACTION.
# [18:55] <trackbot> Created ACTION-603 - Work on cr publication [on Chris Lilley - due 2014-02-03].
# [18:55] <fantasai> ACTION Tab to ping Google engineer working on Variables, ask to formally review Mozilla's tests
# [18:55] * trackbot is creating a new ACTION.
# [18:55] <trackbot> Created ACTION-604 - Ping google engineer working on variables, ask to formally review mozilla's tests [on Tab Atkins Jr. - due 2014-02-03].
# [18:55] <SimonSapin> Where No WG Has Gone Before
# [18:55] <fantasai> Topic: Masking
# [18:56] * Joins: jet (~junglecode@public.cloak)
# [18:56] <fantasai> krit: One issue was reference box
# [18:56] <fantasai> krit: I added reference boxes for clip-path, same syntax as in Shapes
# [18:57] <fantasai> krit: can choose which box you want to use as reference box for clipping
# [18:57] <fantasai> krit: This was an LC request
# [18:57] <fantasai> krit: We have no resolution on this. Are there any objections/concerns?
# [18:57] * Joins: tantek (~tantek@public.cloak)
# [18:57] <fantasai> krit: bounding-box
# [18:57] <fantasai> krit: Something that fantasai pointed out...
# [18:57] <fantasai> krit: idea of bounding box is that a box can have children that overflow
# [18:58] <fantasai> krit: using bounding box, can size a shape according to this box here
# [18:58] <fantasai> krit: so ellipse of 100% will take entire overflow area
# [18:58] <fantasai> krit: If you fragment across, say, columns
# [18:58] <fantasai> krit: bounding box is box that surrounds all of client rects
# [18:59] <fantasai> krit: which is not matching how we want to handle fragmentation otherwise
# [19:00] <TabAtkins> ScribeNick: TabAtkins
# [19:00] <TabAtkins> ChrisL: Rather than leaving it undefined, we can say the current def isn't very helpful.
# [19:01] <TabAtkins> ChrisL: So it's defined, but not useful in that particular case.
# [19:01] <TabAtkins> ChrisL: You get a result, it's not undefined.
# [19:01] <TabAtkins> krit: I don't want to put that into the spec.
# [19:02] <TabAtkins> fantasai: I don't want to add something with that behavior because it's not how the other boxes work.
# [19:02] <TabAtkins> fantasai: It's not consistent.
# [19:02] <TabAtkins> fantasai: The goal of the reference box changing is which box you're changing, not how you wanna handle fragmentation.
# [19:02] <TabAtkins> fantasai: If we wanna have a bounding box ability for that, it should be an independent switch.
# [19:03] <TabAtkins> krit: [something about the way the fragmentation and boxes are defined]
# [19:03] <TabAtkins> szilles: If you didn't have fragmentation, what would you want?
# [19:03] <TabAtkins> krit: Without fragments, you'd have a ref box for the whole overflowing area, and an ellipse would then fill the whole thing.
# [19:04] <TabAtkins> szilles: There's already specs for what to do for background-* stuff. Why not have it work the same way?
# [19:04] <TabAtkins> fantasai: You do, but the definition of bounding-box isn't compatible.
# [19:04] <TabAtkins> szilles: I'd do slice, and then put things back together per fragment.
# [19:05] <TabAtkins> fantasai: We could define that, we just can't call it bounding box. That term already has a meaning in some OM functions.
# [19:05] <TabAtkins> fantasai: I'd call it overflow-box, since the concept is capturing the overflow.
# [19:05] <dbaron> I'm not crazy about the term "overflow box"
# [19:05] <TabAtkins> krit: So you'd just say you take the overflowing area?
# [19:05] <TabAtkins> astearns: Just as with other boxes, if the box gets fragmented, you apply it to the fragments the same way backgrounds do.
# [19:05] <TabAtkins> astearns: Same definition as the other shape boxes, but for overflow.
# [19:05] <TabAtkins> dbaron: I'm not too happy with the term overflow-box.
# [19:06] <TabAtkins> dbaron: One, it sounds like it should be a rectangle.
# [19:06] <TabAtkins> dbaron: Also, it doesn't quite feel like overflow.
# [19:06] <TabAtkins> astearns: It is a rectangle, except in fragmented stuff, same as the other boxes.
# [19:06] <TabAtkins> florian: Isn't it a list of boxes?
# [19:06] <TabAtkins> fantasai: Yeah, but for symmetry we should do *-box for the value name.
# [19:07] <TabAtkins> krit: But all the keywords have the same problem; it would be weird to have them be *-box and have this one be something "fixed".
# [19:08] <TabAtkins> dbaron: Okay, so why is it overflow?
# [19:08] <TabAtkins> astearns: If you ahve an element with content that overflow, what do you call the box that contains everything from that element?
# [19:08] <TabAtkins> dbaron: Well, there's two kinds of overflow.
# [19:08] <TabAtkins> dbaron: Overflow you scroll to, and overflow you don't. And maybe a third.
# [19:09] <TabAtkins> fantasai: It's defined as the rectangle that would contain the border boxes of the element and all its descendants (with descendants possibly transformed).
# [19:09] <TabAtkins> dbaron: And doing 3d flattening if you're in the middle of a 3d tree?
# [19:10] <TabAtkins> shepazu: Are the different things written down somewhere?
# [19:10] <TabAtkins> TabAtkins: They're things we've discussed before, but haven't written down yet.
# [19:10] <TabAtkins> shepazu: Can we write them down?
# [19:10] <TabAtkins> TabAtkins: Yeah, they should go in Overflow. dbaron's the editor.
# [19:11] <TabAtkins> krit: So is name the only problem?
# [19:11] <TabAtkins> fantasai: No, definition is also the problem.
# [19:11] <TabAtkins> dbaron: So what is the use-case for clipping to the overflowing things?
# [19:12] <TabAtkins> dbaron: And what does that imply for an overflow region that is a union of rectangles but not a rectangle itself.
# [19:12] <TabAtkins> dbaron: I'm having trouble seeing why you'd want to use overflow as a clip path.
# [19:12] <TabAtkins> shepazu: If you're trying to highlight a particular thing, you might want to just have that shown.
# [19:13] <TabAtkins> ChrisL: [another example]
# [19:13] <TabAtkins> dbaron: This is for masking, not clip?
# [19:13] <TabAtkins> fantasai: Both.
# [19:14] <TabAtkins> SimonSapin: The region we're talking about is just about sizing the clip path, not about clipping itself?
# [19:14] <TabAtkins> dbaron: You're going to end up making very specific assumptions about what your overflow is.
# [19:17] <TabAtkins> szilles: So the boudning box is the smallest box around all the content.
# [19:17] <dauwhe> s/boudning/bounding/
# [19:17] <dbaron> s/3d tree/preserve-3d tree/
# [19:17] <TabAtkins> Rossen_: What elika and I have been using for "bounding box" is the pre-fragmented box, sliced appropriate.
# [19:19] <dbaron> I don't even know what we're deferring to the next specification...
# [19:19] <TabAtkins> ;_;
# [19:19] * TabAtkins is also lost.
# [19:19] * sgalineau { defer: auto; }
# [19:19] <TabAtkins> TabAtkins: Okay, so we're deferring the "bounding box" value and anything like it?
# [19:20] <TabAtkins> shepazu: Wait, SVG already defines it, right?
# [19:20] <TabAtkins> krit: No, SVG does something completely different, and doesn't have fragmentation.
# [19:20] <TabAtkins> RESOLVED: Defer the 'bounding-box' value from clip-path and mask-origin to next level.
# [19:20] * astearns "clip-path: <clip-source> deferred-box" will secretly work
# [19:21] <TabAtkins> krit: Okay, new topic. Fragmentation for clip-path and masking.
# [19:21] <TabAtkins> krit: We need to define in general how clip-path works with fragmentations.
# [19:21] * sgalineau it has been resolved to resolve later.
# [19:21] <TabAtkins> krit: I propose we do the same thing as background/etc.
# [19:22] <TabAtkins> krit: I'd like to extend Fragmentation to include this.
# [19:22] <TabAtkins> fantasai: Sure. We can just define that the behavior is the same as for *
# [19:22] <TabAtkins> krit: clip-path/clip/mask same as background wrt box-decoration-break
# [19:23] <TabAtkins> krit: mask-box same behavior as border-image wrt box-decoration-break
# [19:23] <TabAtkins> fantasai: So b-d-b controls masking/clipping as well as backgrounds.
# [19:24] <TabAtkins> smfr: Are there any cases where you'd want to use different b-d-b behaviors between the properties?
# [19:24] <TabAtkins> krit: I think not.
# [19:24] <TabAtkins> RESOLVED: clipping/masking properties respond to box-decoration-break as proposed above.
# [19:24] <TabAtkins> krit: Last issue is a proposal for a 9-slice image function.
# [19:25] <TabAtkins> krit: Simon and Dean suggested that instead of mask-box, we should define a 9-slice image function.
# [19:25] <TabAtkins> krit: Then use the normal mask property to allow masking borders of the element.
# [19:25] <TabAtkins> krit: We didn't really resolve if the CSSWG even wants to define such a function.
# [19:26] <TabAtkins> krit: There's also a question of if we want to remove mask-box anyway, even though it's implemented in WK/Blink.
# [19:26] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:26] <TabAtkins> fantasai: My concern is that it's pretty complex, and one part (the outset) isn't useful for generic images.
# [19:26] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:26] <TabAtkins> krit: Right. All of the property values for mask-box would have to go in.
# [19:27] <TabAtkins> krit: Elika pointed out that we don't have the box outset.
# [19:27] <TabAtkins> krit: So that can't be done with 9-slice.
# [19:27] <TabAtkins> smfr: At least without adding a mask-box-outset property.
# [19:28] <TabAtkins> krit: So, do we want to work on a 9-slice image?
# [19:28] <TabAtkins> krit: And maybe the extension to a 5x5 one?
# [19:28] <TabAtkins> fantasai: What's the use-case for it?
# [19:28] <TabAtkins> fantasai: I can't imagine using it for anything beyond border-image.
# [19:29] <TabAtkins> fantasai: Mayb multiple border-images, but it won't be a list bullet.
# [19:29] <TabAtkins> fantasai: That's it, as far as I can imagine.
# [19:29] <TabAtkins> krit: So we have a request for border-image with 5x5, but no request for an image function that does that.
# [19:29] <TabAtkins> fantasai: So since I can't imagine using a 9-slice for anything besides matching against the box...
# [19:30] <TabAtkins> fantasai: And it would be a really long function.
# [19:30] <TabAtkins> fantasai: I'm somewhat opposed to doing this.
# [19:30] <fantasai> krit: fantasai^: Not opposed to extending border-image to 5x5, there were requests to do that in the L3 cycle as well
# [19:30] <TabAtkins> krit: So any othe ropinions? I'd like to resolve that we at least keep mas-box.
# [19:31] <fantasai> s/krit: fan/fan/
# [19:31] * smfr found 2 stack overflows asking for sliced images
# [19:31] * fantasai for doing what, exactly?
# [19:31] <TabAtkins> RESOLVED: Keep mask-box. No opinion on whether or not to do a slice image function yet.
# [19:31] * TabAtkins Hook us up with some links, smfr.
# [19:32] <smfr> http://stackoverflow.com/questions/5284743/image-slices-placed-using-css-divs
# [19:32] <fantasai> s/doing this/doing this unless there are some solid use cases outside decorating the border-box/
# [19:32] <smfr> not sure if these are 9-way slicing
# [19:32] <TabAtkins> krit: If you ref a <mask> element, it has maskUnits=''.
# [19:32] <TabAtkins> krit: Something like the reference box, but for SVG.
# [19:33] <TabAtkins> krit: Can be object bounding box (OBB) or userSpaceOnUse (USOU).
# [19:33] <TabAtkins> krit: obb is pretty clear you want the element's reference box. We choose content-box for HTML and bounding box for SVG.
# [19:33] * Joins: eliezerb_2nd (~Eliezer@public.cloak)
# [19:33] <TabAtkins> krit: usou, for SVG, it takes the viewport of the reference box.
# [19:33] <TabAtkins> krit: But "viewport" has a different meaning in CSS.
# [19:34] <TabAtkins> krit: You can't scroll (in theory) for SVG, it's the width/height of the whole document.
# [19:34] <TabAtkins> krit: But in CSS it's the width/height of your window.
# [19:35] <fantasai> lots of confusion over viewbox vs. viewport
# [19:35] <TabAtkins> TabAtkins: SVG's viewport is the size of the nearest <svg>.
# [19:35] <TabAtkins> TabAtkins: viewbox is a way to establish a coordinate system over the viewport.
# [19:35] <TabAtkins> TabAtkins: Neither have any connection to CSS's definition of "viewport".
# [19:36] <TabAtkins> krit: If an SVG element takes a <mask> as a mask, it finds the nearest viewport, and does coordinates from that.
# [19:36] <TabAtkins> fantasai: Similar to our line about abspos containing block?
# [19:37] <TabAtkins> krit: Yeah, similar.
# [19:37] <fantasai> krit: So we have this concept in SVG. What do we do for HTML?
# [19:38] <fantasai> TabAtkins: roc had this proposal, where has exact same rectangle as object-bounding-box, but fills that with the outsides coordinate space
# [19:38] <fantasai> TabAtkins: in our case, it would mean you can du normal px units, and will work out fine
# [19:38] * Quits: eliezerb (~Eliezer@public.cloak) (Ping timeout: 180 seconds)
# [19:38] <fantasai> TabAtkins: difference is how big is a user unit
# [19:38] * fantasai confused
# [19:39] * fantasai thinks Tab needs to fill this bit in
# [19:40] * ChrisL makes temporary minutes to get a url for the resolution for variables cr
# [19:40] <ChrisL> rrsagent, make minutes
# [19:40] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/27-css-minutes.html ChrisL
# [19:40] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [19:41] <TabAtkins> TabAtkins: So, OBB establishes a box from the ref box, and scales the "user-space unit" so that that box is exactly 1 unit wide and 1 unit tall.
# [19:41] <ChrisL> rrsagent, make logs public
# [19:41] <RRSAgent> I have made the request, ChrisL
# [19:41] <ChrisL> rrsagent, make minutes
# [19:41] <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/27-css-minutes.html ChrisL
# [19:41] <TabAtkins> TabAtkins: USOU establishes the same box, but sizes the "user-space unit" to be equal to the CSS px.
# [19:41] <TabAtkins> krit: So I support roc's definition (or Tab's interpretation of it) for HTML element.
# [19:42] <TabAtkins> krit: So do we want to propose this to the SVGWG? It seems a lot of people don't understand it.
# [19:43] <TabAtkins> [fantasai reviewing the example again]
# [19:45] <SimonSapin> (plinss, additional topic for Syntax: http://lists.w3.org/Archives/Public/www-style/2014Jan/0537.html)
# [19:45] <TabAtkins> fantasai: I suggest we make all these edits, review them, *then* publish as LC.
# [19:46] <TabAtkins> fantasai: So we don't cycle through LC.
# [19:46] <TabAtkins> krit: If we assume that this WD gets published, how long do we wait until LC?
# [19:46] <TabAtkins> fantasai: I say 3 weeks?
# [19:46] <TabAtkins> szilles: Depending on the level of comments.
# [19:47] * Quits: florian (~Adium@public.cloak) ("Leaving.")
# [19:52] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [19:52] * Joins: koji (~koji@public.cloak)
# [19:55] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [19:55] * rossen____ is now known as Rossen_
# [19:57] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:59] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [19:59] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [20:00] * Joins: koji (~koji@public.cloak)
# [20:03] * Joins: dauwhe (~dauwhe@public.cloak)
# [20:05] * Joins: florian (~Adium@public.cloak)
# [20:07] <fantasai> ScribeNick: fantasai
# [20:07] <fantasai> Topic: MQ
# [20:07] <fantasai> s/MQ/Syntax/
# [20:07] <fantasai> SimonSapin: Editorial feedback from i18n
# [20:07] * Joins: MaRakow (~MaRakow@public.cloak)
# [20:07] <fantasai> SimonSapin: some discussion about changing the @charset behavior
# [20:07] <fantasai> SimonSapin: Tab and I agree it's not a good idea
# [20:07] <fantasai> TabAtkins: Henri also agrees it's not a good idea
# [20:07] <fantasai> plinss: What is the proposed changed?
# [20:08] <fantasai> TabAtkins: That actual CSS syntax would trigger behavior. Currently only very restricted set
# [20:08] <fantasai> fantasai: How different from CSS2.1?
# [20:08] <fantasai> florian: Not different, same restrictions
# [20:08] <fantasai> plinss: I agree with that
# [20:08] <fantasai> fantasai: me, too. Don't see a reason to change it from what was in 2.1
# [20:09] <SimonSapin> Starts here: http://lists.w3.org/Archives/Public/www-style/2014Jan/0060.html
# [20:09] <fantasai> florian: Argument for was that people would not understand the restricted subset, might do something not quite right
# [20:09] <fantasai> florian: But we don't want people to use this anyway, want only for legacy documents. Everything else should use UTF-8
# [20:10] <fantasai> fantasai: Don't see any reason not to use UTF-8 for CSS files, really. :)
# [20:10] <fantasai> SimonSapin: Did make one change based on Henri's feedback
# [20:10] <fantasai> SimonSapin: Since we trip white space in encoding name between quotes
# [20:10] <fantasai> SimonSapin: The series of @charset is unbounded, which is bad because want to set encoding asap
# [20:11] <fantasai> SimonSapin: In HTML, encoding has to be within first 1024 bytes
# [20:11] <fantasai> TabAtkins: This is only relevant if you want to put tons of spaces between first quote and charset name
# [20:11] <fantasai> which nobody will do
# [20:11] <fantasai> plinss: Why do we trim white space there anyway?
# [20:12] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [20:12] <fantasai> TabAtkins: encoding spec says so
# [20:12] <fantasai> TabAtkins: ... waitaminute. We don't currently allow spaces there.
# [20:12] <fantasai> [discussion of fixing this]
# [20:13] <fantasai> dbaron: If implementations don't allow spaces, then let's not allow spaces
# [20:13] <fantasai> dbaron: If nobody's checked, let's check first.
# [20:13] <fantasai> fantasai: Do you have a DoC prepared?
# [20:14] <fantasai> No.
# [20:14] <fantasai> SimonSapin: We introduced concept of environment encoding
# [20:14] <fantasai> SimonSapin: Idea is that specs that use CSS should define that
# [20:14] <fantasai> SimonSapin: Meantime, I defind for HTML, @important, xml, etc.
# [20:14] <fantasai> SimonSapin: HTML one has moved ot HTML spec. Want to move @important one to Cascade
# [20:14] <fantasai> SimonSapin: Can we move things between CR?
# [20:15] <fantasai> fantasai: I think this particular case it's OK, because doesn't affect interpretation of either spec in isolation or both together.
# [20:15] <SimonSapin> s/@important/@import/
# [20:15] <fantasai> glazou: Adding technical info to a CR is problematic
# [20:15] <fantasai> fantasai: But it doesn't invalidate anyone's review (litmust test)
# [20:15] <fantasai> s/st/s/
# [20:16] <fantasai> dbaron: One other question, this "environment encoding" concept. Is there something that encourages future consumers to just set it to UTF-8?
# [20:16] <fantasai> dbaron: I think this concept only exists because of legacy
# [20:17] <fantasai> dbaron: If that's the case, it's good for the spec to say that, so that people who don't have a legacy problem
# [20:17] <fantasai> dbaron: don't copy this. And give some advice on what the spec should say
# [20:17] <fantasai> SimonSapin: Already say that if environment encoding is not explicitly defined, it's UTF-8.
# [20:17] * Joins: sgalineau (~sgalineau@public.cloak)
# [20:17] <fantasai> SimonSapin: Could add that new things should not define anything else
# [20:17] * Ms2ger thinks user-defined encoding is legacy anyway
# [20:18] * fantasai :)
# [20:18] <fantasai> glazou: So, Chris says it's ok if we can make a good argument for the move if it's not tied in with other things
# [20:18] <fantasai> SimonSapin: no problem
# [20:18] <fantasai> ACTION SimonSapin prepare disposition of comments, complete Syntax edits for tomorrow
# [20:18] * trackbot is creating a new ACTION.
# [20:18] <trackbot> Created ACTION-605 - Prepare disposition of comments, complete syntax edits for tomorrow [on Simon Sapin - due 2014-02-03].
# [20:19] <fantasai> glazou: Suggest Shapes for 20min, then flexbox
# [20:19] * dbaron Ms2ger, you mean x-user-defined?
# [20:19] * fantasai is skeptical of flexbox before lunch
# [20:19] <fantasai> Topic: Shapes
# [20:19] <fantasai> astearns: We had LC for shapes
# [20:19] * Ms2ger !utf-8
# [20:19] <fantasai> astearns: comments ended up changing computed value of shape-outside
# [20:19] <fantasai> astearns: I think the way shape functions are serialized should be defined better
# [20:19] <fantasai> astearns: computed value of position doesn't really correspond to syntax that go into the declared value
# [20:19] <astearns> http://lists.w3.org/Archives/Public/www-style/2014Jan/0277.html
# [20:20] <fantasai> astearns: so I set up a list of rules that I've linked to here
# [20:20] <fantasai> astearns: for how to serialize position
# [20:20] <fantasai> astearns: It's a set of rules, rather than algo
# [20:20] <fantasai> astearns: think that's better
# [20:20] <fantasai> astearns: if people are good with this, then last thing before next LC for shapes
# [20:20] <fantasai> krit: serialization is used for getComputedStyle as well as .style
# [20:21] <fantasai> dbaron: This is about the <position> syntax that takes 2/4 values?
# [20:21] <fantasai> dbaron: One of my longstanding prefs wrt serialization is that when we expand the syntax of CSS, we should prefer serializing to the more longstanding syntax than the new syntax
# [20:21] <fantasai> dbaron: becaue if you want to round-trip into a context that gets consumed by other tools, want it to be most compatible possible
# [20:22] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:22] <fantasai> astearns: Current rules prefer keywords to percentages/lengths
# [20:22] <fantasai> astearns: if you introduce new keywords... might not end up as you want
# [20:23] <fantasai> fantasai: Would suggest we prefer percentages, probably easier for OM people
# [20:24] <dbaron> peterl: one thing that concerns me about these serialization things is that we're encouraging the UA to not preserve the input
# [20:24] <fantasai> astearns: case is e.g. calc(100% - 10px), will be serialized as right 10px
# [20:24] <fantasai> glazou: I prefer that, author is more likely to have entered it that way
# [20:24] * TabAtkins Okay, confirmed, Chrome at least allows plenty of whitespace in the label name.
# [20:24] * Ms2ger boo
# [20:24] * fantasai TabAtkins, check anotehr implementation?
# [20:24] <dbaron> (peterl line goes here)
# [20:24] * TabAtkins So yeah, I'll change Syntax back to allowing "anything but 0x22" there.
# [20:24] * TabAtkins fantasai, yeah, let me download FF.
# [20:24] <fantasai> plinss: I'm concerned that if you serialize and round-trip exactly what came in, should that ever be considered wrong/
# [20:25] <fantasai> [various on not preserving input string]
# [20:25] <fantasai> dbaron: We've been adding more preservation of author input, for our own developer tools.
# [20:25] <fantasai> dbaron: In many cases, we don't expose that to the web
# [20:25] <fantasai> dbaron: mostly it's for color syntaxes atm
# [20:25] * Joins: smfr (~smfr@public.cloak)
# [20:26] <fantasai> florian: I think we can't require preservation everywhere
# [20:26] <fantasai> plinss: ...
# [20:26] <fantasai> florian: At least some implementations will not preserve the input
# [20:26] <fantasai> florian: Also, it's valuable that everyone has the same output
# [20:27] <fantasai> florian: Since not everyone preserves the input ..
# [20:27] <fantasai> astearns: ...
# [20:27] <fantasai> astearns: If you say left top, other person says top left, would be nice to have consistent serialization
# [20:28] <fantasai> florian: Leaning towards dbaron's approach, for Web content normalize more, but for developer tools expose more thngs
# [20:28] <fantasai> plinss: I accept that there are utilities for having a normalized serialization
# [20:28] <fantasai> plinss: for manipulation via script (which we should avoid by having a better OM)
# [20:28] <fantasai> plinss: But I'd like to avoid having 2 output paths for serialization
# [20:29] <fantasai> plinss: Asking for normalized version, and other asking for getting absolutely / partially preserved / normalized value /whatever
# [20:29] <fantasai> krit: I think it's important to have a constant output for same input across all browsers. This is the first thing we should agree on, because not the case today
# [20:29] * Joins: rhauck (~Adium@public.cloak)
# [20:29] <fantasai> SteveZ_: I think you need to take the audience into consideration
# [20:29] <fantasai> SteveZ_: JS writers would prefer canonicalized output
# [20:30] * TabAtkins Yes, FF also allows lots of spaces in encoding labels.
# [20:30] <fantasai> SteveZ_: Another is developers, who would like to see what they wrote, because that's what they're trying to debug
# [20:30] <fantasai> SteveZ_: We're not trying to solve the developer recovering their input
# [20:30] <fantasai> SteveZ_: is what I think plinss was syaing
# [20:30] * Quits: jet (~junglecode@public.cloak) (jet)
# [20:30] <fantasai> fantasai: I think that we should focus the existing OM on the first problem (JS writer)
# [20:30] <dauwhe> s/syaing/saying/
# [20:31] <fantasai> fantasai: Create a different OM to solve the second problem, that's designed to solve that second problem, and simply wont' be implemented if impl won't preserve the info
# [20:31] <fantasai> florian: [says mostly the same thing]
# [20:32] <fantasai> krit: Adding new values, not very compatible.
# [20:32] <fantasai> glazou: We're being too broad, suggest we refocus on Shapes
# [20:32] * Joins: yamamoto (~yamamoto@public.cloak)
# [20:32] <fantasai> astearns: So canonical form for shape serialization is the problem
# [20:32] <fantasai> astearns: so question is, is the email post there what we want
# [20:33] <fantasai> dbaron: ...
# [20:33] <fantasai> astearns: Think the text could be used for multi-component values elsewhere
# [20:34] <fantasai> dbaron: Think we should keep it with Shapes, might want to make calls on keyword vs. length based on which is older in other cases
# [20:34] <fantasai> RESOLVED: Shapes to LC pending fantasai's review due tomorrow morning
# [20:35] <krit> ScribeNick: krit
# [20:35] <krit> topic: Flexbox
# [20:35] <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
# [20:35] <krit> TabAtkins: going to issue list
# [20:36] <krit> fantasai: did we solve 23?
# [20:36] <krit> fantasai: looks open
# [20:36] <krit> glazou: not closed
# [20:36] <fantasai> http://dev.w3.org/csswg/css-flexbox/#changes
# [20:36] <krit> TabAtkins: nothing to discuss
# [20:37] <krit> plinss: do we want to resolve on something?
# [20:37] <krit> fantasai: possibly later today
# [20:38] <krit> topic: Update ShadowDOM
# [20:38] <krit> TabAtkins: intended to have a spec for shadow dom ready, but don;y
# [20:38] <krit> TabAtkins: shdowDOM is an isolated sub tree
# [20:39] <krit> TabAtkins: take an existing update but hide away the subtree
# [20:39] <krit> TabAtkins: this subtree is isolated for CSS
# [20:39] <krit> TabAtkins: stlyeesheets of other docs, don;t effect anything inside same other way around
# [20:40] <krit> TabAtkins: inheritance penetrates
# [20:40] <krit> ChrisL: well, you can no can up in tree
# [20:40] <krit> TabAtkins: in JS yes
# [20:40] <krit> TabAtkins: for CSS they are isolated
# [20:40] <krit> TabAtkins: you can block styling outside
# [20:40] <krit> TabAtkins: but in general inheritance goes through
# [20:40] <krit> TabAtkins: just a feqw new things to CSS
# [20:41] <shepazu> q+ to ask about native components (scrollbars, widgets, etc.)
# [20:41] * Zakim sees shepazu on the speaker queue
# [20:41] <krit> TabAtkins: new combinators
# [20:41] <dbaron> hat ^ and cat ^^
# [20:41] <krit> TabAtkins: if I am in the outer document then I can't see inside shadowRoot
# [20:42] <krit> TabAtkins: but I can do x-foo^div which will let you into the shadow root
# [20:42] <krit> TabAtkins: x-ffo has to be shadow host, something with shadowroot
# [20:42] <krit> TabAtkins: we have cat as well
# [20:42] <krit> TabAtkins: if you want to style every button in your document.. used in components or in the document
# [20:43] <krit> phl: why not *
# [20:43] <krit> shepazu: you may not want to
# [20:43] <krit> TabAtkins: cat goes through any kind of boundary
# [20:43] <dbaron> TabAtkins: these are both style sheets in the outer document
# [20:44] <krit> glazou: I hate this
# [20:44] <krit> glazou: should be different "this declared for that" instead
# [20:44] <krit> glazou: I think we are mixing regular selectors with whole tree with part of the tree
# [20:44] <fantasai> glazou thinks the <div> should be consider some kind of pseudo-element of the x-foo
# [20:44] <krit> glazou: don't like syntax
# [20:45] <krit> glazou: don't like cat
# [20:45] <fantasai> tab explained that they tried to do this, went with it for months and implemented it, but ended up being clumsy and not powerful enough, and had to change
# [20:45] <krit> glazou: we don't need to add that ::identifier is enough
# [20:45] * plh wonders if we can use ✰✰ instead
# [20:46] <krit> glazou: if you want to extend html, then you don't want to use div
# [20:46] <fantasai> tab^: that would create namespace collisions with future pseudos
# [20:46] <krit> shepazu: don't you just like the cheat code or the syntax?
# [20:46] <krit> shepazu: don't like syntax... should be more integrated to CS
# [20:46] <fantasai> s/shepazu/glazou/
# [20:46] <krit> glazou: don't think it should get new operators
# [20:46] <fantasai> s/CS/CSS/
# [20:46] <fantasai> q+
# [20:46] * Zakim sees shepazu, fantasai on the speaker queue
# [20:47] <krit> shepazu: this will change how we do things
# [20:47] <plh> ack she
# [20:47] <Zakim> shepazu, you wanted to ask about native components (scrollbars, widgets, etc.)
# [20:47] * Zakim sees fantasai on the speaker queue
# [20:47] <krit> shepazu: and avoids conflicts with anything else we come up with
# [20:47] <krit> TabAtkins: yes, we tried a lot of ways
# [20:47] <krit> TabAtkins: either to weak or to complex
# [20:47] <fantasai> TabAtkins: it took me a long time to come around to this, was very resistent, but this was the only thing we came up with after many tries that was usable
# [20:47] <krit> TabAtkins: this was the easiest way we came up to
# [20:47] <krit> TabAtkins: team was unhappy with anything esle
# [20:47] * astearns I like ✰ and ✰✰ - the star-bellied combinators
# [20:48] <krit> fantasai: a combinator tights two elements together
# [20:48] <krit> fantasai: we are expressing a relation ship
# [20:48] <krit> fantasai: so should not be a combinator
# [20:48] <fantasai> s/not/
# [20:48] <krit> TabAtkins: right
# [20:48] <fantasai> s/not//
# [20:48] <fantasai> (that's what a combinator is)
# [20:48] * plh the named of the character is "shadowed whitestar", so perfectly in context
# [20:48] <krit> TabAtkins: :top selects the top of the shadow root
# [20:49] <krit> TabAtkins: and the you define what you want in the shadow tree
# [20:49] <krit> smfr: why can't you combine the ...
# [20:49] <fantasai> glazou: I don't understand :top
# [20:49] <krit> TabAtkins: child of sub tree is not a top level element
# [20:50] <fantasai> TabAtkins: It is any element whose parent isn't an element. So matches :root, but also matches child of a Shadow Root
# [20:50] <smfr> q+
# [20:50] * Zakim sees fantasai, smfr on the speaker queue
# [20:50] <fantasai> TabAtkins: It's an element that's at the top of its local tree
# [20:50] <fantasai> ack fantasai
# [20:50] * Zakim sees smfr on the speaker queue
# [20:50] <fantasai> ScribeNick: fantasai
# [20:50] <fantasai> glazou: I understand what you said wrt combinators, still unsure if we need a new combinator
# [20:50] <fantasai> glazou: Think descendant combinator and pseduo-element would be enough
# [20:51] <fantasai> TabAtkins: pseudo-elements are basically a combinator
# [20:51] * plh ::^^ ?
# [20:51] <fantasai> SteveZ_: Why couldn't I say ::shadow?
# [20:51] <fantasai> florian: Would be same as ^
# [20:51] * sgalineau ::dark-side
# [20:51] <fantasai> [would need another pseudo-for ^^]
# [20:51] <glazou> x-foo ˆ div ====> x-foo::shadow div
# [20:52] <fantasai> smfr: Why not scoped style sheets to solve this problem?
# [20:52] <fantasai> TabAtkins: ...
# [20:52] <florian> a ^b —> a::shadow b
# [20:52] * Joins: adenilson_ (~anonymous@public.cloak)
# [20:52] <fantasai> smfr: You want to select across the boundary?
# [20:52] <florian> a ^^b —> a ::shadow b
# [20:52] <florian> ?
# [20:52] <fantasai> TabAtkins: Scoped styles prevent styles from affecting things further up the tree
# [20:52] <fantasai> TabAtkins: but we want to also prevent styles from coming in across the boundary
# [20:53] <fantasai> fantasai: That's a completely different problem
# [20:53] <fantasai> smfr: You can style the shadow tree by ..
# [20:53] <fantasai> smfr: You could invent a syntax that allows applying style just to the shadow tree
# [20:53] <fantasai> ChrisL: but you want to attach to particular ones by pinning to their ancestors
# [20:53] * glazou aˆˆb ===> a::shadow ::shadow b
# [20:53] <fantasai> fantasai: Like some particuar ID, then the selectors of things in shadow trees
# [20:54] <fantasai> SteveZ_: I thought shadow trees were an encapsulation method. What you're showing me is the exact opposite
# [20:54] <fantasai> TabAtkins: Corret
# [20:54] <fantasai> TabAtkins: You want encapsulation by default
# [20:54] * glazou aˆˆb ===> a::shadow b, a::shadow ::shadow b
# [20:54] <fantasai> TabAtkins: But want ways to pierce that encapsulation sometimes
# [20:54] <fantasai> ...
# [20:54] <shepazu> q+
# [20:54] * Zakim sees smfr, shepazu on the speaker queue
# [20:54] <fantasai> SteveZ_: Can I turn it off?
# [20:55] <plh> q+
# [20:55] * Zakim sees smfr, shepazu, plh on the speaker queue
# [20:55] <smfr> q-
# [20:55] * Zakim sees shepazu, plh on the speaker queue
# [20:55] * sgalineau CSS encapsulation: it's hidden if you hold it at arm's length
# [20:55] <fantasai> TabAtkins: No, but people have to pierce encapsulation explicitly
# [20:55] <fantasai> astearns: Could happen by accident, if you try to style something and then add another component that happens to match
# [20:55] <fantasai> plh: User style sheet, if you don't go across the boundaries explicitly?
# [20:56] <fantasai> TabAtkins: Interesting question.
# [20:56] <fantasai> TabAtkins: We know that the UA style sheet must apply inside the boundary
# [20:56] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [20:56] * adenilson_ is now known as adenilson
# [20:56] <fantasai> TabAtkins: We're not sure about user styles yet
# [20:56] <fantasai> TabAtkins: Maybe just want author-level style sheets to be blocked out
# [20:56] <fantasai> florian: If you have element::shadow that would be ^, and element ::shadow be ^^
# [20:57] <fantasai> TabAtkins: That wouldn't work
# [20:57] <fantasai> fantasai: that would be element *::shadow, wouldn't work
# [20:57] <fantasai> TabAtkins: * ^ div
# [20:57] <fantasai> TabAtkins: shows that it only hits first level of shadow
# [20:58] <fantasai> TabAtkins: * ^^ div pierces both
# [20:58] <fantasai> florian and Tab exchanging examples
# [20:59] <fantasai> ...
# [20:59] <dbaron> just wait until we need to use the = combinator
# [20:59] <fantasai> SteveZ_: I like ::shadow because it makes it clear that you're crossing a boundary
# [20:59] <fantasai> SteveZ_: I agree that the caret is equivalent
# [20:59] <fantasai> TabAtkins: One hesitation wrt picking combinator rather than pseudo, was that pseudos currently are the only way to leave your tree
# [20:59] <fantasai> TabAtkins: ...
# [21:00] <fantasai> fantasai: seems we have two proposals that are equivalent, except syntactically
# [21:00] <fantasai> fantasai: one is ^ and ^^ combinators
# [21:00] <fantasai> fantasai: the other is ::shadow and ::darkside combinators
# [21:00] <fantasai> fantasai: I think they're actually equivalent syntactically
# [21:01] <SimonSapin> s/combinators/pseudo-elements/
# [21:01] <fantasai> fantasai: That makes me have not too much of a preference (atm) considering Shadow DOM in isolation
# [21:01] <fantasai> fantasai: however, we have two other features that need similar ability to cross boundaries in their selction mechanisms
# [21:01] <fantasai> fantasai: These are region selection, which is very, very similar structurally to shadow dom
# [21:02] <fantasai> fantasai: the other one is page selection, which is just like regions except that the parent selection set is the pages
# [21:02] <fantasai> fantasai: I think that we should have parallel syntax for all three of these
# [21:02] <fantasai> fantasai: because they work exactly the same way as far as selection is concerned
# [21:03] <fantasai> fantasai: which makes me lean towards having the functionality you described with the pseudo-element syntax
# [21:03] <fantasai> ...
# [21:03] <fantasai> florian: Do we need two levels for each type of thing?
# [21:04] <fantasai> people don't think so, seems use-case based
# [21:04] <fantasai> astearns: Seems unlikely to want that for either regions or pages
# [21:04] <fantasai> astearns: ... well ...
# [21:05] <fantasai> fantasai: For regions, might want to do descendants all the time, not have it cut out at first level ever
# [21:05] * ChrisL ::penumbra
# [21:05] <astearns> ::shadow and ::shadow-*
# [21:05] <fantasai> plh: If you use pseudos, you can use combinators. Won't need :top
# [21:05] <fantasai> s/plh/plinss/
# [21:05] <fantasai> TabAtkins: OK, I guess I'll take that back.
# [21:06] <fantasai> TabAtkins: So all these are way to start from the outside, and select in
# [21:06] * dbaron suggests ::𝔰𝔥𝔞𝔡𝔬𝔴
# [21:06] <fantasai> TabAtkins: for customizing something your component is doing
# [21:06] <fantasai> TabAtkins: Now starting inside a shadow root, want to select based on your context
# [21:07] <fantasai> TabAtkins: Given A B C, selecting a C.
# [21:07] <fantasai> TabAtkins: If there's a shadow root boundary between B and C, then ...
# [21:08] <fantasai> TabAtkins: Suppose I want to respond to light vs. dark themes, based on class on <body>
# [21:09] <fantasai> TabAtkins: I need to ship a style sheet inside my component, but I need to somehow react to the stuff up there.
# [21:09] <fantasai> TabAtkins: I can't just say body.lighttheme ^^ div, because first part of this applies inside my tre
# [21:09] <fantasai> TabAtkins: It's not looking outside my tree
# [21:09] * dbaron is amused that tab called ^^ cat-cat
# [21:10] <fantasai> TabAtkins: This will try to find a body.lighttheme inside my shadow tree and try to pierce *its* shadow tree. Neither of these things exist.
# [21:10] <fantasai> TabAtkins: So, have div:ancestor(.light-theme)
# [21:11] <fantasai> TabAtkins: This is like a descendant combinator, but it looks outside the shadow root
# [21:11] <fantasai> SteveZ_: So if I'm double-deep in shadow roots?
# [21:11] <fantasai> TabAtkins: Goes all the way up to the root of the document
# [21:11] <fantasai> TabAtkins: Also have :host(...)
# [21:12] * sgalineau lunch::burritos { visibility: visible; }
# [21:12] <fantasai> TabAtkins: This only selects against the shadow root host element
# [21:12] <fantasai> fantasai: Problem -- ancestor implies any ancestor, not just ones outside the shadow tree
# [21:13] * Quits: kawabata2 (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [21:13] <fantasai> Bit of a naming issue
# [21:13] <fantasai> :host-ancestor was suggested
# [21:13] * krit no, still hidden for me
# [21:13] * dauwhe :host and :parasite
# [21:13] <fantasai> TabAtkins: Those are all the syntactic additions we're considering
# [21:13] * krit guess I am in a shadow tree
# [21:14] <fantasai> TabAtkins: Specificity between rules from outside / inside is defined
# [21:14] <florian> q+
# [21:14] * Zakim sees shepazu, plh, florian on the speaker queue
# [21:14] * sgalineau is pretty sure we have achieved bikeshedding boundaries
# [21:14] <fantasai> SteveZ_: ??
# [21:15] <fantasai> TabAtkins: just like descendant combinator
# [21:15] <fantasai> fantasai: wrt :ancestor/:host, we have the exact same problem with scoped styles
# [21:15] * glazou the first one renaming shadow to shades-of-grey pays beers to the whole WG
# [21:15] <fantasai> fantasai: So again, would want to have same or parallel syntax for that
# [21:16] <fantasai> TabAtkins: Current plan for scoped styles is @global rule
# [21:16] <plh> q-
# [21:16] * Zakim sees shepazu, florian on the speaker queue
# [21:16] * sgalineau "50 shades of DOM shadows", by Tab Atkins
# [21:16] <dbaron> fantasai: You only have a selector without combinators. Someday you're going to come back and extend it.
# [21:16] <dbaron> TabAtkins: we might
# [21:16] <fantasai> TabAtkins: For :ancestor(), wanted to restrict only to compound selector, not have complex selectors
# [21:16] <dbaron> fantasai: you will
# [21:17] <fantasai> fantasai: I have no objection to restricting it, but have to choose syntx assuming it will be extended
# [21:18] <fantasai> florian: Do regions have a parallel requirement?
# [21:18] <fantasai> fantasai: No. Scoped styles do, though.
# [21:18] <fantasai> glazou calls a wrap-up
# [21:19] <fantasai> TabAtkins: All examples I showed so far just have shadow root. They don't have any light DOM children.
# [21:19] <florian> q-
# [21:19] * Zakim sees shepazu on the speaker queue
# [21:19] <fantasai> TabAtkins: Suppose in your original document, have divs with stuff.
# [21:19] <fantasai> TabAtkins: as children of x-foo
# [21:19] <fantasai> TabAtkins: Then x-foo attaches shadow root that add some element,s and then pulls children of host x-foo and shows them
# [21:20] <fantasai> TabAtkins: The shadow root style sheet can't style those <div>s
# [21:22] <dbaron> tab shows a <content select="div" id="bar" /> and then selects the things selected into it with #bar::content div
# [21:22] <fantasai> TabAtkins: So we introduce a pseudo-element, called ::content, which allows to cross this boundary and style the light dom things that have been pulled into the shadow tree
# [21:22] <fantasai> fantasai: Could we call that ::light?
# [21:22] <fantasai> TabAtkins: It's not exactly the light dom...
# [21:22] <fantasai> SteveZ_ asks something about regions
# [21:22] <fantasai> SteveZ_ was asking if regions could be the mechanism for content redistribution
# [21:23] <fantasai> answer was no, because flows are not ...
# [21:23] <fantasai> [...???]
# [21:23] <fantasai> shepazu: What is the relationship of this to styling e.g. scrollbars or calendar widgets
# [21:23] <fantasai> shepazu: I thought browsers would allow access to those via component model
# [21:24] <fantasai> TabAtkins: Answer is, internally we use shadow DOM for all of our inputs etc.
# [21:24] <fantasai> TabAtkins: We will not be exposing it directly, because we have very good reasons to not expose exact markup structure of widgets
# [21:24] <fantasai> TabAtkins: Otherwise we wouldn't be able to vary widgets based on platform
# [21:24] <fantasai> [or over time]
# [21:25] <fantasai> TabAtkins: We are working with MS to come up with some ways of allowing more styling, but through magic, not through exposing the components
# [21:25] <fantasai> shepazu: maybe use a magical standardized shadow dom
# [21:25] <fantasai> TabAtkins: Might do it that way. not sure yet
# [21:25] <fantasai> SteveZ_: his comment suggests maybe you want parameterized shadow dom
# [21:25] <fantasai> TabAtkins: Turns out it's not worth the cost in general
# [21:26] <fantasai> TabAtkins: Might use it for this particular case, but generally exposing to authors, we've found won't be worth it
# [21:26] <glazou> <br type="lunch"/>
# [21:26] * Quits: glazou (~glazou@public.cloak) (glazou)
# [21:26] <fantasai> TabAtkins: for now, will rely on people to document what selectors to use for customization of widgets
# [21:26] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [21:27] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [21:27] * Joins: koji (~koji@public.cloak)
# [21:27] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [21:27] * Joins: koji (~koji@public.cloak)
# [21:28] * Quits: koji (~koji@public.cloak) (Client closed connection)
# [21:28] * Joins: koji (~koji@public.cloak)
# [21:30] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [21:33] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [21:35] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [21:47] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:48] * Joins: smfr (~smfr@public.cloak)
# [21:50] * Joins: koji (~koji@public.cloak)
# [22:08] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [22:09] * Joins: emalasky1 (~Adium@public.cloak)
# [22:13] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:14] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [22:21] * Joins: MaRakow (~MaRakow@public.cloak)
# [22:24] * Quits: smfr (~smfr@public.cloak) (smfr)
# [22:27] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [22:28] * Joins: smfr (~smfr@public.cloak)
# [22:30] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [22:32] * Joins: leif (~lastorset@public.cloak)
# [22:33] * Joins: koji (~koji@public.cloak)
# [22:39] * Quits: emalasky1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [22:39] * Joins: sgalineau (~sgalineau@public.cloak)
# [22:39] * Joins: glazou (~glazou@public.cloak)
# [22:40] <TabAtkins> ScribeNick: TabAtkins
# [22:40] <TabAtkins> Topic: Merging animatable and computed value lines
# [22:40] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:40] * Joins: emalasky (~Adium@public.cloak)
# [22:41] <TabAtkins> fantasai: [points out that computed value and animatable lines duplicate information in the propdef table]
# [22:41] * Joins: Rossen__ (~Rossen@public.cloak)
# [22:41] <TabAtkins> fantasai: Both say what the data model is for a property.
# [22:41] <TabAtkins> fantasai: If the computed-value line was as rigorous and consistently defined as how we're structuring the animatable lines, we could just replace "animatable" with "yes" or "no" or "yes, except FOO".
# [22:42] <TabAtkins> fantasai: I'd prefer not to say things twice, particular if they're slightly different wording.
# [22:42] <TabAtkins> dbaron: "computed value" line is saying what space your value is in, and how to get it there.
# [22:42] <TabAtkins> dbaron: While "animatable" is saying what parts of the space are animateable, and how.
# [22:43] <TabAtkins> astearns: There are some cases where a value takes multiple kinds of values, and computed-value line says "compute it this way, or compute it that way", and animatable.
# [22:44] <TabAtkins> dbaron: Animatable draws a distinction between a repeatable list and a simple list, for example, which computed value doesn't.
# [22:44] <TabAtkins> dbaron: I'd like to see a proposal first, and I'd be skeptical before seeing that.
# [22:44] <TabAtkins> ChrisL: Animatable line seems to mostly be patching in failures of the computed value line, with a bit more detail.
# [22:45] <TabAtkins> ChrisL: I'd also like seeing worked-out examples for lots more properties. But I'm confident it would work.
# [22:45] <TabAtkins> dbaron: There are many places in the spec which we could replace with "it's obvious", but it's not obvious to everyone, and that's why we say it.
# [22:46] <TabAtkins> fantasai: Well, if a prop takes a length, it'll animate as a length, not a percentage or an angle.
# [22:46] <TabAtkins> dbaron: But a computed value of "length or percentage or calc" is three possible terms, but in animation it's one thing.
# [22:47] <TabAtkins> tantek: So what will y'all do?
# [22:48] <TabAtkins> fantasai: I think go through a few specs and do all the conversions, making a concrete proposal from the experience.
# [22:48] <TabAtkins> Topic: Grid
# [22:48] <TabAtkins> fantasai: Still have a few topics to discuss.
# [22:49] <TabAtkins> fantasai: First is Issue 2.
# [22:49] * Joins: jet (~junglecode@public.cloak)
# [22:49] <TabAtkins> TabAtkins: This is about a "join argument" for the repeat function, to put something between the repetitions.
# [22:49] <TabAtkins> fantasai: [draws example]
# [22:52] * Quits: smfr (~smfr@public.cloak) (smfr)
# [22:53] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [22:53] * Joins: sgalineau (~sgalineau@public.cloak)
# [22:53] <TabAtkins> fantasai: So add it now, or defer it?
# [22:54] <TabAtkins> RESOLVED: Defer join argument of repeat() until later.
# [22:55] <TabAtkins> fantasai: Issue 3, default value for grid-auto-flow
# [22:55] * Joins: smfr (~smfr@public.cloak)
# [22:56] * Quits: jet (~junglecode@public.cloak) (jet)
# [22:56] <TabAtkins> TabAtkins: Old behavior (implemented by MS) put items into cell 1,1 by default, overlapping.
# [22:57] <TabAtkins> fantasai: So, suggestions to resolve it:
# [22:57] <AdobeSeattle> http://lists.w3.org/Archives/Public/www-archive/2013Aug/0024.html
# [22:57] <TabAtkins> fantasai: 1) Dont' do anything. I don't think we'll be doing that.
# [22:58] * florian scheme does (string-join strings separator)
# [22:59] <TabAtkins> fantasai: 2) Put things in the first empty slot, with a "stack" value (or "deck").
# [22:59] <TabAtkins> fantasai: 3) Add a way to specify where they stack.
# [22:59] <TabAtkins> fantasai: 4) Just let MS define their own special value in the UA stylesheet, -ms-none or whatever, which has the "stack in 1-1" behavior.
# [22:59] <TabAtkins> Rossen_: I don't think this is much-used, and thus not really a compat issue either way.
# [23:00] <TabAtkins> fantasai: I'd prefer, then, to not add grid-auto-position, as it's not that useful. At least not now.
# [23:01] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [23:01] * florian Haskell is the other way around though
# [23:02] * florian there is no consistent order to follow, we can do whatever we want.
# [23:03] <TabAtkins> fantasai: So my suggestion is "grid-auto-flow: [row | column] || deck;"
# [23:03] <TabAtkins> szilles: Don't like the name "deck". Why not "stack" or "pile"?
# [23:03] <TabAtkins> TabAtkins: "stack" is already used in XAML for a different thing, so Rossen preferred not using it.
# [23:04] <TabAtkins> multiple: don't really like "pile" ^_^
# [23:04] * Joins: emalasky (~Adium@public.cloak)
# [23:04] <glazou> grid-auto-flow: 💩
# [23:05] * dauwhe Did you know the hole's only natural enemy is the pile?
# [23:05] <TabAtkins> [naming discussion]
# [23:06] * Joins: jet (~junglecode@public.cloak)
# [23:07] * astearns -ms-stack
# [23:08] <TabAtkins> [quick straw poll for naming prefs: stack 13, pile 0, deck 3, layer 1]
# [23:09] <TabAtkins> fantasai: So, we think the spec is design-complete. Tab and I want to do an algorithm review, but that's it.
# [23:10] <astearns> rossen: need to decide on collapsing, fragmentation...
# [23:10] <TabAtkins> fantasai: We have an open issue on collapsing, which we need to figure out and still have no ideas yet.
# [23:11] <TabAtkins> Rossen_: I have a proposal for general collapsibility. I'll post to www-style.
# [23:11] <TabAtkins> fantasai: So if you want to review for general implementability, please do it now. This is a call for general design review.
# [23:13] <TabAtkins> Topic: Issue Tracking
# [23:14] <TabAtkins> SimonSapin: As I explained on the list, I think we have too many ways to track issues.
# [23:14] <TabAtkins> SimonSapin: It took a year for me to learn that we have some bugs in W3C Bugzilla.
# [23:14] <TabAtkins> SimonSapin: We also have tracker, in-spec, in-mailing-list, etc.
# [23:14] * plh wonders if Simon is going to propose to use a new issue tracking :)
# [23:14] <TabAtkins> SimonSapin: I'm sure there are some issues we knew about at some point, but forgot about.
# [23:14] <TabAtkins> dbaron: Also, sometimes we have bugzilla and/or tracker components for specs where the spec's editors aren't using bz/tracker for that spec.
# [23:14] <glazou> think http://xkcd.com/927/ and apply s/Standards/Issue Trackers
# [23:14] <TabAtkins> dbaron: So things get dumped in there and lost.
# [23:14] <TabAtkins> dbaron: I was trying to reduce the list of open issues for Transitions, which is in bugzilla.
# [23:14] <TabAtkins> dbaron: Roughly half of the open issues need to be moved to other specs.
# [23:14] <TabAtkins> dbaron: But I don't know how to do that.
# [23:15] <TabAtkins> dbaron: The process is "ask the editor".
# [23:15] <TabAtkins> astearns: Or "email the list saying it needs to be moved".
# [23:15] * glazou DO NOT SUGGEST JIRA !
# [23:15] * plh "Don't know how to solve an issue? Create a new spec and move the issue there" :)
# [23:15] <TabAtkins> dbaron: In many cases the issue in bz is a one-link link to a www-style list.
# [23:15] <TabAtkins> dbaron: Another problem, some editors *have* gone to th eeffort of moving www-style issues to bugzilla, but I don't know at what date that effort stopped.
# [23:16] * astearns all the specs in github markdown, tracked with github issues (until the next flavor-of the week)
# [23:16] <TabAtkins> ChrisL: Tracker is nice there, because it recognizes "Issue-XXX" in the titles.
# [23:17] <TabAtkins> tantek: Isn't there already an agreement to track the issue-reporting place?
# [23:17] <TabAtkins> TabAtkins: Not really. We agreed, yeah, but we didn't follow it.
# [23:18] <TabAtkins> plh: Because we use too many systems, it's too easy to get confused and use the wrong system.
# [23:18] <TabAtkins> tantek: I think it's on the editor to deal with that.
# [23:19] <TabAtkins> TabAtkins: But it doesn't work well today. I agree that having less issue-tracking systems are fine.
# [23:19] <TabAtkins> tantek: Is this primarily a problem with multi-editor specs?
# [23:20] <TabAtkins> TabAtkins: Nah, happens plenty with single-editor.
# [23:20] <TabAtkins> dbaron: But it's often worse if editors transition over time.
# [23:22] <TabAtkins> fantasai: A problem with Tracker is that only editors can update it.
# [23:22] <TabAtkins> fantasai: I'm okay to drop Tracker.
# [23:22] <TabAtkins> fantasai: What I don't want to transition out of is using text files for LC comments.
# [23:23] <TabAtkins> tantek: And I prefer using wiki...
# [23:23] <TabAtkins> dbaron: I also find using bugzilla fairly painful.
# [23:23] <TabAtkins> fantasai: Mailing list is great for collecting issues. It's not good for seeing if it's still open.
# [23:24] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [23:24] <TabAtkins> astearns: If you see a mailing-list item, how do you get to the corresponding issue?
# [23:24] <TabAtkins> fantasai: It would be more solveable if when I replied to the ML issue it actually showed up in the archive.
# [23:24] <fantasai> as a reply
# [23:24] <TabAtkins> dbaron: If they cross month boundaires they don't show as replies...
# [23:26] <TabAtkins> [missed something about threads and issues]
# [23:26] * ChrisL fantasy software development
# [23:27] * sgalineau agreement we want a mail stack but we have a mail pile
# [23:27] <TabAtkins> dbaron: So, any conclusions?
# [23:27] <TabAtkins> fantasai: Does anyone actually want to use Tracker?
# [23:27] * astearns considers my picks for my fantasy software development team
# [23:27] <fantasai> florian and fantasai use tracker, but doesn't mind not using it if that helps this situation
# [23:28] <ChrisL> iisue-273?
# [23:28] <fantasai> issue-273?
# [23:28] * trackbot is looking up issue-273.
# [23:28] <trackbot> issue-273 -- Interaction of text-decoration longhands and blink -- closed
# [23:28] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/273
# [23:28] <ChrisL> issue-273?
# [23:28] * trackbot is looking up issue-273.
# [23:28] <trackbot> issue-273 -- Interaction of text-decoration longhands and blink -- closed
# [23:28] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/273
# [23:28] * Joins: kawabata2 (~kawabata@public.cloak)
# [23:28] <fantasai> florian: for integration and simplicity, I kindof like tracker
# [23:28] <TabAtkins> smfr: Tracker doen't send you update emails.
# [23:30] <TabAtkins> dbaron: I think I heard that the solution to the Transitions things is to just send email about them and closing them.
# [23:30] * krit Bugzilla forever!
# [23:31] <TabAtkins> SimonSapin: So here's a suggestion. We tell people to open bugs on Bugzilla (or some system that actually tracks things), and have that spam the mailing list.
# [23:32] * dauwhe Don't nail lists of issues to doors. Forking may ensue.
# [23:32] * shepazu +1 dauwhe
# [23:32] * ChrisL if people want to raise an issue, they have to write a new issue tracking system first
# [23:34] * astearns at a rate of one tracking system per issue, getting the perfect tracking system should take no time at all
# [23:34] * tantek please be sure your fax cover sheet identifies the specification in question.
# [23:35] * Joins: emalasky (~Adium@public.cloak)
# [23:39] * sgalineau keeps filing issues on CSS Foo Last Calls
# [23:41] <ChrisL> Tracking: data:text/plain,Never gonna give you up, Never gonna let you down, Never gonna run around and desert you
# [23:42] <TabAtkins> RESOLVED: Be more vigilant about specs actually declaring their issue tracking style.
# [23:42] <astearns> not to pick on you, TabAtkins, but you could add an issues link to the custom properties draft before you publish CR
# [23:44] <TabAtkins> Topic: Transitions and Animations
# [23:44] <TabAtkins> dbaron: I've made some progress on Transitions.
# [23:44] <TabAtkins> dbaron: A bunch of what's left is going through issues, by which I mean "here's a 4-page email message that I think is already dealt with, but I need to read the whole thing first".
# [23:45] <TabAtkins> dbaron: Probably about half the Transitions issues are value-type-specific.
# [23:45] <TabAtkins> dbaron: I think basically all of them should be deferred to th enext level of the spec defining those values.
# [23:46] <TabAtkins> dbaron: There are a few that require editing work.
# [23:46] <TabAtkins> dbaron: One is dealing with out-of-range values.
# [23:46] <TabAtkins> dbaron: I think most of what is left before LC is me doing work that I haven't gotten to yet.
# [23:46] <TabAtkins> dbaron: I have not been following the Animations issues as well yet.
# [23:47] <TabAtkins> dbaron: Also, I've been putting in "defer til level 2" in the status whiteboard for some issue, and have two links for the normal and the deferred ones.
# [23:47] <TabAtkins> dbaron: I made some pretty significant edits around TPAC, and I think I talked about those.
# [23:48] <TabAtkins> krit: One issue I'm not sure is tracked is the paint server animation.
# [23:48] <TabAtkins> krit: I'd remove the section completely.
# [23:49] <TabAtkins> RESOLVED: Remove the paint server definition from Transitions, deferring to the Images definition for transitioning <image> values.
# [23:50] <TabAtkins> dbaron: There's also a section about gradient.
# [23:51] <TabAtkins> dbaron: Does anyone implement the Transitions definition of gradient interpolation, rather than Images?
# [23:51] <TabAtkins> krit: Blink and WK don't.
# [23:51] <TabAtkins> dbaron: Gecko doesn't animate gradients at all.
# [23:51] * leif neither does Presto (from memory)
# [23:52] * florian my memory of Presto matches Leif's
# [23:52] <glenn> on phone again
# [23:52] <TabAtkins> RESOLVED: Remove the gradient animation text from Transitions.
# [23:54] <TabAtkins> krit: I'd like to reference the shadow interpolation for drop-shadow(), but it only defines shadow-list. Should I just say it's a list of one item?
# [23:54] <TabAtkins> [some dicussion]
# [23:54] <TabAtkins> krit: Yes.
# [23:54] <dauwhe> s/dicussion/discussion/
# [23:55] <TabAtkins> plh: I heard you were going to move some issues to other specs. Are you planning to do that?
# [23:55] <TabAtkins> dbaron: I can do it, though I'd be happy with others to help.
# [23:58] <TabAtkins> dbaron: I think one of the bigger Animation issues is that we agreed to make pretty substantive changes about a year ago, which nobody had the time to edit and I'm not sure is compatible anymore.
# [23:58] * Quits: jet (~junglecode@public.cloak) (jet)
# [23:58] <TabAtkins> dbaron: Especially regarding animating non-interpolable values.
# [23:58] <TabAtkins> krit: SVG's model is still a bit simpler, where it switches over at half the time progress.
# [23:59] <TabAtkins> TabAtkins: We currently say that it switches at half the progress, not half the time.
# [23:59] <TabAtkins> krit: Right, but that means it could hit that point more than once.
# [23:59] <TabAtkins> sylvaing: Last time I pull issues out of the mailing list was Jan 1st 2013 for Animations. Not sure for Transitions.
# Session Close: Tue Jan 28 00:00:00 2014

The end :)