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
[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
[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
[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
[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>
[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
[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>
[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
[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
[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
[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
[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>
[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
[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!