fluid-work IRC Logs-2008-09-19

Owned by Fluid IRC Log Bot
Last updated: Sept 19, 2008Version comment
13 min read

[08:14:28 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:14:37 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[08:54:45 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[08:57:55 EDT(-0400)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:23:28 EDT(-0400)] * Topic is 'http://www.talklikeapirate.com/' set by jessm on 2008-09-19 09:23:28 EDT(-0400)
[09:51:56 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:54:39 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:05:10 EDT(-0400)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[10:07:28 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1176018330.dsl.bell.ca) has joined #fluid-work
[11:42:18 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[11:44:46 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:47:45 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-48.LIPS.Berkeley.EDU) has joined #fluid-work
[11:49:31 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[13:02:49 EDT(-0400)] <jessm> ecochran: can you turn off video in connect – see if that speeds things?
[13:03:34 EDT(-0400)] <ecochran> its very unresponsive
[13:03:40 EDT(-0400)] <jessm> ugh
[13:03:44 EDT(-0400)] <ecochran> I can click buttons but nothing happens
[13:03:47 EDT(-0400)] <jessm> i hope those admins are watching
[13:04:22 EDT(-0400)] <ecochran> it took seconds to get my camera to turn on and then seconds to get it to turn off
[13:04:59 EDT(-0400)] <jessm> audio on skype all
[13:05:01 EDT(-0400)] <ecochran> I just started a new session to see if that will help
[13:05:28 EDT(-0400)] <ecochran> ok, ... wait I don't have Skype on the loaner machine!
[13:05:40 EDT(-0400)] <ecochran> I'll just pass along my update here...
[13:06:15 EDT(-0400)] <ecochran> I'm working on Uploader IE bugs in both Uploader1 and 2
[13:09:52 EDT(-0400)] <jessm> k
[13:10:01 EDT(-0400)] <jessm> gotcha
[13:39:19 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[13:40:28 EDT(-0400)] <ecochran> Justin_o: I can't reproduce FLUID-1578, could this be a Windows 2000 only problem?
[13:40:36 EDT(-0400)] <ecochran> Although why I don't know
[13:40:48 EDT(-0400)] <Justin_o> ecochran: i'll double chekc
[13:40:50 EDT(-0400)] <Justin_o> check
[13:40:55 EDT(-0400)] <ecochran> thanks
[13:41:14 EDT(-0400)] <Justin_o> this one is really weird
[13:41:28 EDT(-0400)] <Justin_o> it may be an error with win2000 and the swf file
[13:41:42 EDT(-0400)] <Justin_o> basically ff3 can't run it locally in windows 2000
[13:43:42 EDT(-0400)] <ecochran> OK, if that is the case, I'm very tempted to mark this "Will not fix" as I don't think that there is anything that we can do about it
[13:43:58 EDT(-0400)] <ecochran> Sounds like a Flash/Win 2000 problem
[13:44:16 EDT(-0400)] <ecochran> But it works in IE <head scratching>
[13:44:18 EDT(-0400)] <ecochran> ?
[13:44:39 EDT(-0400)] <Justin_o> yes... i know... i don't understand
[13:46:24 EDT(-0400)] <Justin_o> I'm thinking about leaving this one open for now. just in case
[13:46:35 EDT(-0400)] <ecochran> fine by me
[13:47:11 EDT(-0400)] <ecochran> Another ? for you: FLUID-1031 (no focus styling applied to files in file queue, using IE)
[13:47:17 EDT(-0400)] <ecochran> this is very true
[13:47:27 EDT(-0400)] <ecochran> however, I can't reproduce part of the decscription
[13:47:49 EDT(-0400)] <Justin_o> sure.. which part
[13:47:53 EDT(-0400)] <ecochran> you say that you can delete files using the keyboard, even though the row isn't highlighted... I can't do that
[13:48:09 EDT(-0400)] <ecochran> if it is true then it indicates a different problem than what I'm seeing
[13:48:11 EDT(-0400)] <Justin_o> really... let me check again in case something has changed
[13:49:16 EDT(-0400)] <ecochran> basically I think that selectable in the keyboard-a11y plug-in is broken in IE at least for this instance... I can't get the files to select at all using the keyboard, which is different than just a styling problem
[13:50:49 EDT(-0400)] <Justin_o> I was able to do it in IE7... i'll check now for IE6
[13:51:20 EDT(-0400)] <ecochran> Uploader 1 or 2?
[13:51:54 EDT(-0400)] <Justin_o> Uploader 1
[13:51:59 EDT(-0400)] <Justin_o> is that what you are checking?
[13:52:19 EDT(-0400)] <Justin_o> I was also able to do it in IE 6
[13:52:37 EDT(-0400)] <Justin_o> The first tab off of the address bar puts you into the file queue.. then just start hitting the delete key
[13:52:39 EDT(-0400)] <colinclark> ecochran: Tiny detail...
[13:52:55 EDT(-0400)] <colinclark> I'm wondering if we should call the focus class in Uploader "focused" to match with our states-style thinking.
[13:53:20 EDT(-0400)] <colinclark> It seems to me a useful semantic to convey that an element is focused. Too bad the :focus pseudo-selector is broken in IE 6!
[13:53:58 EDT(-0400)] <colinclark> Although, thinking about it more...
[13:54:14 EDT(-0400)] <ecochran> actually :focus appears to be broken in IE7 as well
[13:54:17 EDT(-0400)] <colinclark> What is the focused state for a file row? Does it actually convey that a particular row is "selected?"
[13:54:27 EDT(-0400)] <colinclark> ecochran: ooh, drag. I didn't realize that. (sad)
[13:54:44 EDT(-0400)] <colinclark> Or is focused different here than selected?
[13:54:55 EDT(-0400)] <ecochran> I like in the css that it is elm:focus and elm.focus
[13:55:15 EDT(-0400)] <ecochran> but selected is the "state", that's how you wrote it for Uploader2
[13:55:26 EDT(-0400)] <colinclark> Right. It's already there.
[13:55:30 EDT(-0400)] <ecochran> yes
[13:55:36 EDT(-0400)] <colinclark> I see the lack of symmetry you're thinking of.
[13:55:42 EDT(-0400)] <ecochran> but it's not working in any of the IEs
[13:56:05 EDT(-0400)] <colinclark> I wonder if, in a sense, it's more descriptive to key of this selected state.
[13:56:07 EDT(-0400)] <colinclark> Thoughts?
[13:57:13 EDT(-0400)] <ecochran> it's not really focused the way that a button is focused in that it doesn't have an inherent focus in HTML
[13:57:52 EDT(-0400)] <ecochran> but the behavior is exactly the same as a focus
[13:58:06 EDT(-0400)] <ecochran> and we're calling the focus event on it
[13:58:09 EDT(-0400)] <ecochran> so it is the same
[13:58:30 EDT(-0400)] <ecochran> it is "focused" for all intents and purposes
[13:58:38 EDT(-0400)] <ecochran> so I like
[13:58:42 EDT(-0400)] <ecochran> "focus"
[13:58:54 EDT(-0400)] <colinclark> Yes, it's literally focused. That's what the non-negative tabindex affords.
[13:59:08 EDT(-0400)] <ecochran> exactly
[13:59:23 EDT(-0400)] <colinclark> The problem with this is a different kind of symmetry...
[13:59:25 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[13:59:39 EDT(-0400)] <colinclark> With the API for the keyboard plugin, which makes things "selectable."
[14:00:03 EDT(-0400)] <ecochran> yes, what is clearer to have symmetry in the JS or in the CSS
[14:00:17 EDT(-0400)] <colinclark> Perhaps this is a more specifc notion of focus that conveys how focus was obtained... through the arrow key-style of interaction.
[14:00:32 EDT(-0400)] <ecochran> and selectable is how we distinguish from tabbable
[14:00:37 EDT(-0400)] <ecochran> yes
[14:00:38 EDT(-0400)] <colinclark> Exactly
[14:00:48 EDT(-0400)] <colinclark> But it's certainly overlapping...
[14:01:10 EDT(-0400)] <ecochran> so, use focus for tabbable items and selected for selectable items
[14:01:13 EDT(-0400)] <ecochran> or focused
[14:01:26 EDT(-0400)] <colinclark> Well, but the question is if we really need that sort of distinction.
[14:01:27 EDT(-0400)] <ecochran> tabbed?
[14:01:48 EDT(-0400)] <ecochran> in the CSS something would never have both
[14:01:56 EDT(-0400)] <ecochran> selected = focused
[14:02:05 EDT(-0400)] <colinclark> right
[14:02:09 EDT(-0400)] <ecochran> selected === focused
[14:02:13 EDT(-0400)] <colinclark> (smile)
[14:02:25 EDT(-0400)] <colinclark> Is it likely that the style applied for showing the focus indicator is very different for a tab-focusable item versus a arrow-key focusable item?
[14:03:33 EDT(-0400)] <ecochran> not sure I agree with the "very", different yes, the two styles buttons vs. rows are remarkably alike in Uploader, both use a 2px wide border
[14:03:56 EDT(-0400)] <ecochran> but still your point is valid
[14:04:20 EDT(-0400)] <ecochran> what do you like about my idea that the styling should be part of selectable?
[14:04:25 EDT(-0400)] <ecochran> with a default?
[14:04:50 EDT(-0400)] <ecochran> styling a focused item just seems so basic...
[14:05:05 EDT(-0400)] <ecochran> or are we just hoping that this will go away with a new version of IE?
[14:05:42 EDT(-0400)] <ecochran> perhaps an even more compelling reason to have it in one place, instead of every component managing the focused state of it's elements
[14:05:51 EDT(-0400)] <ecochran> its elements
[14:06:53 EDT(-0400)] <colinclark> yeah
[14:07:03 EDT(-0400)] <colinclark> just had to join a call
[14:07:07 EDT(-0400)] <colinclark> but we should clarify this
[14:07:26 EDT(-0400)] <colinclark> i totally agree that it would be great to abstract those kinds of states so components don't have to manage so much
[14:09:20 EDT(-0400)] <colinclark> trying to imagine how it would work... sounds like you've got something in mind
[14:13:08 EDT(-0400)] <ecochran> pretty much that selectable would have a default className (selected, focused, whatever) that would be applied on onSelect and onUnselect and that className could either be overridden or empty, if empty then no className action would happen
[14:13:33 EDT(-0400)] <ecochran> this would be completely separate from the onSelect and onUnselect callbacks
[14:13:50 EDT(-0400)] <ecochran> perhaps using those callback names confused things
[14:14:20 EDT(-0400)] <colinclark> aha
[14:14:27 EDT(-0400)] <jacobfarber> Justin_o: here?
[14:14:40 EDT(-0400)] <Justin_o> jacobfarber: yep
[14:14:53 EDT(-0400)] <colinclark> ecochran: so you're thinking that the keyboard-a11y plugin should drop this class onto the element automatically, so the author doesn't have to bother?
[14:15:05 EDT(-0400)] <ecochran> exactly
[14:15:11 EDT(-0400)] <colinclark> awesome!
[14:15:32 EDT(-0400)] <colinclark> ecochran: This fits in with my thinking about "accessibility decorators." The plugin's not enough, it's just really base infrastructure.
[14:15:48 EDT(-0400)] <colinclark> I'd like to roll some code that will make it super easy to build keyboard-accessible UIs by name...
[14:16:05 EDT(-0400)] <colinclark> so in otherwords, you'd just say "this is an arrowable list," and you'd get all the handlers and styles for free.
[14:16:20 EDT(-0400)] <ecochran> I like that...
[14:16:23 EDT(-0400)] <colinclark> I'd like to build it up from "qualities"...
[14:16:43 EDT(-0400)] <colinclark> "This is a list, it should be arrowable, and each of its items should be deletable."
[14:16:43 EDT(-0400)] <ecochran> but as infrastructure ... should the default be nothing so that the plugin is less obtrusive
[14:16:59 EDT(-0400)] <colinclark> I'm thinking so, yes.
[14:17:19 EDT(-0400)] <colinclark> So the idea is that components like the Uploader would just ask for a selectable, deletable list and get it.
[14:17:40 EDT(-0400)] <colinclark> Whereas something else, building up its own low-level keyboard logic, might use the plugin directly...
[14:17:47 EDT(-0400)] <colinclark> specifying its own styles, behaviour, based on its needs.
[14:18:04 EDT(-0400)] <colinclark> Don't know if I'm fully making sense...
[14:18:15 EDT(-0400)] <ecochran> no... you're making sense...
[14:18:19 EDT(-0400)] <colinclark> also participating in an Internet2 call. (wink)
[14:18:20 EDT(-0400)] * Bosmon (n=Bosmon@142.150.154.129) has joined #fluid-work
[14:18:30 EDT(-0400)] <Bosmon> I am here now
[14:18:35 EDT(-0400)] <Bosmon> To hear of your blasts from Hell
[14:18:44 EDT(-0400)] <Justin_o> Bosmon, jacobfarber: just wanted to chat about the bugs with the springboards.
[14:19:05 EDT(-0400)] <Justin_o> maybe we can get an idea of where come from... markup or code
[14:19:35 EDT(-0400)] <colinclark> Justin_o is king. His blasts are divine! (tongue)
[14:20:01 EDT(-0400)] <Bosmon> (tongue)
[14:20:06 EDT(-0400)] <ecochran> there is an issue of "generalizability" of the interface... for example would every list have a "delete me" button on each row... or would the context require that the whole row have a click to delete action? So there would still need to be some level of customizability. But generally this is good!
[14:20:08 EDT(-0400)] <Justin_o> 8)
[14:20:11 EDT(-0400)] <ecochran> Say hi to Lois
[14:20:12 EDT(-0400)] <Bosmon> Yes, and they move in straight lines
[14:20:22 EDT(-0400)] <colinclark> ecochran: Will do.
[14:20:31 EDT(-0400)] <Justin_o> i'm trying to find you guys a filter so we can look at the issues.. one sec
[14:20:52 EDT(-0400)] <colinclark> ecochran: I was thinking that it would be pretty pragmatic... if no other details were present, we'd need to be told only what element to click to get a particular piece of behaviour... activate or delete or whatever.
[14:20:57 EDT(-0400)] <Justin_o> Bosmon, jacobfarber: http://issues.fluidproject.org/secure/IssueNavigator.jspa?reset=true&amp;mode=hide&amp;pid=10001&amp;sorter/order=DESC&amp;sorter/field=priority&amp;resolution=-1&amp;component=10068
[14:21:16 EDT(-0400)] <colinclark> So the reason I call them "decorators" is because they'd just wrap something from the outside, without core access to how it was built.
[14:21:47 EDT(-0400)] <ecochran> yep... not quite as slick as $(listelm).fluidlisteething();
[14:22:08 EDT(-0400)] <colinclark> (smile)
[14:22:10 EDT(-0400)] <Justin_o> Bosmon, jacobfarber : we probably just work our way down from the top...
[14:22:12 EDT(-0400)] <Bosmon> So, FLUID-1591 I think is impossible
[14:22:23 EDT(-0400)] <Bosmon> I haven't the slightest idea even how to begin on such a bug...
[14:22:41 EDT(-0400)] <Bosmon> Other than historical "binary section"
[14:22:57 EDT(-0400)] <Bosmon> Take away roughly half the page or half the markup at various trials, and see when it stops happening (tongue)
[14:23:21 EDT(-0400)] <Justin_o> Bosmon: do you think it is an issue with the reorderer or somewhere else?
[14:23:35 EDT(-0400)] <jacobfarber> im looking through them now...
[14:24:08 EDT(-0400)] <Bosmon> Justin_o: My feeling is that we will find some piece of markup or CSS is "provocative" in this situation for IE6
[14:24:24 EDT(-0400)] <Bosmon> I am wondering whether it is this "anchor within li" idiom that is so popular these days
[14:24:28 EDT(-0400)] <ecochran> Although, and here we're getting into the realm of non-DOM-agnostic, just as we wrap things with DOM we want to do things, we could inject DOM and behavior into a generic context... simple list + fluid = accessible smart list with behavior
[14:24:36 EDT(-0400)] <ecochran> colinclark: ^
[14:24:39 EDT(-0400)] <Bosmon> Which may also be responsible for the jquery-tabs tabindex cycle issue
[14:24:45 EDT(-0400)] <Bosmon> But it may well be more subtle than that
[14:24:57 EDT(-0400)] <colinclark> ecochran: Template renderer! (wink)
[14:25:23 EDT(-0400)] <colinclark> I think it will have a lot of potential if it can do things like that... progressively enhance a simple document with wicked dynamic components.
[14:25:40 EDT(-0400)] <ecochran> yep, although in my example we're not building the list, we're "decorating" the list
[14:25:56 EDT(-0400)] <ecochran> when I think of template rendering I think of data + renderer = dom
[14:26:27 EDT(-0400)] <lessthanzero> what is the difference between "fix versions" and "affects versions" in the tracker?
[14:26:32 EDT(-0400)] <jacobfarber> Bosmon + Justin_o I think we can agree 1593 is a reorderer thing?
[14:26:42 EDT(-0400)] <lessthanzero> would a new feature be an "affect version" and a bug issue be a "fix versions" ?
[14:27:02 EDT(-0400)] <Bosmon> 1593 is something it may be possible to mitigate
[14:27:25 EDT(-0400)] <Bosmon> But it may have to result in a bit of a "regression" with respect to our cursor + avatar positioning fixes
[14:27:59 EDT(-0400)] <Justin_o> Bosmon: I'm not sure it would be worth it then
[14:28:08 EDT(-0400)] <Bosmon> Well no, I mean via a browser detect
[14:28:17 EDT(-0400)] <Bosmon> IE6 is the only environment where this screws up
[14:28:36 EDT(-0400)] <Bosmon> So it might make sense to simply use mouse coordinates "uncorrected" if we detect precisely this browser
[14:29:27 EDT(-0400)] <Justin_o> Bosmon: i'm double checking right now if it is not working correctly on the lightbox page
[14:29:45 EDT(-0400)] <Bosmon> Oddly 1593 seems to not affect other kinds of samples too much
[14:29:52 EDT(-0400)] <Bosmon> Justin_o: thanks
[14:30:15 EDT(-0400)] <Justin_o> Bosmon: yes it working fine there... if you were to implement that fix would it then impact the other examples
[14:30:19 EDT(-0400)] <jacobfarber> FLUID-1597 is definitely a springboard problem, I can work on that one.
[14:30:32 EDT(-0400)] <Bosmon> Justin_o: Yes, it might
[14:30:58 EDT(-0400)] <Bosmon> It would probably bring ourselves back on IE6 to the situatoin before the click offset corrections were implemented
[14:31:54 EDT(-0400)] <Justin_o> lets put this one hold for now... what do you guys think about Fluid-1597
[14:32:06 EDT(-0400)] <jacobfarber> Justin_o, Bosmon: brb
[14:32:08 EDT(-0400)] <colinclark> ecochran: Well, I guess I'm thinking that the template renderer could actually decorate, too. So I'm thinking, given a plain old list, it could render the appropriate additional DOM required to get one of these dynamic thingies for free.
[14:32:10 EDT(-0400)] <Bosmon> Another thing to try might be to fall back on JQuery dimensions for IE6 which will be somewhat slower but might be more accurate
[14:32:24 EDT(-0400)] <colinclark> ecochran: Still just thinking out loud here.
[14:32:33 EDT(-0400)] <ecochran> yep
[14:32:57 EDT(-0400)] <Bosmon> 1597....
[14:32:58 EDT(-0400)] <ecochran> the renderer could definitely do that
[14:33:14 EDT(-0400)] <ecochran> colinclark: build were needed, decorate where needed
[14:33:25 EDT(-0400)] <colinclark> ecochran: Yes! You nailed it.
[14:33:43 EDT(-0400)] <Bosmon> 1597 is just bollocks
[14:33:51 EDT(-0400)] <colinclark> complete pants
[14:33:55 EDT(-0400)] <colinclark> (tongue)
[14:34:00 EDT(-0400)] * colinclark is learning British.
[14:34:08 EDT(-0400)] <Justin_o> Bosmon: does that mean it's up to jacobfarber to fix
[14:34:21 EDT(-0400)] <Bosmon> Again, we can just try a browser detect
[14:34:34 EDT(-0400)] <Bosmon> If we think that MacOS Safari is congenitally incapable of computing the height of an element
[14:35:02 EDT(-0400)] <Bosmon> I only put that fix in "opportunistically"
[14:35:08 EDT(-0400)] <Bosmon> Since it doesn't do anything for the portal sample
[14:35:17 EDT(-0400)] <Bosmon> jacobfarber was saying that it was helpful to him and was sometimes working
[14:35:17 EDT(-0400)] <colinclark> Bosmon: Only half following the covo. Is it possible to detect the incapacity rather than making a blanket browser assumption?
[14:35:41 EDT(-0400)] <Bosmon> colinclark: I'm not sure how one could detect in closed form that one has been given the wrong height for an element
[14:35:47 EDT(-0400)] <Bosmon> What would one compare the answer to? (smile)
[14:35:57 EDT(-0400)] <colinclark> That's what I figured.
[14:36:23 EDT(-0400)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[14:36:23 EDT(-0400)] <Bosmon> In the browser world, "We are all thirteen-inch rulers"
[14:37:39 EDT(-0400)] <Justin_o> Okay... lastly although jacobfarber will probably have to weigh in on this one but i'll ask it now so we can start to get some ideas is about Fluid-1542
[14:38:18 EDT(-0400)] <Bosmon> Again, it might be worth replacing the computation for 1597 with JQuery's own
[14:38:23 EDT(-0400)] <Bosmon> To see if it is subject to the same bug
[14:39:08 EDT(-0400)] <Justin_o> Bosmon: what do you believe the intended behaviour is. I'm not exactly sure what is meant by a static portlet
[14:39:27 EDT(-0400)] <Bosmon> Static portlet?
[14:41:13 EDT(-0400)] <Bosmon> Btw I am not getting any drop warnings on the Springboard samples - is this known/JIRAed?
[14:42:19 EDT(-0400)] <Justin_o> Bosmon: jacobfarber just added them to example 3... I'm not sure if they are supposed to be there in example 2
[14:47:01 EDT(-0400)] <Justin_o> Bosmon, jacobfarber: I'm wondering if this example is still necessary
[15:04:51 EDT(-0400)] * apetro-_ (n=apetro@ip24-56-20-55.ph.ph.cox.net) has joined #fluid-work
[15:08:53 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[15:49:05 EDT(-0400)] <jacobfarber> Bosmon: you there?
[15:56:30 EDT(-0400)] <Bosmon> Yes
[15:57:33 EDT(-0400)] <Bosmon> jacobfarber: I have had a poke at FLUID-1593
[15:57:46 EDT(-0400)] <Bosmon> It seems it is not really related to my "pointer offset" code at all
[15:58:03 EDT(-0400)] <Bosmon> Actually that code seems to be helping here, since it does seem to manage to successfully compensate for the avatar offset
[15:58:09 EDT(-0400)] <Bosmon> even if it is ludicrously far from the mouse pointer
[15:59:13 EDT(-0400)] <jacobfarber> hmmm
[15:59:42 EDT(-0400)] <Bosmon> Whatever is happening to the avatar, it seems to be somewhere between JQuery draggable and the browser
[16:00:16 EDT(-0400)] <jacobfarber> thats what I was wondering
[16:00:16 EDT(-0400)] <Bosmon> Hmm
[16:00:24 EDT(-0400)] <Bosmon> I wonder if it is the height issue again
[16:00:26 EDT(-0400)] <Bosmon> Let me experiment
[16:00:28 EDT(-0400)] <jacobfarber> someswhere. coords are being thrown off
[16:01:06 EDT(-0400)] <jacobfarber> but i figured its a prob. in the mousemove event itself....
[16:01:11 EDT(-0400)] <jacobfarber> just a guess though
[16:01:37 EDT(-0400)] <jacobfarber> which would be strange, since you would prob. hear more from people about this issue then, right?
[16:01:49 EDT(-0400)] <Bosmon> No, the avatar sizing is not relevant either
[16:02:09 EDT(-0400)] <Bosmon> Well, I know you may not be wanting to hear this
[16:02:15 EDT(-0400)] <jacobfarber> (tongue)
[16:02:24 EDT(-0400)] <jacobfarber> you think its a css thing?
[16:02:32 EDT(-0400)] <Bosmon> But I can't help feeling that a lot of these issues really are caused by this "oversize anchor within tag" trick that we are increasingly using (tongue)
[16:02:51 EDT(-0400)] <jacobfarber> in the springboards? Doesnt exist there
[16:02:57 EDT(-0400)] <Bosmon> It might be worth experimenting with different choices of markup and css and see if it doesn't happen that the issue goes away
[16:03:00 EDT(-0400)] <jacobfarber> for the layout customizer i mean
[16:03:04 EDT(-0400)] <jacobfarber> ok
[16:03:04 EDT(-0400)] <Bosmon> Well, the markup for that sample seems to be of the same form
[16:03:06 EDT(-0400)] <jacobfarber> will do
[16:03:16 EDT(-0400)] <jacobfarber> LC right?
[16:03:20 EDT(-0400)] <Bosmon> Oh sorry, I misread
[16:03:25 EDT(-0400)] <Bosmon> These are just plain "<p"> tags
[16:03:40 EDT(-0400)] <Bosmon> Gah
[16:03:45 EDT(-0400)] <Bosmon> Well, really, I have no idea (sad)
[16:03:55 EDT(-0400)] <Bosmon> This just seems to be a general area of dark magic (tongue)
[16:04:38 EDT(-0400)] <Bosmon> For some reason, we aren't seeing this in the Lightbox, for example
[16:06:05 EDT(-0400)] <jacobfarber> im going to try to do some super basic stuff and see what happens
[16:06:11 EDT(-0400)] <jacobfarber> whats the jira on this?
[16:06:26 EDT(-0400)] <Bosmon> 1593
[16:06:46 EDT(-0400)] <Bosmon> I can't help feeling that 1593 and 1591 are related
[16:07:02 EDT(-0400)] <Bosmon> There might be something about the markup of in the earlier samples that interacts with the later one on the same page....
[16:08:09 EDT(-0400)] <jacobfarber> if only there was a firebug for IE6....and not firebug lite
[16:13:47 EDT(-0400)] <jacobfarber> I wonder.....http://dev.jquery.com/ticket/2618
[16:13:54 EDT(-0400)] <jacobfarber> BUT we dont use quirksmode!
[16:14:08 EDT(-0400)] <jacobfarber> yet this is something im going to look into
[16:17:44 EDT(-0400)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[16:19:08 EDT(-0400)] <Bosmon> Yes, well, I tinkered a bit with firebug lite
[16:19:19 EDT(-0400)] <Bosmon> But all it seemed to reveal on this example was that everything was roughly as it should be
[16:19:28 EDT(-0400)] <Bosmon> Except, of course, for the avatar position (smile)
[16:23:15 EDT(-0400)] <Bosmon> jacobfarber: You may want to read through some of the code in ui.draggable.js
[16:23:23 EDT(-0400)] <Bosmon> In particular, "mouseStart" at line 31
[16:23:39 EDT(-0400)] <Bosmon> And see if it suggests anything to you (tongue)
[16:23:49 EDT(-0400)] <Bosmon> In particular, line 49 would seem to be very relevant
[16:24:02 EDT(-0400)] <Bosmon> if(this.helper[0] != this.element[0] && !(/(fixed|absolute)/).test(this.helper.css("position"))) this.helper.css("position", "absolute");
[16:24:02 EDT(-0400)] <Bosmon>
[16:24:16 EDT(-0400)] <Bosmon> This line seems to test and adjust css properties related to the positioning of the avatar....
[16:25:39 EDT(-0400)] <Bosmon> Also line 156, "generatePosition" has to be crucial
[16:27:10 EDT(-0400)] <jacobfarber> good lord
[16:34:07 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work
[17:07:33 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-71-150-249-107.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[17:31:00 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:47:37 EDT(-0400)] * apetro-_ (n=apetro@ip24-56-20-55.ph.ph.cox.net) has joined #fluid-work
[18:52:04 EDT(-0400)] * jessm_ (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work