fluid-work IRC Logs-2011-12-21

[09:45:05 CST(-0600)] <Sydney> Hello fluid infusion I have a question about the fat panel component

[09:45:19 CST(-0600)] <colinclark> Hey Sydney

[09:45:41 CST(-0600)] <colinclark> What's your question?

[09:48:11 CST(-0600)] <Sydney> So i got it working and everything works perfectly fine, its just every time I refresh the page there is a little bump at the top of the page that fixes itself is there a way to remove it the little bump completely?

[09:48:47 CST(-0600)] <colinclark> What does the "bump" look like?

[09:48:57 CST(-0600)] <Sydney> sorry its not a bump its a gap**

[09:49:02 CST(-0600)] <colinclark> Ah, the gap

[09:49:12 CST(-0600)] <colinclark> michelled: Doesn't that sound like a bug Bosmon fixed recently? ^^

[09:49:18 CST(-0600)] <colinclark> with some very simple CSS?

[09:51:29 CST(-0600)] <colinclark> Sydney: Here's a thread from the fluid-work mailing list, which I'm pretty sure is about exactly this topic

[09:51:29 CST(-0600)] <colinclark> http://lists.idrc.ocad.ca/pipermail/fluid-work/2011-December/008284.html

[09:51:53 CST(-0600)] <colinclark> Bosmon has a pull request in that fixes this, but I think in the meantime it would be very easy for you to apply the fix yourself

[09:51:57 CST(-0600)] <colinclark> let me just take a closer look

[09:53:25 CST(-0600)] <Sydney> alright ill give it a shot

[09:55:32 CST(-0600)] <colinclark> Sydney: Yeah, it looks like it's exactly as Bosmon says in the email...

[09:56:32 CST(-0600)] <colinclark> put a display:block stye on .fl-uiOptions-fatPanel and that should resolve the gap

[09:56:45 CST(-0600)] <colinclark> You can do this either by patching our style sheet or by putting it in your own with a higher specificity

[09:56:50 CST(-0600)] <colinclark> Let us know if it works

[09:57:10 CST(-0600)] <colinclark> Sydney: You're using UI Options for the VULab, is that right?

[09:57:54 CST(-0600)] <Sydney> Yeah that is right

[09:59:49 CST(-0600)] <Sydney> okay so in the .fl-uiOptions-fatPanel.iframe classs i would add display:block style?

[10:05:38 CST(-0600)] <michelled> colinclark: yep, that was exactly what we had hit with the Studio's site and Bosmon fixed.

[10:07:50 CST(-0600)] <Sydney> alright thanks a lot colinclark i got it to work!

[10:09:17 CST(-0600)] <Sydney> and if i don't comeback for anymore question have merry Christmas and happy holidays

[10:25:07 CST(-0600)] <michelled> colinclark: when you get a chance, can you look at this pull request for me please?

[10:25:09 CST(-0600)] <michelled> https://github.com/fluid-project/studios.fluidproject.org/pull/43

[10:25:36 CST(-0600)] <colinclark> sure

[10:25:41 CST(-0600)] <colinclark> how can I test it?

[10:26:53 CST(-0600)] <michelled> colinclark: you need to have at least 3 entries in your studios

[10:27:16 CST(-0600)] <michelled> then look at the alignment of the right edge of the prefs button and the right edge of the 3rd column on the first page

[10:28:04 CST(-0600)] <michelled> they should line up when your view port is wide enough to see the textured background on both sides of the entry summaries

[10:45:29 CST(-0600)] <michelled> colinclark: jameswy and I were talking about the studios process a bit and he had a really good point which I think we need to figure out

[10:46:04 CST(-0600)] <michelled> I made account for all the students in the masters program since it is part of their course work to share within studios

[10:46:15 CST(-0600)] <colinclark> Right

[10:46:18 CST(-0600)] <michelled> none of the students had requested access on list

[10:46:26 CST(-0600)] <colinclark> I think with courses, we can have the instructor make the request on list

[10:46:36 CST(-0600)] <colinclark> I think the key is that we need to provide that on-ramp to openness

[10:46:38 CST(-0600)] <michelled> ah, that's interesting

[10:47:00 CST(-0600)] <michelled> so in the instructor's request, they could introduce the students maybe?

[10:47:04 CST(-0600)] <michelled> what do you thinik?

[10:47:59 CST(-0600)] <colinclark> That's a great idea

[10:48:34 CST(-0600)] <michelled> maybe I'll write up an e-mail introducing the current cohort

[10:48:44 CST(-0600)] <michelled> I know it's after the fact but at least it will be up there

[11:07:45 CST(-0600)] <colinclark> michelled: jameswy could definitely write that

[11:15:30 CST(-0600)] <clown> michelled: update re: my emailing some list for advice about best practices for HTML5 video player controls:

