[08:07:22 CST(-0600)] <heidi_> hey cindyli, is the yellow box that remains after you select a new pkg intentional?
[08:07:29 CST(-0600)] <heidi_> (on builder)
[08:17:33 CST(-0600)] <heidi_> have we been doing any testing with system access to go?
[08:18:07 CST(-0600)] <cindyli> heidi_: sorry, was talking to greg. the yellow box is not mentioned inthe test plan but it seems the behaviour across the browser so i assume that's what it's supposed to be
[08:18:48 CST(-0600)] <heidi_> cindyli i think we should maybe remove it - seems like it could be a bug? but maybe there are reasons for it. who wrote builder html?
[08:19:19 CST(-0600)] <cindyli> heidi_: Justin_o, not sure, jacob?
[08:22:21 CST(-0600)] <cindyli> heidi_: another thing i noticed is when u click on the button, the button is sort of like breaking into 2 parts at the mouse down. this is more obvious in ie. do u see the same in your testing?
[08:22:22 CST(-0600)] <Justin_o> cindyli, heidi_: I pretty sure it was jacob who do the previous round of styling changes
[08:23:22 CST(-0600)] <heidi_> okay maybe we need to revisit the html/css
[08:23:48 CST(-0600)] <heidi_> cindyli - i haven't noticed that. but ill check IE now
[08:26:08 CST(-0600)] <heidi_> cindyli my IE8 doesn't break, but it has a weird yellow box around the column when i click on something
[08:26:52 CST(-0600)] <jhung> justin_o: I was planning on testing Layout Reorderer today, or is there something else I should be looking at?
[08:27:22 CST(-0600)] <heidi_> i don't really like how a hover item changes to bold cos sometimes that resizes the box.
[08:27:24 CST(-0600)] <cindyli> heidi_: u mean when u click on the checkbox? i see the same at mouse down but once selected, the yellow box is gone
[08:27:34 CST(-0600)] <heidi_> cindyli yeah mousedown
[08:28:46 CST(-0600)] <cindyli> heidi_: i agree that the box resize is a bit annoying
[08:30:25 CST(-0600)] <heidi_> cindyli i can help tweak the css after i'm through the test plan
[08:30:46 CST(-0600)] <cindyli> heidi_: that's great. thank you!
[08:30:48 CST(-0600)] <heidi_> i feel like the whole yellow box should be clickable - not just the header
[08:30:53 CST(-0600)] <heidi_> what do you think?
[08:31:12 CST(-0600)] <Justin_o> jhung: i think that's probably good for now
[08:31:14 CST(-0600)] <Justin_o> thanks
[08:32:20 CST(-0600)] <cindyli> heidi_: i feel the same. but if u get to the almost bottom of the test plan, if i rmb correctly, this is what's supposed to be
[08:32:54 CST(-0600)] <heidi_> maybe we should change it
[08:33:02 CST(-0600)] <heidi_> ill keep going through for now
[08:33:13 CST(-0600)] <cindyli> heidi_: good idea
[08:34:01 CST(-0600)] <heidi_> cindyli what does the empty iframe do?
[08:36:40 CST(-0600)] <cindyli> heidi_: that's a workaround for the ff bug that the spinner only spins the first time after the page loads. this bug happens when the page url is re-located to fetch the download. the iframe is to handle the url re-direct
[08:37:13 CST(-0600)] <heidi_> crazy - is there a jira for that?
[08:37:56 CST(-0600)] <heidi_> isn't it do-able to force a d/l without a redirect? just push headers
[08:37:59 CST(-0600)] <cindyli> heidi_: yes, that jira is resloved and closed. u want to have a look? i can dig it up
[08:38:02 CST(-0600)] <heidi_> in php it is anyway...
[08:38:09 CST(-0600)] <heidi_> yes please !
[08:40:13 CST(-0600)] <cindyli> heidi_: http://issues.fluidproject.org/browse/FLUID-3233
[08:40:36 CST(-0600)] <heidi_> thanks cindyli
[08:41:32 CST(-0600)] <cindyli> heidi_: that jira only has one line for this iframe thing but i can explain more if u r interested. if u need, skype call?
[08:41:54 CST(-0600)] <heidi_> cindyli sure maybe in a bit!
[08:42:12 CST(-0600)] <cindyli> heidi_: ok. let me know
[08:42:13 CST(-0600)] <heidi_> i'll keep testing for now. is there a way to push headers with ajax
[08:43:16 CST(-0600)] <cindyli> heidi_: because of the push header, cannot use ajax
[08:44:29 CST(-0600)] <heidi_> hmm
[08:49:52 CST(-0600)] <colinclark> cindyli: maybe it's also worth updating that JIRA with some further explanation of the technique we're using
[08:50:16 CST(-0600)] <cindyli> cindyli: sure. will do it
[08:50:18 CST(-0600)] <colinclark> no doubt it's the sort of thing we might forget about in a few months or a year, and then someone will come along and ask "what's the empty iframe do?"
[08:50:20 CST(-0600)] <colinclark>
[08:50:34 CST(-0600)] <cindyli> colinclark: understand
[08:50:41 CST(-0600)] <colinclark> Clearly we're doing it for a well-thought out-if somewhat odd-reason
[08:51:12 CST(-0600)] <colinclark> So heidi_, I've just been following along with some of your questions and observations in the channel as you're testing Builder
[08:51:16 CST(-0600)] <colinclark> mind if I ask a few questions?
[08:51:38 CST(-0600)] <heidi_> sure!
[08:52:08 CST(-0600)] <colinclark> Going backwards...
[08:52:15 CST(-0600)] <colinclark> "i feel like the whole yellow box should be clickable - not just the header"
[08:52:20 CST(-0600)] <colinclark> can you elaborate on that one
[08:52:26 CST(-0600)] <colinclark> I think it's something I noticed as annoying, too
[08:52:31 CST(-0600)] <colinclark> but I just want to make sure I understand it
[08:53:06 CST(-0600)] <colinclark> So, if I understand it, you're thinking that both the title and the description should be active, right?
[08:53:08 CST(-0600)] <heidi_> right now when you hover over a component, there's a yellow box around the header & description paragraph
[08:53:15 CST(-0600)] <heidi_> yeah
[08:53:26 CST(-0600)] <colinclark> yeah, that one strikes me as really clear
[08:53:40 CST(-0600)] <colinclark> we give the user an affordance-that yellow box on hover-but we don't follow through with what we afford
[08:53:42 CST(-0600)] <colinclark> if that makes sense
[08:53:49 CST(-0600)] <colinclark> Yellow box says "this thing is clickable"
[08:53:54 CST(-0600)] <colinclark> yet only part of it is clickable
[08:53:58 CST(-0600)] <heidi_> yeah you sort of have to feel around in the box until you get the hand
[08:54:01 CST(-0600)] <colinclark> yep
[08:54:16 CST(-0600)] <colinclark> So, you know that jhung and jameswy have been working on a whole new design for the Builder, right?
[08:54:21 CST(-0600)] <heidi_> didn't know that
[08:54:22 CST(-0600)] <colinclark> Have you seen those designs yet?
[08:54:24 CST(-0600)] <colinclark> Ah, okay
[08:54:27 CST(-0600)] <colinclark> Hey jhung
[08:54:31 CST(-0600)] <heidi_> for implementing nowish?
[08:54:38 CST(-0600)] <colinclark> Can you fire us a link to your latest Builder wireframes so we can take a peek?
[08:54:45 CST(-0600)] <colinclark> heidi_: For implementing later-ish
[08:54:49 CST(-0600)] <heidi_> okee
[08:54:55 CST(-0600)] <colinclark> Nowish, we ship
[08:55:00 CST(-0600)] <heidi_> i ran through with voice over - works nicely
[08:55:04 CST(-0600)] <colinclark> cool!
[08:55:10 CST(-0600)] <colinclark> Users have been waiting for Builder for about a year and a half
[08:55:15 CST(-0600)] <colinclark> so it's high time we ship
[08:55:16 CST(-0600)] <heidi_> it's super neat
[08:55:18 CST(-0600)] <jhung> colinclark, heidi_: digging them up now.
[08:55:24 CST(-0600)] <colinclark> Little things we can probably do--like making the whole region clickable
[08:55:24 CST(-0600)] <colinclark> w
[08:55:34 CST(-0600)] <colinclark> what else did you find interesting, heidi_?
[08:55:45 CST(-0600)] <heidi_> cool - any idea why there's a yellow box leftover after you select something and move away from it?
[08:56:03 CST(-0600)] <colinclark> heidi_: You recognize that
[08:56:07 CST(-0600)] <heidi_> it feels like it maybe shouldn't happen
[08:56:09 CST(-0600)] <colinclark> That's your old friend
[08:56:14 CST(-0600)] <heidi_> haha is it?
[08:56:26 CST(-0600)] <colinclark> heidi_: try hitting tab, see what happens?
[08:56:47 CST(-0600)] <heidi_> nooooo
[08:56:49 CST(-0600)] <heidi_> haha
[08:56:58 CST(-0600)] <colinclark> So, I'm really of two minds about this...
[08:57:02 CST(-0600)] <heidi_> okay it's an overlap of active styling
[08:57:03 CST(-0600)] <colinclark> I'd argue that there are two separate issues
[08:57:26 CST(-0600)] <colinclark> 1. The :focus outline is the same colour as the mouse hover style, so it causes weird display issues
[08:57:40 CST(-0600)] <colinclark> That part could be fixed by making it, say, blue or something
[08:57:57 CST(-0600)] <colinclark> The other issue is the deeper issue--the one that Gary and mpollizotti mentioned in our meeting
[08:58:15 CST(-0600)] <colinclark> 2. Should we be restyling :focus at all, or is the browser's natural indication of focus sufficient?
[08:58:21 CST(-0600)] <colinclark> That's where I'm of two minds
[08:58:35 CST(-0600)] <colinclark> We've found that often the browser's native focus indicator is pretty "ghostly"
[08:58:42 CST(-0600)] <colinclark> hard to see
[08:58:43 CST(-0600)] <heidi_> yeah
[08:58:54 CST(-0600)] <colinclark> So I think there are often cases where it should be additionally highlighted
[08:59:09 CST(-0600)] <colinclark> But, then the other question is, "should we do this by default, and always?"
[08:59:18 CST(-0600)] <colinclark> The answer Gary and Matt gave us is "no"
[08:59:37 CST(-0600)] <colinclark> One might argue that clear, easy-to-see focus styling is something that keyboard users need, and that nobody bothers with
[08:59:37 CST(-0600)] <jhung> colinclark, heidi_: could it be that there isn't a Jira task to redesign the builder? I couldn't find one. I'll attach the wireframe to that.
[08:59:45 CST(-0600)] <heidi_> it's not an issue on safari tho
[08:59:48 CST(-0600)] <colinclark> so it should be a default
[09:00:01 CST(-0600)] <colinclark> but on the other hand, this design of the Builder shows how it doesn't really always work
[09:00:34 CST(-0600)] <colinclark> jhung: it's quite possible, yep
[09:00:43 CST(-0600)] <colinclark> Justin_o would probably know definitively
[09:01:27 CST(-0600)] <colinclark> heidi_: Safari's default focus indicator is really good
[09:01:30 CST(-0600)] <heidi_> only happens on FF for me... and on IE the entire column gets the outline
[09:01:38 CST(-0600)] <heidi_> only on hover.
[09:01:39 CST(-0600)] <colinclark> I guess it might suck on a site with a light blue colour scheme
[09:01:51 CST(-0600)] <heidi_> actually not just on hover
[09:02:02 CST(-0600)] <colinclark> that's interesting
[09:02:06 CST(-0600)] <colinclark> how do you reproduce, heidi_ ?
[09:02:22 CST(-0600)] <heidi_> just click on a component and the column it's in gets a yellow outline
[09:02:45 CST(-0600)] <colinclark> hmm
[09:02:48 CST(-0600)] <colinclark> Seems fine in FF4
[09:02:54 CST(-0600)] <heidi_> clicking on the paragraph of a component
[09:02:57 CST(-0600)] <colinclark> let me try a browser that has actually be officially released
[09:03:08 CST(-0600)] <heidi_> this is IE
[09:03:11 CST(-0600)] <heidi_> IE 8
[09:03:14 CST(-0600)] <colinclark> ah
[09:03:19 CST(-0600)] <heidi_> the focus is on the entire column
[09:03:23 CST(-0600)] <colinclark> let me fire up my vm
[09:03:49 CST(-0600)] <heidi_> jhung and i ran into this focus'ing of divs issue with the pager as well, in IE
[09:03:59 CST(-0600)] <colinclark> ah, very interesting
[09:04:02 CST(-0600)] <colinclark> In all IEs?
[09:04:05 CST(-0600)] <colinclark> or just more modern ones
[09:04:07 CST(-0600)] <colinclark> ?
[09:04:09 CST(-0600)] <heidi_> ill try 7
[09:04:21 CST(-0600)] <colinclark> I guess I'm more interested in 6
[09:04:26 CST(-0600)] <colinclark> IE 7 is pretty much a dead browser already
[09:04:36 CST(-0600)] <colinclark> The world is split between IE 6 and IE 8 for the most part
[09:04:39 CST(-0600)] <jhung> heidi_, colinclark: yes. It's FSS's aggressive focus styling.
[09:04:47 CST(-0600)] <heidi_> IE7 doesn't have that problem, just 8
[09:05:01 CST(-0600)] <colinclark> jhung: I guess that goes beyond "aggressive" into the territory of "bug," right jhung?
[09:05:08 CST(-0600)] <heidi_> i guess it was one of their "improvements"
[09:05:13 CST(-0600)] <colinclark> lol
[09:05:26 CST(-0600)] <colinclark> IE 6 and possibly 7 never supported the :focus pseudo selector
[09:05:30 CST(-0600)] <heidi_> ah
[09:05:32 CST(-0600)] <colinclark> perhaps IE 8 doesn't support it properly
[09:05:43 CST(-0600)] <colinclark> or we're doing some kind of IE hack that is not needed in 8
[09:05:44 CST(-0600)] <heidi_> yeah focusing a div is.. interesting
[09:05:57 CST(-0600)] <colinclark> you should take a look at the CSS, heidi_ and see if it's apparent why it happens
[09:08:03 CST(-0600)] <jhung> heidi_, colinclark: the Builder design needs a little updating. It'll take me a few minutes.
[09:09:16 CST(-0600)] <colinclark> jhung: No worries. We're just looking at it for reference, not because we're about to implement it or anything
[09:09:37 CST(-0600)] <jhung> colinclark: ah okay. In that case I'll attach what I have in a sec.
[09:09:47 CST(-0600)] <colinclark> k, thanks
[09:10:36 CST(-0600)] <heidi_> the css has a yellow outline on .fl-infusionBuilder :focus
[09:11:30 CST(-0600)] <colinclark> Right, that's the :focus pseudo selector
[09:11:35 CST(-0600)] <colinclark> is it done any other ways?
[09:11:58 CST(-0600)] <jhung> Heidi_, colinclark: http://issues.fluidproject.org/browse/FLUID-3840
[09:12:12 CST(-0600)] <colinclark> thanks, jhung
[09:13:45 CST(-0600)] <heidi_> new builder looks slick. just curious why all the dark greys?
[09:15:15 CST(-0600)] <heidi_> reading about active vs focus
[09:15:43 CST(-0600)] <heidi_> yeah that's not it... hm
[09:19:16 CST(-0600)] <mlam> jameswy: any updates on the html5 upload button?
[09:25:22 CST(-0600)] <colinclark> heidi_, cindyli: Have either of you tested Builder in IE 8 yet?
[09:25:31 CST(-0600)] <heidi_> colin next on my list
[09:25:52 CST(-0600)] <heidi_> unless cindyli have you
[09:26:13 CST(-0600)] <cindyli> heidi_: i did. seems fine
[09:26:23 CST(-0600)] <colinclark> I'm using http://builder.fluidproject.org
[09:26:27 CST(-0600)] <colinclark> I can't get it to work at all
[09:26:36 CST(-0600)] <colinclark> maybe it's something on my system, I'll try to dig up some error messages
[09:26:46 CST(-0600)] <colinclark> since "It doesn't work" isn't very helpful in fixing it
[09:26:54 CST(-0600)] <cindyli> colinclark: what's wrong
[09:27:06 CST(-0600)] <colinclark> Well, nothing happens
[09:27:11 CST(-0600)] <colinclark> I just see the template, unrendered
[09:27:32 CST(-0600)] <jessm> fluid infusion builder at the top still links to a dead link
[09:27:46 CST(-0600)] <colinclark> Good call jessm
[09:27:54 CST(-0600)] <colinclark> justin_o: Do we have a bug parade JIRA for that one? ^
[09:28:13 CST(-0600)] <jessm> justin_o: i think we decided that it wouldn't be a link
[09:28:14 CST(-0600)] <justin_o> colinclark: nope.. we should add one though
[09:28:18 CST(-0600)] <jessm> does that make sense?
[09:28:24 CST(-0600)] <colinclark> It does to me
[09:28:26 CST(-0600)] <heidi_> i'm able to select stuff and d/l on IE8
[09:28:29 CST(-0600)] <justin_o> jessm: that's what we were thinking
[09:28:29 CST(-0600)] <colinclark> strange
[09:28:38 CST(-0600)] <colinclark> I wonder what's wrong with my copy of IE 8
[09:28:45 CST(-0600)] <colinclark> Maybe I turned JavaScript off or something
[09:28:55 CST(-0600)] <colinclark> I'll take a look--ignore me until I have a meaningful bug report
[09:29:16 CST(-0600)] <heidi_> one thing w/ IE8 is if i select say infusion framework core, and it selects its dependents
[09:29:22 CST(-0600)] <heidi_> if i unselect it the depends stay selected
[09:29:38 CST(-0600)] <cindyli> colinclark: try this, http://builder.fluidproject.org/html/InfusionBuilder.html
[09:29:49 CST(-0600)] <heidi_> actually that happens on all browsers
[09:30:14 CST(-0600)] <heidi_> but im not sure if its avoidable since you can't really know if they selected the parent or the children
[09:31:03 CST(-0600)] <jessm> heidi_: i can't reproduce that
[09:31:10 CST(-0600)] <heidi_> to reproduce: select framework core, select table of contents, unselect core
[09:31:47 CST(-0600)] <jessm> because TOC depends on Framework core
[09:32:26 CST(-0600)] <heidi_> jessm , doesn't have to be TOC, can be anything
[09:32:55 CST(-0600)] <heidi_> hm, maybe i'm confused...
[09:33:03 CST(-0600)] <jessm> heidi_: but isn't that just hte builder intelligently not letting you deselect dependencies?
[09:33:11 CST(-0600)] <colinclark> cindyli: okay, it was definitely my IE 8 settings
[09:33:16 CST(-0600)] <colinclark> resetting them has me back in business
[09:33:22 CST(-0600)] <cindyli> colinclark: great
[09:33:41 CST(-0600)] <jessm> heidi_: try undo and framework to get a sense of what i think should be happening
[09:34:20 CST(-0600)] <colinclark> Okay, so I'm definitely seeing the insane focus styling in IE 8 that mpolizzotti pointed out last week in our meeting
[09:34:25 CST(-0600)] <colinclark> That's just a bug, outright.
[09:34:51 CST(-0600)] <colinclark> The question of whether or not to put enhanced emphasis on :focus out of the box is a separate one that we can debate
[09:35:01 CST(-0600)] <colinclark> but this is just blatantly a bug
[09:36:10 CST(-0600)] <colinclark> heidi_: Once we get through this two-day sprint in preparation for Jan's AEGIS demos, I'd be curious to see if you can cook up a fix
[09:36:29 CST(-0600)] <heidi_> colinclark are there any ie-only css files in components?
[09:36:43 CST(-0600)] <heidi_> it's sort of an ie bug that it focuses divs, maybe
[09:36:57 CST(-0600)] <colinclark> heidi_: We've always done our best to avoid browser-specific stylesheets. I don't think it's very scalable
[09:38:08 CST(-0600)] <heidi_> jessm yeah that illustrates it better. i guess if you select a component that needs core stuff, and then unselect some core stuff, it's your own fault that a component won't work?
[09:38:58 CST(-0600)] <jessm> heidi_: i interpret that to mean that undo will still work with what is left
[09:39:12 CST(-0600)] <colinclark> jessm, heidi_: The issue is actually a bit subtler than that
[09:39:17 CST(-0600)] <heidi_> but if i click undo, and then unselect jquery
[09:39:23 CST(-0600)] <colinclark> So, the current Builder doesn't support what we call "exclusions"
[09:39:30 CST(-0600)] <heidi_> i can still d/l undo w/o jquery which would be a broken thing ?
[09:39:36 CST(-0600)] <colinclark> The UI design actually just doesn't accommodate it properly
[09:39:50 CST(-0600)] <colinclark> So even if you turn off a core dependency by unchecking an item, you'll still get it in your build
[09:39:58 CST(-0600)] <heidi_> oh sneaky
[09:40:00 CST(-0600)] <colinclark> This is counter-intuitive to say the least
[09:40:11 CST(-0600)] <colinclark> So the new designs take into account the notion of missing dependencies
[09:40:14 CST(-0600)] <heidi_> i mean, that's good you don't get broken stuff, but yeah..
[09:40:24 CST(-0600)] <colinclark> Users need to be able to create things that "break," as you say, heidi_
[09:40:26 CST(-0600)] <jessm> nice
[09:40:27 CST(-0600)] <colinclark> Because it's not really broken
[09:40:29 CST(-0600)] <colinclark> Let me give you an example
[09:40:37 CST(-0600)] <jessm> i like the idea of geting what i need regardless
[09:40:39 CST(-0600)] <colinclark> uPortal likes to bundle up a bunch of Infusion together
[09:40:53 CST(-0600)] <colinclark> but they don't want some of our third-part dependencies bundled with it
[09:40:59 CST(-0600)] <colinclark> in fact Sakai does the same thing
[09:41:07 CST(-0600)] <heidi_> because they already have them?
[09:41:09 CST(-0600)] <colinclark> they already have jQuery, so they don't want to get it from us
[09:41:11 CST(-0600)] <colinclark> yes, exactly
[09:41:12 CST(-0600)] <heidi_> right
[09:41:25 CST(-0600)] <colinclark> So, using the command line build tool, they can exclude any dependencies they want
[09:41:27 CST(-0600)] <colinclark> such as jQuery
[09:41:38 CST(-0600)] <colinclark> The UI for the Builder just doesn't support that yet
[09:41:43 CST(-0600)] <heidi_> i see
[09:41:50 CST(-0600)] <colinclark> So, as a result, you'll never get anything "broken," but that in itself is a bug
[09:42:01 CST(-0600)] <heidi_> jira for it?
[09:42:09 CST(-0600)] <colinclark> yes, there is one
[09:42:13 CST(-0600)] <heidi_> cool
[09:42:19 CST(-0600)] <colinclark> I think it's a pretty good compromise for most of our users for our first iteration
[09:42:38 CST(-0600)] <heidi_> yep
[09:42:40 CST(-0600)] <colinclark> jhung's new designs start to add the extra detail required for users to build custom exclusions in a sensible way
[09:43:04 CST(-0600)] <jessm> jhung: did you post a link to those designs?
[09:43:16 CST(-0600)] <colinclark> jessm: yep
[09:43:23 CST(-0600)] <heidi_> jessm http://issues.fluidproject.org/browse/FLUID-3840
[09:43:27 CST(-0600)] <jessm> thanks
[09:43:38 CST(-0600)] <colinclark> so much to scroll through in the channel these days
[09:43:40 CST(-0600)] <colinclark> we're busy and productive!
[09:44:29 CST(-0600)] <colinclark> Okay, so to wrap up on the Builder, heidi_, cindyli, and justin_o
[09:44:36 CST(-0600)] <colinclark> Do we have a few JIRAs that will be added to the bug parade?
[09:44:48 CST(-0600)] <colinclark> Can someone summarize them, if so?
[09:44:58 CST(-0600)] <heidi_> is the keyboard focus a jira already ? we should at least make it look unbroken
[09:45:23 CST(-0600)] <colinclark> heidi_: have a quick look through JIRA and see if you kind find one for it
[09:45:41 CST(-0600)] <colinclark> This is something that I'd like to fix upstream sooner rather than later, though
[09:45:49 CST(-0600)] <colinclark> When I say "upstream" I mean in FSS
[09:47:58 CST(-0600)] <heidi_> ya
[09:47:59 CST(-0600)] <cindyli> colinclark: heidi_: another issue with builder is the 2 download buttons on ie6, and position of the spinner also needs to adjust a bit
[09:48:12 CST(-0600)] <colinclark> cindyli: The "D Button!"
[09:48:16 CST(-0600)] <colinclark> so weird
[09:48:46 CST(-0600)] <colinclark> So the D Button issue is already on bug parade, which is great. FLUID-3443.
[09:49:15 CST(-0600)] <cindyli> colinclark: heidi_. yes, it's in . also noticed the download file name, supposed to be "infusion-1.2.1.zip", with ie6, it's "infusion-1[1].2.1.zip"
[09:49:37 CST(-0600)] <colinclark> bizarre
[09:50:36 CST(-0600)] <colinclark> Okay, so we've got the D Button issue--that one is filed and on bug parade
[09:50:55 CST(-0600)] <colinclark> heidi_: You're looking for an issue related to the keyboard focus styling being crazy, and you'll file one if you don't find it.
[09:51:02 CST(-0600)] <heidi_> creating one
[09:51:04 CST(-0600)] <colinclark> Then petition the King to add it to Bug Parade, and he'll decide
[09:51:09 CST(-0600)] <colinclark> So we have one other issue
[09:51:12 CST(-0600)] <heidi_> yep
[09:51:19 CST(-0600)] <colinclark> The fact that only the module titles are clickable, not the whole description
[09:51:33 CST(-0600)] <colinclark> heidi_: Can you check for a JIRA for that one, file it if not, and similarly petition the King?
[09:51:42 CST(-0600)] <heidi_> checked, couldn't find one
[09:51:45 CST(-0600)] <colinclark> k
[09:52:01 CST(-0600)] <heidi_> will file both and let the king know. the king thing is so funny
[09:52:10 CST(-0600)] <colinclark> it is indeed
[09:52:18 CST(-0600)] <colinclark> I forget how he became the King, but it suits him
[09:52:28 CST(-0600)] <colinclark> He's our benevolent leader
[09:53:14 CST(-0600)] <jhung> We give the king gifts of cheese and biscuits so he doesn't send us to the coal mines.
[09:53:43 CST(-0600)] <michelled> you might do better with chicken
[09:54:18 CST(-0600)] <jhung> On a serf's salary? Impossible.
[09:54:27 CST(-0600)] <colinclark> lol
[09:54:37 CST(-0600)] <justin_o> jhung, michelled; +1 for chicken
[09:55:15 CST(-0600)] * jhung hopes the king doesn't notice that the chicken is actually Canadian goose.
[09:55:50 CST(-0600)] <justin_o> jhung: that's scary... is it even legal?
[09:56:03 CST(-0600)] <jhung> It should be.
[10:01:31 CST(-0600)] <heidi_> justin_o can you consider FLUID-3842 & FLUID-3841 for bug parade (builder)
[10:02:20 CST(-0600)] <justin_o> heidi_: okay... i'll take a look
[10:03:40 CST(-0600)] <justin_o> heidi_: how hard will it be to address those
[10:03:48 CST(-0600)] <justin_o> so how much time and how big of a change will it be
[10:03:50 CST(-0600)] <justin_o> ?
[10:03:52 CST(-0600)] <heidi_> the hover, fast
[10:04:10 CST(-0600)] <heidi_> the outline focus, could at least do so ff outline doesn't look so broken, but not sure about IE
[10:05:08 CST(-0600)] <justin_o> heidi_: any chance you would be able to put up screenshots of those issues?
[10:05:15 CST(-0600)] <heidi_> yep
[10:06:20 CST(-0600)] <justin_o> heidi_: thanks
[10:11:37 CST(-0600)] <heidi_> justin_o attached
[10:11:56 CST(-0600)] <heidi_> ah shoot, wrong issue. sec
[10:12:10 CST(-0600)] <heidi_> :|
[10:12:15 CST(-0600)] <justin_o> heidi_: okay... let me know when it's ready
[10:14:02 CST(-0600)] <heidi_> justin_o okay ready 3841
[10:14:12 CST(-0600)] <justin_o> heidi_: thanks
[10:16:47 CST(-0600)] <jhung> heidi_: did you work on the markup and styling for the layout reorderer demo?
[10:17:00 CST(-0600)] <heidi_> jhung url? i don't think i did
[10:17:37 CST(-0600)] <jhung> heidi_: http://build.fluidproject.org/infusion/demos/reorderer/layoutReorderer/demo.htm
[10:17:56 CST(-0600)] <heidi_> jhung: nope not me
[10:18:32 CST(-0600)] * jhung checkes logs.
[10:19:34 CST(-0600)] <jhung> ah. It was harriswong.
[10:20:57 CST(-0600)] <jhung> justin_o, harriswong: FYI, I'm going to do a little clean-up of the mark-up for layout reorderer demo.
[10:23:51 CST(-0600)] <harriswong> jhung: k.
[10:26:53 CST(-0600)] <justin_o> jhung: okay
[10:27:44 CST(-0600)] <justin_o> heidi_: okay.. just looking at the screenshots.. so you think the ff ones are easily fixable and not sure about the ie one?
[10:27:52 CST(-0600)] <heidi_> ya
[10:28:16 CST(-0600)] <heidi_> since we don't want an ie-only css file
[10:29:36 CST(-0600)] <justin_o> jhung: would you be able to commit against jira numbers
[10:29:57 CST(-0600)] <justin_o> justin_o: it's easier for us to keep track of and part of the bug parade requirements
[10:30:21 CST(-0600)] <jhung> justin_o: should I reopen the old redesign task for the layout reorderer or create a new one?
[10:30:40 CST(-0600)] <justin_o> jhung: up to you, i think reopening would be fine
[10:30:57 CST(-0600)] <jhung> k
[10:31:00 CST(-0600)] <jhung> stand-up
[10:31:51 CST(-0600)] <justin_o> heidi_: maybe we could turn off the :focus styling and only apply it to the the elements that we explicitly want it on... not sure if this is already being done
[10:32:08 CST(-0600)] <heidi_> justin_o that's a good idea
[10:32:31 CST(-0600)] <heidi_> reset has a universal focus
[10:32:43 CST(-0600)] <heidi_> so we'd have to override that to be nothing, then apply it back to what we want
[10:55:49 CST(-0600)] <justin_o> heidi_: yep... i think that is what we did in the inlineEdit demo too
[10:56:05 CST(-0600)] <justin_o> heidi_: okay.. i'll add FLUID-3841 to the bug parade
[10:56:10 CST(-0600)] <justin_o> heidi_: what about the other one
[10:56:16 CST(-0600)] <heidi_> i think that's easy to do
[10:56:23 CST(-0600)] <heidi_> but let me think for a sec
[10:57:33 CST(-0600)] <heidi_> justin_o i think it'd be a js thing
[10:57:52 CST(-0600)] <heidi_> i'm guessing pretty straight fwd
[11:00:40 CST(-0600)] <justin_o> heidi_: i guess that one is okay too if you don't think it will take too long...
[11:00:47 CST(-0600)] <justin_o> do you know what the markup looks like for that
[11:01:43 CST(-0600)] <justin_o> heidi_: i guess if you could put the description into the label things would work properly.. is that valid markup though?
[11:01:55 CST(-0600)] <heidi_> i'm not sure
[11:04:19 CST(-0600)] <heidi_> cindyli i think some of the scripts included in the header for builder aren't there
[11:04:50 CST(-0600)] <cindyli> heidi_: can u give an example?
[11:05:10 CST(-0600)] <heidi_> checking each one. it might be my firebug is being buggy
[11:05:58 CST(-0600)] <heidi_> yeah false alarm cindyli i think its fine
[11:06:18 CST(-0600)] <cindyli> heidi_: ok.
[11:45:53 CST(-0600)] <colinclark> harriswong: I was just looking over your Uploader unit test additions
[11:46:03 CST(-0600)] <colinclark> Really appreciate these--it's nice to have better test coverage
[11:46:13 CST(-0600)] <colinclark> One area of improvement I can suggest:
[11:46:46 CST(-0600)] <colinclark> In some tests, you're assigning to variables without using declaring them with "var"
[11:47:26 CST(-0600)] <colinclark> Due to a bug in JavaScript, this is syntactically correct but causes those variables to inadvertently be exposed in the global namespace. Not what you're intending
[11:49:17 CST(-0600)] <colinclark> Can you run all the tests through JSLint to check for these kinds of errors?
[11:49:25 CST(-0600)] <colinclark> The JSLint settings we use are documented here: http://wiki.fluidproject.org/display/fluid/Coding+and+Commit+Standards
[11:50:21 CST(-0600)] <colinclark> Other than that, you've got a few minor whitespace issues and a commented-out line or two, but JSLint should catch most of that
[11:50:29 CST(-0600)] <colinclark> These tests are really a good contribution, thanks again!
[11:59:43 CST(-0600)] <harriswong> colinclark: sure, i will check it with the JSint, and then commit them later with some other tests i have added.
[12:01:08 CST(-0600)] <colinclark> Cool, thanks harriswong
[12:12:02 CST(-0600)] <heidi_> justin_o should i start on those builder css fixes
[12:13:11 CST(-0600)] <justin_o> heidi_: sure...
[12:13:25 CST(-0600)] <heidi_> justin_o are there other things to test or? let me know
[12:13:35 CST(-0600)] <justin_o> I guess we talk about FLUID-3842 again afterwards
[12:13:54 CST(-0600)] <justin_o> heidi_: sure... i think when we get pager done it will be good to test that.. but we're still working on it
[12:14:03 CST(-0600)] <heidi_> agreed, cool
[12:27:21 CST(-0600)] <jessm> heidi_: when you have a moment, I have a question
[12:27:28 CST(-0600)] <heidi_> jessm yep
[12:27:43 CST(-0600)] <jessm> on the floe site – is the news archived?
[12:27:54 CST(-0600)] <jessm> if i replace the news, i suspect it's gone forever
[12:27:58 CST(-0600)] <heidi_> i imagine so... let me check
[12:28:48 CST(-0600)] <heidi_> jessm did you try addint another news item?
[12:29:17 CST(-0600)] <jessm> no, thought i'd check in first
[12:29:57 CST(-0600)] <heidi_> just did pw reminder... logging in a sec
[12:32:00 CST(-0600)] <heidi_> jessm yeah content management->create content->news will just add a new item
[13:54:21 CST(-0600)] <Bosmon> So, colinclark, justin_o and others - I wanted to talk about an issue raised by my recent file refactoring, and also my work on the "aria little component"
[13:54:34 CST(-0600)] <jhung> jessm, jameswy, justin_o, colinclark: I'm wondering what you guys think about adding a task into this release to unify some of the styling used across demos?
[13:54:45 CST(-0600)] <colinclark> wow, waves of questions
[13:55:29 CST(-0600)] <justin_o> i guess you guys can start talking and we'll try to follow along.. or you can decide who wants to talk first
[13:55:31 CST(-0600)] <colinclark> jhung: For your question, I'm interested in the idea if we can scope the work very carefully so it doesn't add tons of extra work. I might defer to justin_o to make a decision
[13:56:16 CST(-0600)] <jhung> Justin_o, colinclark - Bosmon was first with his, you guys can talk about that first.
[13:56:30 CST(-0600)] <colinclark> ok
[13:56:32 CST(-0600)] <colinclark> Bosmon: Fire away
[13:57:20 CST(-0600)] <Bosmon> So, I created file "fluidDocument.js" - motivated by the idea that we want to maintain some body of utilities which can be used in jquery.keyboard-a11y without causing a dependence on the Fluid codebase
[13:57:56 CST(-0600)] <Bosmon> This actually already seemed a bit of a strain - if you look at the new implementation of "fluid.deadMansBlur" you can see that it is actually trying to create a Fluid component by a "poor man's route"
[13:58:17 CST(-0600)] <Bosmon> The work on the "little component" is still worse - it seems frankly absurd to try to build it without the use of the Fluid framework
[13:58:26 CST(-0600)] <Bosmon> Even if it is something that in theory we might want to contribute to jquery
[13:58:44 CST(-0600)] <Bosmon> So - I wonder what you guys would think about "reconceiving" this issue slightly
[13:59:05 CST(-0600)] <Bosmon> In the few examples of code we have successfully contributed to jquery so far, we have found that they inevitably rewrite 100% of it
[13:59:27 CST(-0600)] <Bosmon> In fact, it seems that the main value that they derive from such a contribution is i) a clearly defined use case, ii) a collection of good test cases
[14:00:05 CST(-0600)] <colinclark> lol
[14:00:11 CST(-0600)] <colinclark> Bosmon: So far, that's actually true
[14:00:32 CST(-0600)] <colinclark> I hadn't realized that you were endeavouring to make the little ARIA component independent of the framework
[14:00:36 CST(-0600)] <colinclark> as you say, it's a big stretch
[14:01:02 CST(-0600)] <Bosmon> I mean, I think a reliance on the Fluid framework per se would represent actually a smaller part of the divergence... there are plenty of other ways in which jquery tends to write and organise its code differently to ours
[14:01:20 CST(-0600)] <Bosmon> Well, I started - since I thought this would be a generically useful piece of accessibility functionality
[14:01:36 CST(-0600)] <colinclark> I'm still hesitant to add a significant framework dependency for the keyboard plugin
[14:01:54 CST(-0600)] <Bosmon> But very rapidly it started to seem absurd trying to write any even mildly ambitious "component", little or otherwise, without using any of the framework
[14:01:58 CST(-0600)] <Bosmon> Well that's fine
[14:02:06 CST(-0600)] <colinclark> At very least, currently, with the Builder you can create a very minimal distribution containing only the plugin and FluidDocument.js, which seems reasonable
[14:02:08 CST(-0600)] <Bosmon> I wasn't suggesting "reversing" the work we had already done on keyboard-a11y
[14:02:12 CST(-0600)] <colinclark> k
[14:02:18 CST(-0600)] <colinclark> For your little ARIA component, I say go for it
[14:02:21 CST(-0600)] <Bosmon> but I was suggesting calling a halt on any further "framework-free development"
[14:02:31 CST(-0600)] <Bosmon> And also shoving fluid.deadMansBlur onto the other side of the fence
[14:02:45 CST(-0600)] <colinclark> Well, I guess we'll always have to consider other cases comparable to the keyboard plugin
[14:03:00 CST(-0600)] <colinclark> but that's always been a case-by-case thing anyway
[14:03:08 CST(-0600)] <Bosmon> Well ok, "calling a halt on it" for any currently envisaged development
[14:03:12 CST(-0600)] <colinclark> We rarely are in the business of creating free-form jquery plugins anyway
[14:03:16 CST(-0600)] <colinclark> Bosmon: lol
[14:03:18 CST(-0600)] <Bosmon> Clearly one can't anticipate the totality of all things
[14:03:22 CST(-0600)] <colinclark> We are in agreement, then
[14:03:26 CST(-0600)] <Bosmon> Awesome
[14:03:39 CST(-0600)] <colinclark> What does it mean to shove deadMansBlur onto the "other side of the fence?"
[14:04:03 CST(-0600)] <Bosmon> To put it into "fluidView.js" as upcoming, and actually use fluid.initLittleComponent to construct it, etc.
[14:04:16 CST(-0600)] <Bosmon> Right now it has some fairly ridiculous code and a big comment explaining why it looks so odd
[14:04:19 CST(-0600)] <colinclark> Where did it live before? The keyboard plugin?
[14:04:27 CST(-0600)] <Bosmon> I put it into "fluidDocument.js"
[14:04:33 CST(-0600)] <Bosmon> Before that it was part of InlineEdit.js
[14:04:37 CST(-0600)] <colinclark> okay
[14:04:44 CST(-0600)] <Bosmon> With a different API, and not actually being a "component" at all
[14:04:48 CST(-0600)] <colinclark> Lemme just take a look at what's in FluidDocument.js now
[14:05:21 CST(-0600)] <Bosmon> Actually taking DMB out of there weakens the case for fluidDocument.js a lot - although actually I think there were some positive results from this refactoring
[14:05:32 CST(-0600)] <Bosmon> For example fluid.getScopedData etc. became elevated to proper public functions
[14:05:48 CST(-0600)] <colinclark> Okay
[14:05:51 CST(-0600)] <colinclark> so you're arguing:
[14:05:58 CST(-0600)] <colinclark> 1. Move DMB to FluidView.js
[14:06:17 CST(-0600)] <colinclark> 2. Leave FluidDocument.js as-is, with largely a handful of mildly generic functions most prominently used by the keyboard plugin
[14:06:25 CST(-0600)] <colinclark> Is that right?
[14:06:30 CST(-0600)] <Bosmon> I mean conceivably we might think of destroying fluidDocument.js again but it was a lot of upheaval to create it
[14:06:34 CST(-0600)] <Bosmon> Yes, that is my current argument
[14:06:46 CST(-0600)] <colinclark> okay
[14:06:53 CST(-0600)] <colinclark> I'll dare to ask this questoin...
[14:07:04 CST(-0600)] <colinclark> how might you conceive of again destroying FluidDocument.js?
[14:07:18 CST(-0600)] <Bosmon> By just putting all the stuff back into jquery.keyboard-a11y again.....
[14:07:43 CST(-0600)] <Bosmon> Now I see that there is no imminent body of "friends" waiting to join it in that file
[14:08:14 CST(-0600)] <Bosmon> I guess now we have the builder working it doesn't really matter so much whether we have "too many files"
[14:09:22 CST(-0600)] <colinclark> justin_o: You had raised a concern about this particular issue
[14:09:33 CST(-0600)] <colinclark> This would be the time to bring it up
[14:10:06 CST(-0600)] <colinclark> My argument in response was the point you make, Bosmon--the Builder
[14:10:13 CST(-0600)] <colinclark> but it's still an interesting one to discuss briefly
[14:10:40 CST(-0600)] <colinclark> Increasingly, I think we're moving to a world where Builder is "the way" to get Infusion--any part of it
[14:10:51 CST(-0600)] <colinclark> I can even vaguely imagine not distributing a .zip file of Infusion anymore
[14:13:05 CST(-0600)] <colinclark> I can see the King is coding with golam and is probably distracted
[14:13:54 CST(-0600)] <justin_o> colinclark: sorry.. can you give me a quick summary
[14:14:03 CST(-0600)] <justin_o> i'm not sure which concern it was
[14:14:07 CST(-0600)] <colinclark>
[14:14:12 CST(-0600)] <colinclark> sorry to distract you from coding
[14:14:28 CST(-0600)] <colinclark> Bosmon wants to move fluid.DMB into FluidView.js
[14:14:44 CST(-0600)] <colinclark> Which leaves FluidDocument.js with stuff that only sort of justifies being in its own file
[14:15:01 CST(-0600)] <colinclark> He could move it back into the keyboard-a11y plugin, but on the other hand the code might be reused by other some day
[14:15:24 CST(-0600)] <colinclark> You had raised the concern of having an extra file dependency for the plugin, which might argue for a migration back into jquery.keyboard-a11y.js
[14:15:29 CST(-0600)] <colinclark> But there is the Builder argument
[14:15:31 CST(-0600)] <colinclark> Any thoughts?
[14:15:58 CST(-0600)] <colinclark> I'm not sure there's a clear winner, so I'm willing to entertain the idea of moving FluidDocument.js back into jquery.keyboard-a11y.js
[14:18:22 CST(-0600)] <justin_o> colinclark, Bosmon: I was saying that it might be better for people who just want the plugin to only have to pull down that single file
[14:19:12 CST(-0600)] <colinclark> Bosmon: Can you muster any really interesting arguments for why to retain FluidDocument.js
[14:20:06 CST(-0600)] <Bosmon> Not any enormously interesting ones... other than that, back in keyboard-a11y, those things are a bit of a "ragbag"
[14:20:18 CST(-0600)] <Bosmon> They don't really relate to its core function, but are just in there for dependency reasons
[14:20:28 CST(-0600)] <Bosmon> fluid.enabled, the focus manager, and the scopedData utils
[14:27:16 CST(-0600)] <golam> heidi_: here is the patch for the pager. http://issues.fluidproject.org/secure/attachment/11356/FLUID-3828.v4.patch
[14:27:33 CST(-0600)] <heidi_> golam - nice. will it be added to the build site soon?
[14:28:48 CST(-0600)] <golam> heidi_: still needs to code review for the aria stuff but the style work should be added already
[14:29:24 CST(-0600)] <heidi_> k, ill check it soon, thanks
[15:13:04 CST(-0600)] <justin_o> michelled: did you want to talk about the pager tooltip now?
[15:13:53 CST(-0600)] <michelled> yep, now's good
[15:14:53 CST(-0600)] <Bosmon> Is this a Skype chat, or a physical one?
[15:15:11 CST(-0600)] <michelled> we were actually just going to talk here Bosmon
[15:15:38 CST(-0600)] <michelled> justin_o: did you manage to see if the new tooltip plugin works with a screen reader?
[15:15:57 CST(-0600)] <Bosmon> Which plugin are we using now?
[15:16:06 CST(-0600)] <Bosmon> I'm interested if this might relate to my work on the "little component"
[15:16:09 CST(-0600)] <Bosmon> For FLUID-3730
[15:16:12 CST(-0600)] <justin_o> michelled: so golam is trying it out now.. and it is mostly working.. he did stumble upon another bug though.. if you use the keyboard to navigate to a page, the tooltip doesn't hide
[15:16:31 CST(-0600)] <justin_o> i think it's because the element that it was attached to is removed from the DOM before the blur event occurs
[15:16:39 CST(-0600)] <colinclark> Bosmon: We're using a pre-release of the new jQuery UI tooltip
[15:16:52 CST(-0600)] <colinclark> which is a reworking of the Filament Group's tooltip from their Progressive Enhancement book
[15:17:07 CST(-0600)] <michelled> Bosmon, colinclark: we've got an API issue which makes us wonder if we can in fact switch to the jQuery UI tooltip
[15:17:08 CST(-0600)] <justin_o> Bosmon: https://github.com/jquery/jquery-ui/blob/tooltip/ui/jquery.ui.tooltip.js
[15:17:09 CST(-0600)] <colinclark> totally different code base than the one Jörn wrote, which we are currently using
[15:17:21 CST(-0600)] <colinclark> ok, fire away
[15:17:30 CST(-0600)] <michelled> currently in the InlineEdit there are a couple of options that are exposed that were used to configure the tooltip
[15:17:38 CST(-0600)] <michelled> the new plugin doesn't support these
[15:17:49 CST(-0600)] <michelled> so if we switch we'd have to make an API change in InlineEdit
[15:18:15 CST(-0600)] <Bosmon> Yes
[15:18:25 CST(-0600)] <Bosmon> Unless we had the "options chewing infrastructure"
[15:19:31 CST(-0600)] <justin_o> Bosmon: yes.. that would help i guess.. but the options still wouldn't do anything
[15:19:43 CST(-0600)] <justin_o> since the new plugin just doesn't support them anymore
[15:19:43 CST(-0600)] <Bosmon> What features does it not support?
[15:20:17 CST(-0600)] <justin_o> specific to the inlineEdit api would be tooltipId and tooltipDelay
[15:20:25 CST(-0600)] <Bosmon> I see it still has nasty hard-baked markup
[15:20:36 CST(-0600)] <Bosmon> I guess, even worse than the old one, which at least allowed you to nominate an existing node
[15:20:49 CST(-0600)] <justin_o> Bosmon: yes.. i suppose that's true
[15:20:50 CST(-0600)] <Bosmon> Why are we considering switching to this one?
[15:21:03 CST(-0600)] <justin_o> keyboard support
[15:21:14 CST(-0600)] <justin_o> this new one shows the tooltip on keyboard focus as well
[15:21:20 CST(-0600)] <justin_o> and it has built in aria support
[15:21:20 CST(-0600)] <Bosmon> I see
[15:22:19 CST(-0600)] <Bosmon> Well, it has a bit... it mysterious sets itself to be "describedby" itself
[15:22:22 CST(-0600)] <Bosmon> mysteriously
[15:22:30 CST(-0600)] <justin_o> I think we have 3 options. 1) don't use the new tooltip at all and write something by hand for pager 2) carry around to tooltip plugins 3) accept this minor breakage in api
[15:22:38 CST(-0600)] <justin_o> Bosmon: really.. let me double check that
[15:22:39 CST(-0600)] <Bosmon> It does use a correct role though
[15:23:41 CST(-0600)] <justin_o> Bosmon: line 109 sets the aria-describedby to the id of the tooltip id
[15:23:52 CST(-0600)] <justin_o> i think the target is the event target.. so whatever you are hovering over
[15:24:17 CST(-0600)] <Bosmon> Ah yes
[15:24:39 CST(-0600)] <Bosmon> Well, the old tooltip code was certainly more mature... even if its codebase was quite a mess
[15:24:47 CST(-0600)] <Bosmon> This one is a good deal simpler and indeed more accessible
[15:25:05 CST(-0600)] <Bosmon> The fact that we leave behind the IE6 support etc. is not something we really care about?
[15:25:59 CST(-0600)] <colinclark> The other reason we're considering switching to this one is that Jörn made it clear, when we gave him a patch, that his plugin was EOL
[15:26:08 CST(-0600)] <Bosmon> Ah, I see
[15:26:20 CST(-0600)] <Bosmon> Did he say why?
[15:26:29 CST(-0600)] <colinclark> Because he's putting his energy into this one
[15:26:40 CST(-0600)] <Bosmon> ah, ok
[15:26:53 CST(-0600)] <Bosmon> Well, this one will certainly be easier for us to issue patches against
[15:27:19 CST(-0600)] <colinclark> This tooltip doesn't support IE 6?
[15:27:29 CST(-0600)] <Bosmon> Well, it doesn't have all the bgiframe crap that the old one did
[15:27:36 CST(-0600)] <Bosmon> So it will probably behave strangely wrt. z-order in some cases
[15:27:56 CST(-0600)] <justin_o> michelled: do you remember if there was a bgiframe dependency on it at all?
[15:28:07 CST(-0600)] <justin_o> sorry i might have wrote that backwards
[15:28:41 CST(-0600)] <michelled> don't think so justin_o
[15:29:36 CST(-0600)] <justin_o> okay
[15:36:34 CST(-0600)] <justin_o> colinclark, Bosmon, michelled: do you have any more thoughts on what we should do about the tooltip
[15:36:35 CST(-0600)] <justin_o> ?
[15:37:09 CST(-0600)] <colinclark> sorry, just one sec
[15:37:28 CST(-0600)] <Bosmon> Moving to the new one seems desirable
[15:37:46 CST(-0600)] <Bosmon> we can support the "delay" option which is the only really significant breakage
[15:37:54 CST(-0600)] <Bosmon> Ignoring the "id" option would be acceptable I think
[15:38:15 CST(-0600)] <michelled> Bosmon: are you suggesting we fork the new one and add support for delay?
[15:38:29 CST(-0600)] <Bosmon> Oh wait, sorry
[15:38:34 CST(-0600)] <Bosmon> I am looking at the wrong source
[15:39:49 CST(-0600)] <Bosmon> Amazing, there really is no support for delay here
[15:40:01 CST(-0600)] <colinclark> justin_o: Is jQuery UI still supporting IE 6 for their next release?
[15:40:01 CST(-0600)] <Bosmon> Other than the 13ms AJAX callback
[15:42:43 CST(-0600)] <Bosmon> I can't imagine a 0-delay tooltip will offer terribly nice user factors
[15:42:55 CST(-0600)] <Bosmon> It would have to be flickering like crazy as you move your mouse all over the place
[15:43:44 CST(-0600)] <justin_o> Bosmon: a little bit
[15:43:56 CST(-0600)] <justin_o> they do some fading in and out too
[15:43:58 CST(-0600)] <colinclark> justin_o: So it kind of flickers?
[15:44:05 CST(-0600)] <Bosmon> That's even more awful
[15:44:26 CST(-0600)] <colinclark> is it actually more awful?
[15:44:32 CST(-0600)] <Bosmon> To fade in and out?
[15:44:36 CST(-0600)] <colinclark> i'd trust jameswy on this sort of issue
[15:44:42 CST(-0600)] <colinclark>
[15:46:43 CST(-0600)] <jameswy> Fades are good. Less harsh. Less disorienting. Unless it's executed terribly.
[15:47:44 CST(-0600)] <Bosmon> I don't actually see where the fade is configured, as part of the component code
[15:47:48 CST(-0600)] <Bosmon> All I see is a call to "stop"
[15:55:47 CST(-0600)] <justin_o> Bosmon: there are calss to fadeIn and fadeOut
[15:56:08 CST(-0600)] <justin_o> do you remember if there is a way to turn off animations in jquery.. i thought there was but can't find it now
[15:56:48 CST(-0600)] <justin_o> okay found it... jQuery.fx.off, but it's global
[15:59:28 CST(-0600)] <Bosmon> justin_o: The only calls there are to stop any animations which might be in progress
[15:59:50 CST(-0600)] <Bosmon> Oh, I see
[15:59:54 CST(-0600)] <Bosmon> Stupid chaining syntax
[15:59:59 CST(-0600)] <Bosmon> It stops things and THEN fades...
[16:00:55 CST(-0600)] <justin_o> Bosmon: yes
[16:14:37 CST(-0600)] <justin_o> Bosmon, colinclark: I have to head out now, but if you guys have any more thoughts on these issues please let me know
[16:47:34 CST(-0600)] <colinclark> So Bosmon, the tooltip
[16:47:42 CST(-0600)] <colinclark> I chatted briefly with justin_o before he left
[16:48:03 CST(-0600)] <Bosmon> Hi there, yes
[16:48:03 CST(-0600)] <colinclark> jameswy actually looked at the plugin and was unhappy with the fading after all
[16:48:08 CST(-0600)] <Bosmon> Cool
[16:48:24 CST(-0600)] <Bosmon> I like the codebase better though... but the question is whether we have resources free to work with it
[16:48:27 CST(-0600)] <colinclark> So, I asked Justin, in context of Pager, what the best scenario was
[16:48:31 CST(-0600)] <colinclark> 1. Use the old tooltip
[16:48:35 CST(-0600)] <colinclark> 2. Improve the new tooltip
[16:48:38 CST(-0600)] <colinclark> 3. Write our own
[16:48:43 CST(-0600)] <colinclark> He didn't hesitate to pick #3
[16:48:48 CST(-0600)] <Bosmon> really?
[16:48:54 CST(-0600)] <colinclark> sorry sorry
[16:48:55 CST(-0600)] <colinclark> #2
[16:48:56 CST(-0600)] <colinclark> I suck
[16:48:57 CST(-0600)] <Bosmon> ok
[16:49:03 CST(-0600)] <colinclark> #2--improve the new jQuery UI tooltip
[16:49:04 CST(-0600)] <Bosmon> You are counting like a C programmer
[16:49:08 CST(-0600)] <colinclark>
[16:49:08 CST(-0600)] <Bosmon> Those decades can rot the brain
[16:49:10 CST(-0600)] <Bosmon> Yes
[16:49:19 CST(-0600)] <Bosmon> #2 seems the preferable option of those 3 to me as well
[16:49:22 CST(-0600)] <colinclark> cool
[16:49:27 CST(-0600)] <colinclark> So I think we'll have a quick meeting with Fish and James tomorrow
[16:49:30 CST(-0600)] <Bosmon> The codebase though incomplete is I think massively better than nothing
[16:49:36 CST(-0600)] <colinclark> To make a list of what we'll need to do
[16:49:45 CST(-0600)] <colinclark> and then to do the work and submit a patch to Scott and Jörn
[16:50:00 CST(-0600)] <colinclark> From your read-through of the code, do you have anything you want to add to that list now?
[16:50:10 CST(-0600)] <colinclark> Since you'll probably be asleep when we make the rest of it
[16:50:32 CST(-0600)] <Bosmon> Well, in order of priority i) configuration to disable animation, ii) configuration to enable tooltip delay, and then if we want, iii) configuration to enable pass-through of id
[16:51:19 CST(-0600)] <Bosmon> I'm personally happy to let the IE6 crap go by-the-by if the rest of the team is
[16:52:53 CST(-0600)] <Bosmon> I can't say I perfectly understand the reasons it was possible to control the tooltip id in the old plugin, to be honest
[16:54:15 CST(-0600)] <Bosmon> Ideally we would want iv) configuration to customise the markup generated by the plugin
[16:55:15 CST(-0600)] <Bosmon> Have we actually given the new plugin any kind of accessibility testing yet?
[16:55:45 CST(-0600)] <Bosmon> It looks like the old plugin had reasonable ARIA support too, is it just the main issue that it wasn't possible to trigger it using keyboard focus?
[16:57:34 CST(-0600)] <Bosmon> I guess on 2nd reading the markup situation with tne new tooltip is considerably better than the old one
[16:58:18 CST(-0600)] <Bosmon> It really just creates 2 divs, whereas the old one created all kinds of unearthly crap... we can probably get by with just i) and ii) on my list as urgent issues for now
[16:59:45 CST(-0600)] <colinclark> This is super helpful
[16:59:47 CST(-0600)] <colinclark> thanks
[17:00:03 CST(-0600)] <colinclark> Yes, we have done some accessibility testing with the new plugin
[17:00:15 CST(-0600)] <colinclark> It seems to be significantly better than the old one, in that it vaguely works
[17:00:42 CST(-0600)] <colinclark> Bosmon: The ARIA support in the old plugin, I believe, was our own fork of it
[17:00:46 CST(-0600)] <Bosmon> Well... at least informally, the old one seemed to work in some way
[17:00:48 CST(-0600)] <Bosmon> Ah, interesting
[17:00:54 CST(-0600)] <Bosmon> It's just I would have hated to have to patch it
[17:01:17 CST(-0600)] <colinclark> Yeah, we added ARIA ourselves and gave Jörn the patch
[17:01:36 CST(-0600)] <colinclark> ok, so we'll add your i) and ii) to the list
[17:01:53 CST(-0600)] <Bosmon> One other piece of significant missing functionality to inventory between the old and new plugin, in addition to the IE crap, is that the old one supported making the tooltip a scrolling viewport
[17:02:03 CST(-0600)] <Bosmon> I'm not sure I think that was terribly desirable in any case
[17:02:22 CST(-0600)] <Bosmon> A tooltip should in theory be something that can be taken in at one glance
[17:02:34 CST(-0600)] <Bosmon> Making it scrollable would defeat a lot of the point...
[17:03:05 CST(-0600)] <Bosmon> I don't see any reason why we can't make our "new" options conform to the API of the old plugin
[17:03:14 CST(-0600)] <Bosmon> It might make life easier for a lot of other people too
[17:03:25 CST(-0600)] <Bosmon> defaults: {
[17:03:25 CST(-0600)] <Bosmon> delay: 200,
[17:03:25 CST(-0600)] <Bosmon> fade: false,
[17:03:25 CST(-0600)] <Bosmon> showURL: true,
[17:03:25 CST(-0600)] <Bosmon> extraClass: "",
[17:03:26 CST(-0600)] <Bosmon> top: 15,
[17:03:26 CST(-0600)] <Bosmon> left: 15,
[17:03:27 CST(-0600)] <Bosmon> id: "tooltip"
[17:03:27 CST(-0600)] <Bosmon> },
[17:03:34 CST(-0600)] <Bosmon> Its old "defaults" block used to look like this
[17:04:13 CST(-0600)] <Bosmon> although "top/left" have now moved permanently as a result of now having a passthrough to the "position" plugin
[17:04:32 CST(-0600)] <Bosmon> Which as you know I am extremely suspicious of - it has now caused so many problems in CSpace that we are disabling it entirely in most cases
[17:04:59 CST(-0600)] <Bosmon> But delay: 200, fade: false seem unproblematic
[17:05:15 CST(-0600)] <colinclark> yep
[17:05:40 CST(-0600)] <colinclark> a scrolling tooltip is crazy
[17:05:42 CST(-0600)] <colinclark> not something we need
[17:05:55 CST(-0600)] <Bosmon> The old one also had a mode where it could "track the mouse" - which also seems a bit pointless
[17:06:05 CST(-0600)] <Bosmon> You know my hatred of things that "move around"
[17:06:11 CST(-0600)] <Bosmon> Except for a CATTT, of course
[17:06:15 CST(-0600)] <colinclark> lol
[17:06:24 CST(-0600)] <colinclark> cats, too, love things that move around
[17:06:32 CST(-0600)] <Bosmon> Right now he is not "moving around" but sitting in my LAPP
[17:06:34 CST(-0600)] <colinclark> i'm convinced sirius can't really see stationary things quite like we can
[17:06:37 CST(-0600)] <Bosmon> Ah gosh!!!
[17:06:43 CST(-0600)] <Bosmon> I must paste my video of him with MMMOUS
[17:06:48 CST(-0600)] <Bosmon> It's pretty exciting
[17:06:55 CST(-0600)] <colinclark> maybe paste it to privately
[17:06:56 CST(-0600)] <Bosmon> Yes, a CATTT cannot really see stationary things
[17:07:01 CST(-0600)] <colinclark> the cahnnel might be scared of cats and mice!
[17:07:03 CST(-0600)] <colinclark>
[17:07:08 CST(-0600)] <Bosmon> I remember looking into this when I was considering getting a Tortoise
[17:07:19 CST(-0600)] <Bosmon> If it moves slowly enough, THER CATTT cannot see it at all....
[17:07:27 CST(-0600)] <colinclark> You were worried your cat wouldn't be able to see your new tortoise?
[17:07:38 CST(-0600)] <Bosmon> Well, this was years and years ago
[17:07:43 CST(-0600)] <colinclark> Clearly they can see stationary things
[17:07:56 CST(-0600)] <Bosmon> After I visited the Amsterdam Zoo I became less excited by the prospect of living with a Tortoise
[17:07:56 CST(-0600)] <colinclark> Since they can-Sirius excepted-leap onto stationary things with great accuracy
[17:08:00 CST(-0600)] <Bosmon> Ah!
[17:08:02 CST(-0600)] <Bosmon> but can they!
[17:08:05 CST(-0600)] <colinclark> I guess they'd just see a Tortoise as something to leap on
[17:08:05 CST(-0600)] <Bosmon> That's the great question
[17:08:10 CST(-0600)] <Bosmon> You see what they do before they jump
[17:08:19 CST(-0600)] <colinclark> hesitate?
[17:08:19 CST(-0600)] <Bosmon> They shuttle their head from side to side in that crazy CATT-like manner
[17:08:22 CST(-0600)] <colinclark> yes
[17:08:28 CST(-0600)] <Bosmon> Hence converting a stationary object into a moving one with parallax
[17:08:31 CST(-0600)] <colinclark> lol
[17:08:42 CST(-0600)] <colinclark> equally, a tortoise moves via parallax
[17:08:56 CST(-0600)] <colinclark> Okay, I'm late for dinner with my in-laws
[17:08:59 CST(-0600)] <colinclark> never good to be late
[17:09:01 CST(-0600)] <Bosmon> ok
[17:09:03 CST(-0600)] <colinclark> see you soon
[17:09:08 CST(-0600)] <Bosmon> I will continue to have fun with the "little component"
[17:09:10 CST(-0600)] <Bosmon> Have a great dinner
[17:09:14 CST(-0600)] <colinclark> thanks, enjoy

Browser not supported