/irc-logs / w3c / #css / 2014-05-19 / end

Options:

# Session Start: Mon May 19 00:00:00 2014
# Session Ident: #css
# [00:11] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [00:11] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [00:22] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [00:43] <sgalineau> just read dauwhe's comment about *30 hours* of travel. Will now introduce him with 'He travels at the speed of specs'
# [01:02] <liam> "I shall put a girdle about the earth in 40 specs!"
# [01:02] * Joins: dbaron (~dbaron@public.cloak)
# [01:12] <sgalineau> :)
# [01:13] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:15] <dbaron> I guess the meeting room should probably be open by 8:30-ish, Ihope
# [01:15] <dbaron> so I guess I should head over (getting some breakfast on the way)
# [01:15] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [01:18] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [01:18] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [01:18] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:23] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [01:24] * Joins: dauwhe (~dauwhe@public.cloak)
# [01:25] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:30] * Joins: dwim_cloud (~uid10661@public.cloak)
# [01:51] * Joins: dbaron (~dbaron@public.cloak)
# [01:59] * Joins: SteveZ (~SteveZ@public.cloak)
# [02:08] * Joins: glazou (~glazou@public.cloak)
# [02:08] * Joins: clilley (~clilley@public.cloak)
# [02:08] * Joins: abinader (~sid21713@public.cloak)
# [02:09] <glazou> test
# [02:09] * Joins: shans_ (~shans@public.cloak)
# [02:09] * Joins: Zakim (zakim@public.cloak)
# [02:10] <clilley> zakim, this meeting spans midnight
# [02:10] <Zakim> I don't understand 'this meeting spans midnight', clilley
# [02:10] * Joins: dael (~dael@public.cloak)
# [02:10] * Joins: koji (~koji@public.cloak)
# [02:10] * Joins: dauwhe (~dauwhe@public.cloak)
# [02:12] * Joins: glenn (~glenn@public.cloak)
# [02:12] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:12] * Joins: kyungtae (~kyungtae@public.cloak)
# [02:12] * Joins: plh (~plh@public.cloak)
# [02:13] * Quits: glenn (~glenn@public.cloak) ("Page closed")
# [02:13] * Joins: glenn (~glenn@public.cloak)
# [02:14] * Joins: Rossen_ (~Rossen@public.cloak)
# [02:14] <dbaron> Rossen is getting "Permission denied" trying to join IRC via the Web UI
# [02:14] <dbaron> oh, never mind
# [02:14] * Joins: glenn_ (~glenn@public.cloak)
# [02:15] * Quits: glenn_ (~glenn@public.cloak) ("Page closed")
# [02:15] <glazou> http://wiki.csswg.org/planning/seoul-2014#proposed-topics-for-the-meeting
# [02:15] * Joins: glenn_ (~glenn@public.cloak)
# [02:17] <astearns_> SteveZ: the phone is not yet set up
# [02:17] * Joins: murakami (~murakami@public.cloak)
# [02:18] * Joins: adenilson (~anonymous@public.cloak)
# [02:19] <dael> [agenda discussion]
# [02:19] * Parts: plh (~plh@public.cloak)
# [02:20] * Quits: glenn (~glenn@public.cloak) (Ping timeout: 180 seconds)
# [02:20] <dael> scribenick: dael
# [02:21] * Quits: dauwhe (~dauwhe@public.cloak) ("Page closed")
# [02:21] * glenn_ is now known as glenn
# [02:22] <dael> glazou: let's start
# [02:22] * Joins: dauwhe (~dauwhe@public.cloak)
# [02:22] <dael> TabAtkins: Did we do intros?
# [02:22] <dael> glazou: Everyone except you two
# [02:23] <dael> glazou: We were about to discuss agenda.
# [02:23] <dael> glazou: We have requests for call ins, I don't know what peopler equested
# [02:23] <dael> s/equested/requested
# [02:23] <zcorpan> s/peopler/people/
# [02:23] * clilley beep
# [02:23] <clilley> s/^G/null/
# [02:24] * Joins: plh (~plh@public.cloak)
# [02:24] <dael> dbaron: There are cosntrants on call in times.
# [02:24] <dael> dbaron: Europeans want afternoon, US early. There's one session with Steve and Krit so there's only on bock for that
# [02:24] <dael> dbaron: I think it would be early afternoon
# [02:25] <dael> glazou: Topics were inline and what else?
# [02:25] <dbaron> 1pm-2pm
# [02:25] <dael> dbaron: There were other from steve, bert, simon
# [02:25] <dael> shane: and liam
# [02:25] <dael> dbaron: And we can't do them all together
# [02:25] <astearns_> s/shane/dauwhe/
# [02:25] <dael> glazou: So inline would be today after lunch?
# [02:25] * liam waves but can probably call in at any time
# [02:25] <dael> dbaron: I think there was prefernce for not today
# [02:26] <dael> dauwhe: I'd like to do something for that tonight
# [02:26] <dael> dbaron: Remember today is Sunday for US
# [02:26] <dael> dauwhe: So do this after lunch tomorrow
# [02:26] <SteveZ> I cannot do today after lunch but can do it on Tues or Wed
# [02:26] <dael> plinss: Simon wants values, grid, box model
# [02:26] <dael> glazou: Inline is tomorrow after lunch
# [02:27] * Joins: kangil (~d25fff94@public.cloak)
# [02:28] * astearns_ tab and elika may be elegantly dressed, but I prefer Ted's sartorial choice today
# [02:28] <glazou> I'll be glaz for this meeting
# [02:28] <SteveZ> My requests were:
# [02:28] <SteveZ> CSS Line Layout  SVG spec (a REC) defines most properties already. SVG WG would like to reference CSS Line Layout instead. Since there hasn't been progress for two years, how should SVG WG proceed?  Specify heuristics for fonts/font systems without enough font metric information.  Initial caps [would like to participate remotely - Liam] Footnotes in GCPM [would like to attend remotely - Liam]  Box Alignment  review next baseline-alignment sect[CUT]
# [02:28] <dael> glaz: So what should we start with?
# [02:28] <dael> glaz: What's a preferred topic?
# [02:29] <dael> glaz: What's the highest priority?
# [02:29] * liam hopes astearns_ will share a picture :)
# [02:29] <dael> TabAtkins: I wouldn't mind values and units, esp. cust-ident
# [02:29] <dael> plinss: Simon wants that in the afternoon
# [02:29] <dael> glaz: How much time?
# [02:29] <dael> TabAtkins: For all of values and units and hour
# [02:29] <dael> plinss: So this afternoon for that
# [02:29] <dael> glaz: Flexbox to CR?
# [02:30] <dael> fantasai: I think we have one open issue
# [02:30] <dael> fantasai: About computer value of flex as auto
# [02:30] <dael> TabAtkins: We can do flex this morning. Let's do 30 minutes
# [02:30] <astearns_> s/computer/computed/
# [02:30] <dael> glaz: I think we should do transistions animations issues. I thinkt hat needs to be moved along rec track
# [02:31] <dael> plh: I agree
# [02:31] <dael> glaz: Anyone wanting to call in?
# [02:31] <dael> dbaron: Is sylvaing available to call in and does he want to?
# [02:31] <dael> glaz: I don't have a message from him saying he wants to
# [02:32] <dael> glaz: I got a personal message saying it's disappointing not being there, but dbaron is here and knows everything
# [02:32] <dael> TabAtkins: WE can finish the calc discussion. It would be good to have simon.
# [02:32] <dael> zcorpan: I'm here :)
# [02:33] <dael> glaz: I don't think we're full for this morning
# [02:33] <dael> plinss: All I have is flex, transitions/animations, and calc()
# [02:33] <dael> glaz: Since Liam said he could attend, we can do footnotes in GCPM
# [02:33] <dael> dauwhe: I'd prefer tomorrow
# [02:33] <dael> plinss: Morning or afternoon?
# [02:34] <dael> dauwhe: Doesn't matter. Liam is the only outside person
# [02:34] <dael> glaz: Image values?
# [02:34] <dael> TabAtkins: We can do that at any point
# [02:34] <dael> plinss: This morning?
# [02:34] <dael> TabAtkins: Yeah.
# [02:34] * liam can call in whenever for footnotes
# [02:34] <SteveZ> I would like to attend footnotes in GCPM
# [02:35] <dael> plinss: Okay, so afternoon for Stevez?
# [02:35] <dael> dbaron: I think he'd prefer morning
# [02:35] <glazou> SteveZ: did you receive the webinar info?
# [02:35] <dael> plinss: Let's keep it in the morning
# [02:35] <SteveZ> Morning is better for both Liam and I
# [02:35] <dael> dbaron: To be clear, it's 2:30am in France and 5:30pm yesterday in CA
# [02:35] <dael> dauwhe: So tomorrow morning for that?
# [02:35] <glazou> SteveZ: morning korean time?
# [02:36] <dael> glaz: So for the afternoon we only have one topic
# [02:36] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:36] <SteveZ> Yes, morning Korean time
# [02:36] <dael> plinss: Values and units so far
# [02:36] <SteveZ> Preferably before 11AM Korean time
# [02:36] <dael> glaz: We can do CSS3 text with Bert. He said later afternoon.
# [02:37] <dael> s/later afternoon/later in the afternoon
# [02:37] <dael> glaz: Right after that we cn do the CSS text from koji
# [02:37] <dael> glaz: How much time for calc()?
# [02:37] <dael> TabAtkins: We'll say a half hour
# [02:37] <dael> TabAtkins: I'm not sure if we'll get through everything
# [02:37] <SteveZ> Note CSS Text is on my list also
# [02:38] <dael> glaz: For values and units and text this afternoon.
# [02:38] <dael> plinss: This afternoon?
# [02:38] <dael> glaz: Yeah.
# [02:38] <SteveZ> Steve cannot do this afternoon
# [02:38] <dael> glaz: oh. SteveZ wants to attend CSS text discussion
# [02:39] <glazou> SteveZ: is csstext ok this afternoon korean time or you prefer morning korean time?
# [02:39] <SteveZ> I did send an e-mail with the sessions I would like to attend
# [02:39] <dbaron> Present: Chris Lilley, Daniel Glazman, Rossen Atanassov, David Baron, Glenn Adams, Jet Villegas, Koji Ishii, fantasai, Simon Pieters, Alan Stearns, Andrey Rybka, Adenilson Cavalcanti, Bruno Abinader, Dongwoo Joshua Im, Tab Atkins, Ted O'Connor, Dael Jackson, Peter Linss, Philippe Le Hegaret, Shane Stevens, Shinyu Murakami, Dave Cramer, 5 observers in the back
# [02:40] <dael> glaz: SteveZ said he wants to attend line layout, fottnotes in GCPM, text alignment, lext and flexbox. That's a lot.
# [02:40] * fantasai note to Dael, this scheduling session doesn't need to be formatted, minutes are just for us :)
# [02:40] <dael> glaz: Okay.
# [02:41] * fantasai also, if you press tab after typing gl, glazou will autocomplete
# [02:41] * astearns_ glaz* is he who must not be named
# [02:41] <dael> glaz: Let's start with flexbox
# [02:41] <dael> TabAtkins: Okay.
# [02:42] <SteveZ> My set of topics are in: https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0119.html
# [02:42] <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325
# [02:42] <dael> TabAtkins: So fantasai do we have anything except auto
# [02:42] <dael> fantasai: We got a few this week, but they're editorial
# [02:42] <dael> fantasai: We can't do CR right now, but we do have the issue of the computation of auto
# [02:42] <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-lc-20140325#issue-13
# [02:42] <dael> TabAtkins: Let's do that one quick
# [02:43] <TabAtkins> http://dev.w3.org/csswg/css-flexbox/#flex-basis-property
# [02:43] <dael> TabAtkins: Flex basis auto is confusing right now
# [02:43] <dael> TabAtkins: If auto is value of flex spaces it means auto is that direction. Question is when it turns into that because it needs to do that to computer
# [02:43] <dael> TabAtkins: Right now it's un-sec.
# [02:43] * liam gets "This system isn't supported" from the webinar page, hmm, maybe will try from laptop
# [02:43] <dael> TabAtkins: I proposed we should change so it transforms at computed value time
# [02:44] <dael> TabAtkins: So a flexspace auto would become that value, but the confising bit it could also be auto
# [02:44] <dael> fantasai: We discussed this two years ago.
# [02:44] <dael> fantasai: We concluded that because auto means two things and it's inhereted we get odd behaviour
# [02:45] <dael> fantasai: You don't get auto width you get auto, but anyone that's inhereting auto on flex it's rare
# [02:45] <dael> fantasai: It's in theory confusing, but the lack of resolve is more confusing
# [02:45] <dael> dbaron: Does respolution of inheret happen prior to computational phase
# [02:45] <dael> TabAtkins: Yes. Similar to cascade
# [02:45] <dael> dbaron: I've always thought that was wrong and it's not how we impl
# [02:46] <dael> fantasai: So do we need to fix cascade?
# [02:46] <dael> dbaron: I think that there are two was to explain doesn't matter as long as computed value went to itself
# [02:46] <astearns_> s/respolution of inheret/resolution of inherit/
# [02:46] <dael> dbaron: Now we're making that not true so now loc in cascade matters so impl might not match since they assumed equivenlency
# [02:46] <dael> TabAtkins: So you're saying you processed at value computetion
# [02:47] <dael> dbaron: Yes. I don't know if that's what other imp do and I don't know how to test in a black box
# [02:47] * astearns_ is now known as astearns
# [02:47] <dael> TabAtkins: Shane says he thinks they're same
# [02:47] <dael> TabAtkins: We can change cascade.
# [02:47] <dael> dbaron: Testing is worthwhile
# [02:47] <dael> TabAtkins: But you say it's not detectable except flex
# [02:47] <dael> dbaron: Impl might have to change their cascade to deal with it
# [02:48] <dael> fantasai: before we have a use value of flex space.
# [02:48] <dael> TabAtkins: It wasn't stted, but implied
# [02:48] <dael> TabAtkins: We want to do it computed so it's right
# [02:48] <dael> TabAtkins: We can still decide this independantly
# [02:48] <dael> dbaron: It's odd for other reasons.
# [02:48] <dael> TabAtkins: You can't feed GCS into style imeediatly
# [02:48] <dael> TabAtkins: But we can't change that now. I made that mistake years ago
# [02:48] <dael> fantasai: Or we leave things as is
# [02:49] <dael> TabAtkins: Once we get use style
# [02:49] <dael> TabAtkins: So are we okay witht aht wierdness of setting to computed value?
# [02:49] <dael> dbaron: I'd prefer a use value time thing
# [02:49] <dael> TabAtkins: Is it okay for use to resolve to an end value?
# [02:49] <dael> dbaron: How would that happen?
# [02:49] * dauwhe liam: I was able to log into the webinar from my mac.
# [02:49] <dael> TabAtkins: I guess it would resolve to use value of width
# [02:50] * liam notes only mac and windows are supported, i'm running Linux
# [02:50] <dael> TabAtkins: That's prob. ok
# [02:50] <dael> zcorpan: I didn't follow what you said
# [02:50] <dael> TabAtkins: We can't change name of flex space auto value
# [02:50] <glazou> SteveZ: can you hear well through Webinar?
# [02:50] <dael> zcorpan: But you can change behaviour
# [02:50] <dael> TabAtkins: Yes.
# [02:50] <dael> TabAtkins: I was wanting to keep things that went to length to be at computer value time, but it's not huge
# [02:50] <dael> fantasai: So close no change?
# [02:51] <dael> TabAtkins: Well, close and actually specify at use value time
# [02:51] <zcorpan> s/flex space/flex-basis/
# [02:51] <dael> fantasai: close, clarify, no change
# [02:51] <dael> TabAtkins: Yep.
# [02:51] <dael> TabAtkins: That's acceptable to me
# [02:52] <dbaron> s/specify/specify that flex-basis is resolved at/
# [02:52] <dael> TabAtkins: We're good. So res would be close this, spec propertly the flex space auto flips to width.height at use value time
# [02:52] <dbaron> s/flex space/flex-basis/
# [02:52] <dael> glaz: obj?
# [02:52] <dael> RESOLVED: Close issue, spec propertly the flex-basis auto flips to width.height at use value time
# [02:52] <dbaron> s/use value/used value/ (multiple times)
# [02:52] <dael> glaz: Next issue?
# [02:52] * Joins: plinss_ (~plinss@public.cloak)
# [02:53] * dauwhe liam: ugh. I guess corporate america hasn't noticed that people use Linux
# [02:53] <dael> fantasai: There's one from greg that we have to think through
# [02:53] <dael> fantasai: Ther rest is editorial
# [02:53] <dael> TabAtkins: Greg posted one that we didn't get to that we'll have to work on tonight
# [02:53] * Quits: plinss_ (~plinss@public.cloak) (plinss_)
# [02:53] <dael> TabAtkins: I'd like to discuss algorithm changes
# [02:53] <dael> TabAtkins: The only major change since CR was...I said at last F2F I wanted to change alg. so that as value approached 0 it was nice
# [02:54] <dael> TabAtkins: It ended up being a bit of a rewrite and recently dholbert came up with a way to do the same, but closer to org language
# [02:54] <dael> TabAtkins: I think it's right, but if anyone is interested in alg. please make sure it maintains proper behaviour
# [02:55] <dael> TabAtkins: That'st he only issue left. I have both versions in spec and flagged. WE're trying to do the CR version.
# [02:55] <dael> TabAtkins: It looks like the old one, but approaches 0 properly
# [02:55] <dael> fantasai: WE folded in the changes
# [02:55] * glazou stopped the fan, too noisy, please let me know when it gets too warm, we'll turn it back on during the break
# [02:55] <dael> dbaron: This confuses me because you're talking about CR predating LC
# [02:55] <dael> TabAtkins: So 9.7.3 is what we're going for
# [02:55] <dbaron> Tab: trying to go for 9.7.2, should be equivalent to 9.7.1
# [02:56] <dael> TabAtkins: WE need to address greg's issue tonight and make editorial. I think we can ask for CR tomorrow
# [02:56] <dael> TabAtkins: I think that's all on Flexbox right now
# [02:56] <dael> glaz: Okay
# [02:56] <dael> glaz: We'll move to transitions
# [02:56] <dael> Rossen_: One question. Where did we leave auto for absolutes
# [02:56] <dael> TabAtkins: Would you like to discuss? It's no change
# [02:57] <dael> Rossen_: It's open on the list. We can do now or just us.
# [02:57] <dael> TabAtkins: Let's do here
# [02:57] <dael> TabAtkins: Right now we have spec that grid and flex are similar for static position of absolutely posistioned child of flexbox
# [02:57] <dael> TabAtkins: The model now is you act as if the abspos is the only child according to alignment and where it goes is the static position
# [02:58] <dael> TabAtkins: If you set justify center you'll have a thing where abspos is centered in flex
# [02:58] <dael> TabAtkins: Rossen_ said that was confusing since you're not getting ceter from the flex.
# [02:58] <dael> TabAtkins: He things that would only apply if that's containing for abspos.
# [02:58] <dael> TabAtkins: I don'th ave strong option, but I'm okay if we make this in the containing block cae, but I also don't have the problem
# [02:59] <dael> fantasai: I pref children of the flex box that have their continaing block be the flex box and the static position of the item is the same.
# [02:59] <dael> fantasai: Everywhere else if you pick static pos of item, that's the pos regardless of containing block
# [02:59] <dbaron> fantasai: I want the static position of the item not to depend on what its containing block is (like everywhere else).
# [02:59] <dael> fantasai: If we do this we have to cacluclate different ways
# [03:00] <dael> fantasai: I don't think that's a good inconcsitancy
# [03:00] <dael> Rossen_: I agree. I don't want something different based on containing block
# [03:00] <dael> Rossen_: What was into. in grid first. When we did it we wanted to align grid items in grid
# [03:00] <dael> Rossen_: However, that was only abspos items in the grid, with the gird as the containing block
# [03:01] <fantasai> Rossen_: That kindof violated the rule fantasai stated
# [03:01] <dael> Rossen_: Basically, the problem is with abspos layout, you complute the static position where the element's natural position would have been
# [03:01] <dael> Rossen_: Then the participation of the element is done and you don't need to reconsider.
# [03:01] <dael> Rossen_: Once you're in containing block you figure out where the item will be and than you size the item
# [03:02] <dael> Rossen_: The problem with the way we have spec auto position, you have to go and fudge with static position to make it work so item appears centered in the flex box
# [03:02] <dael> Rossen_: Even thought he position between flex and item is distant.
# [03:02] <dael> Rossen_: What we wanted to propose is to not find the static position, but to find where the static position applies
# [03:02] <dael> Rossen_: So instead of static as origin you can say it in relation to the box
# [03:03] <dael> Rossen_: So you can work around the static position and center around it
# [03:03] <dael> Rossen_: Instead of after you've computed, reverse engineering
# [03:03] <dael> Rossen_: When I mentioned this on the ML, I said we should do this in position spec
# [03:03] <dael> fantasai: So, you can see static position as a point to which the abspos is attanched
# [03:03] <dael> Rossen_: Isn't it?
# [03:03] <SteveZ> Elika you are breaking up on audio
# [03:04] <dbaron> s/you can see/you (Rossen) concieve of/
# [03:04] <dael> fantasai: In the other models you don't do it that way It's a box, not a point, and that doesn't make a difference
# [03:04] <astearns> s/abspos is attached/abspos start start corner is attached/
# [03:04] <dael> fantasai: So you say static pposition is start,start and you have a small abspos.
# [03:04] <dael> fantasai: If you shift the item it won't be centered and will instead drift. This is odd and won't be useful.
# [03:05] <dael> fantasai: It would be better if cetering kept the item inside the box
# [03:05] <fantasai> s/odd/asymmetric/
# [03:05] <dael> dbaron: I think Rossen_ is discribing a different way to get the same result.
# [03:05] <dael> dbaron: I'm sceptical about this in the whole, and want to know about use cases
# [03:05] <dael> TabAtkins: Largely it's so that you can achieve centering with abspos
# [03:05] <dael> TabAtkins: Treating static more nievely, it seems dumb. It's not what you would want in any case
# [03:06] <dael> TabAtkins: If you say just contenter center and it only uses that and goes to the side, it sounds stupid
# [03:06] <dael> TabAtkins: In terms of author expectations, this is better
# [03:06] <dael> fantasai: If we want to do dumb, t's always start, start corner
# [03:06] <dbaron> I'd be happy with just start,start corner
# [03:06] <dael> fantasai: If we're doing this and trying to make it useful, it's just ending up odd.
# [03:07] <dael> fantasai: So we need to make this always work usefully
# [03:07] * clilley OH "if we are going to do something dumb" (specifies dumb in detail. But a good dumb.
# [03:07] <dael> dbaron: I'm okay with start start corner.
# [03:07] <dael> dbaron: This is a lot of code, but right now you have the flexbox model and you can escape into the old model, oh and you can overlap your content
# [03:07] <dael> TabAtkins: Okay.
# [03:07] <fantasai> fantasai^: Either we should do something useful, or we should do something dumb and predictably useless.
# [03:07] <fantasai> fantasai^: Trying to make it kinda smart but failing to be useful, is not useful
# [03:07] <dael> dbaron: Is the disagreement the way to formulate?
# [03:08] <dael> TabAtkins: I think so. I think his code assumes a simplier order. Rossen_ 's ultimate model let's us position static nievely and end in the right place
# [03:08] <dael> dbaron: You may see static pos comutation as a seperate thing that can happen later
# [03:08] <dael> dbaron: I'm happy with Rossen_ 's since it might be easier to impl
# [03:08] <dael> TabAtkins: It shouldn't have anything detectable
# [03:09] <dael> TabAtkins: The only things that play off are realpos, which isn't a thing
# [03:09] <dbaron> Tab: There shouldn't be any detectable differences ... / dbaron: Famous last words.
# [03:09] <dael> fantasai: I think if you want to computate static pos that if you store instead of a point, but as a box
# [03:09] <dael> Rossen_: What's the relation between that and the box
# [03:10] <dael> fantasai: You store as a rectangle so in the case of most things it's a 0 height, but depending on if you are, it'll be that or the size of the 0 height
# [03:10] <dael> fantasai: Then it'll happen at the time of positioning. For flex it would be a flex container
# [03:10] <dael> dbaron: I don't think it makes sens as a rectangle
# [03:10] <dael> dbaron: To fit into existing you want an x coordinate and a y cordinate with top-center-bottom coordinate
# [03:11] <dael> Rossen_: hich is what we did in grid
# [03:11] <dbaron> s/x coordinate/x coordinate and left-right-center alignment/
# [03:11] <dael> TabAtkins: Was this org. in grid and we changed it?
# [03:11] <dael> TabAtkins: Are we okay with refom in those terms, assuming positioning will do this later and better?
# [03:11] <dael> fantasai: Can we discuss the rectangle later, with a white board?
# [03:11] <dael> TabAtkins: yes.
# [03:12] <dael> Rossen_: When you start counting all the modes you'll have fun with a rectangle. As an impl I promise that a point will be conseptionally easier.
# [03:12] <dael> Rossen_: I'm sure with a white board we can solve this in a few minutes
# [03:12] <dael> TabAtkins: So for now let's resolve for what Rossen_ said
# [03:12] <dael> fantasai: I don't want center and off to the side stuff
# [03:12] <dael> Rossen_: Let me repeat
# [03:13] <dael> TabAtkins: Rossen_ wants identical behaviour in a different way
# [03:13] <dael> TabAtkins: Let me write out this resolution
# [03:13] <TabAtkins> proposed resolution: Switch the flexbox/grid abspos model to be more naive, just positioning a 0x0 box as currently specified, but then also define that, based on alignment, the abspos child aligns relative to its static position differently. Same layout results should be achieved.
# [03:14] <dael> TabAtkins: Okay.
# [03:14] * liam hears loud whispering
# [03:14] <dael> TabAtkins: Rossen_ is that right?
# [03:14] <dael> Rossen_: Yep.
# [03:14] * liam (it's not a problem but if you didn't want people on the phone to hear, don't do it next to the mic ;-) )
# [03:14] <dael> fantasai: So maybe we have both models in the spec, one as a note so people can think about it
# [03:14] <TabAtkins> Such that "justify-content: center" puts the static pos in the center of the flexbox, and the abspos aligns its *center* with the static pos, rather than its start edge.
# [03:15] <dael> fantasai: I think for authors it would be easier, but for impl they want the details.
# [03:15] <dael> TabAtkins: So. That sound fine for now?
# [03:15] <fantasai> s/easier/easier to talk about aligning the abspos within teh box/
# [03:15] <dael> Rossen_: For now. I think we're going in the right direction
# [03:15] <dael> TabAtkins: Now we can do transforms.
# [03:15] <fantasai> s/they want the details/we can formulate in terms of static position point/
# [03:15] * TabAtkins liam, it wasn't meant for public
# [03:15] <dael> glaz: So transitions/animations and OM issues
# [03:15] * TabAtkins just the two of them whispering about something among themselves.
# [03:16] <dael> dbaron: should we start with transitions? The issues are pretty different
# [03:16] <dael> dbaron: So.
# [03:16] <dael> dbaron: When we met in, I think a year ago
# [03:16] <dael> dbaron: We had agreed to. we had an issue with a bunch of different ways for how transitions started.
# [03:17] <dael> dbaron: No one liked thier own except Safari, so we had no proposals on the table
# [03:17] <fantasai> s/Safari/Safari, who couldn't explain theirs/
# [03:17] <dael> dbaron: I came up with one that people were okay with that we put in the spec, but at the time we had no impl
# [03:17] <dael> dbaron: I think in Paris Shane said google had impl it.
# [03:17] <dael> shans_: Some of it.
# [03:17] <dael> dbaron: When I tried to impl in Geicko, I found a piece that didn't work.
# [03:17] <fantasai> s/Geicko/Gecko/
# [03:18] <dael> dbaron: I am hoping I will have some time in the next few weeks to think about a fix
# [03:18] <fantasai> s/work/work, which Shane also ran into/
# [03:18] * glazou types slower than fantasai, clearly
# [03:18] <dael> dbaron: Basically the spec is based on haveing a coherent way to say when transitions start and how to start them
# [03:18] * astearns s/glazou/everyone/
# [03:18] <dael> shans_: This is the interation between transitions and animations?
# [03:19] <dael> dbaron: The edits I made in the fall was transitions/animations and transitions on same prop depending on ancestors and descendant.
# [03:19] * Joins: dino (~textual@public.cloak)
# [03:19] <dael> dbaron: There's a bunch of hard cases whose behaviour changes based on the model.
# [03:19] * hober waves at dino
# [03:19] <dael> dbaron: There was a lot of disagreement on those cases.
# [03:19] <dael> dbaron: We decided that we like the behvaiour from the model spec
# [03:19] <dael> dbaron: Current breaks inturrupting of running transtions and that's what needs a fix
# [03:20] <dael> dbaron: Other than that I think transitions is ready for LC. That's pretty significant
# [03:20] <dael> dbaron: I think we shouldn't move to LC, but someone or I needs time to figure this out
# [03:20] <dael> dbaron: I don't think it's that hard if I had a solid chunk of 3 days, but I'm not expect that sson
# [03:20] <fantasai> s/sson/until mid-June/
# [03:21] <dael> clilley: I have a question. You said model is wrong, but we've before gone forward with an imperfect model. How much are we paining into a corner?
# [03:21] <dael> dbaron: Depends on if you care about impl not conforming to spec.
# [03:21] <dael> clilley: Yeah, that is fairly bad
# [03:21] <dael> dbaron: It doesn't start certain trans that need to start.
# [03:22] <dael> dbaron: In particular when you have a transition that happens when you move the mouse over and when you move the mouse away, it lets the transition move out
# [03:22] <dael> dbaron: I don't think there's much to discuss unless someone has thoughts
# [03:22] <dael> shans_: I don't know the text spec.
# [03:22] <astearns> s/the text/how to fix it in the/
# [03:23] <dael> dbaron: I've be curious to know how you fixed it in impl. I wrote a series of patches, start the tests, and realized that transitions that inturrupt don't work
# [03:23] <dael> dbaron: Now my patch series has the same bug as the spec
# [03:23] <dael> clilley: That's fine. You've proved the spec is wrong, but if people have impl there must be something that's working
# [03:23] <dael> dbaron: There's a pile of edge cases where impl do different things, expect a broke a case where they were interop.
# [03:23] <fantasai> s/expect/except/
# [03:24] <dael> fantasai: You said you'd have time in June?
# [03:24] <dael> dbaron: I hope so.
# [03:24] <dael> fantasai: So maybe we aim for LC at end of June?
# [03:24] <dael> dbaron: That might be tight. shans_ and I can talk.
# [03:24] <dael> dbaron: I think I should move on to aniimations.
# [03:24] <dael> dbaron: That has a lack of editorial resournces. I've mostly kept up with trans edits, but not animations
# [03:25] <dael> dbaron: I added a list of pending res that need edits so people know what's wrong.
# [03:25] <dael> dbaron: I was hoping sylvaing could help with editing
# [03:25] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [03:25] * Quits: dauwhe (~dauwhe@public.cloak) ("Page closed")
# [03:25] <dael> clilley: Brian Birtloes understands these issues. He's got a model in his head, can he be drug into editing
# [03:26] <TabAtkins> `s/Birtloes/Birtles/
# [03:26] <TabAtkins> s/Birtloes/Birtles/
# [03:26] * krit dbaron I think he is looking into it already
# [03:26] * fantasai notes that sylvaing also has all the time he's not spending on an airplane to Seoul this week to do edits :)
# [03:26] <TabAtkins> s/Birtloes/Birtles/g
# [03:26] <dael> shans_: I'm not sure if he has the integration part in his head. He's been deffering to myself and TabAtkins
# [03:26] * krit he being sylvaing
# [03:26] * TabAtkins Ugh, shipping regexes to formatters later down the line is confusing.
# [03:26] <dael> shans_: We have a model of web integration almost ready to be looked at. Maybe I can get that would to the list
# [03:26] <dael> shans_: There's a question about animations intergration. Maybe we can do that now?
# [03:27] <dael> [brief pause as the white board arrives]
# [03:29] <SteveZ> I will drop of listening for today. I will be back at 9AM Korean time on Tuesday. I will check the IRC for schedule for Tuesday (and Wednesday)
# [03:29] * dauwhe_ we need a bart simpson at the chalkboard meme.
# [03:30] * krit glazou Is it possible to call in? Conf code is not accepted
# [03:30] * plh "I will not use the terms CSS3 or CSS4"
# [03:30] * dauwhe_ SteveZ: so sorry you couldn't make it
# [03:31] * liam hopes the air conditioning is not too strong, it's only 65F here as it is, and a frost possible tonight!
# [03:31] * clilley krit are you using the webinar?
# [03:31] * liam krit yes
# [03:31] <glazou> krit: see webinar info in private list
# [03:31] * krit oh, didn't thought about it as a conf system :P
# [03:32] * plinss changes topic to 'http://wiki.csswg.org/planning/seoul-2014#agenda'
# [03:32] * liam the webinar gives a telephone number (after checking you are not running Linux)
# [03:32] <dael> dbaron: So the state of animations is stuck on editing resources.
# [03:32] * Joins: lmclister (~lmclister@public.cloak)
# [03:32] <dael> dbaron: I don't know how much exposure he has to CSS concepts
# [03:32] <dael> clilley: Given that he doens't understand the concepts and his spec is supposed to be wonderfully useful
# [03:33] <dael> shans_: There's a lot of us working on that spec and between us we have a good grasp
# [03:33] <dael> shans_: you don't have to model every CSS concept in web animations to make it work. There's a shadowy topic of what does CSS do to start/stop anmations
# [03:34] <shans_> http://rawgit.com/shans/98cb810920ac43876020/raw/b77db7529411066c9f3cdd36a52d0b98553525f9/Overview.html
# [03:34] <dael> shans_: At the moment we have transtioiins and animations, we have web animations and we've just started a 3rd piece
# [03:34] <dael> shans_: That talks about how to take the concepts from CSS to web animations
# [03:34] <dael> shans_: We were looking at this while discussing web animations and trying to decide if this 3rd peice makes sense or if it makes sense to re-write
# [03:35] <dael> clilley: And to help use to discuss what were your findings?
# [03:35] <dael> shans_: I think it's useful, but I don't know what level
# [03:35] <dael> dbaron: I feel we should get current set out with the model they have because we have impl and interop
# [03:35] <dael> clilley: Weren't you aruging the oposite about it not working?
# [03:35] <dael> dbaron: that's a small set of issues
# [03:35] <dael> clilley: That's nto what I heard
# [03:36] <dael> hober: I think that's not what I said. We have a lot of edge cases, but I agree with dbaron that we should get out and think about the other issues in the future
# [03:36] <dael> clilley: This goes back to my last comment, though.
# [03:36] <dael> dbaron: I think there's a different time scale of work.
# [03:37] <dael> dbaron: transitions issues can be solved in a week, but I don't think someone can re-write in a week to match web animations
# [03:37] * birtles fwiw dbaron is right, I don't know all the CSS-specifics (and I agree we should get out the current level spec without confusing it with web animations)
# [03:37] <dael> shans_: I agree with that. It would be a lot of work to do the reqrite and a lot more to get things correct
# [03:37] <dael> clilley: I take the point about verifications, but it doesn't sound like theyre using any specific model
# [03:38] <dael> dbaron: But we were talking about the model about starting transitions before, but now we're talking about the whole model, which is a lot bigger
# [03:38] <dael> shans_: It's not as big as it sounds. Web animations model talks about how to do interpreted values and put them back into CSS. The statrt/stop remains unchanged.
# [03:38] <dael> shans_: Unfortunatly, that's the stuff we have trouble with
# [03:39] <dael> dbaron: I'm fine with someone doing the other in parrall, but I don't think we should block advancement
# [03:39] <dael> clilley: You said a week, you mean one not doing anything else. Is that likely?
# [03:39] <dael> dbaron: I'll see. I'm hoping 2nd half of June
# [03:39] <dael> clilley: I'm trying to not have a thing where the skys have to open to make this work
# [03:39] <dael> dbaron: I don't think it's that complecated. I also think it's really a day, which is why I'm saying a week
# [03:40] <dael> clilley: So we're almost ready for LC?
# [03:40] <dael> dbaron: For transitions, yes.
# [03:40] <dael> dbaron: Was there stuff you wanted to discuss about this draft?
# [03:40] <dael> shans_: Not spec. I think it's worth looking at some point, but not high priority.
# [03:40] * astearns dbaron just violated the star fleet engineering code. never admit that your week is actually a day
# [03:41] <dael> shans_: I have some changes to intergrate, but than I'll send an e-mail. I wanted to clarify what we should be doing and I think that's clear.
# [03:41] <dael> shans_: This should be part of Animations 4. I think this draft will never be a spec. It'll be a reference until we're ready to merge.
# [03:41] <dael> shans_: Than we'll pub transisions/animations 4.
# [03:41] <dael> dbaron: Sounds fine to me.
# [03:41] * krit glazou I am muted by the organizer. Not want to talk right now. But would like to know what to do when I want to.
# [03:41] * clilley so the problem is that we are moving, but the engines canna tak it captain
# [03:42] <dael> Rossen_: Is this something you're prop bringing into CSS?
# [03:42] <dael> Rossen_: I see this is something you posted outside of w3c.
# [03:42] <dael> Rossen_: I don't remember this...are you going to bring this offically?
# [03:42] <dael> shans_: That's the question. It's not pub at all, it's just avail for sharing
# [03:43] <dael> clilley: So web animations is going onward. I'd imagine this will be intergrated in
# [03:43] <dael> shans_: My proposal is to keep this as unoffical reference until trans/animations 3 is ready.
# [03:43] <dael> shans_: Thank roll this into trans/anim level 4
# [03:43] <dael> shans_: So we won't have another spec lying around.
# [03:44] <dael> glaz: Your doc is a W3c...maybe we should move this to the dev pages?
# [03:44] <dael> shans_: Absolutely
# [03:44] <dael> glaz: It's only an unoffical ED
# [03:44] <dael> glaz: We decded a while ago to move stuff to dev only if the WG agrees
# [03:44] <dael> clilley: We've lots of times had two levels going.
# [03:44] <dael> glaz: This is up to the WG. Any obj?
# [03:45] <dael> shans_: To be clear, take my doc and put it on the dev pages and than start to bring in animations 4 later?
# [03:45] <dael> dbaron: If we want to start to edit now or later is open
# [03:45] <dael> hober: The question is just to bring it across
# [03:45] <dael> plh: Does this need to be charter?
# [03:45] <dael> Rossen_: If it's title trans/anim 4 no.
# [03:45] <dael> plh: I jsut want to make sure it's in the right place with the charter.
# [03:46] <dael> clilley: Thanks, btw for the ac's that have commented on charter
# [03:46] <dael> clilley: So is the trans/anim 4?
# [03:46] <dael> shans_: Eventually
# [03:46] <dael> clilley: So do we want to call it that now so we can put it in the charter?
# [03:46] * dino suggests we go to 5 blades
# [03:46] <dael> glaz: If we want to add to the charter, some ACs have already voted, so what would happen to the charter? revote?
# [03:46] <dael> plh: We have to get the approval to do that
# [03:47] <dael> clilley: WE have comments from an AC asking for edits, so I've got a copy already
# [03:47] <dael> glaz: From an AC prospective, some people could be bothered about adding a new doc
# [03:47] <dael> dbaron: If an AC suggests we add that doc
# [03:47] <dael> glaz: Okay.
# [03:47] * krit glazou ping? See question above.
# [03:47] <dael> clilley: I'm not editing the AC copy.
# [03:47] <dael> clilley: So do we haev a resolution on that?
# [03:48] <dael> glaz: so move that document to dev pages?
# [03:48] <dael> dbaron: I think in the min. that status should say that the intent is to merge.
# [03:48] <dael> hober: I'm not confortable witht he title change.
# [03:48] <dael> dbaron: I think this shouldn't get the name, yes
# [03:48] <dael> clilley: It just means I need to put this title in the doc.
# [03:48] <glazou> krit: now unmuted
# [03:48] <dael> Rossen_: If we need it to be unofficial...
# [03:49] * krit glazou thanks
# [03:49] <dael> plh: So if it'll be integrated at the end, we don't need to change charter
# [03:49] <dael> clilley: Okay.
# [03:49] <dael> RESOLVED: Migrate shans_ document (link above) into the dev pages
# [03:50] <dbaron> (and the SotD section should say that it's intended to be incorporated into Transitions and Animations 4)
# [03:50] <dael> glaz: I suggest a break, 10 or 15 min
# [03:50] <dael> shans_: Did dbaron have further?
# [03:50] <dael> dbaron: [shake head]
# [03:50] <dael> Break until 11am Seoul
# [03:50] <dbaron> <br style="min-width: calc(60s * 10)" />
# [03:50] * Quits: dino (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [03:52] * krit is someone still editing the schedule for the meeting?
# [03:55] * Joins: myakura (~myakura@public.cloak)
# [03:57] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [03:58] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [03:59] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [04:03] * Quits: arronei (~arronei@public.cloak) (Client closed connection)
# [04:03] * Joins: arronei (~arronei@public.cloak)
# [04:06] * liam wonders what Korean coffee is like
# [04:08] * Joins: Kyounga (~Kyounga@public.cloak)
# [04:08] * Quits: Kyounga (~Kyounga@public.cloak) ("Page closed")
# [04:09] * Joins: jh_hong (~jh_hong@public.cloak)
# [04:10] * Zakim excuses himself; his presence no longer seems to be needed
# [04:10] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [04:10] * dauwhe_ liam: lots of US-style coffee shops in the area. I believe there's a Starbucks in this building.
# [04:11] * dauwhe_ finding tea is more difficult.
# [04:11] * liam bewails the ubiquity of universality
# [04:11] * Joins: kyounga (~kyounga@public.cloak)
# [04:12] * dauwhe_ I'm told the "americano" is the drink of choice. Sigh.
# [04:13] * dauwhe_ liam: yet you work for a global standards organization :)
# [04:14] * liam :)
# [04:16] * hober the espresso at angel-in-us coffee is pretty good; even glazou approves of it
# [04:17] * liam hopes dbaron is not trying to pout coffee into the electrical outlets
# [04:17] * liam s/pout/pour/
# [04:17] * Joins: Rossen_ (~Rossen@public.cloak)
# [04:17] * astearns hober: directions to the closest one of those?
# [04:18] * astearns there's lots of good espresso in Seoul proper
# [04:18] * astearns www.coffeelec.com is the best I've found so far
# [04:18] * hober astearns it's <1 block from here
# [04:19] <dael> glaz: Let's start.
# [04:19] <dael> glaz: con't animations?
# [04:19] <dael> dbaron: Did we have other things?
# [04:19] <dael> glaz: One about animations OM issues?
# [04:19] <dael> plinss: Also, cascading behaviour?
# [04:19] <dael> TabAtkins: That'st he how do things start we were discussing.
# [04:19] <dael> dbaron: I don't know how added those items?
# [04:19] <dael> plinss: What are the OM issues?
# [04:19] * krit TabAtkins are you editing the agenda page?
# [04:20] <TabAtkins> I was, but I committed it.
# [04:20] <TabAtkins> Like, 20 minutes ago at least.
# [04:20] <dael> [silence]
# [04:20] * krit TabAtkins tuesday is nearly empty, wednesday literally is
# [04:20] <dael> TabAtkins: Zakim excused himself...is he needed?
# [04:20] <dael> glaz: No
# [04:20] * krit TabAtkins many items are missing
# [04:21] <dael> glaz: Let's move on to calc
# [04:21] * Joins: Zakim (zakim@public.cloak)
# [04:21] * dbaron Zakim, remind us in 7 hours to go home
# [04:21] * Zakim ok, dbaron
# [04:21] <dael> TabAtkins: Yes.
# [04:21] <dael> TabAtkins: [heads to the white board]
# [04:21] <glazou> astearns: good espresso 25 meters from this building
# [04:21] <dael> TabAtkins: It's the plus/minus thing
# [04:21] * dbaron The ± thing :-)
# [04:21] <glazou> eheh
# [04:21] <dael> TabAtkins: Right now, calc requires spaces around + and - to avoid ambiguities
# [04:22] * Joins: Jet (~Jet@public.cloak)
# [04:22] * Quits: jh_hong (~jh_hong@public.cloak) ("Page closed")
# [04:22] <dael> TabAtkins: There's a proposal to allow us to omit these.
# [04:22] * Joins: jh_hong (~jh_hong@public.cloak)
# [04:22] <dael> TabAtkins: Does anyone need a review, or are we just doing whatever TabAtkins wants.
# [04:22] <dael> dbaron: I'd like to hear it
# [04:22] <dael> hober: With examples
# [04:22] <dael> TabAtkins: For example, right now I need to write 1 + 2 it tolkinies as a number.
# [04:23] * Joins: adenilson (~anonymous@public.cloak)
# [04:23] <dael> TabAtkins: One change is that if you get the right combination of tolkins, If you run into a + or - it assumes that it's negative/positive
# [04:23] <dael> clilley: Can I do 1 + -2?
# [04:23] <dael> TabAtkins: Yes.
# [04:23] <dael> TabAtkins: This is the less complex.
# [04:23] <Jet> s/tolkins/tokens
# [04:24] <dael> fantasai: Does that first one mean if I write [whiteboard] it would work?
# [04:24] <dael> TabAtkins: Yes. In this new approach it remmebers if numbers are positive or negative.
# [04:24] <fantasai> [whiteboard] = 1/**/2
# [04:25] <fantasai> s/Yes/No/
# [04:25] <dael> plinss: To clarify. In the case with a negative, you're converiting to 1 - 2 to 1 + -2?
# [04:25] <dael> TabAtkins: Yes.
# [04:25] <fantasai> TabAtkins^: It looks at the represntation to see if there was a plus sign
# [04:25] <dael> plinss: The thing is you can always call it addition if it's number number, but at some point we need to know if we're adding a positive or a negative
# [04:25] <dael> TabAtkins: This is us fighting the process to get it to do what we want.
# [04:26] <dbaron> s/1 + -2/1 - +2/
# [04:26] <dael> TabAtkins: The complex part is about units
# [04:26] <dael> TabAtkins: + isn't relevent because as soon as there's a unit it's easy.
# [04:27] <dael> TabAtkins: The hard part is negatives.
# [04:27] <dael> TabAtkins: 1px-2em looks like one big unit.
# [04:27] <dael> TabAtkins: The current proposal that I'm okay with is we change the syntaz parsing of dementions.
# [04:27] <dael> TabAtkins: The unit is slightly more restrive so you can't have dash after the unit
# [04:28] <dael> TabAtkins: so that would became 1px and -2em
# [04:28] <dael> TabAtkins: Whenever we...It's only one...no, it is two characters
# [04:28] <dael> plinss: So you can have dashes in units as long as it isn't followed by units
# [04:28] <fantasai> dbaron^: So you're adding a 3-character lookahead to the scanner?
# [04:28] <dael> TabAtkins: Yes. prefixes are still valid in demensions.
# [04:28] <fantasai> s/3/2/
# [04:29] <fantasai> TabAtkins^: It's already got a 3-char lookahead
# [04:29] <dael> clilley: Do we have syntax for prefixes and does it allow digits?
# [04:29] <dael> TabAtkins: Right now it's an ident
# [04:29] <dael> clilley: For a vendor prefix?
# [04:29] <dael> TabAtkins: Yes.
# [04:29] <dael> dbaron: If a vendor prefix starts with a number yyou're in trouble
# [04:29] <plinss> s/followed by units/followed by digits/
# [04:29] <dael> clilley: So to use this as units, you hve to put a restriction on vendor prefix
# [04:30] <liam> [ calc(3px - border-width) ]
# [04:30] <dael> TabAtkins: It would never work
# [04:30] <dael> dbaron: You want your vendor prefix as 2px, it would be a demesion anywhere
# [04:30] <dael> clilley: I'm looking for consistant
# [04:30] <dael> TabAtkins: It is. Vendor prefixes are in ascii vendor range
# [04:30] <dael> hober: Are there any cases left that req. whitespace?
# [04:31] <dael> glaz: Do we need a digit after a dash in idents?
# [04:31] <dael> TabAtkins: Yes.
# [04:31] <dael> TabAtkins: Translate -3d i think
# [04:31] <dael> zcorpan: There's one place with whitespace
# [04:31] <dael> TabAtkins: Yes. If you're trying to subtract a function.
# [04:31] <dbaron> transform-style: preserve-3d means we need to keep allowing it in idents
# [04:31] <dael> TabAtkins: If I say 2px - attr(foo). Without white space it would be a dimension with stuff.
# [04:32] <dael> TabAtkins: The thought it this is okay b/c people are familiat with white space and dashes in ident names.
# [04:32] * sgalineau css-animations OM issues were those raised by Daniel. Happy to join in on Tue or Wed AM if there is time. Or later.
# [04:32] <dael> hober: I don't think so
# [04:32] <dael> fantasai: Especially in area where people re using spaces because there are words. I don't think that works
# [04:32] <dael> hober: model in CSS is that I can use this thing to produce values and I can use it anywhere.
# [04:33] <dael> glaz: If preserve 3d is the only case, why don't we change that.
# [04:33] <dael> fantasai: We'll have same problem with min-content. We can't change all keywords
# [04:33] <dael> glaz: I'm saying forbid digit after dash.
# [04:33] <dael> TabAtkins: If we only did numbers, it would only help us with number and number.
# [04:33] <dael> plinss: You only need the space after the dash?
# [04:34] <dael> TabAtkins: There are no trailing dashes.
# [04:34] <dael> plinss: In idents
# [04:34] <dael> TabAtkins: We can make that a no...
# [04:34] <dael> TabAtkins: Calc can examine and say it's a negative. This is less awful.
# [04:34] <dael> TabAtkins: Opinions.
# [04:34] <hober> s/use this thing/use calc()/
# [04:34] <dael> fantasai: I'm against this because I think it'll make functions and keywords confusing since they won't realize when you swap you need spaces
# [04:35] <dael> TabAtkins: I agree, but I see why we'd want to optimize for the common case
# [04:35] <dael> dbaron: There's the common case and than there's editing and modifying
# [04:35] <dael> hober: If I do a search and replace, it's going to break half the places
# [04:35] <dael> plinss: Only if you're replacing inside a calc.
# [04:35] * Joins: koji (~koji@public.cloak)
# [04:35] <dael> clilley: So it's either you have to use spaces all the time or you can get rid of them sometimes, but you have to remember when.
# [04:36] <dael> clilley: That's what you're against?
# [04:36] <dael> fantasai: Yes. I'm all for optimizing, but I don't want people tripping over themselves
# [04:36] <dael> dbaron: Or you get rid of dashes in units and removing poss of vendor prefixed units.
# [04:36] <fantasai> fantasai: I'm all for optimizing the common cases, but as you transition to more complicated cases, don't want to trip people up.
# [04:36] <dael> TabAtkins: Yes.
# [04:36] <dael> hober: The only unit I know is __qem
# [04:37] <dael> hober: It's not used, but it doesn't trip over this case.
# [04:37] <dael> TabAtkins: Doing so would mean we can't later allow user spec demensions b/c they start is --
# [04:37] <hober> s/It's not used/It's only used in the WebKit UA stylesheet/
# [04:37] <dael> TabAtkins: Or they can start with a dash, but not contain inside
# [04:37] <dael> zcorpan: If we change as dimensions, it wouldn't solve the keyword
# [04:37] <dael> TabAtkins: It wouldn't solve several cases
# [04:38] <dael> dbaron: But you can do it the way you desc where the -adder function is calc is a - only
# [04:38] <dael> TabAtkins: It would be problematic, still, with vendor prefix.
# [04:38] <plinss> s/-adder/-attr/
# [04:38] <dael> tabatkins: like we couldn't do -webkit addr unless we add special cases.
# [04:38] <dael> TabAtkins: And keyword-keyword
# [04:39] <hober> s/ addr/-attr()/
# [04:39] <dael> zcorpan: On the flip side if we want to req spaces, the current spec doesn't do that
# [04:39] <dael> dbaron: Current req spaces around + and -, but not the others because we didn't need to
# [04:39] <dael> dbaron: So there's a grouping that makes sense with mult and division
# [04:40] <dael> fantasai: You can certainly put spaces everywhere.
# [04:40] <fantasai> dbaron^: Mult/div bind tighter than add/subtrack
# [04:40] <dael> zcorpan: So the search and replace arguement, does that apply?
# [04:40] <dael> TabAtkins: Well, if you're doing * to / you'll break way more
# [04:41] <dbaron> calc(auto−min-content)
# [04:41] <dael> zcorpan: I can see that. On the other hand if you're first used to multi and than you move to plus and you need to add spaces
# [04:41] <dael> TabAtkins: I agree it's confusing.
# [04:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [04:41] <dael> TabAtkins: There's author feedback saying the spaces are confusing
# [04:41] <dael> hober: So we have a compat constraint and there's existing content. To address author confusion we can't add spaces everywhere b/c compat
# [04:41] <dael> hober: The other way is to make the white space always optional
# [04:42] <dael> TabAtkins: That's literally impossible, though.
# [04:42] <dael> hober: So if neither extreme is possible, which do we move toward? It seems optional as much as possible is better.
# [04:42] <dael> fantasai: Since we have to pick the middle, we can decide our goal is get as close as possible to one, or to pick a logical line that makes it easy to understand.
# [04:43] <dael> fantasai: I think that we're at a logical place.
# [04:43] <dael> glaz: I think the discussion is to make authors can use it.
# [04:43] <dael> hober: I agree, but I think you're point is different
# [04:43] <fantasai> fantasai: It's not as close to our ideal as possible, but we can't get all the way there, and what we have is easier to understand and remember
# [04:43] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [04:43] <fantasai> s/there/there anyway/
# [04:43] <dael> TabAtkins: fantasai is saying that current spec is clear and easy to understand but the proposal requires knowing and remembering a lot more which is worse.
# [04:43] <dael> TabAtkins: You have to understand why something does/doesn't make sense
# [04:44] <dael> fantasai: If we keep it where it is, you don't need to understand parsing, you just have to remember + and - need space
# [04:44] <dael> TabAtkins: The rule becomes you need space around keywords which I think is reasonable
# [04:44] <dael> fantasai: That is, but it's a more complex thing to understand and a more complex line.
# [04:44] <dael> fantasai: If we try and get closer to where authors want, we can't get there and the solution would be worse
# [04:45] * sgalineau ...maybe we could use tabs?
# [04:45] <dael> TabAtkins: I can agree with both.
# [04:45] <dael> zcorpan: I don't understand why we can't always need space
# [04:45] <dael> TabAtkins: Too many things already don't require the spaces.
# [04:45] * astearns no need to use spaces, just use zero-width nonbreaking spaces
# [04:45] <fantasai> s/many things/much existing content/
# [04:45] <dael> TabAtkins: There are things out there in the world that we can't get rid of.
# [04:45] <fantasai> s/require/use/
# [04:46] <dael> TabAtkins: I don't know how to resolve this because I can't decide. Someone else needs to decide this.
# [04:46] <dael> glaz: I'm ready for straw poll
# [04:46] <dael> TabAtkins: Options are no change or this
# [04:46] <dael> hober: So going back to authors needs, I'd like the poll to be what authors need to remember
# [04:46] <dael> TabAtkins: option 1) Space around - and + all the time
# [04:46] * Quits: kyounga (~kyounga@public.cloak) (Ping timeout: 180 seconds)
# [04:47] <dbaron> today's new smiley face: -−-
# [04:47] <dael> TabAtkins: options 2) Space around - when using functions and keywords
# [04:48] <dael> glaz: so before the poll, what is current?
# [04:48] * astearns tab fills the whiteboard with the explanation of option 2
# [04:48] <dael> TabAtkins: Option 1
# [04:48] <dael> glaz: So is there a third option before we do the poll?
# [04:48] <dael> dbaron: In 2 you're saying that when you're using functions in keywords, there has to be a space around just the - sign and are you saying the space hast o be on the side of the minus sign?
# [04:48] <dael> TabAtkins: yes
# [04:49] <dael> glaz: let's do the poll
# [04:49] <dael> clilley: 1
# [04:49] <dael> Rossen_: i
# [04:49] <dael> dbaron: 1
# [04:49] <dbaron> glaz: 1
# [04:49] <dael> glenn abs
# [04:49] <dael> jet: abs
# [04:49] <dael> koji: 1
# [04:49] <krit> abstain
# [04:49] <dael> koji : abs
# [04:49] <dael> fantasai: 1
# [04:50] <dael> zcorpan: 2
# [04:50] <dael> arronei: 1
# [04:50] * plh Space: the final frontier. These are the voyages of the CSS WG. Its two-year charter: to explore strange new syntaxes, to seek out new properties and new syntaxes, to boldly go where no web engine has gone before.
# [04:50] <astearns> s/arronei/astearns/
# [04:50] <dael> andre: abs
# [04:50] <liam> 1 because any option that needs a full whiteboard to explain it must be bad :-)
# [04:50] <dael> addneilson: 1
# [04:50] <dael> bruno: 1
# [04:50] <dael> dongwoo: 1
# [04:50] <dael> TabAtkins: abs
# [04:50] <dael> hober: 2
# [04:50] <dael> plh: abs
# [04:50] <dael> shans_: abs
# [04:51] <dael> shinuyu: abs
# [04:51] <dael> dauwhe: abs
# [04:51] <dael> plinss: abs
# [04:51] <dael> TabAtkins: So it seems clear for 1
# [04:51] <dael> hober: I can live
# [04:51] <dael> glaz: zcorpan can you live with 1?
# [04:51] <dael> zcorpan: I can live with 1. I think SimonSapin said 2 on the ML
# [04:51] <myakura> s/shinuyu/shinyu/
# [04:52] <dael> hober: The quick case for 2 is that it would be easy for the web inspector to highlight the odd cases with this problem.
# [04:52] <dael> hober: It's unusual to encounter this
# [04:52] <dbaron> I don't feel that strongly either; I'd be ok with 2.
# [04:52] <dael> TabAtkins: For now. When we allow keywords it'll be more
# [04:52] <dael> hober: You add more than you run into this problem.
# [04:52] <dael> glaz: I was looking for something more usable and be able to do things as we say it.
# [04:53] <dael> hober: 2 is as close
# [04:53] <dael> glaz: But 2 makes it wierd
# [04:53] <dael> RESOLVED: No change
# [04:53] <dael> TabAtkins: There's more issues in values and units
# [04:53] <dael> glaz: That's this afternoon
# [04:53] <dael> glaz: Image values now
# [04:53] <dael> plinss: It's cropping features from image
# [04:53] <fantasai> Topic: Image Values
# [04:54] <astearns> s/cropping/dropping/
# [04:54] <dael> TabAtkins: Currenly image function is image(features, image*, color) this is roughly the grammar
# [04:54] <dael> fantasai: I don't think we have features
# [04:54] <dael> dbaron: ltr?
# [04:54] <dael> TabAtkins: That's next level.
# [04:55] <dael> TabAtkins: It does image fallback and does each one in turn. If it can't do an image it goes to the next one. If it can't it does a solid fallback image
# [04:55] <dael> TabAtkins: This function will also be how we provide additional feaures later.
# [04:55] <dael> hober: What is the interinic size of image when you do fallback?
# [04:55] <dael> fantasai: It doesn't have one
# [04:56] <dael> TabAtkins: problem now is we also have image-set in level 4 which is image-set([image resolution]#)
# [04:56] <dael> TabAtkins: this doens't fallback, it jsut sleectes based on resolution
# [04:56] <dael> TabAtkins: So now we have two types of fallback in ways that don't work well together.
# [04:56] <dael> TabAtkins: You can't do what you want even if you combine these together.
# [04:56] <dael> krit: image-set takes a function or type, right?
# [04:57] <dael> TabAtkins: Yes, but it doesn't work the way you want
# [04:57] <dael> krit: You can't have for each resolution?
# [04:57] <dael> TabAtkins: You can't in image size five both
# [04:57] <dael> hober: Because you can't make the 1px work with a 2px
# [04:57] <dael> dbaron: Is there a usecase for people having 1x and 2x
# [04:57] <dael> TabAtkins: 404ing might be the case.
# [04:58] <dael> TabAtkins: Image's currently is half format, half network error protection
# [04:58] <dael> TabAtkins: Since this was solving in two ways
# [04:58] <clilley> s/2x/2x with different aspect ratios/
# [04:58] <dael> hober: These functions have differen purposes. image-set doesn't have a fallback
# [04:58] <dbaron> s/1x and 2x in different formats/
# [04:58] <dael> hober: It isn't trying to solve fallback at all
# [04:58] <dbaron> s/1x and 2x/1x and 2x in different formats/
# [04:58] <dael> TabAtkins: You're saying pick a version based on this url, but they decide how to choose differently
# [04:59] <dael> hober: If it was called fallback it would be clearer
# [04:59] <dael> TabAtkins: We have two pick an image from this set, but they don't work the same
# [04:59] <dael> krit: They have two purposes
# [04:59] <dael> TabAtkins: They don't that's what I said
# [04:59] <dael> hober: Youc an use image-set for an image function
# [04:59] <dael> TabAtkins: You can't do that at all
# [04:59] <hober> image(image-set(a 2x, b 1x), b, black)
# [05:00] <dael> TabAtkins: Any way you can write it only works in one direction.
# [05:00] <krit> image-set(image(list) 2x, image(list) 1x)
# [05:00] <dael> TabAtkins: That only works if you're falling back in that way.
# [05:00] <SteveZ> Please do not do CSS Text this afternoon late. That does not work for Californians
# [05:00] <dael> TabAtkins: What if the browser chooses b and it's 404ing so let's load a, you can't
# [05:00] <dael> TabAtkins: You can only pick an exact path. You can't say pick the best of these.
# [05:01] <dael> krit: For each image set condition you have one list of images that apply to this condition. Why wouldn't that work
# [05:01] <dael> TabAtkins: That's different fallback.
# [05:01] <dael> TabAtkins: So what he put is valid, but it doesn't let you provide a set of images and provide a res. that works
# [05:01] <dael> hober: It would be great if we had a image function that took a bunch of information and always magically did the right thing
# [05:01] <dael> TabAtkins: I think we can, but a combination of image and image-set isn't right
# [05:02] <dael> TabAtkins: So I say we make some of image option and than later creat e a propety that allows for a do what I mean approach
# [05:02] <dael> krit: That works in the begining, but what about the future
# [05:02] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [05:02] <dael> TabAtkins: We don't want one thing doing everything. This already does fallback color and adding full fallback makes things too complex
# [05:03] <dael> hober: What's the compat risk of not allowing 0 fallback
# [05:03] <dael> TabAtkins: non. no one uses it
# [05:03] <astearns> s/uses/implements/
# [05:03] <dael> hober: 2nd I like seperating fallback from other features, but I'm not crazy about squeezing into image-set
# [05:04] <dael> hober: Suppose we had a fallback that takes a seq of arguements and either shared micro-syntax or use image-set and when you do so it imposes an order
# [05:04] <dael> TabAtkins: That's how I want to handle this
# [05:04] <dael> hober: What I like is it doesn't make micro syntax complex.
# [05:04] <myakura> s/jsut sleectes/just/selects/
# [05:04] <dael> hober: It's a bit magical because it imposes and order that wasn't there. That's wierd, but not that weird.
# [05:04] <dael> hober: If you're using fallback, you want it
# [05:05] <dael> TabAtkins: To check, you have a fallback and you load an image set and it still tries to load the best, but if it fails it falls back
# [05:05] <dael> hober: Yes, I image the check would be the same, but the second ordering is used if there's a failure
# [05:05] <dbaron> Tab writes "fallback(imageset(a 1x, b 2x))"
# [05:05] <dael> krit: With image function, what do you suggest now?
# [05:05] <dael> TabAtkins: Drop the fallback. In level 3 it would be an image and color
# [05:06] <dael> dbaron: You're preserving fallback from imge to color
# [05:06] <dael> TabAtkins: yes.
# [05:06] <dael> dbaron: It's a feature we had previously defered and brought back
# [05:06] <dbaron> (from background-color taking 2 values)
# [05:06] <dael> hober: If we don't have impl so no compat risk, there's also no risk in changing the name of image. It seems very generic.
# [05:06] <dael> hober: It's also providing additional information and a color. It's the odd man out.
# [05:07] <dael> hober: I can't tell from function name what it does
# [05:07] <dael> dbaron: There's other things we wanted to tie like media fragments. We also have a proposal to tie it to handling x-if
# [05:07] <dael> dbaron: Basically, saying that something should have its x-if interpreted.
# [05:08] <dael> dbaron: So we're designing the moden way to handle an image, but we've tied it to optins
# [05:08] <dael> TabAtkins: That's why we have a generic name
# [05:08] <clilley> s/x-if/EXIF/g
# [05:08] <dael> hober: And that's why there's no impl. You need to have the add ins
# [05:08] <dael> TabAtkins: You don't. You have to either understand media fragments or treat as broken.
# [05:08] <clilley> http://en.wikipedia.org/wiki/Exchangeable_image_file_format
# [05:08] <dael> TabAtkins: Minimun is url and fallback color
# [05:08] <dael> krit: People often want image not because fallback, but because you can say a color.
# [05:09] <dael> TabAtkins: We're keeping that.
# [05:09] <dael> krit: That's why I was concerned. I'm supportive of limiting image functions
# [05:09] * glazou lunch is ready
# [05:09] <dael> TabAtkins: That's good since you were opposing earlier
# [05:09] <dael> zcorpan: So do we need the fallback function? Do we need to fallback?
# [05:09] <dael> hober: I think it's useful and I like that it's generic and sep. You can use it for something liek a font case
# [05:10] <dael> TabAtkins: There's the transient image issues, but there's also for unsupported types
# [05:10] <dael> zcorpan: Then you'd want to add the type up front
# [05:10] <dael> TabAtkins: Yes. I was waiting on a decision
# [05:10] <dael> zcorpan: But for type fallback we don't need netowkr fallback
# [05:10] <dael> hober: It's true they're different
# [05:11] <dael> TabAtkins: Technically, but to authors they're the same. You can omit type and network would still work.
# [05:11] <dael> TabAtkins: That's why they should be together. In terms of things authors would use, they're the same.
# [05:11] <dael> TabAtkins: Were you suggesting we only keep type fallback?
# [05:11] <dael> zcorpan: Yes, I think network has complexity and authors need it
# [05:11] <dael> hober: We don't have that elsewhere.
# [05:11] <dael> TabAtkins: The image function does do network fallback. If something happens you get a solid color
# [05:12] <dael> zcorpan: Yes, but solid color doesn't get you another network item
# [05:12] <dael> TabAtkins: I've kinda added type fallback to image-set. I want to make it similar to picture.
# [05:12] <dael> TabAtkins: We can always jsut have image-set feature equvellent to picture and we can decide on full network fallback later.
# [05:12] <dael> TabAtkins: So are theyre obj to this proposal?
# [05:13] <dael> TabAtkins: The proposal is we drop fallback from image except fallback to color. Later we introduce that fallback as an explicit function.
# [05:13] <dael> clilley: Is that better seperate?
# [05:13] * krit picture(<source src="image1.png"><source src="image1.jpg>)
# [05:13] <dael> hober: Suppose in the future you define it...
# [05:14] <dael> TabAtkins: You still want to just say load the image you want in image-set without extra requests, but with the option to say I do waht to budon the network
# [05:14] <dael> hober: Sounded sep. First was to drop.
# [05:14] <dael> TabAtkins: Well, it's to drop and add later
# [05:14] <dael> RESOLVED: we drop fallback from image except fallback to color. Later we introduce that fallback as an explicit function.
# [05:14] <dael> glaz: We have 2 thins on image values. dropping image resolution and orientation.
# [05:15] <dael> TabAtkins: We can do taht after lunch
# [05:15] <dael> krit: Can someone update the agenda?
# [05:15] <dael> TabAtkins: What's on there is what we have.
# [05:15] <dael> dbaron: And there's a large number of time constrants for people calling in.
# [05:15] * liam suggests multiple lunch breaks :-)
# [05:15] <zcorpan> s/authors need it/authors don't need it/
# [05:15] <dael> glaz: So I suggest lunch break.
# [05:15] <dael> [ break = lunch]
# [05:16] <SteveZ> I repeat: please do not do CSS Text 3 late this afternoon; that is in hospitiable to Californians and Quebecious [Spelling?]
# [05:20] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [05:20] <fantasai> SteveZ: I got the message, will pass that on
# [05:20] <fantasai> SteveZ: What time would you suggest?
# [05:20] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [05:21] * Quits: jh_hong (~jh_hong@public.cloak) (Ping timeout: 180 seconds)
# [05:22] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [05:23] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:27] * Quits: Jet (~Jet@public.cloak) ("http://www.kiwiirc.com/ - A hand crafted IRC client")
# [05:28] * Quits: kyungtae (~kyungtae@public.cloak) (Ping timeout: 180 seconds)
# [05:33] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [05:41] * Joins: myakura (~myakura@public.cloak)
# [05:46] * Joins: jh_hong (~jh_hong@public.cloak)
# [05:47] * jdaggett wonders who will be the first to cut off tab's tie...
# [05:48] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [05:49] * dauwhe_ rough draft of new initial caps section of css inline at http://dauwhe.github.io/dropcaps/Overview.html
# [05:54] <myakura> tabatkins, you might've missed the closing </pre> in http://dev.w3.org/csswg/css-values/#component-combinators
# [05:54] <TabAtkins> Nah, I like it that way.
# [05:55] <liam> :)
# [05:56] <TabAtkins> Fixed now.
# [05:56] * Quits: lmclister (~lmclister@public.cloak) ("")
# [05:56] <myakura> :)
# [06:02] * Joins: lmclister (~lmclister@public.cloak)
# [06:07] * Joins: kyounga (~kyounga@public.cloak)
# [06:08] * Quits: kangil (~d25fff94@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [06:08] <clilley> @ dauwhe_ can we call then drop initials instead? Not necessarily capitals, even in bicameral scripts
# [06:09] <liam> [yes, drop initials is OK, although there are also raised initials]
# [06:09] * Joins: kangil (~d25fff94@public.cloak)
# [06:10] * Joins: adenilson (~anonymous@public.cloak)
# [06:12] * liam tries google translate and gets vélo excrétion
# [06:18] * Joins: dael (~dael@public.cloak)
# [06:19] <dael> TabAtkins: There's a proposal for auto-applied and to let it just be an HTML thing
# [06:19] <dael> TabAtkins: If we can't, drop everything except what's supported by printers
# [06:19] * dauwhe_ clilley: I believe my pre-ED uses the term "drop initials" throughout, although I like "versals" :)
# [06:19] <dael> clilley: That's odd since HTML isn't the only place that brings up images
# [06:19] <dael> dbaron: You do it in a different way for CSS.
# [06:19] <dael> TabAtkins: In the image function
# [06:19] <dael> clilley: I don't like building a gap
# [06:20] <dael> TabAtkins: The reason it was thought weird is the only thing that should be applied is use the native oreientation.
# [06:20] <dael> TabAtkins: The only thing we have in this level is just to use the one oreintation
# [06:20] <dael> TabAtkins: The question is do we drop this or just keep what's needed for printers.
# [06:20] <dael> hober: Do you mean in the print screen
# [06:20] <dael> TabAtkins: no
# [06:20] <dael> clilley: Is this XHTML print?
# [06:21] <dael> fantasai: We have a CSS profile that's referenced by printers/scanners that we can't remove, but we can obsolute it in the performance notes saying that it's not required
# [06:21] <zcorpan> s/CSS profile/CSS print profile/
# [06:21] <fantasai> s/obsolute/obsolete/
# [06:21] <dael> clilley: That CSS thing the XHTML print were coupled. Can't we get XHTML print to have this attr?
# [06:21] <dael> fantasai: I don't think that's good
# [06:22] <dael> fantasai: The XHTML print stuff is to allow printers to create templates from themselves. This is old.
# [06:22] * Joins: murakami (~murakami@public.cloak)
# [06:22] <dael> fantasai: I don't think anyone wants to work on that. We'll do the minimum to not break anything and that's to say here's the spec, it's obsolete. Don't implement it
# [06:22] * Joins: Rossen_ (~Rossen@public.cloak)
# [06:22] <dael> clilley: So the spec that referenced it, what stage?
# [06:22] <dael> fantasai: I don't know
# [06:23] <dael> clilley: It has a forward reference to something we haven't spec'ed
# [06:23] <dael> fantasai: It was, but it was in paged media and we pulled it out.
# [06:23] <dael> fantasai: paged media hit CR but we pulled it back
# [06:23] <dael> clilley: Well that's the weasel out is we're saying people aren't depending on it.
# [06:23] <dael> fantasai: There are, but they're not on the web. We say if you're on the web, this isn't useful for you
# [06:24] <dael> zcorpan: Do we need to have it at all?
# [06:24] <dael> fantasai: They are impl it, they're fine with what's there now. They're satisfied
# [06:24] <dael> clilley: They were fine with a non-standard thing. What'st he benefit of putting in our own spec
# [06:24] <dael> fantasai: Well we pulled it out and put it here so it hast o be somewhere.
# [06:24] <SimonSapin> (what’s the topic?)
# [06:24] <dael> clilley: Right, I'm saying they were using something old
# [06:25] <dael> fantasai: Well, we moved it and didn't want to break the links.
# [06:25] <dael> clilley: We moved it because we thought we wanted it and don't now
# [06:25] <dael> hober: If we don't want it and they do, why don't they define it.
# [06:25] <dael> fantasai: All we need to do is put an obsolete notice
# [06:25] <dael> hober: But we don't need it at all because they're using it and don't need us to have it
# [06:26] <dael> fantasai: I don't want to break people. Leave it with a note in 3 and remove it from 4.
# [06:26] <dael> TabAtkins: Who is broke?
# [06:26] <dael> fantasai: This is referenced.
# [06:26] <dael> fantasai: I don't see the problem with leaving and marking
# [06:26] <dael> clilley: Marking or depricating?
# [06:26] <dael> fantasai: Either.
# [06:26] <astearns> s/Marking/Marking obsolete/
# [06:26] <dael> clilley: one says don't do it, the other says everyone should implement it, but we're not using it anymore.
# [06:27] <dael> clilley: I don't want effort into something we don't want.
# [06:27] * dauwhe_ sounds like we need RFC 6919
# [06:27] <dael> hober: I'm perfectly happy with fantasai adding a note in the document or whatever
# [06:27] <dael> fantasai: I don't want to break references.
# [06:27] <dael> clilley: Skipping is fine until we're at CR
# [06:27] <dael> hober: But we can define our own criteria saying that obsolete features don't need to be impl
# [06:28] <fantasai> to exit CR
# [06:28] <dael> TabAtkins: That means I have to add things to bikeshead.
# [06:28] <dael> hober: Other groups have custom criterea already.
# [06:28] * Joins: koji (~koji@public.cloak)
# [06:29] <dael> TabAtkins: Okay. Sounds good. I will cut out everything not defined, remove my additions, move to an appendix, call it obsolte and make a custom setting for that
# [06:29] <dael> plh: Is it normative or informative
# [06:29] <plinss> s/custom setting/custom CR exit criteria/
# [06:29] <dael> TabAtkins: It'll be normative. web browsers must not support it and we don't have to test it to exit CR
# [06:29] <dael> glaz: No obj?
# [06:29] <dael> RESOLVED above plan
# [06:30] <dael> hober: Since clilley seems interested, it might be worth considering the eneral. Do people like that specs that define obsolete features don't need to test those features to exit CR
# [06:30] <dael> hober: So can we resolve now?
# [06:30] <dael> glaz: We just put it no the radar. We define our own criterea.
# [06:31] * astearns http://tools.ietf.org/html/rfc6919#section-3
# [06:31] <dael> glaz: It's basically a generalization of what we said.
# [06:31] <dael> dbaron: So what is the name of this HTML attr?
# [06:31] <glazou> s/no the/on the
# [06:31] * fantasai doesn't think 6919 applies here
# [06:31] <dael> TabAtkins: I have to look. I saw it in a recent bug.
# [06:32] <dael> RESOLVED: specs that define obsolete features don't need to test those features to exit CR
# [06:32] <dael> dbaron: I want to make sure this really happens b/c we impl the image orientation
# [06:32] <dael> dbaron: I'm okay with changing it, but we're not going to remove image orentation until the HTML exists.
# [06:33] <dael> dbaron: If we leave it too long we may not be able to remove completely
# [06:33] <dael> TabAtkins: Let me ping hixie and get him to put it in.
# [06:33] <dael> dbaron: What I need to know if the attr name and it's not in the spec
# [06:33] <hober> Just making sure it gets minuted that obsolete != deprecated this resolution is for features that should not be implemented in browser engines
# [06:33] <dael> glaz: You can't say you might obj in the future.
# [06:33] <dael> plinss: Well, you can't say you may have objected in the past.
# [06:33] <dael> glaz: I don't want to make life hard, I want this to be simple now
# [06:34] <dael> hober: It's always been the case that we can revisit issues if new information arrises.
# [06:34] <dael> clilley: And in this case if Hixie gets back to TabAtkins and it's not there we need to revisit.
# [06:34] <dael> dbaron: I think it'll be fine, I'm just saying that it might not be.
# [06:34] * Joins: Kyounga_ (~Kyounga@public.cloak)
# [06:35] <dael> TabAtkins: Okay.
# [06:35] <dael> TabAtkins: Next is two value image resolution.
# [06:35] <dael> TabAtkins: SimonSapin painted out that some formats allow seperate X and Y resolutions.
# [06:35] <dael> TabAtkins: Esp. TIFF and technically SVG.
# [06:35] * TabAtkins http://lists.w3.org/Archives/Public/www-style/2013Jul/0568.html
# [06:35] <dael> hober: That never went through
# [06:35] * liam used to work with laser printers that had hexagonal pixels
# [06:35] <dael> TabAtkins: Oh.
# [06:35] <dael> clilley: I think TIFF is for geoTiff.
# [06:36] <liam> [ccitt group 4 fax can have different x & y res too]
# [06:36] * glazou unmuted krit again
# [06:36] <dael> TabAtkins: There's two resonable answers. One is keep image resolution as spec and when provided with non-square pixals, take the vertical and adjust to create square px
# [06:36] <dael> clilley: So it would have to resample the image.
# [06:36] <dael> TabAtkins: Yes.
# [06:36] <dael> dbaron: So you're chaning aspect ratio
# [06:37] <dael> TabAtkins: Transfering from non-square and aspect ratio into square aspect ratio
# [06:37] <dael> TabAtkins: Asummer there's non-square px.
# [06:37] * Joins: silentobserver (~silentobserver@public.cloak)
# [06:37] * Parts: silentobserver (~silentobserver@public.cloak)
# [06:37] <dael> TabAtkins: We'd say whatever the resolution is we'd set it to the height and the image keeps same size.
# [06:37] * Joins: silentobserver (~silentobserver@public.cloak)
# [06:38] <dael> TabAtkins: That's one option. The other is we add 2nd option value to allow it to hand non-square and define how that works with normal
# [06:38] <dael> hober: So the first possibility req authors to do what?
# [06:38] <dael> TabAtkins: nothing
# [06:38] <dael> hober: And the second would allow a new thing that would require impl.
# [06:38] <dael> TabAtkins: Someone has to write down what's there now
# [06:38] <dael> clilley: But that's what it has to do now.
# [06:38] <dael> TabAtkins: Or ignore it completely
# [06:39] <dael> hober: So where is the burdon of the work
# [06:39] <dael> TabAtkins: Neither case on authors. Someone has to write it in either case.
# [06:39] <dael> TabAtkins: So do we care about adding the feature?
# [06:39] <dael> dbaron: For what it's worth I've had monitors with non-square pixels.
# [06:39] * Joins: kyungtae (~kyungtae@public.cloak)
# [06:39] <dael> TabAtkins: Those just map one square to one non-square
# [06:40] <dael> hober: Seems we need a use case to justify this.
# [06:40] <dael> hober: What I've heard is there are small number of odd cases and we don't need to add for that
# [06:40] <dael> dbaron: I thin there was confusion on the wording.
# [06:40] <dael> dbaron: I think the proposal should be defined so you end up witht he size you want and you shouldn't talk about super samiling.
# [06:41] <dael> dbaron: You should assume there would be passes at image scaling, but we shouldn't say there has to be 2 passes
# [06:41] <clilley> I was wrong, its TIFF from Faxes https://forums.adobe.com/message/3843629
# [06:41] <dbaron> s/passes at/a pass of/
# [06:41] * Quits: kyounga (~kyounga@public.cloak) (Ping timeout: 180 seconds)
# [06:41] <dael> TabAtkins: So in this case it's spec as 2x2 and wants to be 2x4 and we say that's okay.
# [06:41] <dbaron> s/samiling/sampling/
# [06:41] <clilley> https://discussions.apple.com/thread/2627401
# [06:41] <dael> zcorpan: So we say the size of the pixal are whatever that one dimension is
# [06:41] <dael> TabAtkins: I prefer one dimension
# [06:41] <dael> hober: So if you pick width...
# [06:42] <Rossen_> q
# [06:42] <Rossen_> q+
# [06:42] * Zakim sees Rossen_ on the speaker queue
# [06:42] <dael> clilley: It's not geoTIFF it's TIFF from faxes. It's going away but more wide spread.
# [06:42] <glazou> Zakim, ack Rossen_
# [06:42] <Zakim> I see no one on the speaker queue
# [06:42] <dael> Rossen_: Quic question. What is the intensic size of that image and what do you see in CSS
# [06:42] <dael> TabAtkins: The size is the number px in that dimension by the size of those.
# [06:43] <clilley> "A typical fax machine has a default (Standard) horizontal resolution of 8 pels/mm, which is roughly 204 pels per inch (or 204dpi). Some faxes are also capable of increasing the horizontal res to 16 pels/mm - roughly 400dpi."
# [06:43] <dael> Rossen_: So in your ex it's 2x2
# [06:43] <dael> TabAtkins: It'll be treated as 2x4
# [06:43] <dael> Rossen_: So you're saying intrensic size is on the x axis
# [06:43] <dael> TabAtkins: This will be pixels in the x direction and their size
# [06:43] <dael> zcorpan: But why the width instead of using the smaller?
# [06:43] <dael> TabAtkins: Seems easier
# [06:44] <dael> zcorpan: The image could get smaller than intended
# [06:44] <dael> TabAtkins: Not smaller, blurrier
# [06:44] <dael> hober: So we need to say we squaify the image
# [06:44] <dael> hober: But if we don't say how we can defer to impl
# [06:44] <dael> TabAtkins: WE still need to say it's interop
# [06:44] <dael> clilley: [Reads IRC comments]
# [06:44] <dael> TabAtkins: So it ends up in tall case
# [06:45] <dael> hober: So if we do width, the fax case will look better.
# [06:45] <dael> TabAtkins: Yes.
# [06:45] <dael> zcorpan: I didn't follow the dimensions
# [06:45] <dael> TabAtkins: Normally internsic is px x/y. This is px by size of px
# [06:45] <dael> zcorpan: I think the resulting size should be the same but flipped
# [06:45] <dael> TabAtkins: No.
# [06:45] * clilley TIFF stands for Thousands of Incompatible File Formats
# [06:46] <dael> zcorpan: I want the one to resolve to 2 x 4 because the other is 4 x 2
# [06:46] <dael> TabAtkins: It is really what dimensionn to you apply image resolution to
# [06:46] <dael> hober: Let me try. There are two dimensions. One of them is more interesting.
# [06:46] * dbaron thousands of incompatible tagged image file formats?
# [06:47] <dael> hober: In an information way, there's more going on. So if you break up the other dimension you're not losing quality
# [06:47] <dael> TabAtkins: zcorpan is suggesting to never break up image quality
# [06:47] <dael> hober: So both are easy to impl, one is slightly more complex.
# [06:48] <dael> zcorpan: I think HTML spec deals with this for video. I haven't been able to pull it up, but I think it uses smaller dimension
# [06:48] <dael> TabAtkins: Interesting.
# [06:48] <dael> plinss: non-square is more common in video
# [06:48] <dael> TabAtkins: So that is what it does, use the smaller?
# [06:48] <dael> hober: Can we resolve now to match HTML?
# [06:48] <dael> TabAtkins: That's fine.
# [06:49] <dael> TabAtkins: So, squaify the pixels...
# [06:49] <dael> zcorpan: [reads the spec text]
# [06:49] <dael> zcorpan: so if you have the right case, you stretch.
# [06:49] <dael> TabAtkins: So it's making sure you never lose information.
# [06:50] <dael> TabAtkins: So apply resolution to the smaller pixel size.
# [06:50] <dael> clilley: Sample up not down
# [06:50] <zcorpan> "If an anamorphic format does not define how to apply the aspect ratio to the video data's dimensions to obtain the "correct" dimensions, then the user agent must apply the ratio by increasing one dimension and leaving the other unchanged." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-video-intrinsic-width
# [06:50] <dael> TabAtkins: That's fine.
# [06:50] <dael> clilley: I found two more use cases. One is some video callbacks, the other is space imaging using scan.
# [06:50] <dbaron> s/callbacks/formats/
# [06:51] <liam> [many flatbed scanner devices can also generate images with different x and y resolutions - usually in TIFF]
# [06:51] <clilley> linescan Narrow Angle Camera images
# [06:51] <dael> TabAtkins: proposed res is keep resolution with a single value and apply that value to the smaller of the two pixel dimensions. Then treat it like it has square pixels while maintining image aspect ratio
# [06:51] <dael> hober: Can you coordinate that with Ian to defer to HTML?
# [06:51] <dael> TabAtkins: Yes.
# [06:51] * dbaron should discuss the old geostationary weather satellites (e.g., GOES-7 and earlier, I think) with clilley
# [06:51] <dael> TabAtkins: Though it sounds the HTML video turns the pixels square.
# [06:52] <zcorpan> s/maintining/maintaining/
# [06:52] <dael> TabAtkins: I can think on this a bit.
# [06:52] <dael> clilley: What do you mean turns them square. You mean distorts aspect ratio?
# [06:52] <dael> plinss: sometimes you want to do that in video.
# [06:52] <dael> hober: I'm hoping for a default that can be in UA sheet and matching HTML video.
# [06:53] <clilley> for video. it isn't appropriate for those fax and scanner tiffs
# [06:53] <dael> adenilson: I have a question. The description is for both, isn't it resampling, but favoring the smaller resolution axis?
# [06:53] <dael> TabAtkins: It has to be harder because you can't just take the smaller size because you want to make sure elements stay wide/tall
# [06:53] <dael> adenilson: So we won't resample in the same way both axis.
# [06:53] <dael> TabAtkins: yes
# [06:54] <dael> adenilson: So it won't be semetric, it'll be asemetric. If I recall a similar stategy in a misnathop sampling
# [06:54] <dael> adenilson: So we can say in such a case we can go with that sampling
# [06:54] <dael> tab
# [06:54] <dael> yes
# [06:54] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [06:54] <clilley> s/misanthrop/anisotropic/
# [06:54] <dael> adenilson: If is reqall there's a mathematical formula
# [06:54] <dael> TabAtkins: I don't know, but I'm happy to write something up and have you suggest better temrs
# [06:55] <clilley> s/misnathop/anisotropic/
# [06:55] <dael> TabAtkins: I need to publish a new thing for Images. These are the big changes. Would we be okay with a quick 3 week LC to CR cycle?
# [06:55] <dael> fantasai: I think we should fold in all the changes.
# [06:55] <dael> TabAtkins: After I edit
# [06:55] <dael> fantasai: Let's do that and give a week on www-style for people to notice changes.
# [06:55] <dael> dbaron: What'st he timeline fort he new w3c process.
# [06:56] <dael> clilley: 6 months to a year and there's an odd transisiton period.
# [06:56] <dael> plh: And the reason is that new specs will reach LC for a short period
# [06:56] <dael> TabAtkins: That's in most cases, yes.
# [06:56] <dael> TabAtkins: So it's a bit more busy work, but we'll cycle quick. In two weeks I'll ask for a LC
# [06:57] <dael> TabAtkins: So please have objections ready.
# [06:57] <dael> Topic: Values and Units
# [06:57] <dael> TabAtkins: How to handle custom identifiers
# [06:57] <dael> fantasai: Didn't we say this was wording
# [06:57] <dael> TabAtkins: no.
# [06:58] <dael> TabAtkins: custom-idents are used in ways where they can't be distinguished just on position
# [06:58] <dael> TabAtkins: ex animation name or list style types
# [06:58] <dael> TabAtkins: You can provide an animation name backwarkds or you can do a list style called inside.
# [06:58] <dael> TabAtkins: How to handle those is something we want to establish genericly
# [06:58] <dael> TabAtkins: There's three cases. Some where custom-iidents are completely seperated
# [06:59] <dael> TabAtkins: examples are line names in grid shorthands
# [06:59] * Zakim dael, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [06:59] <SimonSapin> ("completely separated…" sometimes)
# [06:59] <dael> TabAtkins: You can say for example 10px(foo)20px(bar)
# [06:59] <dael> TabAtkins: The only rule is that they can't be global words.
# [06:59] <dael> TabAtkins: There's nothing else they can be ambiguous with.
# [06:59] * plh notes that new W3C Process could take effect as early as end of June
# [07:00] <dael> TabAtkins: But if you do grid-row: span-foo and that could be potentially weird if you called foo span
# [07:00] * fantasai tosses some spaces around those parens up there
# [07:00] <fantasai> s/span-foo/span foo/
# [07:00] <dael> TabAtkins: This could be weird, not ambigious because there's strict wording.
# [07:00] * dbaron is waiting for buffalo buffalo buffalo buffalo buffalo buffalo buffalo in CSS
# [07:00] <dael> TabAtkins: So because of positioning it's not technically ambigous
# [07:01] <fantasai> [Tab edits s/foo/span/ to make the example more illustrative]
# [07:01] <dael> TabAtkins: The harder case is @counter-style inside {...} and later say list-style: inside url()
# [07:01] <fantasai> TabAtkins^: grid-row: span span 2;
# [07:01] * fantasai that goes above the ambiguous line
# [07:01] <dael> TabAtkins: What option does this mean?
# [07:02] <dael> TabAtkins: It's not ambigous if you say list-style-type: inside
# [07:02] <dael> TabAtkins: Shorthand magic can move this into a prop where it's ambigous
# [07:02] <dael> TabAtkins: There's two options. We take the closure of any shorthands that may appear in a value and dsiallow them.
# [07:02] <dael> TabAtkins: You could still use counter-style inside in counter where it's ambigous
# [07:03] <dael> TabAtkins: The other option is to let it say and have generic handling rules. We have those and we could use those, even though they're not great
# [07:03] <dael> TabAtkins: I believe animation handling rules are you look for a keyword that matches all the names and if you can't find one you use the last one.
# [07:03] * hober http://w3cmemes.tumblr.com/post/86185680362/span-grid-def-rows-10px-span-20px-span
# [07:04] <dael> dbaron: I think it matters what you've used values for. You can say animation backwards backwads
# [07:04] * Joins: adenilson (~anonymous@public.cloak)
# [07:04] <dael> dbaron: Or forward backwards. I think it says that the first value since you don't have a direction it's a direction. And since you have a drection backwards is your animation name
# [07:04] <dael> TabAtkins: In the related case of forwards infinate..
# [07:04] * fantasai hopes we are consistent in the use of plurals for all forwards and backwards in CSS
# [07:04] <dael> dbaron: In that case forward is direction and infinate is...??
# [07:05] * hober that would be awfully forward-looking of us, fantasai
# [07:05] <dael> TabAtkins: But wouldn't that be invalid?
# [07:05] <dael> dbaron: Maybe
# [07:05] * hober forwards-looking, sorry
# [07:05] <dael> TabAtkins: I'm not sure what the spec requires.
# [07:05] <dael> dbaron: No, it doesn't. Maybe it should
# [07:05] <dael> TabAtkins: It should. the property doesn't define anything without a name
# [07:05] <dael> dbaron: Well it's none.
# [07:05] <dael> astearns: It says if ambigous you can't interpret as none
# [07:06] <dael> dbaron: [reads example 4[] That's seriealiztion
# [07:06] * fantasai nope http://www.w3.org/TR/css3-marquee/#the-marquee-direction
# [07:06] <dael> TabAtkins: If none if the list of animation names, that's fine.
# [07:06] <dael> dbaron: None is a value of amination fill mode.
# [07:06] <dael> dbaron: So you can have none in the animation name properties
# [07:06] <glazou> hober: I think Rossen_ just sent to the private list a nice photo AND legend for a meme
# [07:06] <dael> dbaron: Even better, non is the value of another value in animation shorthand
# [07:06] * Zakim dael, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [07:06] <dael> TabAtkins: And do we diambiguate that?
# [07:07] <clilley> zakim, get a life :)
# [07:07] <Zakim> I'm glad that smiley is there, clilley
# [07:07] <dael> dbaron: I know what I would write...[reads spec]
# [07:07] <dael> dbaron: So it doesn't explain forwards backwards.
# [07:07] <dael> TabAtkins: So the animation: fowards backwards is weird
# [07:07] <dael> TabAtkins: Animation in general is weird but I'm okay with it.
# [07:07] <dael> dbaron: I'm not crazy about it. It makes serialization hard.
# [07:08] <dael> TabAtkins: You always have to serialize animation name last.
# [07:08] <dael> TabAtkins: And that makes...
# [07:08] <dael> dbaron: You not only have to serealize last, but you have to serialize anything that takes a keyword value of what your animation is
# [07:08] <dael> zcorpan: Doesn't font keyword have similar?
# [07:08] <dael> TabAtkins: They have positional knowledge that makes it unabmigous.
# [07:09] <fantasai> by keyword, we mean shorthand, right?
# [07:09] <dael> zcorpan: If you spec small caps small caps...
# [07:09] <dael> TabAtkins: you can't it's unvalid
# [07:09] <dael> dbaron: I don't like the animation shortand and maybe should have pushed back more
# [07:09] <dael> TabAtkins: I agree.
# [07:09] <dael> TabAtkins: I tried to push for a change and we couldn't.
# [07:09] <dael> hober: It was too late
# [07:10] <dael> dbaron: Animation and transition do the same with times
# [07:10] <dael> dbaron: So 0 without units aren't valid times
# [07:10] <dael> TabAtkins: Time and duration aren't ambig for transition
# [07:10] <dael> TabAtkins: So with the calification that animation forward backwards should take the last
# [07:10] <SimonSapin> Was custom-ident just a bad idea?
# [07:11] <dael> TabAtkins: A property with a custom-ident will look to assign to everything but the custom-ident first
# [07:11] <dael> TabAtkins: Or is the custom is required, it would take the last value
# [07:11] <dael> dbaron: The last rule could require a lot of llok ahread
# [07:11] <dael> dbaron: If animation name was required and you see keywords you might have the number in twice.
# [07:11] <dael> TabAtkins: Yes. Unlike in this case where it would work
# [07:12] <dael> TabAtkins: Maybe we require that if a custom ident is required it must be diambigouated via position
# [07:12] <dael> TabAtkins: I just want some rules here.
# [07:12] <dael> astearns: To be clear we'd discussing this as option 2 where option 1 is not allow those keywords aas idents
# [07:13] * glazou is melting
# [07:13] <dael> TabAtkins: Yeah. In places where the closure of grammer would creat problems
# [07:13] <dael> TabAtkins: I don't like it.
# [07:13] <dael> TabAtkins: Regardless of option, there will be problems.
# [07:13] <dael> TabAtkins: If we take option 1 every time we add a value, it would be an error
# [07:13] <dael> TabAtkins: Option 2 could cause you to parse funky
# [07:14] <dael> TabAtkins: option 1 is take the closure of all the value keywords that could show up and disalow as custom idents in that position
# [07:14] <dael> TabAtkins: option 2 is parse like animation name and we make sure it's well defined for corner cases
# [07:14] <dael> fantasai: Isn't that similar to list style for non?
# [07:14] <dael> TabAtkins: No. If it's none in the url it says it's a keyword
# [07:14] <dael> dbaron: So these examples can be parsed left to right and list style can't
# [07:15] * Joins: snsk (~snsk@public.cloak)
# [07:15] <dael> hober: Does option 1 require us to incomp change animation name
# [07:16] <dael> TabAtkins: If we wanted to apply generically, yes. Obviously that's not an option.
# [07:16] <fantasai> s/in the url/and a url/
# [07:16] <dael> TabAtkins: If we go with this there's an animation exception
# [07:16] * myakura .air { flow-into: room }
# [07:16] <fantasai> s/keyword/keyword, if it's none and a style type, it says it's an image/
# [07:16] <dael> TabAtkins: There's one more that I forgot to mention. Take the closure. There's also disallow all keywords in given context
# [07:16] * fantasai air { flow-into: room } /* air is elemental, not classical */
# [07:16] <dael> dbaron: So a problem with 1 is that it creates more compat rsk when adding keywords.
# [07:17] <dael> dbaron: In 2 we have a risk witht he shorthand, but stuff that has longhand is okay
# [07:17] <dael> TabAtkins: There's also 1 1/2 that disallows in a given property context.
# [07:17] <dael> TabAtkins: So if you try and do inside and there isn't a value you get an empty string.
# [07:18] * liam did wonder :)
# [07:19] * Joins: yamamoto (~yamamoto@public.cloak)
# [07:19] <SimonSapin> (I can’t here fantasai :/)
# [07:19] <dael> TabAtkins: In option 1 it's at risk. It's orignally valid, but it suddly becomes invalid
# [07:19] <SimonSapin> s/here/hear/
# [07:19] <dael> dbaron: We still have risk that shorthand will get parsedinto new properties.
# [07:19] * fantasai will talk louder next time
# [07:19] <dael> dbaron: Some structures are less likely to trigger.
# [07:19] <SimonSapin> (thanks)
# [07:19] <dael> dbaron: If you fully spec we can do that last.
# [07:20] <dael> TabAtkins: We can add a long hand to the short hand that overlaps the custom ident.
# [07:20] <dael> TabAtkins: I don't like #1. Option 2 is less bad, but means you can't serialize.
# [07:20] <fantasai> 1. Disallow keywords from closure of shorthands
# [07:20] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [07:20] <dael> TabAtkins: Option 3 is weird but somewhat familar from animation.
# [07:20] <fantasai> 2. Disallow keywords in the individual current context
# [07:20] <fantasai> 3. Whatever 'animation' does
# [07:20] <dael> TabAtkins: A lot of changes won't have an effect.
# [07:21] <dael> hober: I prefer 3, but it's because 1 and 2 are under defined
# [07:21] <dael> hober: 1 and 2 are easy to explain but three is a little washy
# [07:21] <hober> s/1 and 2 are under/it's under/
# [07:21] <dael> astearns: You said 3 was more familiar, but you can't define it easily
# [07:22] <dael> dbaron: 3 is you define as you find properties and leave custom to the end. your preference puts custom idents last
# [07:22] <dael> dbaron: As part of that you don't consider prop you've already assigned to.
# [07:22] <dael> TabAtkins: That requires we adopt a rule that you never had a required amb. custom ident.
# [07:22] <dael> TabAtkins: If you have a req it must be positionally unambigous.
# [07:22] <dael> dbaron: In general having positioning req for complex shorthands is good
# [07:23] <dael> hober: Do we think options 3 can be explained in a way for spec authors to follow
# [07:23] <dael> TabAtkins: Yes. It's easy to say here's what you do. Writing grammer is easier than parsing grammer.
# [07:23] <dael> TabAtkins: I'm happy to do 3.
# [07:23] <dael> TabAtkins: Once animation defines animate: forwards infinate; correctly
# [07:24] <dael> zcorpan: For new things isn't it better to req the order.
# [07:24] <dael> TabAtkins: Yes. That will be part of spec guidelines. Try and make it positionally unamb.
# [07:24] <dael> zcorpan: So whatever we choose here new things won't use this
# [07:24] <dael> TabAtkins: Yes.
# [07:24] <dael> hober: Should we resolve on that first?
# [07:24] <dael> TabAtkins: Only time it'll be happen is times like when you retrofit
# [07:24] <dael> TabAtkins: Whatever we decide shouldn't apply here.
# [07:25] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:25] <dael> TabAtkins: propr res: Any new properties with custom-ident make them positionally unambigous.
# [07:25] <dael> RESOLVED: Any new properties with custom-ident make them positionally unambigous.
# [07:25] <SimonSapin> Is that a "should" for new specs?
# [07:25] <dael> TabAtkins: Second is we handle the list style custom ident in the fashion of animation.
# [07:26] <dael> TabAtkins: In general for any custom idents that violate the above, we use the animation style
# [07:26] <dael> fantasai: So what about the good stuff?
# [07:26] <dael> TabAtkins: Grid is unabigous
# [07:26] <dael> dbaron: And at the break you'll help me fix the anmation spec
# [07:26] <dael> TabAtkins: Yes.
# [07:26] <dael> TabAtkins: So for grid you can just put whatever you want expect global
# [07:27] <dael> fantasai: There may be other cases where we want to diallow
# [07:27] <dael> TabAtkins: There are places you can disallow individual things.
# [07:27] <dael> TabAtkins: In general the rule being there's not auto-disallowed
# [07:28] <dael> fantasai: From a spec prospective you may want to figure out what keywords you want.
# [07:28] <dael> fantasai: So we should have a note in custom valeus
# [07:28] <dael> TabAtkins: Any obj to that resolution?
# [07:28] <dael> RESOLVED: we handle the list-style custom ident in the fashion of animation.
# [07:29] <dael> TabAtkins: That's the...ah yes. Order combinator
# [07:29] <dael> TabAtkins: We have combinators for grammer for five of the six common combinations
# [07:30] <dael> TabAtkins: we have { zero+, one+, all+} x {in-order, any-order}
# [07:30] <astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0230.html
# [07:31] <dael> TabAtkins: So we can address these so there's a big question mark that can't be addressed without grammer contortions
# [07:31] <dbaron> (the question mark being one+, in order)
# [07:31] <dael> TabAtkins: You can do a | a? b
# [07:31] <dael> TabAtkins: This is showing up in enough grammer that we should have it. Background position, image function, it's a lot.
# [07:32] <dael> TabAtkins: For now I propose a??b, but we can do anything we want.
# [07:32] <dael> TabAtkins: So do people think we should add this or if we do what combinator should this be?
# [07:32] * Joins: lmclister (~lmclister@public.cloak)
# [07:32] <dael> zcorpan: I thought we concluded this couldn't work because of combinator issues
# [07:32] <dael> TabAtkins: Is there a better idea than ?? or any issue with addnig to the grammer
# [07:32] <dael> jet: Is whitespace required
# [07:33] <dael> TabAtkins: Yes.
# [07:33] <dael> hober: How common is this?
# [07:33] <dael> TabAtkins: It shows in several places and it's always weird to read
# [07:33] * krit am back in 1.5h. I would really like to see Geometry Interfaces FPWD and Masking LC on the agenda and don't really care when.
# [07:33] <dael> hober: Does anyone have this where we can borrot it from?
# [07:33] <dauwhe_> s/borrot/borrow/
# [07:33] <dael> dbaron: I'm not crazy about having the thing in between. The in order ones use space sperated stuff
# [07:34] <dael> TabAtkins: Another suggestion was [a? b?]!
# [07:34] <dael> dbaron: I think it's less crazy from reading view.
# [07:34] <dael> TabAtkins: So you like the symetry of the in-orders?
# [07:34] <dael> hober: There's other cases that might have complex sub production that needs to be non-empty
# [07:35] <dael> TabAtkins: That is possible. I'm not sure we need it, but it's possible
# [07:35] <clilley> [a? b?]±
# [07:35] <dael> TabAtkins: I want to express this somehow. I just don't know how
# [07:35] <liam> a b? | b might be clearer
# [07:35] <dael> TabAtkins: While we usually use white space, we do sometimes use commas. It's verbose to use commas whichi s why we use the # multiplier
# [07:35] <dael> TabAtkins: Having a way to handle commas in these productions would be nice, but I don't know how.
# [07:36] <dael> dbaron: I appliers to all of them
# [07:36] <dael> TabAtkins: Commas are easy for a b but hard for the rest
# [07:36] * glazou wants a swimming pool
# [07:36] * dbaron thought it was all the ones in the first two columns, but it's indeed 5 of the 6
# [07:36] <dael> TabAtkins: If you're doing multiple of these it would be nice to have a comma
# [07:37] <dael> zcorpan: Would it work to put the comma in the grammer for all and say the comma must be there if left or right keywords are there, elseiwse you omit.
# [07:37] <dael> TabAtkins: I like that. I like simple, but I'm not sure where to put the comma for all of them
# [07:37] * liam offers glazou his swimming pool
# [07:37] <dael> TabAtkins: I like that you need to comma if you need to disambiguate, but elsewise leave it off.
# [07:37] <dael> zcorpan: Is there grammer that uses the comma for the space?
# [07:37] <dael> TabAtkins: I don't think there is in CSS
# [07:38] <dael> zcorpan: So we can add the comma thing
# [07:38] * glazou liam this room is a stove, really
# [07:38] * liam :(
# [07:38] <dael> TabAtkins: Yeah. We could have the comma just show up there and deal with the any-orders later
# [07:38] <dael> TabAtkins: I think you didn't like [a? b?]!, fantasai
# [07:38] <dael> fantasai: It doesn't seem like a multiplier
# [07:38] <dael> TabAtkins: Well it's not really.
# [07:39] <dael> plinss: It seems like the ? are redundant with []
# [07:39] <dael> TabAtkins: No, the [] are grouping not functional
# [07:39] <dael> hober: So the [] are to group and the ! is to say it has to return something
# [07:39] <dael> TabAtkins: I'm okay with a form like [a? b?]!
# [07:39] <dael> fantasai: It seemslike a lot of punctuation
# [07:40] <dael> hober: It avoid the redundency.
# [07:40] <dael> hober: It doesn't read to me that a or b are optional
# [07:40] <dael> TabAtkins: Or that order matters
# [07:40] <dael> hober: The grouping with the ! says that hte order matters
# [07:40] <dael> TabAtkins: So add something in place of the ?.
# [07:40] <dael> TabAtkins: We're not bound by characters.
# [07:41] <dael> hober: Use the interrobang
# [07:41] <dael> TabAtkins: You'd have to use grouping.
# [07:41] <dbaron> ‽
# [07:41] <dael> hober: That does highlight the the existing syntax does matter.
# [07:41] <dael> TabAtkins: It says the quisi-optional things are quasi-optional in the group
# [07:41] * dbaron offers ¡ a? b? !
# [07:41] * jdaggett egads
# [07:41] <dael> zcorpan: I don't like ??
# [07:42] <dael> TabAtkins: Should we eliminate the ‽ I guess we should
# [07:42] <dbaron> group eliminates a ?? b and eliminates a‽ b‽
# [07:42] * hober ¡important
# [07:42] <liam> sometimes a less expressive grammar is easier for people to learn and use, even f it's sometimes cumbersome
# [07:42] <dael> TabAtkins: So [a? b?]! ?
# [07:42] * dbaron ¡important!
# [07:42] <dael> TabAtkins: The other alternative is a grouper becides square brackets
# [07:43] <dael> TabAtkins: WE have the whole ascii space to work with
# [07:43] <dael> TabAtkins: We could use <a? b?>
# [07:43] * dauwhe_ ‽
# [07:43] * dauwhe_ just had to see an interobang in IRC
# [07:43] <dael> TabAtkins: So remaining brackets are {} << >>
# [07:44] <dael> hober: Why are we doing new groupers?
# [07:44] <dael> hober: Oh, I see the new grouper implies the bang.
# [07:44] <dael> dbaron: I'm happy the the [] and !
# [07:44] <dael> TabAtkins: So does anyone obj to the !?
# [07:44] <dael> shans_: What happens if there are things in there without ?
# [07:44] <dael> TabAtkins: It's required to be non-empty
# [07:45] * Quits: Kyounga_ (~Kyounga@public.cloak) (Ping timeout: 180 seconds)
# [07:45] <dael> TabAtkins: so a?! = a
# [07:45] <dael> fantasai: I guess we could do ?!
# [07:45] <dael> TabAtkins: If we do a single modified we need the grouping
# [07:45] <dael> plinss: So how about ! instead of ?
# [07:46] <dael> TabAtkins: That's implicit grouping. So we'd have to as a! b! || c, how to we sort that?
# [07:46] <dael> hober: You get it but it's harder to read
# [07:46] <dael> TabAtkins: Here's a more ambigous case a! b! c d! e!
# [07:46] <dael> TabAtkins: The answer is if you have vaguely ambigous you need groupers
# [07:47] <dael> fantasai: So in that is there a situation where you'd want one of a b and d?
# [07:47] <dael> fantasai: So you'd want a multiplier grouper
# [07:47] * dbaron ⸘ a b ‽ (running out of characters for syntax jokes)
# [07:47] <dael> hober: So are you talking about the case where a c is okay a d is okay but a e isn't.
# [07:48] <dael> TabAtkins: She's saying where if you have htis just c is no good, but one of the ! is required plus the required c
# [07:48] <dael> dbaron: I seems like it should be more important than not a !
# [07:48] <dael> fantasai: Idea: you take a character and within that level of grouping you have to have at least one thing with that character
# [07:48] <dael> fantasai: So if you have multi levels and you want to group it would apply across the entire thing
# [07:49] <dael> TabAtkins: And if a ! appears at least of the !ed things would be required.
# [07:49] <dael> fantasai: Instead of a grouping symbol, we need a symbol that says this thing must appear
# [07:49] * liam lost as to why extra syntax is needed if the existing grammar can express it and blames collective jetlag :)
# [07:49] <fantasai> at least one of the marked things must appear
# [07:49] <dael> fantasai: I think interrobang would be better there.
# [07:50] <dael> hober: I suggested it because if you're using this in your syntax it's already gone wrong. So in the case of [a? b?]! saying the entire group must be non empty
# [07:50] <dael> hober: We're not adding a feature that works inside of the group.
# [07:50] <dael> hober: So it's not a magical case where you need context to understand.
# [07:50] <dael> TabAtkins: Right.
# [07:50] <dael> hober: Putting it on the group makes it clear it's for the whole group
# [07:51] <dbaron> ‽
# [07:51] <dael> glaz: Don't think of this. We'll get questions.
# [07:51] <dael> fantasai: No one will type this
# [07:52] <dael> dbaron: I agree that this feels too complicated
# [07:52] <dael> TabAtkins: On the other hand you like having to interpret what grammer means?
# [07:52] <dael> dbaron: I don't like action at a distrance
# [07:52] <dael> hober: We suggested new groupers to limit charactes, but this adds even more characters
# [07:52] * glazou cannot believe we're considering using interrobang in specs
# [07:52] <dael> plinss: That's because one is non-optional
# [07:52] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:53] <dael> TabAtkins: I like the features, but I also like something simple
# [07:53] * astearns cannot believe the interrobang doesn't get proposed in every other grammar discussion
# [07:53] <dael> TabAtkins: What I want is handling the simipliest common case and say anything fancier write it out.
# [07:53] <dael> TabAtkins: So it sounds like we could resolve on [a? b?]! for one+ in-order?
# [07:53] <dael> fantasai: I'm going to vote no and everyone else can vote yes
# [07:53] <dbaron> fantasai still prefers the [ a‽ b‽ ]
# [07:54] <liam> [a? b?]! would be [a | b] yes?? or, [a+ b* | b+ ] instead?
# [07:54] <dael> hober: can you live with it fantasai
# [07:54] <dael> fantasai: I can live with it, but I'm unhappy with it.
# [07:54] <dael> fantasai: You lose anbilitiy
# [07:54] <dael> TabAtkins: But you can always write in prose
# [07:54] <dael> fantasai: I don't like the grouper has to match the multipier etc.
# [07:54] <dael> astearns: The instance you wrote out doesn't have cases.
# [07:55] <dael> TabAtkins: That's true.
# [07:55] * Quits: kyungtae (~kyungtae@public.cloak) (Ping timeout: 180 seconds)
# [07:55] <dael> TabAtkins: I'll catch liam's comment in a sec.
# [07:55] <dael> hober: Any objections?
# [07:55] * TabAtkins liam, no, [a? b?]! === a | [ a? b ]
# [07:55] <dael> fantasai: Where this shows up tends to be so complex, having one lessg rouper would be good
# [07:56] <dael> dbaron: But if the problem is too many groupers being explicit would be better.
# [07:56] <TabAtkins> It's "a and/or b, in that order".
# [07:56] <dael> hober: The impicit grouping is just as cognatively complex as this group
# [07:56] <dael> fantasai: It's the same as a combinator and that doesn't add the extra level
# [07:57] <liam> maybe and/or would be a better symbol to add to the grammar then
# [07:57] <dael> RESOLVED: Use [a? b?]! for the one+ in-order grammar
# [07:57] <dael> TabAtkins: Related is SimonSapin comment about commas
# [07:57] <astearns> s/simonsapin/zcorpan/
# [07:57] <dael> TabAtkins: So if I wanted a? b? you need to have the comma to seperate. If it's both you need the comma
# [07:57] * Joins: clilley_ (~clilley@public.cloak)
# [07:58] * Quits: clilley (~clilley@public.cloak) (Ping timeout: 180 seconds)
# [07:58] <dael> dbaron: We can hyperlink the commas
# [07:58] <dael> TabAtkins: We can do that
# [07:58] <SimonSapin> hyperlink all the things
# [07:58] <dael> TabAtkins: Sounds good. Can someone file an issue on bikeshead
# [07:58] <dael> fantasai: The current template has the values
# [07:58] <dael> TabAtkins: Yes.
# [07:59] * clilley_ Algol68 grammar required the user to distinguish a comma and an *italic comma*
# [07:59] * dauwhe_ [hyperlink? bikeshed?]! all of the things.
# [07:59] <dael> plinss: So we can't use ,? because there's a patint on that (the , being in the space of the.)
# [07:59] <glazou> s/patint/patent
# [07:59] <dael> dbaron: I will file the bikeshead issue
# [07:59] <dael> TabAtkins: Anything else with values and units?
# [07:59] * plinss http://worldwide.espacenet.com/publicationDetails/biblio?CC=WO&NR=9219458&KC=&FT=E&locale=en_EP
# [07:59] <dael> TabAtkins: Publish an update
# [08:00] <dael> RESOLVED: Publish an update
# [08:00] <dael> TabAtkins: How long is the LC? 3 weeks?
# [08:00] <zcorpan> s/bikeshead/bikeshed/g
# [08:00] <dael> clilley_: We have to ask other chairs for options
# [08:00] <dael> TabAtkins: Okay, are we fine with proposing three weeks
# [08:00] <dael> group: yes
# [08:01] <dael> break = 10 minutes
# [08:04] * myakura found ⸮ but too late
# [08:05] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [08:06] * Joins: Kyounga (~Kyounga@public.cloak)
# [08:12] * Joins: adenilson (~anonymous@public.cloak)
# [08:12] * Quits: snsk (~snsk@public.cloak) (Client closed connection)
# [08:13] * Quits: Kyounga (~Kyounga@public.cloak) (Ping timeout: 180 seconds)
# [08:13] * Joins: Matsuki (~Matsuki@public.cloak)
# [08:14] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [08:21] <dael> glaz: Let's resume
# [08:21] <dael> TabAtkins: Alright.
# [08:22] <dael> TabAtkins: Counter styles. There are 3 issues that I don't know how to resolve
# [08:22] <dael> TabAtkins: The fourth is in line with what we did in animations
# [08:22] <dael> dbaron: There's a reply to one of your messages so there might be a 5th.
# [08:22] * Joins: adenilson_ (~anonymous@public.cloak)
# [08:22] <dael> TabAtkins: He's just saying I need to define range-auto. I will do that.
# [08:22] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
# [08:22] * adenilson_ is now known as adenilson
# [08:23] <dael> TabAtkins: First issue
# [08:23] <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2014May/0146.html
# [08:23] <dael> TabAtkins: How do we read out counter styles in interesting manners
# [08:24] <dael> TabAtkins: There's speak-as which lets you say to read the numeric value, read as a bullet, or read alphabetical values
# [08:24] <dael> TabAtkins: There's some where it might be good to read as a word.
# [08:24] * Joins: kyungtae (~androirc@public.cloak)
# [08:25] <dael> TabAtkins: And example was a text on Tolkin and you were doing your lists with numbering quenyan you'd want them read out in that language
# [08:25] <dael> TabAtkins: The question is should we add speaking out counter styles as words, using whatever engines that you have for speech.
# [08:25] <clilley_> http://en.wikipedia.org/wiki/Quenya
# [08:25] <dael> TabAtkins: So that something like and system:fixed; symbols: "first", "second"... will be read as first, secdon, etc.
# [08:26] <dael> TabAtkins: So should we address this or we can just say no change and let it just be called numeric.
# [08:26] <dael> TabAtkins: I'm fine with adding a value, but wanted to avoid obj.
# [08:27] <dael> hober: It seems easy to get internationalizion wrong. I made a cool set of styles and say you can read as 1, 2, etc. and someone uses them in a different language it would be read as first...
# [08:27] <dael> TabAtkins: But that's the right way to do it.
# [08:27] <dael> dbaron: The normal case is speak-as numeric, though that says 1, 2
# [08:27] <dael> TabAtkins: It ignores what the symbol is. This would let it literally read the word.
# [08:27] <dael> hober: And if you have a symbol?
# [08:27] <dael> TabAtkins: It would do whatever your reader does
# [08:28] <dael> dbaron: And I think alphabetic should be something like spelled out?
# [08:28] <dael> TabAtkins: Yeah. I'm fine with changing that
# [08:28] <dael> fantasai: So this is the alt proposal?
# [08:28] <dael> TabAtkins: Yes. The way this would be done, it allows the alt proposal in a slightly more complex way
# [08:28] <dael> dbaron: speak-as can refer to a differenet counter style
# [08:29] <dael> TabAtkins: So if you have a list of symbols where you want them names as something, you would use speak-as that.
# [08:29] * dauwhe_ proposal to encode Tengwar in Unicode: http://std.dkuug.dk/JTC1/SC2/WG2/docs/n1641/n1641.htm
# [08:29] <dael> TabAtkins: So does anyone obj to me adding this?
# [08:29] <dael> [silence]
# [08:29] * Joins: murakami (~murakami@public.cloak)
# [08:29] <dael> TabAtkins: So, names. We have a value called alphabetic that reads leter by letter.
# [08:29] <dael> TabAtkins: It's not a clear name and I'd be fine with naming it something like spelled-out
# [08:30] <dael> TabAtkins: So we'd also need a name for this like speak-out-as
# [08:30] <dael> fantasai: speell-out is already defined
# [08:30] <dael> TabAtkins: great
# [08:30] <dael> fantasai: that spells the text one letter at a time.
# [08:30] <dael> TabAtkins: So that would be speak-as, spell-out...
# [08:31] <dael> fantasai: And I would use read-aloud
# [08:31] <dael> TabAtkins: that's less clear
# [08:31] <dael> fantasai: We have an auto value
# [08:31] <dael> TabAtkins: I like speak-as-words
# [08:31] <dael> dbaron: The auto does things dependant on the system of the counter style
# [08:31] <dael> TabAtkins: I like spell-out and words
# [08:31] <dael> TabAtkins: bullet and numberic are the other existing values.
# [08:31] <dael> fantasai: Do we have a clearer word than bullet?
# [08:32] <dael> TabAtkins: If someone can come upw ith one
# [08:32] <dael> dbaron: Bullet is fine to me.
# [08:32] <dael> fantasai: Okay.
# [08:32] * clilley_ speak-as: projectile
# [08:32] <dael> TabAtkins: So does anyone object to bullet, number, spell-out and words?
# [08:32] <dael> dauwhe_: Is there digits?
# [08:32] <dael> TabAtkins: That would be spell-out, I guess
# [08:33] <dael> fantasai: speak-as applies to general text so spell-out digits would pronounce as a number
# [08:33] <dael> fantasai: In this case it's a strange thing.
# [08:33] * astearns speak-as: death-growl;
# [08:33] <dael> dbaron: So speak-as digits in speach does do normal for everything but a number and number as a number
# [08:33] <dael> TabAtkins: So I'm happy for these four values and will handle in the sepc alts using the secondary style
# [08:33] <dael> fantasai: I'm thinking about words. Should it be read-words?
# [08:34] <dael> TabAtkins: Well, these are nouns and don't need individual parts of speech.
# [08:34] * hober speak-as: anguished-cry;
# [08:34] <dael> fantasai: Well, maybe we should pick a part of speech for all of these
# [08:34] <dael> dauwhe_: Have you gotten accessability input?
# [08:34] <dael> TabAtkins: Yes.
# [08:34] <dael> dauwhe_: Has Daneil ? commented on this?
# [08:34] <dael> TabAtkins: Keeping to one kind of speech is probably good.
# [08:35] <dauwhe_> s/Daneil ?/Daniel Weck/
# [08:35] <dael> dbaron: A property called speak-as seems to hnd a noun
# [08:35] <dael> fantasai: speak-as and spell-out exist.
# [08:35] <dael> dbaron: So spell-out is the exception
# [08:35] <dael> TabAtkins: speak-as bullets, numbers, characters, words
# [08:35] <dael> fantasai: I think characters would want to be left out.
# [08:36] <dael> TabAtkins: I want to change this to numbers since numeric was the old way
# [08:36] * Quits: Matsuki (~Matsuki@public.cloak) (Ping timeout: 180 seconds)
# [08:36] <dael> TabAtkins: We need a better name to just say it's a list item
# [08:36] <dael> TabAtkins: So let's resolve we should add a speak this as a word value.
# [08:36] <dael> RESOLVED: add a speak this as a word value.
# [08:37] <dael> TabAtkins: For now, as a tentitive resolution, change the keywords to bullets, numbers, words and spell-as
# [08:37] <dael> fantasai: We could use queues?
# [08:37] <dael> TabAtkins: I don't think that works out of context.
# [08:37] <dael> zcorpan: But there's only one bullet or list topic
# [08:37] <dael> TabAtkins: There's only one number
# [08:37] <dauwhe_> s/queues/cues/
# [08:37] <dael> zcorpan: So why plural?
# [08:38] <dael> TabAtkins: Dunno. We can depluralize
# [08:38] <dael> zcorpan: It applies to one
# [08:38] <dael> TabAtkins: And all things generted by the counter styl
# [08:38] <dael> zcorpan: So I guess plural.
# [08:38] <dael> TabAtkins: So that ones done. I'll edit that in.
# [08:38] * Joins: Matsuki (~Matsuki@public.cloak)
# [08:38] <dael> fantasai: You can ask James Craig if he's got a better idea for a name than bullets
# [08:38] <dael> TabAtkins: The third topic is easier
# [08:38] * krit What is the topic?
# [08:39] * krit a counter style
# [08:39] * astearns krit: counter styles
# [08:39] * krit astearns thanks
# [08:39] <dael> TabAtkins: I accidently made a contridiction. I have two descriptions that modify the length of a value. Pad adds and negative adds
# [08:39] <dael> TabAtkins: Question is which goes first.
# [08:40] <dael> TabAtkins: So you have pad: 2 "0" and negative: "-". Is it -2 or -02?
# [08:40] <dael> TabAtkins: It's impl both ways so we can decide. The spec says both, by accident.
# [08:40] <dael> TabAtkins: So which do people like better?
# [08:41] <dael> TabAtkins: Because alignment it looks like this [whiteboard]
# [08:41] <dael> TabAtkins: so do people prefer 1st or 2nd on whiteboard.
# [08:41] <dael> TabAtkins: okay, second one is the choice.
# [08:41] <dael> RESOLVED: process pad before negative
# [08:41] <dbaron> (so that we get -02, -01, 00, 01, 02)
# [08:41] <dael> TabAtkins: Last one which is second.
# [08:42] <dael> TabAtkins: How to handle the spacing between a bullet and its text
# [08:42] <dael> fantasai: Isn't that out of scope?
# [08:42] <dael> dbaron: There's a problem whichi s why
# [08:42] <dael> TabAtkins: It's counter styles or lists.
# [08:42] <dael> TabAtkins: So there's some space. Where is it from? margin on the list item, spaces on the suffix, magic?
# [08:42] <dael> TabAtkins: Browsers do both.
# [08:43] <dael> dbaron: Firefox does margin based, but drops for CJK counter styles
# [08:43] <dael> TabAtkins: For CJK you don't want to have a space.
# [08:43] <dael> fantasai: And in english if you're copying you want that to stay
# [08:43] <dael> hober: So the good part about embedded is that it lets you do both
# [08:43] <dael> TabAtkins: I need to alter the definitions so that it says that but that's okay
# [08:44] <dael> TabAtkins: So there's a desire to have this happen with majic, but I don't like the appraoch
# [08:44] <dael> dbaron: The problem is I suspect the margin might be interop
# [08:44] <dael> TabAtkins: We use space.
# [08:44] <dael> dauwhe_: And it's an ordinary space?
# [08:44] <dael> TabAtkins: Yes.
# [08:44] <dael> dauwhe_: I'm worried because justification can change the width
# [08:45] <dael> TabAtkins: Outside markers are outside of that context.
# [08:45] <dael> TabAtkins: I'm okay with altering to say there's a space in the suffix.
# [08:45] <dael> fantasai: If you have outside markers than do you want that space there?
# [08:45] <dael> TabAtkins: Yes.
# [08:45] <dael> fantasai: But if you have CJK outside marker...
# [08:45] <dael> TabAtkins: You take away the space. From what I understand you want the same behaviour for outside and inside
# [08:46] <dael> fantasai: If that's the case this is the right decision
# [08:46] <dael> TabAtkins: So if you have an outside list item, do you want the marker on the end or do you want space here, koji or others?
# [08:46] <dael> fantasai: Okay. In that case we're good.
# [08:47] <dbaron> http://dbaron.org/css/test/2014/bullet
# [08:47] <dael> dbaron: Here's the test case I was playing with.
# [08:47] <dael> dbaron: Though I should maybe try with Chinese characters
# [08:47] <dael> TabAtkins: Well, we scale, but its true if we use a space or em value. The only way to tell is to expect code or find a font with a significnatly different space.
# [08:48] <TabAtkins> s/expect/inspect/
# [08:48] <dael> TabAtkins: Is your approval going to hang on this case?
# [08:48] <dael> dbaron: I don't think so. I'm okay witht he space in list styles
# [08:48] <dael> TabAtkins: We were discussing if CJK wants the same inside and outside.
# [08:49] <dael> TabAtkins: So provistionally we say the spacing between a list item and its content should be done as space characters in the suffix
# [08:49] <dael> fantasai: Can you send a patch it internationaliztion?
# [08:49] <dael> TabAtkins: Yes
# [08:49] <dael> RESOLVED: the spacing between a list item and its content should be done as space characters in the suffix
# [08:50] <dael> TabAtkins: Final issue is that one of the system values is override which lets you point to another style and say do what that does, but i'm overriding some of the discriptors
# [08:50] <dael> TabAtkins: So I can say override: decimal negative: "(" ")"
# [08:51] <dael> TabAtkins: So this is do whatever decimal does but do this for negative
# [08:51] <fantasai> s/override:/system: override/
# [08:51] * liam hearing music?
# [08:51] <dael> TabAtkins: So fantasai doesn't think this is the right word.
# [08:51] <dael> fantasai: We're only overeriding parts of the system
# [08:51] <dael> dbaron: So do you want to use inheret?
# [08:52] <dael> fantasai: It's close
# [08:52] <dael> TabAtkins: I'd oject to that
# [08:52] <dael> TabAtkins: It's similar, but we just disallowed inheret everywhere.
# [08:52] <dael> dbaron: Do you have another idea?
# [08:52] <dael> fantasai: I think it would be clear for authors.
# [08:52] <dael> dbaron: Except maybe we don't want to confuse them.
# [08:52] <zcorpan> s/inheret/inherit/
# [08:53] <dael> TabAtkins: So what should we actually use.
# [08:53] <dael> TabAtkins: How about extends?
# [08:53] <dael> TabAtkins: I like that better than inherit.
# [08:53] <dael> glaz: extended
# [08:53] <dael> dbaron: It's a bit different
# [08:53] <dael> TabAtkins: It being a verb is good
# [08:53] <dael> dbaron: Having it be part of the system discriptor works well.
# [08:54] <dael> TabAtkins: Already i have that an override cannot do symbols.
# [08:54] <dael> fantasai: Unless someone has something better I'm satisfied with extends
# [08:54] <dael> TabAtkins: I'm okay with this
# [08:54] <dael> dbaron: One issue with extends is that it makes it sound like it adds
# [08:54] <dael> TabAtkins: It's the same semantic as JS
# [08:54] <dael> dbaron: Not everyone is familair with it
# [08:55] <dael> fantasai: So we have inherit, extends, or override. Any other ideas?
# [08:55] <dael> ??: Copy
# [08:55] <dael> fantasai: Okay, copy.
# [08:55] <zcorpan> s/??/andrey/
# [08:55] <dael> TabAtkins: Any other suggestions?
# [08:55] <dael> TabAtkins: So let's poll on answers.
# [08:55] <dael> fantasai: We'll deal with plurilization after.
# [08:55] * astearns impersonate!
# [08:56] <dael> clilley_: abs
# [08:56] <dael> fantasai: anything but override
# [08:56] <dael> glaz: anything but 4
# [08:56] <dael> dbaron: i think anything but 4.
# [08:57] <fantasai> 1. inherit
# [08:57] <dael> andrea: 2
# [08:57] <fantasai> 2. extend
# [08:57] <fantasai> 3. override
# [08:57] <dael> astearns: 2
# [08:57] <fantasai> 4. copy
# [08:57] <dael> Rossen_: Anything but 3 or 4.
# [08:57] <dael> plinss: 2
# [08:57] <dael> TabAtkins: 2
# [08:57] <dael> TabAtkins: Okay. 2 wins.
# [08:57] <dael> dauwhe_: 2
# [08:57] <SimonSapin> what are the choices?
# [08:57] <SimonSapin> thanks fantasai
# [08:57] <dael> fantasai: Is it plural?
# [08:57] <dael> TabAtkins: JS uses extends
# [08:58] <clilley_> ExistenZ
# [08:58] * plh z: the new frontier. There are ...
# [08:58] <dael> TabAtkins: So is extends okay?
# [08:58] * glazou suggest kstendz
# [08:58] <dael> fantasai: What are the other values? In the system?
# [08:59] <dael> dbaron: fixed numeric alphabetic
# [08:59] <dael> fantasai: so extends is different
# [08:59] <dael> RESOLVED: Change the name of the override to extends
# [08:59] <fantasai> s/different/is consistent/
# [08:59] <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/#descdef-system
# [08:59] <dael> TabAtkins: So. Cool. That's all counter styles
# [08:59] <glazou> more oculus rift, right ?
# [08:59] <dael> TabAtkins: It's been in LC for a year because we keep getting new issues from zcorpan
# [08:59] <dael> TabAtkins: I suspect we're near the end.
# [09:00] <dael> TabAtkins: So do we issue a new LC once I make these changes?
# [09:00] <dael> dbaron: That's reasonable
# [09:00] <dael> dbaron: There's a chance of feedback once the impl lands.
# [09:00] <dael> dbaron: Since that replaces numbering with code based on this spec and thus people will notice if it does something
# [09:00] <fantasai> s/numbering/existing numbering/
# [09:01] <dael> TabAtkins: Any obj to a new LC of counter styles? I propose a 6 week period to give maximum time to find issues.
# [09:01] <dael> fantasai: So say that for the purposes shipping this counts a s CR?
# [09:01] <dael> TabAtkins: They're shipping anyway
# [09:01] <dael> dbaron: Was it in CR?
# [09:01] <dael> TabAtkins: It never made it there.
# [09:01] <dael> fantasai: We resolved to publish and before we did we got issues.
# [09:02] <fantasai> s/issues/lots of issues from Xidorn/
# [09:02] <dael> TabAtkins: So, I'm not hearing obj to going to last call
# [09:02] <dael> fantasai: You could do a shorter period
# [09:02] <dael> TabAtkins: I'm happy
# [09:02] <dael> RESOLVED: Publish a 6 week last call of counter styles
# [09:03] * dauwhe_ last call should be forty days and forty nights.
# [09:03] <dael> astearns: Bert asked to call for text
# [09:03] <dael> fantasai: SteveZ wanted not today
# [09:03] <dael> dbaron: It's now midnight in CA so 1pm-3pm is likely okay for CA.
# [09:04] <dael> astearns: What about Bert?
# [09:04] <dael> dbaron: There may not be a time for overlap
# [09:04] <fantasai> TabAtkins, http://lists.w3.org/Archives/Public/www-style/2014Mar/0594.html is the renaming issue for override
# [09:04] <fantasai> TabAtkins, you're missing responses to the last couple issues
# [09:04] <fantasai> TabAtkins, otherwise, looked over the DoC, seems reasonable
# [09:05] <TabAtkins> Yeah, I just put them in today.
# [09:05] <TabAtkins> So it hadn't had time to reach the archives yet.
# [09:05] <dael> [pause to sort out schedule]
# [09:05] <dael> glaz: We're going to have a talk from AH about CSS3 formatting for books
# [09:05] <clilley_> http://nadita.com/murakami/presen201405/#%281%29
# [09:06] <SimonSapin> glazou, is the talk now?
# [09:06] * clilley_ yes
# [09:06] <dbaron> SimonSapin, yes
# [09:06] <dael> [presentation is slides, no minutes]
# [09:08] * dauwhe_ Murakami is speaking over the noise of a jet taking off
# [09:09] * Quits: silentobserver (~silentobserver@public.cloak) (Ping timeout: 180 seconds)
# [09:11] <glazou> SimonSapin: yes
# [09:19] * liam very pleased to hear positive welcome to Antenna House participation
# [09:20] <TabAtkins> +1
# [09:20] <liam> [Liam very pleased to hear positive welcome to Antenna House participation]
# [09:20] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:21] <dael> glaz: So we have an hour. What can we do?
# [09:21] <dael> [brief water break]
# [09:24] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [09:25] * Joins: ar (~ar@public.cloak)
# [09:26] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [09:29] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [09:36] <dael> gaz: Let's start again
# [09:36] <dael> glaz: Since it's been a hard day we propose selectors 4, font load and discuss sept f2f and than maybe media queries
# [09:36] <krit> can we do agenda first?
# [09:37] <dael> fantasai: I think I need to go over it
# [09:37] <krit> So that people calling in can plan better?
# [09:37] <krit> glazou: --^
# [09:37] <dael> TabAtkins: There's still edits to selectors that need to be made
# [09:37] <dael> TabAtkins: I propose we move font load to LC
# [09:37] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:37] <dael> TabAtkins: It's in the ES spec and two browsers are shipping
# [09:37] * Joins: adenilson (~anonymous@public.cloak)
# [09:37] <dael> plinss: Aren't there polyfills?
# [09:38] <dael> TabAtkins: Yes.
# [09:38] * Joins: Jet (~Jet@public.cloak)
# [09:38] <dael> dbaron: Have you gotten rid of the web idl dependency?
# [09:38] <dael> TabAtkins: I haven't removed it yet but I plan to
# [09:38] <dbaron> s/web idl dependency/web idl SetClass dependency/
# [09:38] * krit glazou am still muted so I couldn't speak up :P
# [09:38] <SimonSapin> Fonts load events are in the ES spec‽
# [09:38] <dael> glenn: Shouldn't that be before LC
# [09:38] <dael> TabAtkins: Yes, but we can do that in the future
# [09:38] <glazou> krit is umuted
# [09:38] <dael> dbaron: If you're planning...I guess that's okay, but ut a note in the spec?
# [09:39] <dael> TabAtkins: I can do that
# [09:39] <dbaron> s/ut a note in the spec/put a note in the spec that you're planning to change it/
# [09:39] <dael> krit: I wanted to ask if we can plan the agenda so people calling in can plan, but that can be after this discussion
# [09:39] <SimonSapin> +1, agenda please
# [09:39] * Joins: murakami (~murakami@public.cloak)
# [09:40] <dael> TabAtkins: So that's it. I'll put in a set and deal with it that way for now.
# [09:40] <dael> TabAtkins: Witht he change or the note that it'll change during LC, is that acceptable?
# [09:40] <dael> dbaron: Yes.
# [09:40] <dael> glaz: So any obj to publishing?
# [09:40] <dael> RESOLVED: Publish LC for font loading
# [09:40] <dael> glaz: how long?
# [09:40] <dael> TabAtkins: Standard is fine
# [09:40] <dael> glaz: So 6 weeks?
# [09:40] <dael> glaz: clilley_ will do the publication
# [09:41] <dael> TabAtkins: Great.
# [09:41] <dael> clilley_: Is it ready now?
# [09:41] <dael> TabAtkins: Let me add that note. It will be ready in five minutes
# [09:41] <dael> clilley_: That's close enough to now.
# [09:41] <dael> clilley_: It's been pub before, right?
# [09:41] <dael> TabAtkins: Yeah. It's been out.
# [09:42] <dael> glaz: So back to the agenda since SimonSapin and krit want it
# [09:42] <dael> glaz: So CSS3 text is Wed after lunch for SteveZ can call
# [09:42] <dael> glaz: Line layout is tomorrow afternoon.
# [09:42] <dael> krit: can SteveZ call in in the afternoon?
# [09:42] <dael> glaz: I hope so
# [09:42] <dael> dbaron: He can do early afternoon, not late.
# [09:43] <dael> plinss: remain: Webkit line plan, CSS masking
# [09:43] <dael> TabAtkins: I can do line plan
# [09:43] <astearns> s/plan/clamp/
# [09:43] <dael> glaz: How much time?
# [09:43] <dael> TabAtkins: Something between 15 and 30 minutes
# [09:43] <dael> plinss: So CSS Masking
# [09:44] <dael> glaz: krit you wanted to attend?
# [09:44] <dael> glaz: When are you ready to call in?
# [09:44] <dael> krit: Any time except those two hours I e-mailed about.
# [09:44] <dael> krit: So between 2 and 5pm
# [09:44] <dael> dbaron: I thought 2 to 4?
# [09:44] <dael> krit: Yes.
# [09:44] <dael> glaz: That will be complicated. We have 2 afternoons left.
# [09:44] <dael> krit: Morning is fine.
# [09:45] <dael> glaz: So WEdnesday morning?
# [09:45] <dael> krit: yes
# [09:45] <dael> krit: geometry interface on wednesday morning too?
# [09:45] <dael> glaz: Sure.
# [09:45] <dael> glaz: We have box model/render tree and bert would like to call. Maybe that's tomorrow?
# [09:45] * SimonSapin is interested in Render Tree too. Korean afternoon preferred
# [09:46] <dael> glaz: When do we do GCPM footnotes
# [09:46] <dael> plinss: tomorrow morning
# [09:46] * Quits: dauwhe (~dauwhe@public.cloak) ("Page closed")
# [09:46] <dael> glaz: test results.
# [09:46] <dael> plinss: We can do that tomorrow
# [09:46] <dael> glaz: Who did CSS OM?
# [09:46] <dael> clilley_: Me.
# [09:47] <dael> glaz: Tomorrow okay?
# [09:47] <SimonSapin> TabAtkins, is the surrogate thing worth bringing up?
# [09:47] <dael> clilley_: zcorpan is CSS OM something you're ready to talk about?
# [09:47] <dael> zcorpan: Yeah.
# [09:47] <dael> glaz: Tomorrow morning?
# [09:47] <dael> zcorpan: Okay.
# [09:47] <TabAtkins> SimonSapin: Probably, yeah.
# [09:47] <dael> plinss: We have box alignment? I think SteveZ wanted to call in for that.
# [09:48] <dael> TabAtkins: I hve a syntax issue we can discuss this afternoon. It's unpaired surrigates.
# [09:48] <dael> glaz: ten minutes
# [09:48] <SimonSapin> TabAtkins, maybe in CSSOM rather than Syntax
# [09:48] <zcorpan> s/surrigates/surrogates/
# [09:48] <dael> glaz: So SteveZ wants to do box alignment so right after line layout?
# [09:48] <TabAtkins> SimonSapin: Really it's a querySelector() issue.
# [09:48] <TabAtkins> So, DOM.
# [09:48] <TabAtkins> But we should be deciding on it.
# [09:48] <SimonSapin> well, maybe Syntax will need clarification too, but we can only get surrogate from JS
# [09:49] <clilley_> TabAtkins "This proposal has progressed to the Draft ECMAScript 6 Specification, which is available for review on the official ECMAScript wiki. When referencing the promises specification, you should reference the draft ECMAScript 6 spec, and not this repository."
# [09:49] <dael> glaz: for CSS3 text we have 2 requests. SteveZ wants right after lunc and Bert wants to do late afternoon
# [09:49] <dael> plinss: So do mid-afternoon?
# [09:49] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [09:49] <dael> dbaron: So the comprimise is to do that window krit can't make
# [09:49] <dael> plinss: Still scoping, flexbox, and selectors 4
# [09:49] <dael> glaz: Flexbox is LC to CR
# [09:50] <dael> Rossen_: Any time.
# [09:50] <dael> glaz: We have a slot in the morning?
# [09:50] <dael> plinss: Yes.
# [09:50] <dael> glaz: Scoping in the morning?
# [09:50] <dael> TabAtkins: Yes.
# [09:50] <SimonSapin> TabAtkins, querySelector() yes, but CSSOM too I think. E.g. CSSStyleSheet.insertRule
# [09:50] <dael> plinss: Okay. We'll put it in the morning and shuffle if we need to.
# [09:50] * liam suggests posting updated agenda to mailing list (or pointer to it and the fact it changed) separately from minutes
# [09:50] <zcorpan> TabAtkins: and CSS.escape()
# [09:51] <SimonSapin> right
# [09:51] <dael> plinss: So next F2F?
# [09:51] <dael> glaz: Okay.
# [09:51] <dael> glaz: Did we have something...?
# [09:51] * clilley_ liam http://wiki.csswg.org/planning/seoul-2014#agenda updated live
# [09:51] <dael> dbaron: We had tentitive dates of 8 sept to 10
# [09:52] <dael> glaz: We had proposals for location, Paris, Brighton, and Sophia. I think it will be hard to find a room in Brighton
# [09:52] * liam knows (thanks) is why i said pointer :)
# [09:53] <dael> glaz: So 8 to 10 sept is a monday to wednesday
# [09:53] <dael> glaz: So we stick to Sophia?
# [09:53] <dael> glaz: Any objections?
# [09:53] <dael> hober: There isn't a concrete option, is there? It's somewhere that we know works, versus something more amorphous?
# [09:53] <dael> glaz: The more concrete second option is Paris
# [09:53] <dael> clilley_: Who would host?
# [09:54] <dael> glaz: I'm not sure.
# [09:54] <dael> plinss: As a side note, CSS conf is Berlin on 12 Sept
# [09:54] <dael> TabAtkins: Is anyone here speaking there?
# [09:54] * Quits: kyungtae (~androirc@public.cloak) (Client closed connection)
# [09:54] <dael> plinss: There's an open call for speakers.
# [09:54] * Joins: kyungtae (~androirc@public.cloak)
# [09:54] <dael> clilley_: So you can get from any of those locations to Berlin easily
# [09:55] <SimonSapin> also, cssconf.eu != cssconf.com
# [09:55] <dael> plinss: And JS conf is the two days right after
# [09:55] * Quits: Matsuki (~Matsuki@public.cloak) (Ping timeout: 180 seconds)
# [09:55] <dael> glaz: Call for speakers is open until 1 July
# [09:56] <dael> glenn: Can you get zurick, TabAtkins?
# [09:56] <dael> TabAtkins: I think Zurich would be big enough. I don't see a problem, but would have to check dates.
# [09:56] <TabAtkins> s/think/know/
# [09:57] <dael> glaz: So do we stick to Sophia until zurick is more concrete?
# [09:57] <dael> TabAtkins: Yep. So ping tantek.
# [09:57] * Joins: Matsuki (~Matsuki@public.cloak)
# [09:57] <dael> plinss: We're firm on dates?
# [09:57] <dael> glaz: Yes.
# [09:57] <dael> krit: Is there a problem with Sophia?
# [09:57] <dael> TabAtkins: It's a little harder to get to.
# [09:57] <dael> TabAtkins: So we're doing 8 to 10 Sept, somewhere in Europe
# [09:57] <dael> glaz: Next is TPAC in Santa Clara
# [09:58] <dael> TabAtkins: We've been non-US a lot, so we can maybe do US.
# [09:58] <dael> astearns: Except the last meeting.
# [09:58] <dael> krit: I wouldn't mind doing Seattle more.
# [09:59] <dael> dbaron: Do we know where 2015 TPAC is?
# [09:59] <dael> glaz: Paris
# [09:59] <dael> plinss: not Leon?
# [09:59] <dael> glaz: I don't think so.
# [09:59] <dael> dbaron: You sure that's not AC?
# [09:59] <plinss> s/Leon/Lyon/
# [09:59] <dael> glaz: Oh, it was.
# [09:59] * dauwhe_ eventually we should meet in the Eastern US
# [09:59] <dael> plh: 2015 is under discussion. There's the idea of doing Japan and it's going to become a funding question.
# [10:00] <dael> plh: If we can find funds we'll go to Japan.
# [10:00] <dael> glaz: So.
# [10:00] <dael> dbaron: It's likely not urgent.
# [10:00] <dael> glaz: It's good to say something like Feb in US.
# [10:00] <dael> TabAtkins: I want to do summer in US. specifically Seattle
# [10:01] <dael> glenn: I could maybe do Bolder for skiiers
# [10:01] <dauwhe_> s/Bolder/Boulder/
# [10:01] * Joins: yamamoto (~yamamoto@public.cloak)
# [10:01] <dael> glaz: So let's give some time to collect possibilities.
# [10:01] <dauwhe_> s/skiiers/skiers/
# [10:01] <dael> glaz: So let's wait a bit
# [10:01] <liam> hmm, xml prague is in february
# [10:01] <dael> glaz: TPAC is in early november?
# [10:01] <dael> plh: No, it overlaps halloween
# [10:02] <dael> glaz: So begining of Feburary will be good.
# [10:02] <myakura> “ TPAC 2014 (a W3C event) takes place 27 Oct to 31 Oct 2014 in Santa Clara, California.” http://www.w3.org/wiki/TPAC2014
# [10:02] <dael> glaz: Could Bloomburg host in NYC?
# [10:02] <dael> andrea: I can see. We're tight on space, usually, though.
# [10:03] <dael> dauwhe_: I could eventually look at NYC. We're moving in Oct and may have better spaces.
# [10:03] <dael> plh: NYC in Feb? Might as well do Boston.
# [10:03] <liam> [we had a F2F in Ottawa in Jan/Feb once, hosted by Adobe, and had -50° and an ice storm]
# [10:04] <dael> Rossen_: How about Austrailia in Feb?
# [10:04] <dael> clilley_: I've been to one end of Jan/Feb.
# [10:04] <dael> TabAtkins: It's like a texas august.
# [10:04] <dael> shans_: I don't think we could get the same space.
# [10:04] <dael> Rossen_: We could get SVG in Feb.
# [10:05] <dael> glaz: We can investigate that too.
# [10:05] <dael> shans_: Sure.
# [10:05] <dael> plinss: Tentitive dates?
# [10:05] <dael> glaz: Begining Feb.
# [10:05] <dael> clilley_: If we're investigating Australia, we should make sure we're co-located with SVG
# [10:05] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [10:05] <dael> glaz: Okay. Is that all for F2F?
# [10:05] * Joins: yamamoto (~yamamoto@public.cloak)
# [10:06] <dael> plinss: So go to MQ?
# [10:06] <dael> TabAtkins: Can we do syntax quick?
# [10:06] <dael> TabAtkins: So the CSS parse handles unpaired surrigates fine, it turns them into replacement characters
# [10:07] <dael> TabAtkins: Some JS calls aren't using CSS parser. CSS doesn't explicitly handle encoding
# [10:07] <SimonSapin> Not the parser, the character encodings just never emit surrogates
# [10:07] <dael> TabAtkins: So if you cann query selector unpaired get passed in. So do we want to force processing of those?
# [10:07] <dael> clilley_: Yes.
# [10:07] <SimonSapin> Note that surrogates are forbidden in UTF-8
# [10:07] <dael> TabAtkins: The risk is it's totally possible to set a class name with an unpaired from JS
# [10:07] <dael> TabAtkins: There's a chance that people may be depending on that.
# [10:08] <dael> clilley_: Then they should reap what the soe
# [10:08] <dael> dbaron: I'm more worried about extra processing passes and/or duplicating things that exist. What about web idl?
# [10:08] <clilley_> s/the soe/they sow
# [10:08] <dael> TabAtkins: I don't think have anything to say
# [10:08] <dael> dbaron: I'd like to hear what boris and heycam have to say
# [10:08] <SimonSapin> dbaron, I think WebIDL has a [EnsureUTF16] thing, or something
# [10:08] <dael> TabAtkins: Boris brought up the maybe people are querying issue
# [10:09] <dael> zcorpan: It's not clear to me what the value in banning is.
# [10:09] <dael> TabAtkins: I'm in theory okay with it. CSS just handles it.
# [10:09] <dael> zcorpan: Seems it's an extra performance cost.
# [10:09] <dael> TabAtkins: I find that acceptable.
# [10:09] <dael> TabAtkins: There's nothing spec wise that would make that problematic.
# [10:09] <dael> TabAtkins: It's just a matter of do we keep CSS unicode clean.
# [10:10] <dael> TabAtkins: If you're fine with normally clean and JS can screw things up that's fine.
# [10:10] <dael> TabAtkins: I'm fine with no change, especially b/c I'd want to handle this on the DOM side.
# [10:10] <dael> dbaron: I feel funny about a solution that's this specific.
# [10:10] <dael> dbaron: I'd like to know what the general pattern is
# [10:11] <dael> TabAtkins: I likely is that we can't change much about the DOM and therefore will mostly let you do unpaired surrigates.
# [10:11] <dael> dbaron: CSS parsing is common sense
# [10:11] <dael> TabAtkins: Yes. So. I don't know.
# [10:11] <dbaron> s/common sense/performance sensitive/
# [10:11] <dael> TabAtkins: Sounds like no change is pref. Shoudl we go with that?
# [10:11] <dael> zcorpan: I have a note in CSSOM to clarify what characters are since it doesn't say if it includes surrigates.
# [10:11] <Ms2ger> What does "JS can screw things up" mean?
# [10:12] <dael> dbaron: [mentions SimonSapin comment]
# [10:12] <TabAtkins> Ms2ger: Insert unpaired surrogates
# [10:12] <dael> zcorpan: But that's only for things that go over the network. Not things like the DOM
# [10:12] <dael> zcorpan: I think.
# [10:13] <dael> TabAtkins: Okay. Using UTF16 does the replacement and it doesn't give guidence in spec about when to usei t
# [10:13] * hober "The Lone Surrogates" was the name of TabAtkins' high school band
# [10:13] <plh> s/guidence/guidance/
# [10:13] * glazou waves at Ms2ger
# [10:13] * Ms2ger waves back
# [10:13] <dael> TabAtkins: So if we do change, WebIDL has a mechanism. There wouldn't be weird prose.
# [10:13] * Ms2ger won't walk in this time :)
# [10:13] <dael> TabAtkins: But I'm going resolve no change.
# [10:13] <dael> glaz: That probably doesn't need a resolution.
# [10:14] <dael> glaz: What else.
# [10:14] <dael> TabAtkins: There's MQ listener
# [10:14] <dael> glaz: What did we decide for font load?
# [10:14] <dael> TabAtkins: Publish LC.
# [10:14] <SimonSapin> wait, was was the result of the discussion on surrogates?
# [10:14] * dauwhe_ hober: anything used with "Lone" should be depluralized.
# [10:15] <astearns> SimonSapin: no change
# [10:15] <dael> glaz: So we do MQ now and than finsih
# [10:15] <SimonSapin> thanks astearns
# [10:15] <dael> TabAtkins: So from conf call a few weeks ago we had a question about how to handle some minor details in the semantics in events for this custom mechanism.
# [10:15] <dael> TabAtkins: That was concerning timing and calls to the listener.
# [10:16] <dael> TabAtkins: Blink is in favor of this because we have a pile of custom code and it gets missed in bug fixes.
# [10:16] <dael> TabAtkins: There were concerns about the semantics changes.
# [10:16] <dael> dbaron: I don't remember them.
# [10:16] <dael> hober: If there's aliasing that can be done in a way so that the existing MQ interface continues to work, then that's great.
# [10:16] * Joins: yamamoto_ (~yamamoto@public.cloak)
# [10:16] <dael> hober: This is shipping in multiple impl so I don't want to mess it up
# [10:17] <dael> TabAtkins: It's odd cases taht would change. Nothing normal would change.
# [10:17] <dael> TabAtkins: I'm looking up dbaron comments.
# [10:17] <SimonSapin> astearns, no change because perf?
# [10:17] <dael> zcorpan: There would be a simple change because the object would inherit and support a listener
# [10:17] <dael> hober: If you're using this interface and this wouldn't change that, it's fine.
# [10:17] <dael> TabAtkins: Okay. You had some concerns but said you were fine with it
# [10:18] <dael> dbaron: There was a thread about this in 2012 and 2014.
# [10:18] <dbaron> http://www.w3.org/mid/20120615033942.GA27405@crum.dbaron.org http://www.w3.org/mid/20140416171058.GA31844@crum.dbaron.org
# [10:18] <dbaron> but I don't see any objections I raised
# [10:18] <dael> TabAtkins: Elliott, one of our impl, is in favor.
# [10:18] <zcorpan> s/inherit and support a listener/inherit from EventListener and support addEventListener and onchange/
# [10:18] <dael> TabAtkins: We all fire in different orders, so if anyone is depending on order, they're already breaking.
# [10:19] <dael> dbaron: The plan is to make the MQ list the event target.
# [10:19] <dael> TabAtkins: Yes.
# [10:19] <zcorpan> s/EventListener/EventTarget/
# [10:19] <dael> TabAtkins: Non bubbling events fired at the MQ list
# [10:19] <dael> TabAtkins: So obj to making the switch and what should we call the event?
# [10:19] <dael> TabAtkins: Someone suggested change which is fine
# [10:20] <dael> glaz: All the other events have a discripive name, but change isn't.
# [10:20] <dael> hober: match-change or something
# [10:20] <dael> dbaron: Something to say it's not true or false?
# [10:20] <SimonSapin> call it "box node"
# [10:20] <dael> zcorpan: I don't see why it needs to be discriptive
# [10:20] <dael> dbaron: The pattern is it's fired on the object and you look at that to determine true/false
# [10:21] <dael> TabAtkins: An event is fired in both mached and unmatched cases.
# [10:21] <dael> TabAtkins: uuuuhhh...anything other than match-change
# [10:21] * clilley_ match-me-maybe
# [10:21] * Quits: yamamoto (~yamamoto@public.cloak) (Ping timeout: 180 seconds)
# [10:21] <dael> glaz: go for change.
# [10:21] <dael> TabAtkins: Cool. go for change
# [10:22] <dael> hober: I want to make sure resolution is clear we're adding API
# [10:22] <clilley_> surface: will-increase
# [10:22] <dael> TabAtkins: Make MQ lists and event target for the change event and alias the existing listener to add event listener and remove event listener
# [10:22] <dael> TabAtkins: Any obj to that?
# [10:22] <zcorpan> s/add event listener/addEventListener/
# [10:22] <zcorpan> s/remove event listener/removeEventListener/
# [10:23] <dael> hober: I don't object, I'm concerned about compat impace
# [10:23] <dael> s/impace/impact
# [10:23] <dael> RESOLVED:Make MQ lists and event target for the change event and alias the existing listener to addeventlistener and removeeventlistener
# [10:23] * Parts: yamamoto_ (~yamamoto@public.cloak)
# [10:23] <dael> glaz: Next item.
# [10:23] <dael> TabAtkins: Isn't next stop?
# [10:23] <dael> glaz: Yes.
# [10:23] * Quits: glazou (~glazou@public.cloak) ("")
# [10:23] * liam thank you for audio
# [10:24] <dael> [End of Day - Return tomorrow 9am Seoul time]
# [10:24] * Quits: abinader (~sid21713@public.cloak) ("")
# [10:25] * Quits: plh (~plh@public.cloak) ("Page closed")
# [10:26] * Quits: clilley_ (~clilley@public.cloak) ("Page closed")
# [10:26] * Quits: kangil (~d25fff94@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [10:26] * Quits: dael (~dael@public.cloak) ("Page closed")
# [10:27] * Quits: glenn (~glenn@public.cloak) ("Page closed")
# [10:27] * Quits: Matsuki (~Matsuki@public.cloak) (Client closed connection)
# [10:27] * Quits: jh_hong (~jh_hong@public.cloak) ("Page closed")
# [10:28] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [10:30] * Quits: ar (~ar@public.cloak) (Ping timeout: 180 seconds)
# [10:33] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [10:34] * Quits: shans_ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [10:38] * Quits: koji (~koji@public.cloak) (Ping timeout: 180 seconds)
# [10:40] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [10:41] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [10:45] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [10:45] * Quits: Jet (~Jet@public.cloak) (Ping timeout: 180 seconds)
# [10:46] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [10:47] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [10:49] * Quits: kyungtae (~androirc@public.cloak) (Ping timeout: 180 seconds)
# [11:01] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [11:21] * Zakim dbaron, you asked to be reminded at this time to go home
# [11:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:48] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:31] * Quits: dwim_cloud (~uid10661@public.cloak) ("Connection closed for inactivity")
# [12:42] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:49] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [13:18] * Joins: darktears (~darktears@public.cloak)
# [13:38] * Joins: dbaron (~dbaron@public.cloak)
# [13:41] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:46] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:47] * Joins: Matsuki (~Matsuki@public.cloak)
# [13:48] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [13:52] * Quits: Matsuki (~Matsuki@public.cloak) (Client closed connection)
# [13:52] * Joins: Matsuki (~Matsuki@public.cloak)
# [13:54] <zcorpan> TabAtkins: did you have a proposal for something like http://dev.w3.org/csswg/cssom-values/ ?
# [13:54] * Joins: jdaggett (~jdaggett@public.cloak)
# [13:55] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [13:59] * Quits: Matsuki (~Matsuki@public.cloak) (Ping timeout: 180 seconds)
# [14:05] * Joins: jdaggett (~jdaggett@public.cloak)
# [14:06] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:07] <TabAtkins> zcorpan: Yeah, presented it last f2f. Basically http://www.xanthir.com/b4UD0
# [14:07] <TabAtkins> zcorpan: It's blocked on JS Value Objects becoming a thing.
# [14:09] <zcorpan> oh right, js value objects
# [14:09] <zcorpan> i remember that now (though i wasn't at the prev f2f9
# [14:09] <zcorpan> s/9/)/
# [14:10] <krit> TabAtkins: ping
# [14:10] <TabAtkins> pong
# [14:11] <krit> TabAtkins: how is the style resolved for an element that is not appended in the document somewhere. Specifically em, rem or %?
# [14:11] <krit> TabAtkins: I mean how to get used value
# [14:11] <TabAtkins> % are done with a zero viewport size.
# [14:11] <TabAtkins> I don't think em/rem is well-defined.
# [14:12] <krit> TabAtkins: ok, thanks
# [14:12] <krit> TabAtkins: so we have no fallback from em/rem or you are just not sure currently?
# [14:12] <TabAtkins> Not sure. I suspect it's the initial value.
# [14:12] <krit> initial value of the property using it?
# [14:13] <TabAtkins> Nah, initial value of the user's font-size.
# [14:13] <TabAtkins> What "font-size: 1em;" gets on the root element.
# [14:14] <krit> TabAtkins: reason I am asking is http://dev.w3.org/fxtf/geometry/#issue-67a0c3ae
# [14:14] <krit> TabAtkins: a matrix is created on a Window
# [14:14] <krit> well, it is in global scope
# [14:14] <krit> If I pass a transform list as DOMString
# [14:15] <TabAtkins> Ah, then yeah, ideal behavior is to base it on a 0x0 viewport with initial values for everything.
# [14:15] <krit> TabAtkins: 1em would still require font metrics, I assume it would be the default font as well?
# [14:15] <dbaron> TabAtkins, btw, I now have animations down to 1 bikeshed error... though I'm not sure how sylvaing ran the spec -- perhaps he was using an old bikeshed version
# [14:16] <TabAtkins> krit: Yeah.
# [14:16] <TabAtkins> dbaron: What's the error?
# [14:16] <SimonSapin> perhaps bikeshed should git-pull itself before doing anything
# [14:16] <TabAtkins> Also: if you're in a hurry, you can always run `bikeshed -f spec` to force generation.
# [14:16] <dbaron> TabAtkins, FATAL ERROR: Couldn't find target document section #timing-functions:
# [14:16] <dbaron> <a href="#timing-functions" data-section=""></a>
# [14:16] <dbaron> TabAtkins, is that data-section="" a feature of bikeshed?
# [14:16] <dbaron> that's supposed to do something?
# [14:17] <krit> TabAtkins: sounds reasonable. What do you think about passing a nullable Element that, if not null, gives the relevant data (including it's viewport)
# [14:17] <TabAtkins> dbaron: Yeah, it's written as just `section` in your source code. It automatically fills the <a> with the heading's title.
# [14:17] <TabAtkins> krit: Sounds good on first blush. Send in a proposal to www-style?
# [14:17] <TabAtkins> dbaron: So I guess it can't find a heading with id=timing-functions.
# [14:17] <krit> TabAtkins: yes, will do. Will keep the issue for FPWD
# [14:18] <dbaron> TabAtkins, I think it's actually in the transitions spec
# [14:18] <TabAtkins> dbaron: Ah, yeah, don't have cross-spec section linking yet.
# [14:18] <TabAtkins> So that's just a markup error.
# [14:18] <TabAtkins> Just replace it with an ordinary <a> for now.
# [14:19] <dbaron> TabAtkins, it was in a revision you committed
# [14:19] <TabAtkins> That's confusing.
# [14:20] <dbaron> TabAtkins, https://dvcs.w3.org/hg/csswg/rev/3e45563964a5
# [14:21] <dbaron> TabAtkins, any idea what you meant?
# [14:22] <TabAtkins> ...huh. Nope.
# [14:22] <dbaron> I guess maybe the section on keyframes?
# [14:22] <TabAtkins> Maybe?
# [14:22] <dbaron> TabAtkins, ... which has the id timing-functions
# [14:22] <dbaron> TabAtkins, which makes me think this is supposed to work
# [14:23] <TabAtkins> Hahaha, the section has id=timing-funtions
# [14:24] <dbaron> TabAtkins, oh
# [14:24] <dbaron> TabAtkins, I guess I should add a compatibility anchor then...
# [14:24] <TabAtkins> I wonder how long that's been around?
# [14:24] * Zakim excuses himself; his presence no longer seems to be needed
# [14:24] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [14:25] <dbaron> hmm, it's not in the last TR draft
# [14:25] <dbaron> It was introduced in the bikeshed conversion patch
# [14:26] <dbaron> I'll just fix it
# [14:27] <dbaron> TabAtkins, any idea why my copy of bikeshed does indentation differently from sylvain's?
# [14:27] <dbaron> also mine seems to produce more </p>s
# [14:30] * dbaron tries upgrading lxml and html5lib
# [14:30] <TabAtkins> dbaron: More recent stuff.
# [14:30] <TabAtkins> I swapped out the way I handle automatic <p>s.
# [14:30] * dbaron thinks the old indentation is better
# [14:31] <TabAtkins> Don't pay attention to the generated source?
# [14:36] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [14:37] * dbaron forgot to give this power adapter to fantasai
# [14:39] <TabAtkins> She doesn't need it quite yet.
# [14:39] <TabAtkins> She says bring it tomorrow.
# [14:40] <dbaron> I could also bring it now, and thus not forget
# [14:40] <TabAtkins> Okay. Room 912, if you want.
# [14:44] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [14:49] * Joins: dholbert (~dholbert@public.cloak)
# [15:04] <krit> What is the topic in the "CSS Object Model" session? Bug fixes? New WD?
# [15:05] <zcorpan> what do you want it to be?
# [15:05] <krit> zcorpan: what I want CSS OM to be?
# [15:05] <zcorpan> no the topic
# [15:05] <krit> zcorpan: a replacement for SVG DOM :P
# [15:05] <Ms2ger> The topic replaces the SVG DOM? Good riddance
# [15:05] <zcorpan> LGTM
# [15:06] <krit> Ms2ger: ;)
# [15:06] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [15:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:11] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [15:17] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [15:55] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:58] * Joins: tantek (~tantek@public.cloak)
# [16:00] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:07] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [16:13] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:19] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:25] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [16:26] * Joins: dauwhe__ (~dauwhe@public.cloak)
# [16:26] * Quits: dauwhe__ (~dauwhe@public.cloak) ("")
# [16:27] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [16:27] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [16:27] * Quits: dauwhe_ (~dauwhe@public.cloak) ("Page closed")
# [16:30] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:33] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [16:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:41] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:44] * Quits: dauwhe (~dauwhe@public.cloak) ("")
# [17:06] * Joins: antonp (~Thunderbird@public.cloak)
# [17:15] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [17:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:46] * Joins: lmclister (~lmclister@public.cloak)
# [17:51] * Joins: rhauck (~Adium@public.cloak)
# [17:51] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:04] * sgalineau always makes sure to bring a power adapter for fantasai....
# [18:05] <Ms2ger> I'm quite sure fantasai lives off food like the rest of us
# [18:05] * sgalineau would pay to see Ms2ger feed fantasai's laptop with food
# [18:06] * sgalineau might as well use the lack of f2f to keep catching up on css-animations
# [18:06] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [18:35] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [18:49] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:50] * Joins: rhauck (~Adium@public.cloak)
# [19:01] * Joins: jcraig (~jcraig@public.cloak)
# [19:24] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [19:53] * Joins: tantek (~tantek@public.cloak)
# [20:00] * Quits: tantek (~tantek@public.cloak) (tantek)
# [20:04] * Joins: tantek (~tpod@public.cloak)
# [20:04] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [20:12] * Joins: darktears (~darktears@public.cloak)
# [20:16] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
# [20:29] * Joins: tantek (~tantek@public.cloak)
# [21:35] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:39] * Joins: tantek (~tantek@public.cloak)
# [21:50] * Joins: Garbee (~uid21171@public.cloak)
# [23:11] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [23:25] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [23:29] * Quits: lmclister (~lmclister@public.cloak) ("")
# [23:32] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:51] * Joins: dbaron (~dbaron@public.cloak)
# [23:55] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# Session Close: Tue May 20 00:00:00 2014

The end :)