[00:20:30 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work <colinclark> So the class is simply a way to denote it, so that you don't have to write your own code like this in each page you want to progressively enhance: $("head").append("<style type='text/css'>.fl-progressive-enhanceable </style>");
[00:30:49 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[01:03:03 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[01:15:22 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[01:17:30 EST(-0500)] * phiggins__ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[02:10:39 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[02:22:42 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[02:47:57 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[05:21:53 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[05:57:21 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[06:02:40 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[06:32:09 EST(-0500)] * phiggins (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[06:54:39 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has joined #fluid-work
[06:56:07 EST(-0500)] * phiggins_ (n=dante@c-71-229-123-70.hsd1.fl.comcast.net) has left #fluid-work
[08:50:53 EST(-0500)] <Bosmon> blug
[08:55:16 EST(-0500)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:26:42 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:52:13 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:58:10 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:18:31 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:23:35 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279621226.dsl.bell.ca) has joined #fluid-work
[11:09:17 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[11:19:13 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:26:48 EST(-0500)] <michelled> jacobfarber: did you say that there is a reorderer in the sakai example?
[11:30:34 EST(-0500)] <jacobfarber> yes, I think so
[11:30:47 EST(-0500)] <jacobfarber> im going to ask nico now
[11:31:22 EST(-0500)] <michelled> what about in the example we ship in our sample code?
[11:31:47 EST(-0500)] <jacobfarber> nico says yes
[11:32:17 EST(-0500)] <jacobfarber> so we should demo that too in this sakai sample-code page
[11:32:36 EST(-0500)] <michelled> makes sense
[11:34:52 EST(-0500)] <jacobfarber> gotta run, back in 30
[11:37:50 EST(-0500)] <michelled> k
[12:01:30 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-44.LIPS.Berkeley.EDU) has joined #fluid-work
[12:29:17 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[12:58:14 EST(-0500)] * hydee (n=hydee@bas10-ottawa23-1177650188.dsl.bell.ca) has joined #fluid-work
[12:59:16 EST(-0500)] <hydee> hi everyone. am reading http://docs.jquery.com/Post and wondering why the php file uses $_GET
[14:23:24 EST(-0500)] <jacobfarber> hydee: have you tried using $_POST and getting the right results?
[14:24:02 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:24:41 EST(-0500)] <hydee> haven't tried - not sure i'm gonna go that route anymore... think it's a documentation error or it submits both ways or?
[14:25:57 EST(-0500)] <jacobfarber> ok
[14:30:30 EST(-0500)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[15:20:05 EST(-0500)] <colinclark> hydee: I missed your question earlier, but if I had to guess, that $_GET is a cut and paste error in jQuery's documentation..
[15:20:10 EST(-0500)] <colinclark> ecochran: Hey.
[15:20:36 EST(-0500)] <colinclark> So In standup this morning, I quickly summarized an idea I have for the flow of instantiation for the Uploader.
[15:20:52 EST(-0500)] <ecochran> colinclark: I'm listening
[15:20:56 EST(-0500)] <colinclark> Here it is:
[15:21:26 EST(-0500)] <colinclark> 1. Include a basic <input type="file"> control in Uploader's template markup.
[15:21:38 EST(-0500)] <colinclark> 2. Use swfobject.js to detect Flash versions > 8
[15:22:21 EST(-0500)] <colinclark> 3. If we're 8 or lower, just use the basic HTML control. If we're using a supported version of Flash, hide the control and show the full Uploader markup.
[15:22:45 EST(-0500)] <colinclark> 4. If we've got Flash 9, use the familiar strategy of just pure HTML buttons.
[15:22:58 EST(-0500)] <colinclark> 5. If we're using Flash 10 in IE, use a visible Flash button so we are AT friendly.
[15:23:06 EST(-0500)] <colinclark> 6. And finally, go with a Flash transparent overlay.
[15:23:16 EST(-0500)] <colinclark> Thats the ideal, anyway.
[15:25:02 EST(-0500)] <ecochran> that makes sense...
[15:25:09 EST(-0500)] <ecochran> In Uploader 1, I did not try to support Flash 8. We didn't test with it and it doesn't give good user feedback and some of the events are missing.
[15:25:14 EST(-0500)] <ecochran> colinclark: ^
[15:25:36 EST(-0500)] <colinclark> ecochran: That's my point. Flash 8 isn't supported.
[15:25:51 EST(-0500)] <ecochran> OK, greater than 8, cool
[15:27:08 EST(-0500)] <colinclark> And then, later on, we can imagine adding a check for gears at the top of all of this, and preferring the use of it in place of Flash.
[15:27:36 EST(-0500)] <colinclark> But you were right at the summit that we'll likely not get to it for 0.6 final.
[15:27:41 EST(-0500)] <colinclark> Unless I have a really good weekend. 
[15:27:48 EST(-0500)] <ecochran> so the check for gears would be automatic, not a choice for the developer?
[15:28:04 EST(-0500)] <ecochran> or auto and/or a choice
[15:30:58 EST(-0500)] <ecochran> colinclark: all my bug parade bugs for Uploader are done, there are still bugs there but they are directly related to the Flash 10 work that you are doing
[15:31:10 EST(-0500)] <colinclark> ecochran: That's great.
[15:31:17 EST(-0500)] <ecochran> I'm going to start looking at some of the other critical Uploader issues
[15:31:21 EST(-0500)] <colinclark> Have you taken a look through the issues listed under FLUID-1083?
[15:31:27 EST(-0500)] <colinclark> You can filter it by all the open issues.
[15:31:31 EST(-0500)] <colinclark> Which makes it way easier to follow.
[15:31:40 EST(-0500)] <ecochran> I'll look now
[15:31:41 EST(-0500)] <colinclark> I'm really really excited about Uploader.
[15:31:46 EST(-0500)] <colinclark> That was my standup update today.
[15:31:59 EST(-0500)] <colinclark> I drank a whack of coffee this morning, then got really excited to see all the bugs you've squashed.
[15:32:09 EST(-0500)] <colinclark> Uploader is getting so hot!
[15:32:40 EST(-0500)] <ecochran> it is at that...
[15:32:53 EST(-0500)] <ecochran> I would still like to get the Stop Upload button working
[15:33:33 EST(-0500)] <colinclark> ecochran: That makes sense.
[15:33:36 EST(-0500)] <colinclark> Should be pretty easy.
[15:33:59 EST(-0500)] <colinclark> DemoUploadManager already has a cancel() method.
[15:34:05 EST(-0500)] <colinclark> It probably should be renamed.
[15:34:44 EST(-0500)] <anastasiac> Bosmon, you're working on Pager, right?
[15:35:00 EST(-0500)] <colinclark> ecochran: Then you'd need to fill in an implementation in SWFUploadManager.
[15:35:09 EST(-0500)] <colinclark> Also fairly straightforward, as far as I can remember.
[15:35:20 EST(-0500)] <ecochran> there are some interesting bugs still left in 1083, mostly very picky stuff, and some cosmetic or partially cosmetic bugs that I'm waiting on some design work from Erin (better messaging)
[15:35:24 EST(-0500)] <Bosmon> Hello
[15:35:25 EST(-0500)] <ecochran> colinclark: yep
[15:35:27 EST(-0500)] <Bosmon> Has the question arrived yet?
[15:35:28 EST(-0500)] <Bosmon> 
[15:35:47 EST(-0500)] <anastasiac> Have you been keeping the Pager tests up to date with the changes you've been making?
[15:35:55 EST(-0500)] <Bosmon> Pager tests??!!
[15:35:56 EST(-0500)] <ecochran> colinclark: I have to run out for lunch and I'll get on this right after... I have a long afternoon ahead of me
[15:36:07 EST(-0500)] <colinclark> ecochran: Yep, I know the feeling.
[15:36:17 EST(-0500)] <anastasiac> yes, there are pager tests
[15:36:19 EST(-0500)] <colinclark> I'd say avoid the stuff you know will change and try to focus on severity.
[15:36:22 EST(-0500)] <Bosmon> I never dreamed
[15:36:29 EST(-0500)] <Bosmon> It did so essentially nothing
[15:36:37 EST(-0500)] <colinclark> Bosmon: Hey, I kept them passing when I was refactoring it.
[15:36:44 EST(-0500)] <Bosmon> You are a rotter
[15:37:10 EST(-0500)] <colinclark> Remind me of your cool cop names again.
[15:37:15 EST(-0500)] <colinclark> British cop names.
[15:37:20 EST(-0500)] <ecochran> colinclark: yep, which is why I asked you about, damn, I've already forgotten the number 8-something
[15:37:28 EST(-0500)] <Bosmon> ?
[15:37:29 EST(-0500)] <Bosmon> Rozzer?
[15:37:32 EST(-0500)] <colinclark> That's it!
[15:37:34 EST(-0500)] <Bosmon>
[15:37:42 EST(-0500)] <Bosmon> Yes, we should send in the rozzers
[15:37:50 EST(-0500)] <colinclark> The unit testing rozzers.
[15:37:54 EST(-0500)] <Bosmon> Right
[15:37:59 EST(-0500)] <Bosmon> JUnit Bluebottles
[15:38:45 EST(-0500)] <anastasiac> ok. I'm working on upgrading jquery ui, and I wanted to make sure that wasn't the cause of the failures
[15:38:46 EST(-0500)] <colinclark> I am also enthusiastic about seeing a test for Reorderer.refresh() some day. 
[15:38:51 EST(-0500)] <colinclark> It will be awesome!
[15:39:12 EST(-0500)] <Bosmon> I guess I should be glad for this positivity
[15:39:24 EST(-0500)] <Bosmon> Since I guess the alternative should be less fun
[15:39:34 EST(-0500)] <colinclark>
[15:39:41 EST(-0500)] <Bosmon> There are now a zillion framework features without test cases
[15:39:57 EST(-0500)] <Bosmon> I just added 6 more
[15:40:06 EST(-0500)] <colinclark> Bosmon: It is something we do seriously need to address.
[15:40:12 EST(-0500)] <Bosmon> Yes
[15:40:58 EST(-0500)] <colinclark> I mean, we can only do so much at this stage, but we are good at testing. So there is no reason not to exercise our testing might.
[15:41:20 EST(-0500)] <Bosmon> Duty, duty, must be done, the rule applies to every-one
[15:41:24 EST(-0500)] <colinclark>
[15:41:27 EST(-0500)] <Bosmon> To shirk the task, for fiddle-de-dee
[15:41:34 EST(-0500)] <Bosmon> To shirk the task, for fiddle-de-dee
[15:41:56 EST(-0500)] <Bosmon> To shirk the task, for fiddle-de, fiddle-de, fiddle-de, fiddle-de-deeee!
[15:42:00 EST(-0500)] * colinclark is dancing.
[15:42:09 EST(-0500)] <colinclark> To the weird unit testing song.
[15:42:14 EST(-0500)] <Bosmon> Actually there should be 7 fiddle-des there.....
[15:42:29 EST(-0500)] <anastasiac> With vigour unshaken
[15:42:29 EST(-0500)] <anastasiac> This step shall be taken
[15:42:33 EST(-0500)] <Bosmon> yes!!
[15:43:10 EST(-0500)] <Bosmon> The lyrics page is clearly missing one "fiddle-de"
[15:44:22 EST(-0500)] <Bosmon> http://math.boisestate.edu/gas/ruddigore/images/0033.jpg
[15:44:32 EST(-0500)] <Bosmon> This is what the weird unit testing dance looks like
[15:46:32 EST(-0500)] <colinclark> Bosmon: Hey look, it's you and Jim Eng!
[15:46:37 EST(-0500)] <colinclark> Dancing in the street!
[15:47:16 EST(-0500)] <Bosmon> !??!
[15:47:24 EST(-0500)] <Bosmon> It's so hard to tell us apart.....
[15:49:32 EST(-0500)] <colinclark> You do remember Ann Arbor.
[15:50:19 EST(-0500)] <Bosmon> Well, it is a bit of a haze
[15:51:43 EST(-0500)] <colinclark> We are celebrating anastasiac's birthday here...
[15:51:51 EST(-0500)] <Bosmon> Oh, that is great
[15:51:59 EST(-0500)] <colinclark> and rather than "happy birthday," the suggestion was to sing the unit testing song.
[15:52:01 EST(-0500)] <Bosmon> I expect there is a good deal of chocolate
[15:52:04 EST(-0500)] <Bosmon> Hah
[15:52:10 EST(-0500)] <colinclark> It is a carrot cake today.
[15:52:21 EST(-0500)] <Bosmon> Yes, well, you can sing along to the KARAOKE file
[15:52:29 EST(-0500)] <Bosmon> The maidens are very
[15:52:29 EST(-0500)] <Bosmon> Elated and merry;
[15:52:29 EST(-0500)] <Bosmon> They are her chums.
[15:52:37 EST(-0500)] <Bosmon> To lash their pride
[15:52:37 EST(-0500)] <Bosmon> Were almost a pity,
[15:52:37 EST(-0500)] <Bosmon> The pretty committee!
[15:53:21 EST(-0500)] <colinclark> I wonder if our singing is driving people out of the channel?
[15:53:50 EST(-0500)] <hydee> happy birthday anastasiac !!
[15:54:33 EST(-0500)] <anastasiac> thanks, hydee
[15:55:20 EST(-0500)] <anastasiac> Bosmon, there is much chocolate at home, from Leonidas
[15:56:45 EST(-0500)] <Bosmon>
[16:02:44 EST(-0500)] <jessm> http://www.alistapart.com/articles/gettingrealaboutagiledesign
[16:03:43 EST(-0500)] <jessm> what do you call a grizzly bear with no teeth?
[16:03:46 EST(-0500)] <jessm> a gummy bear
[16:04:00 EST(-0500)] <jessm> (joke not related to the link above)
[16:07:00 EST(-0500)] <colinclark> jessm: That is a wicked joke!
[16:07:11 EST(-0500)] <colinclark> At least, kind of wicked.
[16:07:14 EST(-0500)] <jessm>
[16:08:13 EST(-0500)] <colinclark> Bosmon: So I am doing a bit of progressive enhancement here.
[16:08:17 EST(-0500)] <colinclark> And an interesting issue comes up.
[16:08:39 EST(-0500)] <colinclark> Flicker is horrible in these situations. Other uploaders that do this sort of thing end up rendering one thing, then replacing it, all before the user's eyes.
[16:09:26 EST(-0500)] <Bosmon> Oh yes
[16:09:31 EST(-0500)] <Bosmon> Well
[16:09:35 EST(-0500)] <Bosmon> It is less of an issue in Firefox
[16:09:45 EST(-0500)] <Bosmon> Assuming you use the "Approved Methodology"(TM)
[16:09:54 EST(-0500)] <colinclark> It's always an interesting challenge, since you want the thing that is being enhanced to be visible if JS is off but CSS is on.
[16:10:07 EST(-0500)] <colinclark> What is your methodology?
[16:10:11 EST(-0500)] <Bosmon> You know the one
[16:10:15 EST(-0500)] <Bosmon> Not doing stuff on onload
[16:10:20 EST(-0500)] <colinclark> yes, right
[16:10:25 EST(-0500)] <colinclark> But that won't apply here, I believe.
[16:11:09 EST(-0500)] <colinclark> So, for example, I've got a plain <input type="file"> in the markup, along with the markup for the Uploader.
[16:11:35 EST(-0500)] <colinclark> Only one will ultimately be shown, depending on either if JS is disable or if the user is using an old version of Flash.
[16:12:25 EST(-0500)] <Bosmon> ok
[16:13:02 EST(-0500)] <colinclark> The best approach to this, I think, is to hide the thing being enhanced by dynamically inserting a style tag before it appears.
[16:13:21 EST(-0500)] <colinclark> This is in some ways distasteful, but it also makes a fair bit of sense.
[16:13:32 EST(-0500)] <colinclark> Though one can imagine that it's also something we'd like to do for free for people.
[16:13:37 EST(-0500)] <colinclark> Am I making sense?
[16:15:25 EST(-0500)] <colinclark> I am thinking about writing a little utility that, if included in a page, will inject a style that covers this case...
[16:15:47 EST(-0500)] <Bosmon> I guess my mind is a bit fuzzy
[16:16:01 EST(-0500)] <colinclark> Here, Simon wrote a blog post that describes the issue:
[16:16:01 EST(-0500)] <colinclark> http://www.bitstructures.com/
[16:17:31 EST(-0500)] <colinclark> So perhaps a file called progressive-enhancement.js that will inject a style tag into the document that will hide everything with, say, a fluid-progressive-enhance class.
[16:19:04 EST(-0500)] <colinclark> I am not sure I'm thinking clearly here. 
[16:19:14 EST(-0500)] * anastasiac is not sure either
[16:19:20 EST(-0500)] <colinclark> No, I think I am.
[16:19:57 EST(-0500)] <colinclark> A little JavaScript file that will, upon inclusion, inject a <style> tag that hides any elements with a class of .fluid-progressive-enhance.
[16:20:05 EST(-0500)] <colinclark> That way, if JS is turned off, the style will never be applied.
[16:21:13 EST(-0500)] <colinclark> If it is, the thing that may be enhanced will be hidden.
[16:21:16 EST(-0500)] <colinclark> Is this making sense?
[16:23:15 EST(-0500)] <Bosmon> Sorry,lots happening here
[16:24:10 EST(-0500)] <michelled> I didn't read the whole thread here but having a single class that denotes things that will be progressively enhanced and then using that class to hide stuff on load makes sense to me.
[16:24:42 EST(-0500)] <colinclark> Bosmon: No worries.
[16:26:19 EST(-0500)] <colinclark> michelled: Thanks. I'm going to try it out and we'll see where it goes.
[16:28:35 EST(-0500)] <Bosmon> OK, Iam back
[16:29:09 EST(-0500)] <Bosmon> Surely this should be fluid-progressive-dehance
[16:29:23 EST(-0500)] <colinclark>
[16:29:32 EST(-0500)] <colinclark> we want to hide the thing that is being enhanced
[16:29:47 EST(-0500)] <Bosmon> ok
[16:29:50 EST(-0500)] <colinclark> it is the class that says "I am a thing that is being enhanced."
[16:29:56 EST(-0500)] <colinclark> I called it .fl-progressive-enhanceable
[16:29:57 EST(-0500)] <colinclark>
[16:30:41 EST(-0500)] <colinclark> it works niftily.
[16:32:59 EST(-0500)] * colinclark gets away with nothing when anastasiac is around.
[16:33:39 EST(-0500)] <anastasiac> I think all the sugar is going to my head
[16:40:50 EST(-0500)] <colinclark> jessm: Off the top of your head, do you know how to restart the Dock process.
[16:40:54 EST(-0500)] <colinclark> ?
[16:41:00 EST(-0500)] <colinclark> This has happened again. My dock has crashed
[16:41:04 EST(-0500)] <jessm> dock .plist?
[16:41:14 EST(-0500)] <jessm> trash it?
[16:41:27 EST(-0500)] <colinclark> i don't think that will restart the process
[16:41:33 EST(-0500)] <colinclark> time to go fishing with ps
[16:41:49 EST(-0500)] <jessm> go to activity monitor and kill the dock process
[16:42:01 EST(-0500)] <jessm> Utilities > Activity MOnitor
[16:42:22 EST(-0500)] <colinclark> wow
[16:42:29 EST(-0500)] <colinclark> mac os x is cooler than nextstep was
[16:42:57 EST(-0500)] <colinclark> jessm: You totally saved the day, thanks.
[16:43:02 EST(-0500)] <jessm> nuh uh!
[16:43:15 EST(-0500)] <colinclark> I would but Activity Monitor on my Dock, but... you know.
[16:43:17 EST(-0500)] <colinclark>
[16:43:47 EST(-0500)] <jessm> i sometimes get kill process happy if i leave it open – best to keep it closed
[16:44:06 EST(-0500)] <jessm> you can put activity monitor at the top of your finder window if that's faster
[16:44:19 EST(-0500)] <jessm> click n' drag the icon to a finder window front/center
[16:55:45 EST(-0500)] <colinclark>
[16:59:18 EST(-0500)] * michelled (n=team@142.150.154.197) has left #fluid-work
[17:00:09 EST(-0500)] <colinclark> Ok, so I have done a couple of things here.
[17:01:00 EST(-0500)] <colinclark> I have created this ProgressiveEnhancement.js which does some <head> injection trickery to hide anything that is supposed to be enhanced, by looking for a .fl-progressive-enhanceable class,
[17:01:34 EST(-0500)] <colinclark> I have modified fluid.layout.css and created a .fl-progressive-enhancer rule that will hide the thing that will replace the enhanceable by default.
[17:02:00 EST(-0500)] <colinclark> And then, for the Uploader, I am creating a decorator that encapsulates the various rules about when to show either the plain old html control or the full uploader in various configurations.
[17:02:51 EST(-0500)] <colinclark> I suppose the only downside to this approach is that, in cases where we have an old version of Flash installed, there will still be an Uploader instantiated behind the scenes, but it will be invisible and the HTML control will be shown instead.
[17:03:50 EST(-0500)] <colinclark> I imagine that this progressive enhancement approach might be the sort of thing an implementer would customize, but presumably they would do that by simply writing a function that decides whether or not to instantiate the Uploader at all...
[17:04:00 EST(-0500)] <colinclark> and hence a decorator is inappropriate here.
[17:18:08 EST(-0500)] <colinclark> Why is everything associated with flash Evil?
[17:18:16 EST(-0500)] <Bosmon> yes
[17:18:36 EST(-0500)] <colinclark> This is terrible...
[17:18:51 EST(-0500)] <colinclark> I am using a library that is expressly designed to detect Flash versions...
[17:18:54 EST(-0500)] <colinclark> however it doesn't seem to work at all.
[17:19:13 EST(-0500)] <colinclark> It has a function that will return true or false if a particular version number or higher is present.
[17:19:22 EST(-0500)] <colinclark> According to it, I have Flash version 400 or higher installed.
[17:19:50 EST(-0500)] <Bosmon> I have made some terrible and subtle disaster in fluid.mergeOptions
[17:19:57 EST(-0500)] <colinclark> Bosmon: How nice!
[17:20:00 EST(-0500)] <Bosmon> I hope I can fix it before anyone notices
[17:20:02 EST(-0500)] <colinclark> We are both Doomed
[17:20:05 EST(-0500)] <colinclark> hahaha
[17:20:17 EST(-0500)] <colinclark> I suppose people will notice now that you've told us about it.
[17:20:32 EST(-0500)] <Bosmon> I'm not quite sure what the scope of the problem is yet
[17:20:37 EST(-0500)] <Bosmon> Only that it is terrible and subtle
[17:23:21 EST(-0500)] <Bosmon> Maybe this has always been there....
[17:24:10 EST(-0500)] <Bosmon> It's just we have never had this many listeners attached to the same thing before, in this particular order...
[17:26:10 EST(-0500)] <colinclark> Eek
[17:26:18 EST(-0500)] <colinclark> How many listeners have you registered?
[17:26:25 EST(-0500)] <Bosmon> Well, there are 6
[17:26:30 EST(-0500)] <Bosmon> Oh, this is rotten and awful
[17:26:33 EST(-0500)] <Bosmon> I think I know what is happening
[17:26:38 EST(-0500)] <Bosmon> But I still can't quite understand how
[17:26:43 EST(-0500)] <colinclark> I am in exactly the same boat with this Flash code.
[17:26:53 EST(-0500)] <Bosmon> The special guids that addListener writes onto function handles, it seems, are being corrupted
[17:26:55 EST(-0500)] <Bosmon> By the merge process
[17:27:08 EST(-0500)] <Bosmon> It is mistakenly merging the actual listener records
[17:27:17 EST(-0500)] <Bosmon> And somehow plastering the guid from one function handle onto another
[17:27:30 EST(-0500)] <colinclark> eek
[17:27:33 EST(-0500)] <Bosmon> I know the exterior registered listener had guid 14 when it was registered, and it was registered first
[17:27:50 EST(-0500)] <Bosmon> But when it comes to be called, it has been duplicated for one of the internal ones returned via returnedOptions
[17:28:48 EST(-0500)] <Bosmon> I can't believe this problem could always have been happening....
[17:48:23 EST(-0500)] <colinclark> wow, I haven't run mvn since upgrading to a new machine.
[17:48:28 EST(-0500)] <colinclark> I have quite a wait ahead of me.
[17:49:08 EST(-0500)] <Bosmon> This is malign and awful
[17:49:14 EST(-0500)] <Bosmon> And I still can't really understand it...
[17:50:21 EST(-0500)] <colinclark> Is there anything I can do to help?
[17:50:34 EST(-0500)] <Bosmon>
[17:54:43 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[18:06:11 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:17:59 EST(-0500)] <Bosmon> Gleep
[18:18:01 EST(-0500)] <Bosmon> It is now fixed
[18:18:04 EST(-0500)] <Bosmon> And the test cases run again
[18:18:07 EST(-0500)] <Bosmon> I guess I will go home...
[18:18:21 EST(-0500)] <Bosmon> The good news is, we now have renderified Pager
[18:24:10 EST(-0500)] <colinclark> Bosmon: Fantastic news!
[18:24:12 EST(-0500)] <colinclark> Nice work.
[18:24:19 EST(-0500)] <colinclark> I've got my progressive enhancement in Uploader working now, too.
[18:24:56 EST(-0500)] <Bosmon> So, how do we imagine "progressive enhancement" is a generalisable concept?
[18:25:04 EST(-0500)] <colinclark> I believe we could generalize this into a pattern if each component provides a "system requirements check" function.
[18:25:08 EST(-0500)] <colinclark> ha
[18:25:16 EST(-0500)] <Bosmon> I mean, insofar as it is a thing which could simply be specified in terms of a single flag
[18:25:19 EST(-0500)] <Bosmon> "I want it or not"
[18:25:51 EST(-0500)] <colinclark> Yes, but each component may make a specific decision about when they are able to work successfully and when they aren't.
[18:25:59 EST(-0500)] <colinclark> In many cases, it's as simple as "JavaScript is turned on"
[18:26:06 EST(-0500)] <colinclark> Though in other cases, they may need more, such as Flash.
[18:26:15 EST(-0500)] <colinclark> I won't generalize any further until we hit another case like this.
[18:26:45 EST(-0500)] <colinclark> In the meantime, if you want it, just include ProgressiveEnhancement.js in your document and at least your base markup will be hidden properly for you when JS is on.
[18:26:53 EST(-0500)] <Bosmon> Interesting
[18:26:59 EST(-0500)] <colinclark> But Uploader is more complicated, in that it wants to a whole series of checks...
[18:27:02 EST(-0500)] <Bosmon> What could it do, in addition to hiding the markup?
[18:27:15 EST(-0500)] <Bosmon> And how does it help, to have a single CSS class which drives this?
[18:27:37 EST(-0500)] <colinclark> Well, the thing has to be hidden somehow at a very early point in the page load cycle.
[18:28:13 EST(-0500)]
[18:28:20 EST(-0500)] <colinclark> It's extremely simple, but it does the trick.
[18:28:55 EST(-0500)] <colinclark> The point in the Uploader case is that it needs more. Even if JS is turned on, it needs to check if the correct version of Flash is installed, and to otherwise fall back again.
[18:29:27 EST(-0500)] <Bosmon> Well, that is interesting
[18:29:46 EST(-0500)] <Bosmon> It sounds like it is a correct idea
[18:29:47 EST(-0500)] <Bosmon>
[18:30:01 EST(-0500)] <Bosmon> But I am still a little baffled as to what exactly it means that there is just one of it
[18:30:13 EST(-0500)] <colinclark> What do you mean, "just one of it?"
[18:31:09 EST(-0500)] <Bosmon> Just one class, just one "function"
[18:31:23 EST(-0500)] <colinclark> Now I'm confused.
[18:31:46 EST(-0500)] <Bosmon> Well, I am probably just feeling vague
[18:32:18 EST(-0500)] <colinclark> ha
[18:32:19 EST(-0500)] <colinclark> well, go home
[18:32:19 EST(-0500)] <Bosmon> I guess you are imagining all of the component-specific "state" wrt. progressive enhancement will reside "elsewhere"
[18:32:25 EST(-0500)] <Bosmon> Where will this be?
[18:32:36 EST(-0500)] <colinclark> Ah, yes.
[18:33:57 EST(-0500)] <colinclark> Well, at the moment, I have only one component that has specific state... I've simply created an alternative creator function that you can use if you want this progressive enhancement support for the Uploader...
[18:34:19 EST(-0500)] <colinclark> it is the one that makes the decision whether or not to bother instantiating the Uploader at all.
[18:35:02 EST(-0500)] <Bosmon> How is this linked in to the use of the CSS class?
[18:35:22 EST(-0500)] <colinclark> That was an interesting question for me, actually.
[18:35:41 EST(-0500)] <colinclark> Since the .fl-progressive-enhanceable should be considered a "global" class...
[18:35:54 EST(-0500)] <colinclark> in other words, if we've got JavaScript turned on, everything with this class should be made to go away.
[18:36:11 EST(-0500)] <Bosmon> Right, but how precisely are these two aspects of the system linked together
[18:36:25 EST(-0500)] <Bosmon> i) the use of the CSS class, ii) the instantiation, alternative or otherwise, of the Uploader
[18:36:40 EST(-0500)] <Bosmon> Btw, the BeanInvalidationModel(TM) is going to be fantastically cool
[18:36:41 EST(-0500)] <colinclark> But since Uploader need to make a further decision about this, I take another argument to the progressiveEnhanceUploader() constructor function that is the specific container of the plain old markup.
[18:36:46 EST(-0500)] <colinclark> If this makes any sense whatsoever.
[18:37:54 EST(-0500)] <colinclark> Has any of the "bean" invalidation model crept into the code base yet?
[18:38:12 EST(-0500)] <Bosmon> Not yet, no
[18:38:24 EST(-0500)] <Bosmon> But I realise that it is at once the solution to two parts of the Pager's design
[18:38:39 EST(-0500)] <Bosmon> It can use it not only for its own "model" (consisting of the paging state) but also for the paged data "model"
[18:38:48 EST(-0500)] <Bosmon> That is, the user's model of the data which is in the table
[18:39:25 EST(-0500)] <Bosmon> ok, well from what you are saying, I can't see that there is actually any connection between i) and ii) there at all?
[18:39:36 EST(-0500)] <Bosmon> They are just two things that the user does at the same time?
[18:40:25 EST(-0500)] <colinclark> Bosmon: Yes, that's right. At least at this point. This is undoubtedly awkward, but they have fundamentally different timing.
[18:40:39 EST(-0500)] <colinclark> The initial "hide if JavaScript" logic has to run ASAP...
[18:40:52 EST(-0500)] <colinclark> whereas component instantiation must occur during its rightful place in the page flow.
[18:42:32 EST(-0500)] <colinclark> If there were a way to link these more closely, that would be great. But I don't think it's possible.
[18:42:59 EST(-0500)] <Bosmon> Hmm, ok
[18:43:10 EST(-0500)] <Bosmon> I guess this makes a bit more sense to me
[18:43:23 EST(-0500)] <Bosmon> I mean, if the only function of the CSS class is to cause hiding, then it is perfectly clear why there is just one of it
[18:44:03 EST(-0500)] <colinclark> right
[18:44:06 EST(-0500)] <colinclark> that's it
[18:44:10 EST(-0500)] <colinclark> it's super-simple
[18:44:43 EST(-0500)] <colinclark> There actually may be a way to tie in this life cycle based on the order that things occur in the page, but I'll have to play with it a bit.
[18:45:38 EST(-0500)] <colinclark> It's a funny lifecycle, since you want to hide the markup destined for the component with CSS and ultimately show it with JavaScript, while ensuring that the fallback markup is hidden via JavaScript so it appears in other cases.
[18:51:18 EST(-0500)] <Bosmon> Did we get anywhere with this "strings" idea?
[18:54:23 EST(-0500)] <colinclark> "strings"?
[18:54:32 EST(-0500)] <colinclark> as far as a quick i18n strategy?
[18:54:34 EST(-0500)] <Bosmon> yes
[18:54:56 EST(-0500)] <Bosmon> I am breaking my brain figuring out where to put this option which configures the string which says "(last)" for the pager
[18:55:01 EST(-0500)] <colinclark> It's there as an approach now for components that render human-readable strings.
[18:55:10 EST(-0500)] <colinclark> I would put it in strings:
[18:55:27 EST(-0500)] <Bosmon> Right, but we now have this baroque 3-level structure for our options for this component
[18:56:00 EST(-0500)] <colinclark> This is not ideal, but for components that don't use the renderer, and dynamically display their own strings, we allow users to customize that text themselves in the strings bundle. I think it's a reasonable lowest common denominator approach.
[18:56:13 EST(-0500)] <colinclark> 3-level structure/
[18:56:14 EST(-0500)] <colinclark> ?
[18:56:24 EST(-0500)] <Bosmon> Well, you can see it in what I have checked in
[18:56:48 EST(-0500)] <Bosmon> I mean, in some sort of interesting way, I am wondering whether many kinds of options should go at "higher" levels than the actual types of their subcomponents are specified
[18:57:03 EST(-0500)] <Bosmon> For example, you would want the string which says "last" to be independent of pretty much every other decision about the pager
[18:58:09 EST(-0500)] <colinclark> If I am understanding you, this is something I've been mulling over myself.
[18:58:27 EST(-0500)] <colinclark> Can you elaborate a bit?
[18:58:55 EST(-0500)] <Bosmon> Well, despite the fact that this option is "destined" currently for a particular implementation of a particular nested subcomponent of the pager
[18:59:11 EST(-0500)] <Bosmon> It is not actually something that you want to force the user to have to configure separately every time they make that kind of decision
[18:59:33 EST(-0500)] <Bosmon> Or further, if they don't want to care which kind of renderer, etc. they use for the page links thing, to allow them to specify this string at top level
[18:59:59 EST(-0500)] <colinclark> Bosmon: Yes, exactly.
[19:00:08 EST(-0500)] <Bosmon> Of course the upshot of this is that unfortunately somehow the top-level options for the component are somehow manually trickled down to every subcomponent
[19:00:08 EST(-0500)] <colinclark> That has been a concern of mine recently as well.
[19:00:10 EST(-0500)] <Bosmon> Which is something that sort of happened anyway, sometimes
[19:00:15 EST(-0500)] <Bosmon> At least for the Reorderer
[19:00:20 EST(-0500)] <Bosmon> And I guess now we have another case of it
[19:00:30 EST(-0500)] <Bosmon> I had carefully localised all the options for the pagerBar in its own init
[19:00:35 EST(-0500)] <colinclark> Bosmon: I think we have a growing set of cases for it.
[19:00:38 EST(-0500)] <Bosmon> And now I have to break it apart again
[19:00:51 EST(-0500)] <Bosmon> But top-level options can be just vast
[19:00:55 EST(-0500)] <colinclark> yes
[19:01:25 EST(-0500)] <colinclark> There's this difficult balancing act in terms of split up options into the subcomponent layer or leaving them in the top level.
[19:05:52 EST(-0500)] <Bosmon> OK
[19:05:59 EST(-0500)] <Bosmon> Well, Pager does something now
[19:05:59 EST(-0500)] <Bosmon> Check it out
[19:06:07 EST(-0500)] <Bosmon> The next step is the BeanInvalidationModel (TM)
[19:06:24 EST(-0500)] <Bosmon> Which will then make us Globally Dominant in All Areas
[19:10:04 EST(-0500)] <colinclark> Cool.
[19:10:14 EST(-0500)] <colinclark> Let's talk more on Monday. But it is great to see it progressing.
[19:10:30 EST(-0500)] <Bosmon> You can see the annoying boilerplate that Pager needs, just even to manage its tiny model
[19:10:30 EST(-0500)] <colinclark> I'm looking forward to when Uploader is done and we can work more on framework and renderer together.
[19:10:35 EST(-0500)] <Bosmon> Full of 3 numbers
[19:10:44 EST(-0500)] <colinclark> I think I saw that, yes.
[19:10:52 EST(-0500)] <colinclark> first/last/total
[19:11:12 EST(-0500)] <Bosmon> I had to add "initiatePageSizeChange" alongside "initiatePageChange", just to illustrate how nasty this will get
[19:11:49 EST(-0500)] <Bosmon> It will be a very funny and interesting world
[19:11:54 EST(-0500)] <colinclark> curious
[19:11:58 EST(-0500)] <Bosmon> Where nobody actually ever touches their models directly
[19:12:07 EST(-0500)] <colinclark> Hands off!
[19:12:08 EST(-0500)] <Bosmon> They will communicate entirely in terms of DARs
[19:12:17 EST(-0500)] <colinclark> My signal to leave!
[19:12:19 EST(-0500)] <Bosmon> HAHAHAHA
[19:12:35 EST(-0500)] <Bosmon> Rotten
[19:13:30 EST(-0500)] <colinclark> interesting how you have bound a model event directly to a DOM event.
[19:13:39 EST(-0500)] <Bosmon> Yes
[19:13:45 EST(-0500)] <Bosmon> As you can see, that is entirely undesirable
[19:13:54 EST(-0500)] <colinclark> yes
[19:14:03 EST(-0500)] <Bosmon> As to fit wheels to a tomato
[19:14:08 EST(-0500)] <Bosmon> "Messy, and highly unnecessary"
[19:15:05 EST(-0500)] <colinclark> you've got strategies for handling how page numbers are displayed
[19:15:10 EST(-0500)] <colinclark> or, well, one
[19:15:15 EST(-0500)] <colinclark> but room for more, presuably
[19:15:16 EST(-0500)] <Bosmon> Yes
[19:15:22 EST(-0500)] <Bosmon> That is just a stateless function
[19:15:49 EST(-0500)] <colinclark> Are the "direct" and "rendered" page lists intended to be alternatives to each other?
[19:15:55 EST(-0500)] <Bosmon> Yes
[19:16:00 EST(-0500)] <colinclark> "direct" being the opposite of self-rendered?
[19:16:03 EST(-0500)] <Bosmon> Yes
[19:16:06 EST(-0500)] <colinclark> k
[19:16:11 EST(-0500)] <Bosmon> "direct" is the strategy we had before
[19:16:17 EST(-0500)] <Bosmon> Where the page geometry is inferred from the markup
[19:16:19 EST(-0500)] <colinclark> Right.
[19:16:21 EST(-0500)] <Bosmon> Rather than the other way round
[19:16:36 EST(-0500)] <colinclark> That kind of terminology will be very important in the future, so we may want to bounce it around a bit later.
[19:16:43 EST(-0500)] <Bosmon> Yes
[19:17:04 EST(-0500)] <Bosmon> There's lots about the details of this design that is not quite right
[19:17:06 EST(-0500)] <Bosmon>
[19:17:12 EST(-0500)] <colinclark> Ultimately I also imagine some sort of support for this, don't you? As in "is my markup here? No, okay, I'll self render."
[19:17:25 EST(-0500)] <colinclark> This is a pattern we've already established, if awkwardly, in InlineEdit.
[19:17:28 EST(-0500)] <Bosmon> Yes well, we have exactly the same situation
[19:17:28 EST(-0500)] <Bosmon> yes
[19:18:08 EST(-0500)] <colinclark> And I suppose at this point, self-rendering will seem odd since we don't have a good scheme for actually sourcing the template, right?
[19:18:19 EST(-0500)] <Bosmon> Well, right now we source the template from the markup
[19:18:22 EST(-0500)] <colinclark> right
[19:18:24 EST(-0500)] <Bosmon> So it doesn't seem terribly odd at all
[19:18:48 EST(-0500)] <colinclark> where can i see an example of the template?
[19:19:03 EST(-0500)] <Bosmon> The app itself runs from pager/renderer
[19:19:04 EST(-0500)] <Bosmon> In samples
[19:19:14 EST(-0500)] <colinclark> sakai-site-setting?
[19:19:17 EST(-0500)] <Bosmon> no
[19:19:22 EST(-0500)] <Bosmon> Just renderer
[19:20:12 EST(-0500)] <colinclark> wait
[19:20:20 EST(-0500)] <colinclark> so i see pager/basic which seems to be the old one
[19:20:48 EST(-0500)] <colinclark> and the render/ directory doesn't seem to have anything relevant
[19:21:11 EST(-0500)] <Bosmon> What do you mean?
[19:21:17 EST(-0500)] <Bosmon> In what way is it not relevant?
[19:21:41 EST(-0500)] <Bosmon> I mean, pager/renderer
[19:21:45 EST(-0500)] <Bosmon> Underneath the pager directory
[19:21:48 EST(-0500)] <colinclark> i must be missing something...
[19:21:52 EST(-0500)] <colinclark> forgot to refresh
[19:21:58 EST(-0500)] <colinclark> sorry
[19:22:01 EST(-0500)] <colinclark> i'm getting tired.
[19:22:10 EST(-0500)] <colinclark> there it is
[19:22:11 EST(-0500)] <Bosmon> But it is only 12:20am
[19:22:34 EST(-0500)] <colinclark> ha
[19:22:36 EST(-0500)] <colinclark> cool
[19:25:15 EST(-0500)] <Bosmon> Getting the page link list to render is surprisingly fiddly
[19:25:24 EST(-0500)] <Bosmon> And is highlighting some infelicities in the renderer
[19:25:47 EST(-0500)] <colinclark> Bosmon: Good!
[19:25:58 EST(-0500)] <Bosmon> This was the issue I was trying to allude to the other day
[19:26:03 EST(-0500)] <Bosmon> When you ran away at that point
[19:26:08 EST(-0500)] <colinclark> Ah...
[19:26:18 EST(-0500)] <colinclark> remind me
[19:26:30 EST(-0500)] <Bosmon> Well, I didn't actually get a chance to articulate it yet
[19:26:34 EST(-0500)] <Bosmon> There is a very interesting issue relating to the fact whether two nodes are the same node or not
[19:26:53 EST(-0500)] <Bosmon> For example, in the pager link list, the node "governing repetition" may or may not be the same node as the one "holding value"
[19:27:17 EST(-0500)] <Bosmon> In this case, we have an <li> surrounding a <a>
[19:27:20 EST(-0500)] <Bosmon> So the nodes are distinct
[19:27:24 EST(-0500)] <Bosmon> But they might just as well be the same
[19:27:38 EST(-0500)] <Bosmon> Now, RSF cares about this quite a lot
[19:27:55 EST(-0500)] <Bosmon> The "canonical" way to handle this is by means of the rather weird special id "payload-component"
[19:28:12 EST(-0500)] <Bosmon> But seen from the point of view of the "selector world" this is really pretty ridiculous
[19:28:25 EST(-0500)] <Bosmon> And I guess is starting to highlight the way in which the selector world is much more clearly declarative
[19:28:36 EST(-0500)] <Bosmon> That is, two different selectors either designate the same set of nodes, or they don't
[19:28:48 EST(-0500)] <Bosmon> Either way, you would expect the renderer to somehow pick up the pieces
[19:29:00 EST(-0500)] <Bosmon> Without you having to invent this curious fabrication of the "payload-component" to bridge the gap
[19:29:05 EST(-0500)] <colinclark> just catching up
[19:29:35 EST(-0500)] <Bosmon> This was all an artifact of the fact that all the instructions were meant to be given to the renderer in forms of a single, atomic string, "rsf:id" which is directly attached to the markup
[19:29:50 EST(-0500)] <colinclark> yes, this makes sense and i agree
[19:29:56 EST(-0500)] <Bosmon> Given there is only ever room for one such string, oddities like "payload-component" and the "elide character" arose
[19:30:10 EST(-0500)] <colinclark> interesting
[19:30:31 EST(-0500)] <Bosmon> Aaron must ask me to remind him what the name is for "payload-component" about once a wekk
[19:30:32 EST(-0500)] <Bosmon> week
[19:31:23 EST(-0500)] <Bosmon> Anyway, I'm still not sure how exactly this problem will be made to go away
[19:31:40 EST(-0500)] <Bosmon> But all I can guess is that somehow the "selector" world makes it a bit clearer
[19:31:57 EST(-0500)] <Bosmon> But it is more than just a selector issue, since it is almost an issue at the component tree level as well
[19:32:04 EST(-0500)] <colinclark> hmm
[19:32:11 EST(-0500)] <Bosmon> The magic of "payload-component" is that thankfully it papers over the issue, once you have got to the component tree
[19:32:19 EST(-0500)] <Bosmon> Since the renderer "magically displaces" one component to another place
[19:32:26 EST(-0500)] <Bosmon> but there are other cases where it cannot "go away"
[19:32:44 EST(-0500)] <Bosmon> Typically when you are dealing with "joint" components which may either cause rendering to branch, or may not
[19:32:56 EST(-0500)] <Bosmon> AH!
[19:33:03 EST(-0500)] <Bosmon> I think I remember what I was planning to do about this
[19:33:12 EST(-0500)] <Bosmon> There were going to be "-" cutpoints and "+" cutpoints
[19:33:44 EST(-0500)] <Bosmon> That is, ones which would "prefer" to slide to be just enclosing the target tag, if there was any slip, and those that would prefer to be enclosed by it
[19:33:58 EST(-0500)] <Bosmon> In the case the selectors did not collide, there would be no difference
[19:34:19 EST(-0500)] <Bosmon> But if they both happened to hit the same tag, they would make sure to bind in a particular order
[19:34:29 EST(-0500)] <colinclark> this is all dreadfully blurry to me
[19:36:01 EST(-0500)] <Bosmon> Ah well, we had better get to bed
[19:36:18 EST(-0500)] <colinclark>
[19:36:47 EST(-0500)] <colinclark> i have a party to go to tonight
[19:36:50 EST(-0500)] <Bosmon> ha
[19:36:58 EST(-0500)] <colinclark> I am most looking forward to the bottle of wine I'm bringing...
[19:37:05 EST(-0500)] <colinclark> though there will be some interesting friends there to talk to.
[19:37:21 EST(-0500)] <Bosmon>
[19:37:29 EST(-0500)] <Bosmon> Talk to the wine, and drink the friends
[19:37:37 EST(-0500)] <colinclark> ha
[19:37:38 EST(-0500)] <Bosmon> I guess that is a Buffy kind of thing to do....
[19:37:43 EST(-0500)] <colinclark>
[19:38:08 EST(-0500)] <colinclark> I need to get this uploader stuff working before I will feel good about leaving.
[19:38:16 EST(-0500)] <colinclark> And it is nearly there, but blowing up in the server-side version.
[19:38:50 EST(-0500)] <Bosmon> ok
[19:38:56 EST(-0500)] <Bosmon> Well, I will biff off home
[19:39:08 EST(-0500)] <Bosmon> If I don't see you before, enjoy the party
[19:39:14 EST(-0500)] <Bosmon> And maybe we will catch up over the weekend
[19:39:20 EST(-0500)] <colinclark> Yep.
[19:39:22 EST(-0500)] <colinclark> Have a good night.
[19:39:28 EST(-0500)] <Bosmon> Cheerio
[20:46:12 EST(-0500)] * Topic is 'Progressive Enhancement Doesn't Suck' set by colinclark on 2008-12-05 20:46:12 EST(-0500)
[21:33:18 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
Unknown macro: { display}
Manage space
Manage content
Integrations