fluid-work IRC Logs-2008-05-29

[06:26:57 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:45:01 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined #fluid-work
[08:53:16 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined #fluid-work
[09:31:51 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:56:19 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:05:15 EDT(-0400)] * jhung (n=Fluid@142.150.154.178) has joined #fluid-work
[10:31:24 EDT(-0400)] * jessm (n=Jess@cpe-069-134-127-060.nc.res.rr.com) has joined #fluid-work
[10:35:44 EDT(-0400)] <jessm> jhung: ping
[10:35:56 EDT(-0400)] <jhung> Hi Jess.
[10:37:15 EDT(-0400)] <jessm> i'm wondering where we can best have a chat about the wiki
[10:37:19 EDT(-0400)] <jessm> in IM? or here?
[12:40:08 EDT(-0400)] * RayDavis (n=chatzill@dhcp-169-229-212-41.LIPS.Berkeley.EDU) has joined #fluid-work
[12:54:56 EDT(-0400)] * jhung (n=Fluid@142.150.154.178) has left #fluid-work
[13:35:11 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-63.LIPS.Berkeley.EDU) has joined #fluid-work
[14:08:17 EDT(-0400)] * davidb (n=davidb@bas4-toronto06-1279310546.dsl.bell.ca) has joined #fluid-work
[14:20:59 EDT(-0400)] * davidb (n=davidb@bas4-toronto06-1279310546.dsl.bell.ca) has joined #fluid-work
[14:30:39 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:43:35 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543721.dsl.bell.ca) has joined #fluid-work
[14:44:04 EDT(-0400)] <colinclark> michelled: I private messaged you about this issue but realized it was probably better on the channel anyway. Here it is again...
[14:44:33 EDT(-0400)] <colinclark> You asked why I chose to package up the column and portlet selectors into an object for reorderLayout().
[14:45:27 EDT(-0400)] <colinclark> The function currently looks like: reorderLayout(containerSelector, layoutSelectors, orderChanged, options)
[14:45:46 EDT(-0400)] <colinclark> You were wondering if it should look like this: fluid.reorderLayout(containerSelector, columnSelector, portletsSelector orderChangedCallback, options);
[14:45:52 EDT(-0400)] <colinclark> michelled: Right?
[14:46:17 EDT(-0400)] <michelled> yup
[14:46:29 EDT(-0400)] <colinclark> I chose a compound object for two reasons, neither of which may be particularly valid:
[14:46:37 EDT(-0400)] <colinclark> 1. A simple heuristic: try to stick to 3 or 4 arguments in a function. Otherwise, things get confusing.
[14:47:07 EDT(-0400)] <colinclark> You pointed out the corollary confusion that some people find it confusing to have to package up arguments into an object. So it's an open question.
[14:47:14 EDT(-0400)] <colinclark> 2. I expect that we may want to add a third selector, lockedPortlets, to the signature at some point in the future. In that case, the compound object makes for a nice way of grouping together a set of related selectors.
[14:47:32 EDT(-0400)] <michelled> this seems reasonable to me.
[14:47:33 EDT(-0400)] <colinclark> michelled or others: Thoughts?
[14:48:12 EDT(-0400)] <michelled> There is also a third bonus and that's keeps a very similar API between reorderList reorderGrid and reorderLayout
[14:48:25 EDT(-0400)] <colinclark> Right.
[14:48:46 EDT(-0400)] <colinclark> At least you can guarantee the consistent order of arguments, even if their types vary slightly between functions.
[14:49:05 EDT(-0400)] <colinclark> We're establishing a pattern of "container, items, other stuff."
[14:50:14 EDT(-0400)] <michelled> so another question about the reorderList and reorderGrid API. We have the concept in the reorderer of 'movables' 'selectables' 'drop targets' and 'grab handle'. There are defaults for all of these except movables.
[14:50:37 EDT(-0400)] <michelled> do you think we should provide a way for people to have more fine grained control when using the reorderList and reorderGrid API?
[14:50:46 EDT(-0400)] <michelled> Right now, all they can specify are the 'movables'
[14:52:01 EDT(-0400)] <michelled> colinclark ^
[14:52:28 EDT(-0400)] <colinclark> michelled: Yeah, I don't think it would hurt.
[14:53:04 EDT(-0400)]

[14:53:23 EDT(-0400)] <colinclark> michelled: each of those properties in the compound object being selectors.
[14:53:56 EDT(-0400)] <colinclark> Eventually we'll move to a "DOM binder" solution where users can easily specify arguments as selectors, jQuerys, or lists transparently. But for now, selectors should do the trick.
[14:55:31 EDT(-0400)] <michelled> sounds good
[15:48:38 EDT(-0400)] <colinclark> anastasiac: Documentation question.
[15:48:52 EDT(-0400)] <anastasiac> colinclark, shoot
[15:49:11 EDT(-0400)] <colinclark> If we're using jQuery.ready() for all our examples, is there any point in illustrating the code within the document's body?
[15:49:35 EDT(-0400)] <colinclark> In other words, this code could just as nicely be put unobtrusively in a separate JavaScript file.
[15:49:52 EDT(-0400)] <colinclark> It's only when you're not using .ready() that you might want to initialize your code inline.
[15:49:54 EDT(-0400)] <anastasiac> yes, it could be put in a file that's included
[15:50:05 EDT(-0400)] <anastasiac> do you think that would be better?
[15:50:10 EDT(-0400)] <colinclark> That strategy is another way of saying "execute this JavaScript as soon as this block of markup has been processed."
[15:50:40 EDT(-0400)] <colinclark> But using jQuery.ready() is the equivalent of saying "execute this JavaScript after all the markup has been processed."
[15:50:42 EDT(-0400)] <anastasiac> I can change the docs to illustrate an external file, no problem, if that seems better
[15:50:49 EDT(-0400)] <colinclark> I think it might be better.
[15:51:04 EDT(-0400)] <anastasiac> ok, no problem
[15:51:13 EDT(-0400)] <colinclark> It actually suggests that we're moving away from recommending the "one line script block" approach. Which I think is fine in most cases.
[15:51:28 EDT(-0400)] <colinclark> Portals may be a more complicated beast. I have to look more deeply into it.
[15:53:05 EDT(-0400)] <anastasiac> so we still need a script block in the doc that invokes the function in the external file, right?
[15:53:39 EDT(-0400)] <anastasiac> oh, no, if we put the ready in the file, then we don't need the script tag
[15:53:45 EDT(-0400)] <anastasiac> ok, sorry, my brain is a bit tired
[15:54:02 EDT(-0400)] * anastasiac sighs
[15:55:21 EDT(-0400)] <colinclark> anastasiac: You've been writing documentation all day! It's totally understandable.
[16:02:35 EDT(-0400)] * colinclark_ (n=colin@bas1-toronto09-1279543721.dsl.bell.ca) has joined #fluid-work
[16:04:22 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543721.dsl.bell.ca) has joined #fluid-work
[16:13:46 EDT(-0400)] <michelled> colinclark: are you here?
[16:13:59 EDT(-0400)] <colinclark> michelled: Yep, I'm here.
[16:14:19 EDT(-0400)] <michelled> the reorderLayout takes a layoutSelectors parameter.
[16:14:34 EDT(-0400)] <michelled> I think that object should have 'columns' and 'modules' in it
[16:14:40 EDT(-0400)] <michelled> instead of 'portlets'
[16:14:43 EDT(-0400)] <michelled> what do you think?
[16:15:11 EDT(-0400)] <colinclark> I don't mind either way.
[16:15:30 EDT(-0400)] <colinclark> I somehow imagined people knew what portlets were, rather than modules. But we're using the term modules, right?
[16:15:58 EDT(-0400)] <michelled> well, underneath we are. That was what was decided on list when we went through the whole naming thing.
[16:16:14 EDT(-0400)] <colinclark> Sure. Modules is fine.
[16:16:22 EDT(-0400)] <michelled> ok
[16:26:46 EDT(-0400)] <colinclark> eocochran: I have a fix for FLUID-660 for you.
[16:27:24 EDT(-0400)] <ecochran> cool
[16:27:31 EDT(-0400)] <colinclark> eocochran: It appears that you missed adding a tabindex on the inline version of Uploader.
[16:28:01 EDT(-0400)] <colinclark> Shall I just go ahead and commit?
[16:28:40 EDT(-0400)] <ecochran> sure
[16:28:47 EDT(-0400)] <colinclark> eocochran: I'm really perplexed by some of this behaviour. Links aren't behaving like normal links.
[16:28:57 EDT(-0400)] <ecochran> i know
[16:28:59 EDT(-0400)] <colinclark> In other words, I shouldn't actually have to put a tabindex on an <a> tag.
[16:29:13 EDT(-0400)] <ecochran> it's because there is not an href attribute
[16:29:26 EDT(-0400)] <ecochran> I probably should make the link a button
[16:29:34 EDT(-0400)] <colinclark> ecochran: It's not a valid document?
[16:29:57 EDT(-0400)] <ecochran> colin: sure it is
[16:32:37 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-63.LIPS.Berkeley.EDU) has joined #fluid-work
[16:33:12 EDT(-0400)] <colinclark> ecochran: Yep, you're right. I had always assumed anchors required an href attribute.
[16:33:27 EDT(-0400)] <ecochran> nope
[16:33:40 EDT(-0400)] <colinclark> But browsers seems to treat them differently without an href, I guess.
[16:33:43 EDT(-0400)] <ecochran> but the browsers don't always do the right thing with out them
[16:33:45 EDT(-0400)] <ecochran> yes
[16:33:52 EDT(-0400)] <colinclark> Interesting! I learned something today.
[16:34:10 EDT(-0400)] <ecochran> but then button has really crappy support as well x browser
[16:34:40 EDT(-0400)] <colinclark> Would it work to put an href in with a value of "#"?
[16:34:55 EDT(-0400)] <ecochran> those are evil
[16:35:10 EDT(-0400)] <ecochran> because the # actually means something
[16:35:16 EDT(-0400)] <ecochran> and will link to the top of the page
[16:35:45 EDT(-0400)] <ecochran> evil is perhaps a strong word
[16:35:55 EDT(-0400)] <colinclark> Pleasantly strong, yes.
[16:35:55 EDT(-0400)] <ecochran> but I've never come up with a null link that I like
[16:36:22 EDT(-0400)] <ecochran> 611 is fixed
[16:36:31 EDT(-0400)] <ecochran> 660 was fixed except in the inline version
[16:36:41 EDT(-0400)] <ecochran> too many samples to keep updating
[16:36:48 EDT(-0400)] <colinclark> Yes, the downside of cutting and pasting.
[16:37:15 EDT(-0400)] <ecochran> except that they are different examples
[16:37:27 EDT(-0400)] <ecochran> even if most of the code is the same
[16:37:43 EDT(-0400)] <ecochran> at one time the were going to be quite different
[16:39:07 EDT(-0400)] <ecochran> I'm not really very happy with how much stuff has to be passed around from function to function in the Uploader
[16:39:13 EDT(-0400)] <ecochran> keeping track of it is a bear
[16:39:35 EDT(-0400)] <colinclark> That's what we get for working with half a refactoring.
[16:39:39 EDT(-0400)] <colinclark> ecochran: I can make the Browse button activatable() to work around the problem. So strange, but should work.
[16:39:53 EDT(-0400)] <ecochran> I did
[16:40:12 EDT(-0400)] <ecochran> browse button is activatable
[16:41:06 EDT(-0400)] <colinclark> ecochran: Okay. I guess you haven't committed yet?
[16:41:16 EDT(-0400)] <ecochran> yes, committed
[16:41:27 EDT(-0400)] <colinclark> It's not working on my machine... let me keep testing here.
[16:41:48 EDT(-0400)] <ecochran> which version are you looking at
[16:41:56 EDT(-0400)] <ecochran> which sample?
[16:42:02 EDT(-0400)] <ecochran> inline or popup?
[16:42:07 EDT(-0400)] <colinclark> Both.
[16:42:59 EDT(-0400)] <ecochran> $(uploader.fragmentSelectors.browse, uploaderContainer).click(function () {
[16:42:59 EDT(-0400)] <ecochran> return (allowMultipleFiles) ? swfObj.selectFiles() : swfObj.selectFile();
[16:42:59 EDT(-0400)] <ecochran> }).activatable(function () {
[16:43:00 EDT(-0400)] <ecochran> return (allowMultipleFiles) ? swfObj.selectFiles() : swfObj.selectFile();
[16:43:00 EDT(-0400)] <ecochran> });
[16:43:00 EDT(-0400)] <ecochran>
[16:43:23 EDT(-0400)] <ecochran> lines 798 to 803
[16:43:25 EDT(-0400)] <ecochran> working for me
[16:48:30 EDT(-0400)] <colinclark> ecochran: Ugh. I think I'm bitten by the Flash issue.
[16:48:35 EDT(-0400)] <colinclark> Will fix.
[16:48:42 EDT(-0400)] <ecochran> probably
[16:58:15 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[17:03:52 EDT(-0400)] <colinclark> ecochran: I committed, marked Fluid-660 as fixed and bounced it to JH to take a look at tomorrow.
[17:04:05 EDT(-0400)] <ecochran> thanks
[17:10:39 EDT(-0400)] <colinclark> ecochran: Keyboard interaction is working really nicely.
[17:11:26 EDT(-0400)] <ecochran> thx, simplistic for this release
[17:12:00 EDT(-0400)] <colinclark> It's a great first start. There are details, but this works nicely.
[17:39:34 EDT(-0400)] * RayDavis (n=chatzill@dhcp-169-229-212-41.LIPS.Berkeley.EDU) has joined #fluid-work
[17:41:01 EDT(-0400)] <RayDavis> ecochran: Just got back to Uploader + Gallery, and Firebug is reporting:
[17:41:07 EDT(-0400)] <RayDavis> $(uploader.fragmentSelectors.browse, uploaderContainer).click(activateBrowse).activatable is not a function
[17:41:09 EDT(-0400)] <RayDavis> http://localhost:8080/sakai-imagegallery2-web/fluid-components/js/fluid/Uploader.js
[17:41:10 EDT(-0400)] <RayDavis> Line 802
[17:41:43 EDT(-0400)] <RayDavis> I see from the IRC log that Colin hit something similar, but I'm afraid I didn't understand the resolution.
[17:41:47 EDT(-0400)] <ecochran> AddImages.html needs to have: <script src="fluid-components/js/jquery/jquery.keyboard-a11y.js" type="text/javascript"></script> added to the head
[17:41:57 EDT(-0400)] <ecochran> I thought that I added it and checked it in
[17:42:08 EDT(-0400)] <ecochran> I'll check
[17:42:17 EDT(-0400)] <RayDavis> Ah, thanks.
[17:43:08 EDT(-0400)] <colinclark> RayDavis: I made a change to that line of code... horror of horrors, I may have broken it.
[17:43:16 EDT(-0400)] <colinclark> I'll also take a look.
[17:43:17 EDT(-0400)] <RayDavis> Nooooooo!
[17:43:32 EDT(-0400)] <colinclark> Just to be sure, what browser?
[17:43:36 EDT(-0400)] <ecochran> I forgot check in
[17:43:38 EDT(-0400)] <ecochran> checked
[17:43:55 EDT(-0400)] <RayDavis> colinclark: Firefox 2.
[17:44:06 EDT(-0400)] <RayDavis> On WinXP.
[17:44:54 EDT(-0400)] <colinclark> ecochran: I've been doing JAWS testing with largely great success.
[17:44:59 EDT(-0400)] <colinclark> On Uploader.
[17:45:05 EDT(-0400)] <RayDavis> NP, Eli. I'm sorry to be popping up and down on your radar so randomly today – it's an odd day so far....
[17:45:43 EDT(-0400)] <ecochran> colinclark: surprising!
[17:45:55 EDT(-0400)] <ecochran> and on the Remove buttons?
[17:46:10 EDT(-0400)] <colinclark> RayDavis: So to confirm, the problem you were seeing was in the Gallery?
[17:46:33 EDT(-0400)] <colinclark> Was it indeed the JavaScript import issue in AddImages.html?
[17:46:38 EDT(-0400)] <RayDavis> Yes, I'm about to try again with Eli's check-in, but I'm sure that will fix the problem.
[17:46:53 EDT(-0400)] <colinclark> Okay, great. You scared me because that was exactly the line where I removed some duplicate code.
[17:46:57 EDT(-0400)] <colinclark> But I tested it!
[17:47:07 EDT(-0400)] <colinclark> ecochran: I'm just trying the remove buttons now.
[17:47:25 EDT(-0400)] <colinclark> The only issue I see is that it would be much more usable if we made the Browse Files button a real button.
[17:47:38 EDT(-0400)] <ecochran> that is easy to do
[17:47:46 EDT(-0400)] <colinclark> For whatever reason, I can't activate it unless I shift out of Virtual PC cursor mode. As a real button, that would be fixed.
[17:47:53 EDT(-0400)] <ecochran> the fact that it is a link is a carry over from a very earlier version
[17:47:56 EDT(-0400)] <colinclark> ecochran: Great! Other than that, it seems to work.
[17:48:01 EDT(-0400)] <ecochran> cool
[17:48:17 EDT(-0400)] <colinclark> I don't love jQuery dialog's behaviour, but it's not a show stopper. When you open the popup, it focuses the X widget.
[17:48:23 EDT(-0400)] <colinclark> Which isn't the worst thing to do by any means.
[17:48:35 EDT(-0400)] <RayDavis> ecochran: All's swell.
[17:48:51 EDT(-0400)] <colinclark> But there's not enough context, so it's initially confusing until you tab around a bit. Something screen reader users are accustomed to doing, I expect.
[17:48:58 EDT(-0400)] <colinclark> So nothing we need to worry about.
[17:49:08 EDT(-0400)] <ecochran> good enough for now
[17:49:43 EDT(-0400)] <colinclark> Yep.
[17:50:24 EDT(-0400)] <colinclark> ecochran: The remove buttons are okay. Unfortunately they aren't described at all which is a drag.
[17:50:31 EDT(-0400)] <colinclark> In fact, the use is invited to activate them.
[17:50:45 EDT(-0400)] <ecochran> ?
[17:51:09 EDT(-0400)] <colinclark> A blank button is read like this in JAWS:
[17:51:17 EDT(-0400)] <colinclark> "Button. To activate press Space."
[17:51:23 EDT(-0400)] <ecochran> what do you think of my idea to put an invisible <span> inside the button?
[17:51:37 EDT(-0400)] <colinclark> ecochran: I was just going to suggest it.
[17:51:47 EDT(-0400)] <ecochran> <span>Remove file from queue</span>
[17:51:52 EDT(-0400)] <colinclark> I'll give it a try.
[17:51:59 EDT(-0400)] <ecochran> not sure how I keep the browser from taking up the space
[17:52:10 EDT(-0400)] <ecochran> probably with a width tag
[17:52:18 EDT(-0400)] <ecochran> attr
[17:52:23 EDT(-0400)] <ecochran> please do
[18:02:31 EDT(-0400)] <colinclark> ecochran: In Firefox, it was enough to put a display: none; style on the span to hide it.
[18:02:43 EDT(-0400)] <colinclark> I can't test in IE 6, since Uploader seems not to work there.
[18:03:05 EDT(-0400)] <colinclark> ecochran: Do you think this is workable?
[18:03:06 EDT(-0400)] <ecochran> I thought that display: none elm are not read by screen readers?
[18:03:16 EDT(-0400)] <colinclark> Yep, it read it without any trouble.
[18:03:33 EDT(-0400)] <ecochran> really
[18:03:36 EDT(-0400)] <ecochran> wow
[18:03:36 EDT(-0400)] <colinclark> I'm assuming it's because its container-the button-was focusable.
[18:03:42 EDT(-0400)] <colinclark> At least in JAWS, yes.
[18:03:43 EDT(-0400)] <ecochran> cool
[18:03:48 EDT(-0400)] <colinclark> I don't have WindowEyes here to test with.
[18:07:26 EDT(-0400)] <colinclark> ecochran: Can I ask you advice on this?
[18:07:39 EDT(-0400)] <ecochran> ye
[18:07:41 EDT(-0400)] <ecochran> s
[18:07:53 EDT(-0400)] <colinclark> Here's the markup I've got for the button:
[18:08:06 EDT(-0400)] <colinclark> <button type="button" class="removeFile" title="Remove File" tabindex="0"><span class="description">Remove file from queue</span></button>
[18:08:38 EDT(-0400)] <colinclark> I was going to create a selector in the infusion-theme.css that would catch the general case of graphic-only buttons with descriptive text hidden inside them:
[18:08:49 EDT(-0400)] <colinclark> .infusion button span.description {
[18:08:49 EDT(-0400)] <colinclark> display: none;
[18:08:50 EDT(-0400)] <colinclark> }
[18:08:58 EDT(-0400)] <colinclark> Does that seem like a reasonable approach?
[18:09:12 EDT(-0400)] <ecochran> yes
[18:09:30 EDT(-0400)] <ecochran> perhaps it should be more explicit and be called spoken-description
[18:09:44 EDT(-0400)] <colinclark> Great, thanks. How about graphic-description?
[18:09:50 EDT(-0400)] <ecochran> that works
[18:09:56 EDT(-0400)] <colinclark> Actually, that sounds funny, doesn't it?
[18:10:12 EDT(-0400)] <colinclark> image-description?
[18:10:28 EDT(-0400)] <ecochran> hmm
[18:10:40 EDT(-0400)] <ecochran> the image is on the element and not on the span
[18:10:56 EDT(-0400)] <colinclark> on the button, you mean?
[18:10:57 EDT(-0400)] <ecochran> I just don't want to confuse anyone trying to use the stylesheet
[18:11:03 EDT(-0400)] <colinclark>
[18:11:04 EDT(-0400)] <ecochran> on the button, yes
[18:11:09 EDT(-0400)] <colinclark> nor do I
[18:11:53 EDT(-0400)] <ecochran> for-tts
[18:12:12 EDT(-0400)] <ecochran> maybe that's too graphic as well?
[18:12:28 EDT(-0400)] <colinclark> Semantically, there's nothing specific for text to speech. It's just an additional (albeit hidden) description
[18:12:53 EDT(-0400)] <colinclark> It's just a name, I guess.
[18:13:36 EDT(-0400)] <ecochran> but it's only hidden for TTS
[18:13:58 EDT(-0400)] <colinclark> well, it's hidden for anything that can't read the button.
[18:14:06 EDT(-0400)] <ecochran> yes
[18:14:07 EDT(-0400)] <colinclark> A screenreader happens to be our most prominent case.
[18:15:05 EDT(-0400)] <colinclark> text-description? It's a text description of the image button.
[18:15:41 EDT(-0400)] <ecochran> I like that
[18:15:51 EDT(-0400)] <ecochran> a tad redundant
[18:16:14 EDT(-0400)] <colinclark> let's go with it for now unless anyone else has bright ideas.
[18:33:01 EDT(-0400)] <colinclark> ecochran: I committed my changes against FLUID-661 and marked it as resolved and bounced it to JH to verify.
[18:33:12 EDT(-0400)] <ecochran> thx
[18:33:23 EDT(-0400)] <colinclark> So there are two things left I noticed in my testing:
[18:33:46 EDT(-0400)] <colinclark> 1. Turning Browse Files into a real button. I can give this a shot if it would be helpful to you.
[18:34:06 EDT(-0400)] <colinclark> 2. Putting focus on the Pause button when the progress bar appears.
[18:35:31 EDT(-0400)] <colinclark> It's sort of a confusing experience for AT users, since they won't necessarily know the progress bar is even there. And it's much more work to make it accessible. So in the interim, it's probably enough to ensure that Pause/Resume are focusable, and then at the end of it all, put focus back on the "Add more" button.
[18:37:07 EDT(-0400)] <colinclark> eocochran: I think we won't get to FLUID-662 through 665 for this release. So those two tasks above should suffice.
[18:38:35 EDT(-0400)] <colinclark> eocochran: And I can take the file list out of the tab order, since it doesn't serve any purpose now that the remove buttons are focusable. Until we add ARIA, it's just an empty tab stop as far as the user is concerned.
[18:51:44 EDT(-0400)] <ecochran> yes
[18:51:58 EDT(-0400)] <ecochran> soryr, Clayton just arrived so we're gabbing
[18:58:48 EDT(-0400)] <ecochran> colinclark: yes
[19:04:14 EDT(-0400)] <colinclark> ecochran: No problem.
[19:04:22 EDT(-0400)] <colinclark> Say hi to Clayton for me.
[19:04:33 EDT(-0400)] <ecochran> I've got some pretty big changes to check in
[19:04:51 EDT(-0400)] <ecochran> all forced because IE doesn't understand display: table-row
[19:04:55 EDT(-0400)] <colinclark> k, no problem.
[19:23:30 EDT(-0400)] <colinclark> ecochran: It's so strange. In FF2, the container for the files seems to be focusable. But I can't figure out why. In FF3, it's not a problem.
[19:24:38 EDT(-0400)] <ecochran> I haven't been using FF3 at all
[19:24:39 EDT(-0400)] <colinclark> Oh well, quirks will live on.
[19:24:49 EDT(-0400)] <ecochran> how are things looking FF3?
[19:24:59 EDT(-0400)] <ecochran> last I looked there were some display bugs
[19:25:08 EDT(-0400)] <colinclark> It actually looks great in FF3.
[19:25:49 EDT(-0400)] <michelled> colinclark: turns out I'm going to commit my patch to FLUID-617
[19:25:56 EDT(-0400)] <colinclark> michelled: Okay, great.
[19:26:05 EDT(-0400)] <michelled> I've put comment into the code about what's bugging me so you can see it there.
[19:26:57 EDT(-0400)] <ecochran> OK, IE6 still looks like crap
[19:27:05 EDT(-0400)] <ecochran> IE7 is looking pretty good
[19:27:42 EDT(-0400)] <ecochran> Progress is really messed up on IE6
[19:31:28 EDT(-0400)] <colinclark> ecochran: IE6 is really messed up.
[19:31:53 EDT(-0400)] <colinclark> I'm going to run now. Doug's here for dinner and then I've got a gig to watch tonight.
[19:31:58 EDT(-0400)] <colinclark> Talk to you all tomorrow.
[19:52:37 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work