15:14:39 <RRSAgent> RRSAgent has joined #css
15:14:39 <RRSAgent> logging to http://www.w3.org/2015/09/23-css-irc
15:14:57 <glazou> RRSAgent, make logs public
15:37:08 <Florian> Florian has joined #css
15:50:07 <glazou> hi Florian
15:50:20 <Florian> hi glazou
15:50:48 <antenna> antenna has joined #css
15:52:48 <Florian_> Florian_ has joined #css
15:54:34 <dael> dael has joined #css
15:56:33 <myles> myles has joined #css
15:57:08 <Bert> Bert has joined #css
15:57:27 <hyojin> hyojin has joined #css
15:57:36 <dael> ScribeNick: dael
15:57:41 <dael> present+ dael
15:58:29 <myles> present+ myles
15:58:42 <dauwhe> present+ dauwhe
15:58:46 <plinss> present+ plinss
15:59:03 <glazou> Regrets: smfr, hober, Rossen, Hiroshi Sakakibara, antonp, Michael Millee
15:59:06 <glazou> present+ glazou
15:59:17 <dauwhe> s/Millee/Miller/
15:59:26 <hyojin> present+ hyojin
15:59:44 <astearns> present+ astearns
16:00:14 <gregdavis> gregdavis has joined #css
16:00:18 <gregwhitworth> gregwhitworth has joined #css
16:01:22 <AndreyR> AndreyR has joined #css
16:01:31 <dbaron> dbaron has joined #css
16:01:45 <gregwhitworth> present+
16:02:25 <dbaron> Present+ dbaron
16:03:15 <alex_antennahouse> alex_antennahouse has joined #css
16:03:24 <gregdavis> present+ gregdavis
16:04:01 <antenna> hello
16:04:05 <antenna> present+ antenna
16:04:17 <tgraham> present+ tgraham
16:04:37 <alex_antennahouse> present+ alex_antennahouse
16:04:50 <SteveZ> SteveZ has joined #css
16:05:13 <dael> glazou: Let's start
16:05:36 <dael> glazou: First thing, gregwhitworth I saw your request, but as you said it came in late so maybe it's good to let people review.
16:05:39 <dael> gregwhitworth: Sure.
16:05:46 <dael> glazou: I'll make sure this is added to next week.
16:05:50 <dael> gregwhitworth: Okay.
16:05:57 <dael> glazou: Any other additions?
16:06:05 <dael> Topic: resize on replaced elements
16:06:06 <glazou> https://lists.w3.org/Archives/Public/www-style/2015Aug/0333.html
16:06:15 <dael> glazou: fantasai are you on?
16:06:24 <dael> glazou: No. Can someone?
16:07:14 <dael> Florian_: For the moment resize only applies to elements that have overflow of something other than visiable. Applying it on images or videos makes sense, on iframes too, so the proposal is to make it apply to replaced elements. There might be difficult for form elements, for things like a button it may be less useful.
16:07:35 <glazou> q+
16:07:44 <dael> Florian_: It might even be harmful on very small form elements like a checkbox where the UI for the broswer could be as large as the control and it messes up the interaction.
16:07:52 <glazou> plh: you’re on the queue ?
16:08:00 <dael> Florian_: Prob no one is trying this on the web, but there is mild compat concern. Generally it makes sense to me.
16:08:26 <dael> glazou: You said you wanted to extend to replaced elements and you mentioned elements that are not replaced.
16:08:29 <dael> Florian_: Did I?
16:08:38 <dael> glazou: Form elements that are not replaced.
16:08:49 <dael> Florian_: Some are and some aren't, maybe I'm wrong on which.
16:08:53 <dael> glazou: Checkboxes are not.
16:08:58 <koji> Present+ koji
16:09:02 <dael> Florian_: Okay, that helps. I think we have a list somewhere.
16:09:05 <dael> glazou: I'm not sure we do.
16:09:12 <dael> dbaron: I don't think we have agreement on what is replaced.
16:09:18 <fantasai> Present+ fantasai
16:09:46 <dael> Florian_: In general if it just applies on something not useful, but no harmful I don't see a problem. But if it would apply to things on which the resize handle would disturb the interaction its' bad.
16:09:57 <dael> glazou: I'd be happy to see resize apply to images, videos and iframes.
16:10:05 <dael> Florian_: So maybe we make it explicit for those three.
16:10:21 <dael> glazou: Implementors? fantasai said +1
16:10:25 <dael> myles: It's fine to me.
16:10:31 <gregdavis> +1
16:10:33 <dael> glazou: Other opinions?
16:10:39 <Bert> present+ Bert
16:10:48 <dael> gregwhitworth: I'd prefer a whitelist where we add those three where the use case makes sense.
16:11:05 <dael> Florian_: Yeah, maybe. It might be okay with replaced elements, but without a list it's difficult to check.
16:11:09 <bcampbell> bcampbell has joined #css
16:11:18 <dael> gregwhitworth: I'm okay with iframes, imanges and videos. Yeah.
16:11:21 <dael> glazou: what about canvas?
16:11:27 <dael> fantasai: It's an image, right?
16:11:33 <dael> Florian_: Yeah...
16:11:46 <dael> glazou: Resizing the canvas could effect the zoom factor when you draw inside.
16:11:52 <TabAtkins> Oh yeah, sorry, +1 from Chrome on adding resize to replaced elements.
16:11:55 <dael> fantasai: Still...then don't set it on a thing that can't be resized.
16:12:13 <dael> Florian_: I don't expect there are a lot of style sheets trying to apply resize to a canvas that's not resizable.
16:12:30 <TabAtkins> Resizing canvas is fine. It just scales it via CSS, no problem.
16:12:32 <fantasai> <img>, <object>, <iframe>, <canvas>
16:12:38 <dael> glazou: There's consensus to add images, videos, and iframes to resize. is that reasonable to everyone?
16:12:39 <TabAtkins> <video>
16:12:49 <dael> Florian_: These elements, or these type of things?
16:13:00 <TabAtkins> Oh, and <svg>!
16:13:01 <dael> glazou: That's the point I was making.
16:13:14 <dael> fantasai: It should be the types of things that go into these tags.
16:13:17 <vollick> vollick has joined #css
16:13:25 <dael> glazou: TabAtkins is right because there's svg images. It's not just img.
16:13:45 <dael> fantasai: Wecan list the tags and state a replaced element is this type of element and if it's introduced some other way it qualifies.
16:13:49 <dael> glazou: Any obj to that?
16:14:09 <dael> RESOLVED: extend resize to <img>, <object>, <iframe>, <canvas>, <video>, <svg>
16:14:12 <dael> glazou: Who will do it?
16:14:16 <dael> Florian_: I will for 4.
16:14:25 <dael> fantasai: We might want to put in 3 that a UI may do it.
16:14:42 <dael> glazou: shall we resolve we need a note in level 3 that a UI may extend resize in level 4.
16:14:49 <dael> Florian_: I'd do it as normative prose.
16:14:52 <dael> glazou: Okay.
16:14:58 <dael> glazou: Other opinions, objections?
16:15:19 <dael> RESOLVED: add normative prose in level 3 that a UI may extend resize in level 4
16:15:27 <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0099.html
16:15:33 <dael> Topic: implementability of computed value rules for align/justify-self/items
16:15:41 <fantasai> s/in level/as described for/
16:15:42 <dael> glazou: dbaron this is yours
16:16:02 <dael> dbaron: Do we think this is useful to discuss on the telecon?
16:16:08 <dael> glazou: It was leftover from last week.
16:16:15 <dael> glazou: If you don't think it is...
16:17:04 <dael> dbaron: My comment was that the way the computed values of a bunch of the prop in align works seems hard to impl for us because they're unusual in ways we haven't done before and we have optmization that rely on not doing those things. WE could hack around but it may be useful to make those less magical properties.
16:17:15 <dael> dbaron: That's more thinking then talking on telecon.
16:17:27 <dael> glazou: TabAtkins said he'd reply. But he's not here right now.
16:17:32 <dael> dbaron: I dont' see a reply on the list.
16:17:44 <bradk> bradk has joined #css
16:17:45 <TabAtkins> I haven't rpelied yet, no. Was sick most of last week.
16:17:45 <dael> Topic: Houdini at TPAC
16:18:16 <dael> glazou: There were some suggestions to meet on Thursday or Friday, but some of use will be at other WG and some will leave. I have no followed the current status, can someone summerize?
16:18:23 <dael> glazou: We don't have Rossen. Right.
16:18:42 <dael> Florian_: I think current status is we should try and meet. Days with CSS WG aren't good, ther rest is fuzzy.
16:19:09 <gregwhitworth> https://github.com/w3c/css-houdini-drafts/wiki/TPAC-F2F-October-2015
16:19:17 <dael> glazou: We'll all be busy all the days. We already have AC and AB meeting overlap. Plenary day is for that. There's the meetup on Sunday. The number of available slots is decreasing quickly.
16:19:38 <TabAtkins> I don't personally think we'll need anything beyond a plenary-day meetup.
16:19:58 <SimonSapin> Present+ SimonSapin
16:20:09 <dael> gregwhitworth: Rossen asked on the list, we agreed at Paris to get together for a could of hours on the plenary day. The link is to the wiki and we were trying to get a sense of who would be there. We were trying to get a sense of would the right people be there. There may not be a reason to talk about those extra days.
16:20:24 <dael> gregwhitworth: If people would put in if they're interested and capable it would help to put it in.
16:20:42 <dael> glazou: On the plenary day there will be breakout sessions and I think there's two consecutive ones on the Wednesday.
16:21:07 <fantasai> gregwhitworth, Doodle link? http://doodle.com/poll/4acs3t47cfp4vc5z
16:21:14 <dael> gregwhitworth: That's what we agreed to, dino was looking for more. If you're able to attend Thursday or Friday or neither, put it on the wiki and that way we can see if there are even enough people.
16:21:22 <dael> glazou: Okay. Let's do that.
16:21:32 <dael> fantasai: I'll link the doodle to the wiki.
16:21:35 <dael> glazou: Okay.
16:21:42 <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JulSep/0260.html
16:21:45 <dael> Topic: computed value for text-orientation: sideways or sideways-right
16:22:40 <dael> koji: sideways and sideways right. We are planning to do it as an alias. When we do getComputedStyle() we want one of them to be canonicalized value, but which one?
16:22:58 <dael> koji: Florian_ and I prefer sideways because it's shorter.
16:23:48 <dael> Florian_: I think sideways-right is for legacy reasons and we may want to drop it from the spec if there's no content depending on it. I thinkt here is so we're keeping it. I don't have an opinion as to if they should be aliases or sep/ values, but if they are alias it should go to sideways which is the value people should be using.
16:23:53 <dael> glazou: Other opinions?
16:24:11 <bradk> Who let the dogs out?
16:24:21 <dael> glazou: Proposal is sideways. Objection?
16:24:42 <dael> Florian: So first prop is treat as aliases. Second is what do they compute to?
16:24:49 <dael> glazou: So comments on the two proposals?
16:25:06 <dael> gregwhitworth: Can I not obj but get feedback? I don't have much knowledge in this space.
16:25:12 <dael> glazou: That's fine. Is a week okay?
16:25:31 <dael> gregwhitworth: I think you can discuss and come to what people agree upon. I can talk to the powers that be and see if it's an issue for us.
16:25:37 <fantasai> am I muted?
16:25:53 <fantasai> Okay, I guess I'm muted.
16:26:04 <dael> myles: What is our historical policy on multi values that mean the same things?
16:26:19 <dael> fantasai: I think this won't effect MS becuase you don't impl text-orientation yet.
16:26:25 <dael> gregwhitworth: That's good to know.
16:27:47 <dael> fantasai: I think this is a case where we want to drop sideways-right now that we have sideways. WE just need one thing to distinguish and having it called sideways is the best. sideways-right is now identicial to sideways. It makes sense to have one value. We may have legacy content, but we should do that in the way that is easiest for UA which is to compute to canonical value.
16:27:59 <dael> Florian: And that case is most likely epub and they prefix.
16:28:09 <dael> koji: Mongolian is prob. using it as well.
16:28:16 <dael> Florian: Is there web content using Mongolian?
16:28:19 <dael> koji: Yes.
16:28:22 <dael> Florian: Okay.
16:28:38 <dael> glazou: Given what we said, Florian Can you sum?
16:29:08 <dael> Florian: It's to drop sideways-right, just desc sideways as what it used to do. Say for legacy compat UA may support sideways-right value that does the same thing and computes to sideways.
16:29:44 <dael> fantasai: Works for me. OTher opion was sideways computes to sideways-right. The arguement for that is we might have sideways-left in the future and it's symetric.
16:30:01 <dael> koji: Works for me too.
16:30:54 <dael> Florian: The counter arguement is sideways-left prob won't be needed in the future because the main use case is addressed through writing modes. Even if we needed that it's not symentrics because it rotates the baseline. So I don't think we're locking ourselves out because there are other good names becides left.
16:31:04 <Bert> (I can't judge the legacy situation, but Florian's formulation sounds good to me, i.e., 'sideways' is the value and 'sideways-right' may be accepted on input, but isn't in the OM.)
16:31:05 <dael> glazou: Any other comments or objections?
16:31:21 <dael> glazou: Given the number of people able to discuss it I'll decalre consensus
16:31:34 <dael> RESOLVED: describe sideways as what sideays-right used to do. Say for legacy compat UA may support sideways-right value that does the same thing and computes to sideways.
16:31:46 <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0002.html
16:31:48 <dael> glazou: Next two items are from ww-style. We thought they could use time.
16:32:04 <dael> Topic: float pushed to next fragmentainter, what about siblings?
16:32:12 <dael> Florian: This is probl worth talking about.
16:33:05 <estellevw> estellevw has joined #css
16:33:09 <dael> Florian: The issue is that when a float won't fit and we push to next fragmentainer, what happens to the countent around it? The first answer that seems obvious is that the content stays and the float moves. But if there are other floats after it, but smaller, if we leave them behind we have out of order floats and we might want that to happen.
16:33:46 <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Sep/0146.html
16:34:09 <dael> fantasai: We looked at a couple of test cases that leaned toward not pushing content. If you have some floats and you clear a float that that pushes it down to the next line, that doens't push the content, just the float. So I concluded that hte float moves, but it doesn't take the content after and that's what Gecko does.
16:34:34 <dael> Florian: For inline content that seems okay. But should we say if the neighboring content contains floats they also get moved to the next fragmentainer?
16:34:42 <dael> fantasai: It's prob easier to be consistent about it.
16:35:09 <dael> astearns: What about Morten's comment about positioned floats not being able to go above the previous float's top.
16:35:21 <dael> fantasai: I would do whatever CSS2.1 says to do and not add anything more.
16:35:55 <dael> dbaron: One of the issues is pages are often printed, even if not designed for it, so it's best for things to stay in relative positions. Which I think argues for keeping the same float ordering rules.
16:36:06 <dael> Florian: So does CSS2.1 mandate that floats stay in order?
16:36:08 <fantasai> " The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document. "
16:36:23 <dael> dbaron: It's done throught he top thing, but I've inter. that applying across fragments as well.
16:36:48 <fantasai> http://www.w3.org/TR/CSS21/visuren.html#float-position
16:36:49 <dael> fantasai: That's covered. When you push down a float subsiquent floats have to move, but text doesn't. So that covers the case where floats are being used for layout.
16:37:16 <dael> Florian: Sounds good to me. Do we need a resolution for the first part? Sibling content that isn't floated stays in the fragmentaner, or is that already there?
16:37:21 <dael> fantasai: We might as well resolve.
16:37:33 <dael> glazou: Can someone type the exact prose of the suggested resolution?
16:37:38 <fantasai> RESOLVED: Moving a float to the next fragmentainer does not move in-flow content that comes after the float.
16:37:52 <fantasai> (However, per CSS2.1, subsequent floats do move down.)
16:37:57 <Bert> +1 to that
16:38:03 <dauwhe> +1
16:38:03 <dael> glazou: So before it's actuallyr esolved, let's let people read it and obj if they want.
16:38:06 <dael> Florian: Sounds good.
16:38:25 <dael> RESOLVED: Moving a float to the next fragmentainer does not move in-flow content that comes after the float. (However, per CSS2.1, subsequent floats do move down.)
16:38:33 <dael> glazou: Okay, second part?
16:38:51 <dael> Florian: I think the between parents is included in the resolution.
16:38:59 <dael> fantasai: We don't need to re-resolve becuase it's in 2.1
16:39:10 <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0106.html
16:39:13 <dael> Topic: clarification prop for border colors
16:39:24 <dael> glazou: adenilson sent this.
16:39:30 <tantek> tantek has joined #css
16:39:40 <dael> glazou: There was some discussion on www-style, but I'm not sure enough for a decision.
16:40:30 <dael> fantasai: I think we can't really prescribe anything, but can point out that colors close to black or white may need a different color computation to make the border visable. Blink is non compat anyway becuase they draw a solid black line which isn't 3D.
16:40:46 <dael> fantasai: I'm okay to clarify the spec, but I'm not comfortable with anything more specific.
16:41:11 <fantasai> s/spec/spec to say that colors close to black or white need special handling/
16:41:17 <dael> glazou: adenilson says the Blink fix was denied...I think the issue is the lack of specification is blocking the interop.
16:41:22 <dael> fantasai: Well tey're non-conformant.
16:41:37 <dael> glazou: I agree with you on one hand, but this is common enough that we should have some specification.
16:41:52 <dael> fantasai: If someone wants to eval the existing impl and see what they actually do...
16:42:10 <bradk> Seems like the line should be lightened on one side and darkened on the other, but I guess no browsers do that.
16:42:13 <dael> glazou: I'm not sure we'll have one algo for everyone. If we have a spec in the future will the minority peopleb e willing to change.
16:42:19 <dbaron> I think it might be worth finding out what the different browsers do
16:42:28 <dael> fantasai: I don't think it's worth dealing with now, we can deal with it in the future if someone wants to.
16:42:44 <dael> glazou: I'll report this to adenilson and if he can spend time that's great.
16:42:51 <tantek> present+ tantek
16:43:15 <dael> fantasai: And I would put this in level 4. I'm happy to clarify in level 3 you can't make it solid black. It's already in the spec, but maybe not clear. An algo goes in level 4 and I honestly don't care enough to work on it.
16:43:16 <tantek> is there a test case?
16:43:27 <Bert> (The shadow color was originally left vague on purpose, so implementations could use whatever was common on the platform, if anything. E.g., if the platform had a contrast setting.)
16:43:29 <gregwhitworth> Tantek: http://codepen.io/Savago/pen/wBKRaX
16:43:32 <dael> Florian: There's no problem adding what you said to level 3, if this is enough to get people to fix we can deal with later.
16:43:42 <dael> glazou: Other opinions about the proposal?
16:43:47 <tantek> looking at test case
16:43:50 <tantek> URL to proposal?
16:43:55 <dael> glazou: Comments, objections, +1, -1?
16:44:09 <dbaron> what's the proposal?
16:44:11 <tantek> hah - we got this right in IE5/Mac
16:44:13 <tantek> who is complaining?
16:44:21 <dael> glazou: Since we have an issue in the spec anyway, I think we should have the clarification
16:44:28 <dael> RESOLVED: clarify in level 3 you can't make it solid black
16:44:33 <dael> glazou: fantasai will you edit?
16:44:36 <dael> fantasai: Yeah.
16:44:39 <gregwhitworth> tantek: in my opinion IE/MS Edge looks the best, it's black with a slight lightning of the black for the highlight areas
16:44:43 <dael> glazou: Great. I'll report to adenilson.
16:44:53 <dael> glazou: That's it for the agenda. Anything to discuss?
16:45:05 <dael> gregwhitworth: Can we cover the control characters?
16:45:20 <glazou> https://lists.w3.org/Archives/Public/www-style/2015Sep/0215.html
16:45:27 <tantek> gregwhitworth: I think FF rendering of black groove looks pretty good too
16:45:37 <tantek> Safari/Webkit shows all black :/
16:45:41 <dael> gregwhitworth: Everybody is aware of what it is, I wanted to call it out. FF and Chrome are shipping the change in Dec. roughly so he wanted to make sure the release was timed. I wanted to call that out for TabAtkins to reply.
16:46:00 <dael> gregwhitworth: I agree we shouldn't stop them, but do we want to give webdev only 2 months to be away of this breaking change?
16:46:30 <adenilson> adenilson has joined #css
16:46:38 <dael> fantasai: It's not a huge breaking change. It only breaks things that are broken. It's up to the Bink and FF teams. If they're okay witht he double cooridanted, that's fine. If they'd like to loop in others wait is fine as well.
16:46:50 <dael> fantasai: It's up to them how much...they're be the ones taking the flack.
16:47:36 <dael> gregwhitworth: I'm not bringing this up as a MS/Safari thing, it's more for the webdevs. As a previous webdev getting boxes that suddenly appear on a client's site is bad. Do we wantt o give more time for webdev to know so that they know.
16:47:47 <dael> Florian: If it's Dec. the PR push needs to go out now.
16:48:08 <dbaron> So given greg's latest message, Jonathan Kew thought maybe we needed to postpone the change.
16:48:18 <dael> gregwhitworth: I agree. I would have liked to to start months ago. We'll still do this for us because we're still a bit away. But this was more as a web dev concern.
16:49:04 <dael> dbaron: I think Jonathan was confused by different things in different e-mails, but I think he's leaning postponing a bit. I think he could go either way. Given Greg's e-mail he added a flag.
16:49:48 <dael> gregwhitworth: And on our side we're going back and forth because people aren't sure it's good. If TabAtkins could reply so we know where it stands and if we need to start the PR beat. MS will help with that because it's important to get out there.
16:49:54 <dael> gregwhitworth: That's good. I brought it up.
16:50:17 <dael> Florian: Process topic- when we announce spec releases we have the twitter account that we share by sharing passwords. Should we do it a better way.
16:50:28 <tantek> why mess with what works?
16:50:31 <gregwhitworth> \s\"on our side"\on the blink dev forum they aren't sure it's worth the change because it's mainly about spec purity
16:50:32 <dael> glazou: So you're suggesting something like tweetdeck. I don't like that because it forces people to use one app.
16:50:38 <dael> Florian: It's one from twitter.
16:50:52 <tantek> what problem are we solving?!?
16:50:59 <astearns> +1 to tantek - let's fix it when we have a problem
16:50:59 <dael> Florian: tantek asks why mess with what works. The way we do it with telling a password it might eventually leak.
16:51:06 <dael> glazou: I don't see it as a big problem.
16:51:20 <dael> gregwhitworth: If they change the password first....Or are you guys verified?
16:51:29 <dael> Florian: No. Somebody could steal the account.
16:51:41 <dael> tantek: I've had my twitter stole and I got it back in less than 24hr
16:52:01 <dael> glazou: This is a guy who has a one character twitter account. You can't compete.
16:52:19 <dael> gregwhitworth: I know! I still agree with Florian but it's not worth spending a ton of time on this.
16:52:27 <dael> glazou: I'm not sure I agree.
16:52:40 <dael> Florian: I can live with the current state of the world, I don't think it's great.
16:53:04 <dael> glazou: Speaking of announcements, the editors of a published spec are supposed to announce it on www-style.
16:53:09 <dael> Florian: The the blog and twitter.
16:53:17 <dael> glazou: The MINIMUM is www-style.
16:53:21 <dael> glazou: Anything else?
16:53:22 <gregwhitworth> tantek: that's a possibly valid point
16:53:26 <fantasai> http://wiki.csswg.org/spec/publish
16:53:30 <dael> glazou: Okay, thank you very much and talk to you next week!
16:53:50 <bradk> bradk has left #css
16:55:12 <hyojin> I'll leave some issue of CSS Round Display on www-style. See you next week :)
17:15:31 <vollick> vollick has joined #css
17:23:56 <vollick> vollick has joined #css
18:03:59 <bcampbell> bcampbell has joined #css
18:11:03 <dbaron> dbaron has joined #css
19:03:16 <dbaron> dbaron has joined #css
19:14:07 <nvdbleek> nvdbleek has joined #css
19:23:30 <dauwhe> dauwhe has joined #css
19:34:36 <zcorpan> zcorpan has joined #css
19:39:31 <myles> myles has joined #css
19:42:42 <Florian> Florian has joined #css
19:44:41 <bcampbell> bcampbell has joined #css
19:48:10 <dauwhe> dauwhe has joined #css
20:02:05 <dbaron> dbaron has joined #css
20:22:07 <myles> myles has joined #css
20:30:30 <myles> myles has joined #css
21:44:01 <Florian> Florian has joined #css
21:49:53 <dbaron> dbaron has joined #css
21:57:06 <dauwhe> dauwhe has joined #css
22:17:21 <dbaron> dbaron has joined #css
22:27:01 <tgraham> tgraham has joined #css
22:38:12 <darktears> darktears has joined #css
22:42:11 <dbaron> dbaron has joined #css
22:53:04 <zcorpan> zcorpan has joined #css
23:08:18 <Hixie> Hixie has joined #css
23:18:59 <myles> myles has joined #css
23:19:56 <myles1> myles1 has joined #css
23:20:08 <myles> myles has joined #css
23:21:23 <dbaron> TabAtkins, yeah, I know... I'm hoping I can get to going through that next week
23:23:29 <TabAtkins> dbaron: kk
23:23:49 <dbaron> I actually have a whole 4 weeks without travel (I think... or maybe just 3)
23:25:00 <bcampbell> bcampbell has joined #css
23:29:39 <Florian> Florian has joined #css
23:33:05 <myles> myles has joined #css
23:37:34 <TabAtkins> dbaron: Yay!  I, on the other hand, am soon to enter an entire month of continuous travel.
23:37:58 <dbaron> TabAtkins, I believe I've been at home less than half the time from May 1 to the present
23:38:57 <TabAtkins> omg
23:39:07 <TabAtkins> my wife would leave me if I did that
23:39:37 <TabAtkins> I limit myself to less than 2 months gone per year.
23:39:56 <TabAtkins> And try my hardest to do no more than a week gone at a time.