[11:16:02 CST(-0600)] <clown> the html-public-a11y list is publicly viewable (even though only members can post). For future reference:

[11:16:03 CST(-0600)] <clown> http://lists.w3.org/Archives/Public/public-html-a11y/

[11:16:18 CST(-0600)] <clown> I was advised to post to wai-xtech. Its archives are here:

[11:16:26 CST(-0600)] <clown> http://lists.w3.org/Archives/Public/wai-xtech/

[11:16:41 CST(-0600)] <clown> If you want, you can "join" the wai-xtech list by going here and subscribing:

[11:16:46 CST(-0600)] <clown> http://lists.w3.org/Archives/Public/

[12:36:48 CST(-0600)] <michelled> thanks clown!

[12:36:57 CST(-0600)] <clown> wlcm michelled

[12:48:31 CST(-0600)] <colinclark> michelled: Are we doing a community meeting today? Bosmon was just asking me

[12:48:55 CST(-0600)] <michelled> I don't think so colinclark

[12:49:01 CST(-0600)] <colinclark> ok

[12:49:07 CST(-0600)] <michelled> many people are away today and we covered our topic last week (smile)

[12:54:09 CST(-0600)] <colinclark> guys

[12:54:11 CST(-0600)] <colinclark> jameswy, michelled

[12:54:15 CST(-0600)] <colinclark> This isn't a big deal

[12:54:19 CST(-0600)] <colinclark> or a big conversation

[12:54:25 CST(-0600)] <colinclark> be sensible

[12:54:32 CST(-0600)] <colinclark> respect people's privacy and encourage them to be open

[12:54:38 CST(-0600)] <colinclark> Use instructors as a gateway to the community

[12:54:52 CST(-0600)] <colinclark> who can, as you say, help to represent them and their work

[12:55:01 CST(-0600)] <colinclark> seem reasonable?

[12:55:11 CST(-0600)] <jameswy> Yep.

[12:55:12 CST(-0600)] <michelled> yep, that's fine

[12:55:54 CST(-0600)] <colinclark> jameswy: Introduce what the class is and what they're working on and, in case where students are comfortable posting publicly, introduce them

[12:56:01 CST(-0600)] <colinclark> This is an on-ramp to open source

[12:56:04 CST(-0600)] <colinclark> a gentle starting point

[12:56:15 CST(-0600)] <colinclark> So we follow very, very rudimentary process

[12:56:17 CST(-0600)] <colinclark> and common sense

[14:37:42 CST(-0600)] <clown> michelled: Chris Blouch has provided a first pass at an answer. Apparently jQueryUI has a set of controls:

[14:37:43 CST(-0600)] <clown> http://lists.w3.org/Archives/Public/wai-xtech/2011Dec/0010.html

[14:47:12 CST(-0600)] <michelled> thanks again clown!

[14:48:00 CST(-0600)] <clown> no problem. Although, taking a quick look at that, I'm not sure it gives enough. And, it's certainly not a "best practices document". On the other hand, it's a start.

[14:48:53 CST(-0600)] <michelled> yes, it's good to know what's out there

[14:53:19 CST(-0600)] <colinclark> michelled: What was it that you were looking to get from the community about video player controls?

[14:53:39 CST(-0600)] <colinclark> I like those controls that Chris Blouch sent along

[14:53:41 CST(-0600)] <colinclark> they're quite nicely made

[14:55:17 CST(-0600)] <colinclark> Hey Bosmon, what's the best way you'd recommend us to approach your many pull requests?

[14:55:24 CST(-0600)] <colinclark> They're all cumulative, I gather

[14:55:35 CST(-0600)] <colinclark> Shall we review them in requested order?

[14:55:37 CST(-0600)] <Bosmon> Hi, yes, after a while they become cumulative

[14:55:41 CST(-0600)] <Bosmon> I think that makes the most sense

[14:55:53 CST(-0600)] <colinclark> So we can safely push one request at a time?

[14:56:00 CST(-0600)] <Bosmon> I'm not sure that you can

[14:56:04 CST(-0600)] <michelled> colinclark: I wanted to know if there were best practices on marking up video player controls

[14:56:08 CST(-0600)] <Bosmon> Some of the fixes interact a bit

[14:56:21 CST(-0600)] <Bosmon> I would review separately, and push all at once in the end, if you are happy

[14:56:28 CST(-0600)] <colinclark> oh, interesting

[14:56:32 CST(-0600)] <Bosmon> I can only guarantee that the current "final state" passes all tests, for example

[14:56:36 CST(-0600)] <Bosmon> The one labelled by "shadow"

[14:56:39 CST(-0600)] <colinclark> So, ultimately we'll push your shadow, then?

[14:57:01 CST(-0600)] <colinclark> michelled: that sounds interesting… tell me more about what you mean by "best practices" in this case

