[08:14:44 CDT(-0500)] <clown> all: I received a copy of the schedule for the aegis conference next week. one phrase caught my eye, and made me smile: "This is the final version of the SAB meeting agenda. Jquery was replaced by Fluid Infusion."
[10:34:27 CDT(-0500)] <jessm> am i missing standup?
[12:21:39 CDT(-0500)] <jhung> colinclark: I think there is about 0.5 day design work left for each inline edit and progress.
[12:22:26 CDT(-0500)] <colinclark> jhung: Okay, great! Do the Progress work first so that golam can get started on implementation.
[12:22:41 CDT(-0500)] <colinclark> And if there's anything he could start on with the Progress demo while you're finishing it up, let him know.
[12:23:04 CDT(-0500)] <colinclark> I think mlam and Justin_o can stay busy on Inline Edit for another day or so even without new wireframes.
[12:23:16 CDT(-0500)] <colinclark> Seem reasonable, jhung?
[12:23:22 CDT(-0500)] <jhung> golam has already started with the current design. The only design task is how to incorporate a valuenow version progress into the same design.
[12:23:31 CDT(-0500)] <colinclark> wicked!
[12:23:47 CDT(-0500)] <colinclark> I think the valuenow version is probably much lower priority at this point anyway.
[12:24:01 CDT(-0500)] <colinclark> So you could even move on to Inline Edit, then cycle back to Progress once that's squared away
[12:24:03 CDT(-0500)] <colinclark> What do you think?
[12:24:10 CDT(-0500)] <jhung> Makes sense.
[12:24:14 CDT(-0500)] <jhung> I'll do that
[12:24:20 CDT(-0500)] <colinclark> This is really good
[12:24:21 CDT(-0500)] <colinclark> Thanks so much
[12:24:27 CDT(-0500)] <mlam> colinclark: we're aiming to finish all 3 approaches by the end of today
[12:24:35 CDT(-0500)] <colinclark> mlam: You guys are on fire!
[12:27:09 CDT(-0500)] <colinclark> So golam, I hear you've already started on the new demo for Progress. That's awesome!
[12:32:12 CDT(-0500)] <mlam> colinclark: Should we be changing the copyrights in all the files from the University of Toronto to OCAD?
[12:32:31 CDT(-0500)] <colinclark> No, definitely not.
[12:32:51 CDT(-0500)] <colinclark> U of T owns the copyright to all of our code, prior to our move to OCAD.
[12:33:03 CDT(-0500)] <colinclark> For new code, we should add a copyright statement for OCAD University
[12:33:10 CDT(-0500)] <mlam> ah , ok
[12:33:17 CDT(-0500)] <mlam> thanks
[12:33:32 CDT(-0500)] <colinclark> So, since you guys have been working on substantial changes in Inline Edit, you should add OCAD to the list in the license header
[12:33:35 CDT(-0500)] <colinclark> np
[12:38:11 CDT(-0500)] <golam> colinclark: I have started on the demo..sorry didn't see your message
[14:33:36 CDT(-0500)] <anastasiac> michelled, could you remind me of the URL for testswarm?
[14:35:45 CDT(-0500)] <michelled> http://swarm.fluidproject.org/
[14:35:50 CDT(-0500)] <michelled> anastasiac: ^
[14:35:56 CDT(-0500)] <anastasiac> thanks
[14:36:20 CDT(-0500)] <michelled> np
[14:37:30 CDT(-0500)] <anastasiac> michelled, so my browser is connected and running tests. I see the timestamped history, but nothing that looks like results - do I assume everything is passing, or do I need to go to some other page to find out the results?
[14:38:02 CDT(-0500)] <michelled> you need to go to a different page
[14:38:41 CDT(-0500)] <michelled> click the 'login' link in the top left
[14:39:08 CDT(-0500)] <michelled> then use the credentials for either fluid or cspace depending on which results you want to see
[14:39:39 CDT(-0500)] <michelled> here's a link to the results from the currently running job: http://swarm.fluidproject.org/job/305/
[14:39:43 CDT(-0500)] <michelled> anastasiac: ^
[14:40:27 CDT(-0500)] <anastasiac> and if you hadn't provided me with that link, how would I know how to see the results of the tests I'm running?
[14:40:49 CDT(-0500)] <michelled> by logging in with the correct credentials
[14:41:12 CDT(-0500)] <anastasiac> I logged in. The url I see is http://swarm.fluidproject.org/user/fluid/, no job number
[14:42:01 CDT(-0500)] <anastasiac> ah - click one of the revision number links on the left...
[14:42:13 CDT(-0500)] <michelled> ya, I should have mentioned that
[14:43:39 CDT(-0500)] <jhung> golam: FLUID-3751 http://issues.fluidproject.org/browse/FLUID-3751
[14:43:47 CDT(-0500)] <golam> thanks
[14:52:26 CDT(-0500)] <colinclark> anastasiac and golam: Are you guys working together today on the Progress demo?
[14:52:59 CDT(-0500)] <anastasiac> colinclark - no plans yet, I was going to check with golam when he wants to start
[14:53:27 CDT(-0500)] <golam> I am ready when anastasia is
[14:53:46 CDT(-0500)] <anastasiac> on my way over
[14:53:50 CDT(-0500)] <golam> cool
[14:54:08 CDT(-0500)] <jhung> Question about Inline Edit: can it use a textarea instead of a text form element?
[14:56:19 CDT(-0500)] <justin_o_> jhung: yes... the integrator can choose
[14:56:34 CDT(-0500)] <jhung> justin_o: thanks!
[14:57:01 CDT(-0500)] <colinclark> Justin_o: Do we actually have an implementation of a textarea Inline Edit?
[14:57:18 CDT(-0500)] <colinclark> Wouldn't it have to work more like a Rich Text Inline Edit because of the ability to put line breaks into a textarea?
[14:58:01 CDT(-0500)] <colinclark> mlam and golam: Just a suggestion--when you're creating a new branch, you may want to explicitly mention that you're "creating a branch to work on FLUID-XYZ..."
[14:58:21 CDT(-0500)] <colinclark> At casual glance, I briefly thought "Wow, Mike's fast! He's already added a tooltip to InlineEdit's edit mode"
[14:58:29 CDT(-0500)] <colinclark> But that was just the description of the work to come
[14:59:44 CDT(-0500)] <mlam> hahaha, not yet.
[14:59:56 CDT(-0500)] <justin_o_> colinclark, jhung: yes.. if you use a textarea, when it displays it will still use the standard html method for displaying text... which will likely remove extra whitespaces and new lines
[15:01:08 CDT(-0500)] <colinclark> justin_o_: But, wait, I'm still confused...
[15:01:26 CDT(-0500)] <jhung> justin_o: but as you were telling me the other day, multiline inline edit should be possible using preformatted text?
[15:01:32 CDT(-0500)] <colinclark> Wouldn't the very use of the enter key for a different action cause Simple Inline Edit not to be suitable for textareas?
[15:08:54 CDT(-0500)] <justin_o_> colinclark: possible, not sure.... we'd have to double check
[15:09:08 CDT(-0500)] <colinclark> justin_o_, jhung, and I just had a little pow wow
[15:09:24 CDT(-0500)] <colinclark> And decided to stick with text fields rather than textareas for now in the demo, specifically because of these unknowns.
[15:10:16 CDT(-0500)] <jhung> Hopefully we'll experiment with multiple inline edit for 1.4
[15:43:49 CDT(-0500)] <justin_o_> colinclark, and anyone else: question about image urls in the javascript
[15:43:59 CDT(-0500)] <Bosmon> Hi
[15:44:07 CDT(-0500)] <colinclark> ok
[15:44:09 CDT(-0500)] <colinclark> fire away
[15:44:12 CDT(-0500)] <Bosmon> We try to put these into CSS whenever we can... but accept that there are cases where it is sometimes impossible
[15:44:26 CDT(-0500)] <Bosmon> The classic case being, an image whose dimensions are expected to affect the layout of the page
[15:44:51 CDT(-0500)] <colinclark> justin_o_: What was the question, though?
[15:44:56 CDT(-0500)] <colinclark> I see Bosmon's answer
[15:45:04 CDT(-0500)] <colinclark> which seems quite reasonable
[15:45:11 CDT(-0500)] <justin_o_> ah okay... so we are wondering in the case of inline edit where we now want to have a pencil or some other image indicator next to the edit field.
[15:45:32 CDT(-0500)] <Bosmon> Yes, I don't want to preempt the question
[15:45:41 CDT(-0500)] <justin_o_>
[15:45:41 CDT(-0500)] <Bosmon> but just wanted to "present some relevant background"
[15:46:40 CDT(-0500)] <justin_o_> yes... had noticed that it was often in the css.... but how would we include this since the image will have to be a real tag so that we can attach a button role to it... we could put the image as a background image but not sure that exactly works
[15:47:46 CDT(-0500)] <justin_o_> If we use the method jacob did for the fluidproject.org site. which is to make the button an anchor with a background image and then use text-indenting to hide the text, we have issues with focus styling and if the image isn't there the text probably won't be visible
[15:47:55 CDT(-0500)] <justin_o_> although in this case, that might be okay
[15:48:30 CDT(-0500)] <justin_o_> but the focus styling seems to continue off page
[15:48:41 CDT(-0500)] <justin_o_> Bosmon, colinclark ^
[15:49:11 CDT(-0500)] <colinclark> justin_o_: just catching up, sorry to be slow
[15:50:22 CDT(-0500)] <Bosmon> Yes
[15:50:30 CDT(-0500)] <Bosmon> I think this is, unfortunately, the "classic case"
[15:50:45 CDT(-0500)] <Bosmon> I don't know whether we want to get together as a group and think of a "concerted policy" for dealing with things like this
[15:50:55 CDT(-0500)] <Bosmon> I mean, an idea that occurs to me now is a possible "CSS to JS URL transfer bus"
[15:51:09 CDT(-0500)] <Bosmon> So far, our reponse to this so far has always been to just ask people configure the URL in options
[15:53:09 CDT(-0500)] <colinclark> I think probably, for this first implementation in Inline Edit, that latter solution is what we'll have to do
[15:54:17 CDT(-0500)] <colinclark> justin_o_, Bosmon: For the short term, can we think of any other approaches except providing an image URL in the component's options?
[15:54:29 CDT(-0500)] <justin_o_> colinclark, Bosmon: okay... we can move on with that... if there is a better approach after we decide on which route to take for inlineEdit we can switch to it
[15:58:02 CDT(-0500)] <Bosmon> I think that is the best short term option
[15:58:17 CDT(-0500)] <Bosmon> I mean, it is what we have done in every case to date
[15:58:25 CDT(-0500)] <Bosmon> Deciding to do something different would be a Big Effort
[15:59:04 CDT(-0500)] <Bosmon> The issue I guess with putting these things in options is that they create a "brittle point of configuration"
[15:59:22 CDT(-0500)] <Bosmon> pretty much everyone who EVER USES the component then commits themselves to a miserable and endless round of URL-rewriting and rebasing
[15:59:50 CDT(-0500)] <Bosmon> Whereas the reason we appreciate putting things in CSS is that this creates a "natural way for the resolution to always work"
[16:00:10 CDT(-0500)] <Bosmon> If URLs work in CSS, then they all work at once, always
[16:03:07 CDT(-0500)] <colinclark> Yes, I completely agree
[16:04:31 CDT(-0500)] <colinclark> So, in the 1.3 time frame, let's using a URL configured in the options for this image
[16:05:07 CDT(-0500)] <colinclark> Beyond that, we should consider what it would mean to be able to somehow have this sort of stuff defined elsewhere
[16:05:32 CDT(-0500)] <Bosmon> I think a crucial barrier is that this "new approach" would be something which we would have to carefully test cross-platform
[16:05:36 CDT(-0500)] <justin_o_> colinclark: the issue with sticking it in the defaults is that it will remain part of the api
[16:05:42 CDT(-0500)] <justin_o_> since it is a production component
[16:05:47 CDT(-0500)] <Bosmon> Transferring URLs "between the worlds" is something that could easily expose other kinds of fragility
[16:05:48 CDT(-0500)] <colinclark> Yep, scarily enough
[16:05:57 CDT(-0500)] <Bosmon> I mean, this is an idea that only just now occured to me anyway
[16:05:58 CDT(-0500)] <colinclark> But what else could we do?
[16:06:09 CDT(-0500)] <Bosmon> But we could have a kind of "FSS convention for transferrable CSS URLs"
[16:06:15 CDT(-0500)] <justin_o_> colinclark: that's what i was asking
[16:06:27 CDT(-0500)] <Bosmon> Clearly you can only START to transfer them once they have already "hopped ship" by being assigned to an active CSS class
[16:06:29 CDT(-0500)] <justin_o_> Bosmon: not sure how that would work
[16:06:46 CDT(-0500)] <Bosmon> I believe we could never directly "read" the cSS
[16:06:52 CDT(-0500)] <colinclark> yeah
[16:06:59 CDT(-0500)] <Bosmon> But we could "read" the live CSS property once it had successfully jumped ship onto a DOM nodce
[16:07:04 CDT(-0500)] <colinclark> We're not going to parse the CSS in code and start ripping out URLs
[16:07:25 CDT(-0500)] <Bosmon> At which point, experience tells me that it will "probably" have been rewritten
[16:07:29 CDT(-0500)] <colinclark> so we'd have to stick these sorts of things on, say, some hidden DOM node whose job was to convey these things "across the gulf"
[16:07:50 CDT(-0500)] <Bosmon> Lots of obscure bugs I found in the renderer related to the fact that the DOM "immediately" rewrites properties which it believes to have the function of hrefs, as soon as they enter the DOM
[16:08:06 CDT(-0500)] <Bosmon> And I assume that CSS paths should be similar but this is something we would need to exhaustively test
[16:08:20 CDT(-0500)] <colinclark> justin_o_: So far, this is just future speculation
[16:08:38 CDT(-0500)] <colinclark> So justin_o_ and mlam, I'd advise you to go ahead and add that image URL as an option in the component's public API
[16:08:42 CDT(-0500)] <Bosmon> colinclark: I thought we might just simply assign them as if they were the background URL... but perhaps your approach is more moral
[16:08:56 CDT(-0500)] <Bosmon> We then of course create a UI that only ever works with Javasctip
[16:08:59 CDT(-0500)] <Bosmon> Javascript
[16:09:07 CDT(-0500)] <Bosmon> But we have absolutely no shortage of these these days
[16:09:11 CDT(-0500)] <colinclark> Bosmon: and likely more prone to browser inconsistencies
[16:09:25 CDT(-0500)] <colinclark> The speculative solutions, were they ever to be implemented, would need to take cross-component backwards compatibility into account
[16:09:51 CDT(-0500)] <colinclark> These aren't easy solutions, but we also shouldn't be totally terrified about introducing new API in cases where we can anticipate fuzzily a change in the future

Browser not supported