[14:57:16 CST(-0600)] <Bosmon> That reminds me to comment your comment

[14:58:12 CST(-0600)] <michelled> colinclark: we can always use common sense and mark up controls as they seem to us semantically. what I was wondering was whether any group had already put some work into that. just wanted to see if there were conversations or something that I should know about

[14:58:17 CST(-0600)] <colinclark> The "oops" one, Bosmon?

[14:58:17 CST(-0600)] <michelled> looks like there aren't colinclark

[14:58:27 CST(-0600)] <Bosmon> The other one (smile)

[14:58:42 CST(-0600)] <colinclark> So, marking up, michelled, meaning things like which HTML tags to use

[14:58:53 CST(-0600)] <colinclark> and which ARIA roles and the like?

[14:58:59 CST(-0600)] <michelled> yep, exactly

[14:59:09 CST(-0600)] <colinclark> makes sense

[14:59:12 CST(-0600)] <Bosmon> michelled commented "I'm wondering about the naming of this event - perhaps it should be 'onGenerateLiveElement' to be more consistent with our event naming patterns."

[14:59:32 CST(-0600)] <colinclark> right

[14:59:33 CST(-0600)] <Bosmon> My feeling was that it might make more sense as it was, since this event wasn't quite the same as our other "on" events

[14:59:40 CST(-0600)] <colinclark> why not?

[14:59:42 CST(-0600)] <Bosmon> Since this event is a unicast (currently our only example)

[14:59:54 CST(-0600)] <colinclark> interesting

[14:59:59 CST(-0600)] <Bosmon> So it doesn't just represent something which happens ON the "event".... it IS the entire event

[15:00:14 CST(-0600)] <Bosmon> This was done so that we could get a return value back out of the event handler, which isn't otherwise possible

[15:00:17 CST(-0600)] <colinclark> Interesting argument

[15:00:26 CST(-0600)] <colinclark> since I guess the event wasn't unicast prior to this change

[15:00:32 CST(-0600)] <Bosmon> So my feeling was that it might make more sense without "on" as part of the name, which might possibly highlight this

[15:00:38 CST(-0600)] <Bosmon> Before the change there was no event, but an "invoker"

[15:00:52 CST(-0600)] <colinclark> oh yes, I see that

[15:00:56 CST(-0600)] <colinclark> now that I'm looking at the whole file (smile)

[15:01:45 CST(-0600)] <colinclark> I guess the idea of your argument is that onX and afterX events are lifecycle hooks around some important moment

[15:01:52 CST(-0600)] <colinclark> whereas this thing is a

[15:01:55 CST(-0600)] <colinclark> delegation

[15:02:00 CST(-0600)] <colinclark> for actually doing the important thing

[15:02:47 CST(-0600)] <michelled> Bosmon: which pull request is shadow? it looks to me like this is your last pull request: https://github.com/fluid-project/infusion/pull/196

[15:03:11 CST(-0600)] <Bosmon> Yes, actually 196 is the current "tip"

[15:03:17 CST(-0600)] <Bosmon> I may not have merged it back into "shadow"

[15:03:19 CST(-0600)] <Bosmon> Although I thought I did

[15:03:54 CST(-0600)] <colinclark> michelled: Do you buy Bosmon's event naming argument?

[15:04:29 CST(-0600)] <michelled> colinclark: yes, that makes sense to me

[15:05:32 CST(-0600)] <michelled> colinclark, Bosmon: by this argument, if someone wanted to register a listener, would we require another event?

[15:05:39 CST(-0600)] <michelled> an 'on' or 'after' event?

[15:06:23 CST(-0600)] <Bosmon> michelled - I think so, yes

[15:06:25 CST(-0600)] <colinclark> I guess the idea is that this is the kind of thing we probably wouldn't expose as an event normally

[15:06:50 CST(-0600)] <Bosmon> Yes, this is really actually part of the implementation

[15:07:08 CST(-0600)] <michelled> I think we should put a comment in code to mention that

[15:07:13 CST(-0600)] <colinclark> This is the distinction that Bosmon and I argued years ago about

[15:07:28 CST(-0600)] <colinclark> between "delegation" and "notifications" to use NeXT's terminology

[15:07:32 CST(-0600)] <Bosmon> Unfortunately I suspect that this implementation is not final either

[15:07:39 CST(-0600)] <colinclark> and about which he was rather scornful (tongue)

[15:07:44 CST(-0600)] <colinclark> So, mostly I lost the argument

[15:07:53 CST(-0600)] <Bosmon> Neither "unicast events", nor "invokers", I feel are an entirely suitable implementation of this kind of concept

[15:07:56 CST(-0600)] <colinclark> in that we have seen that events (multicast events, that is) almost always solve the problem

[15:08:03 CST(-0600)] <Bosmon> But we can't really afford to tinker with either of them for the next year or so

[15:08:08 CST(-0600)] <colinclark> (smile)

[15:08:14 CST(-0600)] <colinclark> Do you have any insights into what ultimately might be the solution, Bosmon?

[15:08:17 CST(-0600)] <Bosmon> We will have to put up with what we've got

[15:08:18 CST(-0600)] <Bosmon> Not really

[15:08:32 CST(-0600)] <Bosmon> All I know is that we can't begin to work on the solution until we have the "GLOBALLY GINGER WORLD"

[15:08:35 CST(-0600)] <Bosmon> So everything is blocked on that

[15:08:53 CST(-0600)] <colinclark> So, we've just made another convention here

[15:09:03 CST(-0600)] <colinclark> which is that for those rare occasions where you're not using IoC

[15:09:14 CST(-0600)] <Bosmon> Yes, we have

[15:09:14 CST(-0600)] <colinclark> and you need to delegate responsibility of an implementation to a third party

[15:09:19 CST(-0600)] <colinclark> you'll use a unicast event

[15:09:22 CST(-0600)] <Bosmon> I'm not sure it's a convention we would want to shout too loudly about (smile)

[15:09:24 CST(-0600)] <colinclark> and it won't include "on" or "after"

[15:09:27 CST(-0600)] <colinclark> indeed

[15:09:28 CST(-0600)] <colinclark> (smile)

[15:09:39 CST(-0600)] <colinclark> michelled: convincing?

[15:09:49 CST(-0600)] <Bosmon> But I imagine it's the most suitable use of the framework, as it stands today

[15:09:58 CST(-0600)] <colinclark> To this day, I think NeXT's delegation naming convention is quite sensible

[15:10:11 CST(-0600)] <Bosmon> I mean, we were almost on the point of abolishing "unicast events" completely : P

[15:10:12 CST(-0600)] <colinclark> since it avoids the ambiguity of the word "on"

[15:10:17 CST(-0600)] <colinclark> but I lost that argument years ago (wink)

[15:10:39 CST(-0600)] <colinclark> Bosmon: Even if the solution osm

[15:10:41 CST(-0600)] <colinclark> ack

[15:10:42 CST(-0600)] <colinclark> i can't type

[15:10:49 CST(-0600)] <colinclark> this keyboard is too big

[15:10:54 CST(-0600)] <Bosmon> too big!!

[15:11:11 CST(-0600)] <clown> colinclark has small hands (question)

[15:11:15 CST(-0600)] <colinclark> even if the solution isn't right, the use of unicast events and invokers suggests that there is a legitimate problem in there, somewhere (smile)

[15:11:25 CST(-0600)] <colinclark> I'm just accustomed now to those absurdly tiny bluetooth keyborads

[15:11:30 CST(-0600)] <colinclark> plus I suck at typing

[15:11:32 CST(-0600)] <Bosmon> Plenty of legitimate problems in there somewhere (smile)

[15:11:44 CST(-0600)] <colinclark> so, michelled, convincing?

[15:11:47 CST(-0600)] <Bosmon> I invite everyone to speculate about how we might want methods to work in our "ultimate framework"....

[15:11:54 CST(-0600)] <colinclark> (smile)

[15:12:05 CST(-0600)] <colinclark> I want them to work like spaceships

[15:12:06 CST(-0600)] <michelled> yes, I think it's reasonable

[15:12:11 CST(-0600)] <Bosmon> Not like jetpacks?

[15:12:24 CST(-0600)] <colinclark> hmm

[15:12:29 CST(-0600)] <colinclark> Jetpacks are so hip

[15:12:30 CST(-0600)] <Bosmon> Or you want them to work like jetpacks, that can BE spaceships? : P

[15:12:42 CST(-0600)] <colinclark> yet still fitted nasally, as required

[15:12:53 CST(-0600)] <Bosmon> I'm so glad you read that book

[15:12:58 CST(-0600)] <Bosmon> Stick it up your nose!!

[15:14:09 CST(-0600)] <colinclark> I haven't read it in years and years

[15:14:14 CST(-0600)] <colinclark> it was michelled who read it recently

[15:14:22 CST(-0600)] <colinclark> jameswy has apparently read it a million times

[15:14:29 CST(-0600)] <colinclark> michelled: So we've got the first two pull requests covered

[15:14:32 CST(-0600)] <colinclark> two of seven

[15:14:43 CST(-0600)] <colinclark> both of which are like three lines of changes (tongue)

[15:14:59 CST(-0600)] <colinclark> we have our work cut out for us before the Interim President sends us home at noon tomorrow

[15:15:17 CST(-0600)] <Bosmon> Why is IP sending you home

[15:16:08 CST(-0600)] <colinclark> as a gesture of kindness

[15:16:17 CST(-0600)] <Bosmon> !!!

[15:16:19 CST(-0600)] <Bosmon> THIS IS A KINDNESS!