[07:36:51 CDT(-0500)] <anastasiac> good morning Justin_o. Are you being kingly today, or are you working on decapod?
[07:37:23 CDT(-0500)] <Justin_o> anastasiac: i'll be doing both
[07:37:34 CDT(-0500)] <Justin_o> probably more decapod in the afternoon
[07:38:42 CDT(-0500)] <anastasiac> I wasn't planning on working from home today, so I didn't bring the laptop. I'm poorly equipped to help with testing: I've got 10.5.8 on my mac and Vista on Chris's PC. I might have XP on the PC upstairs, in which case I could try some testing there...
[07:39:09 CDT(-0500)] <anastasiac> what is the status for testing today, Justin_o? are uploader and UIO ready for testing?
[07:47:37 CDT(-0500)] <Justin_o> anastasiac: uploader should be open.. uio still hs a pull request waiting
[07:47:52 CDT(-0500)] <Justin_o> anastasiac: if you could do some xp testing that would be great
[07:48:06 CDT(-0500)] <Justin_o> but i understand if it isn't possible
[07:48:09 CDT(-0500)] <anastasiac> ok, I'll check if the other computer has XP.
[08:02:52 CDT(-0500)] <anastasiac> Justin_o, I've got FF3.6 and IE6 on Win XP - I'll take those Uploader testing tasks and put them on my list. If UIO becomes ready, I can do that testing too
[08:03:40 CDT(-0500)] <Justin_o> anastasiac: that's great thanks.. luckily you have so many machines
[08:03:57 CDT(-0500)] <anastasiac> yeah... I think :-/
[08:05:26 CDT(-0500)] <anastasiac> ah, Justin_o, it seems that any uploader testing I could do has been done; I'll have to wait for uio testing
[08:07:06 CDT(-0500)] <Justin_o> anastasiac: i think those probably have to be redone.. i'll have to check in with people
[08:12:04 CDT(-0500)] <anastasiac> Justin_o, I don't see an Uploader FF3.6 XP task on the list... is that intentional?
[08:13:51 CDT(-0500)] <Justin_o> anastasiac: no
[08:13:57 CDT(-0500)] <Justin_o> it should be there
[08:14:08 CDT(-0500)] <anastasiac> is there one there, and I'm just not noticing it?
[08:19:39 CDT(-0500)] <anastasiac> Justin_o, please let me know when you've confirmed whether or not the Uploader testing needs to be redone. I'll hold off until then.
[08:23:01 CDT(-0500)] <Justin_o> anastasiac: sure, will you do the FF 3.6 xp test
[08:23:08 CDT(-0500)] <Justin_o> i can add it to your list if you like?
[08:23:19 CDT(-0500)] <anastasiac> thank, that would be great
[08:42:29 CDT(-0500)] <Justin_o> anastasiac: i've updated your list now
[08:42:31 CDT(-0500)] <Justin_o> thanks for the help
[08:42:56 CDT(-0500)] <anastasiac> thanks, Justin_o - np. I'm glad there's at least something I can do from here
[08:44:06 CDT(-0500)] <Justin_o> anastasiac: yep.. i have to check in with heidi but she doesn't seem to be around yet
[08:45:04 CDT(-0500)] <anastasiac> well, Justin_o, it could be worse; our XP computer is connected to the 55" TV
[08:46:08 CDT(-0500)] <Justin_o> nice.. that's huge
[09:33:23 CDT(-0500)] <Justin_o> anastasiac: it looks like heidi won't be around for the rest of the week
[09:33:47 CDT(-0500)] <Justin_o> michelled: does it make sense to restart all of the uploader tests on heidi's list
[09:33:52 CDT(-0500)] <anastasiac> oh, I hope everything is ok
[09:33:56 CDT(-0500)] <Justin_o> i think they came from before we stopped
[09:34:20 CDT(-0500)] <Justin_o> anastasiac: i hope so too, i think she's okay
[09:34:34 CDT(-0500)] <michelled> Justin_o: yes, let's start that over
[09:36:01 CDT(-0500)] <anastasiac> ok, I'll take on the IE6 on XP task.
[09:43:52 CDT(-0500)] <Justin_o> michelled: anastasiac: i've moved all of heidi's uploader tasks
[09:45:27 CDT(-0500)] <michelled> thx Justin_o
[09:53:06 CDT(-0500)] <michelled> cindyli: what did you and Bosmon2 decide yesterday?
[09:53:54 CDT(-0500)] <cindyli> cindyli: jameswy and Bosmon2 will continue their argument today.
[09:54:01 CDT(-0500)] <cindyli> no decision made yet
[09:56:52 CDT(-0500)] <colinclark> cindyli: Can you, super quick, summarize the impact of this issue?
[09:57:04 CDT(-0500)] <colinclark> As I understand it, line height in UIO is actually broken in some browsers currently, is that right?
[09:57:15 CDT(-0500)] <cindyli> not really, colinclark
[09:57:21 CDT(-0500)] <colinclark> oh, okay
[09:57:25 CDT(-0500)] <colinclark> tell me more
[09:57:35 CDT(-0500)] <cindyli> it's about the string value "line-height" returned by the browsers
[09:57:59 CDT(-0500)] <cindyli> ff returns px value in any cases, at lease in the cases that i've discovered so far
[09:58:15 CDT(-0500)] <cindyli> other browsers could return a string value which is "normal"
[09:58:30 CDT(-0500)] <cindyli> however, as we do need a numeric initial line height value
[09:58:45 CDT(-0500)] <cindyli> "normal" is translated into 1em once it's encountered
[09:58:53 CDT(-0500)] <cindyli> which is not an ideal solution
[09:59:35 CDT(-0500)] <cindyli> from our search, the internal translation of "normal" could be in a range, say "0.9 − 1.4" depending on the font family, size etc
[10:00:10 CDT(-0500)] <anastasiac> Justin_o, I'm testing stopping a download in mid-progress. the test plan says that with the server version, if you stop mid-file, that file should continue and finish downloading before the process stops but that's not what I'm seeing: stopping mid-file stops that file, too. Is the behaviour broken, or is the test plan wrong?
[10:00:12 CDT(-0500)] <cindyli> but we have no idea of the actual numberic value that's internally set by those browsers
[10:01:08 CDT(-0500)] <cindyli> btw, firefox returns around 1.2em in the case of "normal"
[10:01:41 CDT(-0500)] <Justin_o> anastasiac: probably was based on some old behaviour.. i think the test plan is wrong
[10:01:48 CDT(-0500)] <michelled> cindyli: how does the patch you've created change the behaviour?
[10:01:50 CDT(-0500)] <Justin_o> would you be able to update that for me. if not i can do it in a bit
[10:01:56 CDT(-0500)] <Justin_o> anastasiac: ^
[10:02:09 CDT(-0500)] <anastasiac> Justin_o, I can update it.
[10:02:14 CDT(-0500)] <Justin_o> anastasiac: thanks
[10:02:17 CDT(-0500)] <cindyli> well, with 1em that's translated by UIO, line spacing adjustment works but not perfectly
[10:03:27 CDT(-0500)] <cindyli> Bosmon2 feels the line spacing multiplier is not quite realistic due to this fact
[10:04:05 CDT(-0500)] <cindyli> colinclark: is my explanation clear?
[10:04:28 CDT(-0500)] <colinclark> I'm sure it is
[10:04:34 CDT(-0500)] <colinclark> I'm in a meeting, so I'm slightly distracted
[10:04:38 CDT(-0500)] <colinclark> but I'll catch up on it in a second
[10:05:03 CDT(-0500)] <cindyli> i see.
[10:06:03 CDT(-0500)] <cindyli> michelled: the patch i created doesn't change anything, the 1em translation is in the place since very beginning of the implementation of line spacing multiplier
[10:06:29 CDT(-0500)] <cindyli> the patch is to fix a bug that 1em was not properly assigned
[10:06:52 CDT(-0500)] <michelled> cindyli, Justin_o: I'm tempted to put the patch in and open up testing on UIO
[10:07:08 CDT(-0500)] <michelled> when Bosmon2 is around we can continue the conversation on linespacing
[10:07:30 CDT(-0500)] <michelled> since it sounds like the two things are not related
[10:07:39 CDT(-0500)] <michelled> what do you think?
[10:08:08 CDT(-0500)] <cindyli> +1 on michelled
[10:11:11 CDT(-0500)] <cindyli> although the conversation of the multiplier leads to the overturn of the multiplier, i wonder if we have time to change all that for this release. Would it be a 1.5 task then?
[10:12:08 CDT(-0500)] <Justin_o> michelled, cindyli: I think we have enough uploader tasks at the moment to keep us busy for a bit. We can revisit this proposal though if when the uploader testing is all wrapped up.
[10:12:12 CDT(-0500)] <Justin_o> does that make sense?
[10:12:31 CDT(-0500)] <Justin_o> cindyli: possibly
[10:12:36 CDT(-0500)] <michelled> makes sense to me Justin_o
[10:12:40 CDT(-0500)] <cindyli> sounds good too
[10:12:53 CDT(-0500)] <michelled> anastasiac: have all the unsupported functions been commented at this point?
[10:13:40 CDT(-0500)] <anastasiac> michelled, that would have to be a question for Bosmon2, since he's the one who would know. My guess would be not all, but I know he did spend a bit of time trying to get it up-to-date
[10:13:58 CDT(-0500)] <michelled> ok, I'll assign it to him
[10:18:12 CDT(-0500)] <michelled> fluid-everyone: here a quick update on the release: we are currently in the midst of uploader testing. We have one UIO blocker left which cindyli has a partial fix for. cindyli, Bosmon2 and jameswy will discuss the intricacies of linespacing this afternoon and we'll determine whether her fix is enough for 1.4.
[10:18:25 CDT(-0500)] <michelled> Once that blocker is done and in we can start in on UIO testing
[10:18:55 CDT(-0500)] <michelled> There are some last minutes tasks that are also happening: Justin_o will be updating licenses, copyrights and version numbers
[10:19:02 CDT(-0500)] <michelled> he'll also turn off debug mode
[10:19:26 CDT(-0500)] <michelled> Bosmon2: will check if all the unsupported functions are documented in the code
[10:20:11 CDT(-0500)] <michelled> if anyone knows of some functions that should be documented as unsupported please do so and issue a pull request against 4250
[10:20:38 CDT(-0500)] <michelled> once all those things are done we are ready to make bundles to test
[10:21:03 CDT(-0500)] <michelled> we really are in the home stretch! Thanks fluid-everyone for your hard work!
[10:24:30 CDT(-0500)] <michelled> Justin_o: I was just doing some sniff testing on the builder - it looks to me like the release notes don't get included in custom builds
[10:24:38 CDT(-0500)] <michelled> does that sound like a blocker to you?
[10:32:55 CDT(-0500)] <jhung> fluid-everyone, the connect room is down
[10:33:15 CDT(-0500)] <anastasiac_> yeah, I noticed. should we meet in the york room?
[10:33:56 CDT(-0500)] <jhung> sure http://breeze.yorku.ca/fluidwork/
[11:59:23 CDT(-0500)] <Justin_o> michelled: Sorry i missed your message earlier. Yes this does sound like a blocker to me. Luckily it won't affect this set of testing, as it would be more of an issue when we start testing the release builds
[12:10:40 CDT(-0500)] <heidi_> hey Justin_o i'm back doing some testing this afternoon fyi ..full w preview on mac
[12:11:30 CDT(-0500)] <Justin_o> heidi_: hello, we're still pausing on UIO testing, because of the issue we spotted yesterday
[12:11:46 CDT(-0500)] <Justin_o> we've had to restart Uploader testing after the blockers were fixed if you want to pick some of those tasks up again
[12:12:04 CDT(-0500)] <Justin_o> I had moved the ones that were in your list already, back to the high priority list
[12:12:07 CDT(-0500)] <Justin_o> heidi_: ^
[12:12:14 CDT(-0500)] <heidi_> Justin_o ah ok, will switch to uploader tasks
[12:12:20 CDT(-0500)] <heidi_> ok vool
[12:12:22 CDT(-0500)] <heidi_> cool
[12:13:38 CDT(-0500)] <Justin_o> heidi_: thanks
[13:01:20 CDT(-0500)] <michelled> Justin_o: do you know if the image gallery gets built nightly? I just want to make sure I'm testing on the most recent code base.
[13:02:01 CDT(-0500)] <Justin_o> michelled: yes it should, and there should also be an hourly build as well
[13:02:11 CDT(-0500)] <michelled> thx
[13:06:00 CDT(-0500)] <michelled> Justin_o, anastasiac: I came across this page - I guess it will need some updating: http://wiki.fluidproject.org/display/fluid/Upload+Compatibility
[13:06:31 CDT(-0500)] <michelled> does anyone know what version of the uploader I should expect when using IE 8 xp?
[13:06:42 CDT(-0500)] <Bosmon2> Hi Justin_o
[13:06:46 CDT(-0500)] <Justin_o> michelled: that was super old and was more to test the compatibility of the different versions of swfupload
[13:06:59 CDT(-0500)] <Justin_o> michelled: you should get the flash uploader
[13:07:02 CDT(-0500)] <Justin_o> Bosmon2: hellow
[13:07:09 CDT(-0500)] <anastasiac> Justin_o, should we update that page, or delete it?
[13:07:31 CDT(-0500)] <michelled> hi Bosmon2
[13:07:34 CDT(-0500)] <Justin_o> anastasiac: maybe we can just rename it, i'm not sure if we want it for some historical refernce
[13:07:45 CDT(-0500)] <michelled> Justin_o: I'm getting the single file uploader
[13:07:49 CDT(-0500)] <michelled> let me try again
[13:07:59 CDT(-0500)] <Justin_o> Bosmon2: I'm looking at FLUID-4252
[13:08:10 CDT(-0500)] <Justin_o> i was going to ask you how to change that now since it looks like the function has been modified
[13:08:13 CDT(-0500)] <anastasiac> Justin_o, what new name would you recommend? Preface the name with "Archive" or something?
[13:09:05 CDT(-0500)] <Justin_o> Bosmon2: I think I can just set softFailure to false
[13:09:12 CDT(-0500)] <Justin_o> but wanted to double check with you
[13:09:18 CDT(-0500)] <Justin_o> maybe it's not necessary at all now?
[13:10:03 CDT(-0500)] <Justin_o> maybe something like swfupload 2.20 beta uploader compatibility
[13:10:06 CDT(-0500)] <Justin_o> or something like that
[13:10:10 CDT(-0500)] <Justin_o> what do you think?
[13:11:14 CDT(-0500)] <Justin_o> anastasiac: ^
[13:11:16 CDT(-0500)] <Bosmon2> Justin_o - I think it is the other way round
[13:11:28 CDT(-0500)] <Bosmon2> The new behaviour required on making a release is to set softFailure to true
[13:11:33 CDT(-0500)] <anastasiac> Justin_o, that looks reasonably clear and informative
[13:11:34 CDT(-0500)] <Bosmon2> At least that is what my brain seems to think
[13:11:58 CDT(-0500)] <Bosmon2> No wait
[13:12:01 CDT(-0500)] <Bosmon2> That can't be right..
[13:12:29 CDT(-0500)] <Bosmon2> No, that is right
[13:12:45 CDT(-0500)] <Justin_o> Bosmon2: yes.. i see now… why is it an array by the way?
[13:12:51 CDT(-0500)] <Justin_o> anastasiac: thanks, i'll change the name now
[13:13:03 CDT(-0500)] <Bosmon2> It's an array since it now gets things pushed and popped onto it, depending on what the user demands in various environments
[13:13:08 CDT(-0500)] <Bosmon2> You can see this usage in several test cases
[13:13:35 CDT(-0500)] <Bosmon2> For example, if a test case knows that it needs to test provoking a failure, it "pushes" softFailure of true onto the stack
[13:13:47 CDT(-0500)] <Bosmon2> and then when it is done, it pops it off, restoring whatever the original value was
[13:14:10 CDT(-0500)] <Justin_o> Bosmon2: ah i see.. that way you don't need to temporarily store the original state somewhere
[13:14:45 CDT(-0500)] <Justin_o> Bosmon2: i suppose i should set all instances of fluid.setLogging to false, unless there is some global way to do this somewhere
[13:17:10 CDT(-0500)] <Bosmon2> Justin_o - those should only exist in test cases
[13:17:27 CDT(-0500)] <Bosmon2> You should definitely destroy completely any of them you find anywhere else : P
[13:17:28 CDT(-0500)] <Justin_o> there's one in the fluid.fail function as well
[13:17:35 CDT(-0500)] <Bosmon2> Oh, interesting
[13:17:38 CDT(-0500)] <Justin_o> but it might make sense there i guess
[13:17:41 CDT(-0500)] <Bosmon2> Well, it does, I think
[13:17:47 CDT(-0500)] <Bosmon2> Otherwise the message it generates will not get logged
[13:17:52 CDT(-0500)] <Justin_o> ah
[13:18:03 CDT(-0500)] <Justin_o> this setLogging does more than i thought i guess
[13:19:10 CDT(-0500)] <Bosmon2> I mean, I guess in theory, it should just turn logging off again after the next statement
[13:19:16 CDT(-0500)] <Bosmon2> But really, after a failure, "all bets are off"
[13:21:24 CDT(-0500)] <michelled> Bosmon2: I assigned FLUID-4250 to you - could you take a look and see if all the unsupported functions are commented?
[13:21:32 CDT(-0500)] <Bosmon2> michelled - thanks, I will
[13:21:45 CDT(-0500)] <michelled> thank you!
[13:23:00 CDT(-0500)] <michelled> Bosmon2: the other thing that would be good is to figure out what we do with FLUID-4473
[13:23:23 CDT(-0500)] <michelled> it's obvious from you conversation yesterday with cindyli that we don't have an ideal solution yet
[13:23:40 CDT(-0500)] <michelled> but what I'm wondering is whether her partial solution should be pushed and shipped with 1.4
[13:23:52 CDT(-0500)] <michelled> or whether we should hold the release to do a more complete solution
[13:24:05 CDT(-0500)] <michelled> I know that you and jameswy and cindyli were going to have that conversation today
[13:24:29 CDT(-0500)] <Justin_o_> fluid-everyone: powers out in the Toronto office, luckily most of us are using laptops
[13:34:22 CDT(-0500)] <michelled> Justin_o: it was because I hadn't installed flash in my ie8 vm yet - so the progressive enhancement is certainly working
[13:34:42 CDT(-0500)] <Justin_o> michelled: nice to see you are testing everything
[13:34:53 CDT(-0500)] <michelled>
[13:38:02 CDT(-0500)] <Justin_o> michelled, Bosmon2, colinclark: do you think that demos should ever have fluid.setLogging on
[13:38:10 CDT(-0500)] <Justin_o> i'm wondering if i should set it to false or just remove it
[13:38:13 CDT(-0500)] <Bosmon2> Justin_o - I don't believe so, no
[13:38:15 CDT(-0500)] <Bosmon2> You should just remove it
[13:38:24 CDT(-0500)] <Justin_o> Bosmon2: okay, thanks
[13:38:26 CDT(-0500)] <Justin_o> i will do that
[13:41:56 CDT(-0500)] <Justin_o> Bosmon2: there's a setLogging in fluidParser.js
[13:41:59 CDT(-0500)] <Justin_o> line 357
[13:42:13 CDT(-0500)] <Justin_o> it's for the fluid.XMLP._ERROR
[13:42:21 CDT(-0500)] <Justin_o> would this one also have to be left on?
[13:48:34 CDT(-0500)] <Bosmon2> Hmm
[13:48:44 CDT(-0500)] <Bosmon2> I guess it would be helpful, if there is a logging statement after it
[13:48:54 CDT(-0500)] <Bosmon2> It should only fire in the case someone has a corrupt template
[13:49:00 CDT(-0500)] <Bosmon2> In which case they would probably appreciate knowing the reason why
[13:49:15 CDT(-0500)] <Justin_o> Bosmon2: makes sense
[13:49:26 CDT(-0500)] <colinclark> michelled, anastasiac: I wondered if we could chat real quick about the blurb for the Renderer demo from yesterday
[13:49:26 CDT(-0500)] <Justin_o> i'm also thinking of leaving all the ones in the tests on
[13:49:32 CDT(-0500)] <Justin_o> since they should be relatively harmless
[13:49:38 CDT(-0500)] <Justin_o> and would be useful there
[13:49:40 CDT(-0500)] <Bosmon2> Justin_o - that seems reasonable
[13:49:42 CDT(-0500)] <anastasiac> sure, colinclark
[13:50:03 CDT(-0500)] <colinclark> The text is now here: http://build.fluidproject.org/infusion/demos/renderer/demo.html
[13:50:12 CDT(-0500)] <colinclark> The more I think about it, the more I wonder if this is quite what we want
[13:50:18 CDT(-0500)] <colinclark> I understand what it is saying
[13:50:38 CDT(-0500)] <colinclark> but I'm thinking about the purpose of the demo portal, and the fact that it's often the first place someone goes to learn about our stuff
[13:50:48 CDT(-0500)] <Justin_o> Bosmon2: thanks
[13:50:49 CDT(-0500)] <colinclark> This blurb has a lot of specific technical detail
[13:51:18 CDT(-0500)] <colinclark> contrasting simple and complex use cases
[13:51:38 CDT(-0500)] <colinclark> and mentioning things like the need for further processing
[13:51:49 CDT(-0500)] <colinclark> I wonder, for most people visiting the demo portal, if these concepts will mean much
[13:52:03 CDT(-0500)] <colinclark> or if really it just complicates the understanding of what the Renderer does
[13:52:13 CDT(-0500)] <colinclark> My rough suggestion is this:
[13:52:26 CDT(-0500)] <colinclark> Perhaps we could have a very succinct blurb about what the Renderer does
[13:52:35 CDT(-0500)] <colinclark> and then links to more documentation and demos
[13:52:37 CDT(-0500)] <colinclark> and leave it at that
[13:52:51 CDT(-0500)] <colinclark> Thoughts?
[13:53:30 CDT(-0500)] <anastasiac> colinclark, I agree that the details might throw a newcomer off
[13:54:03 CDT(-0500)] <anastasiac> I'm concerned about people who are turning to the demo for the code: how do we let them know that this code is not what they want if they have a simple use case?
[13:55:33 CDT(-0500)] <colinclark> Well, I think it's a very difficult to thing to do
[13:55:48 CDT(-0500)] <colinclark> And I think we're probably better off simply giving users the tools they need to make these sorts of decisions for themselves
[13:55:57 CDT(-0500)] <colinclark> which means, point them directly to the documentation and more demos
[13:56:03 CDT(-0500)] <colinclark> they can explore and learn what they need most
[13:56:22 CDT(-0500)] <colinclark> We've just added two quite complex and technical paragraphs to paper over a demo that we feel isn't quite what we want
[13:56:53 CDT(-0500)] <colinclark> I think we're better off just trying to direct people to a few other sources of useful information and solve the root problem in our next release
[13:56:59 CDT(-0500)] <colinclark> i.e. making a really hot Renderer demo
[13:57:19 CDT(-0500)] <anastasiac> sounds reasonable. I'll redraft it and run it by you - would that be ok, colinclark?
[13:57:27 CDT(-0500)] <colinclark> thanks, anastasiac
[13:57:41 CDT(-0500)] <colinclark> michelled: You're cool with another pull request?
[13:59:03 CDT(-0500)] <michelled> yes, that would be great colinclark
[13:59:12 CDT(-0500)] <colinclark> ok
[13:59:21 CDT(-0500)] <michelled> please reopen the jira
[14:02:28 CDT(-0500)] <jhung1> colinclark: fyi, B&H Photo is closed until Saturday 8pm EST. So we won't be getting any quotes from them until at least Monday.
[14:02:48 CDT(-0500)] <jameswy> Bosmon2: Any new thoughts on the line spacing challenge?
[14:03:01 CDT(-0500)] <colinclark> jhung1: Who else are we getting quotes from?
[14:03:30 CDT(-0500)] <Bosmon2> jameswy - well, my first thought is that it is impossible for us to achieve any of our goals
[14:03:36 CDT(-0500)] <jhung1> vistek, henrys, aden
[14:03:58 CDT(-0500)] <jameswy> Bosmon2: I like your optimism.
[14:04:51 CDT(-0500)] <Bosmon2> Certainly, your two goals of achieving an "actionless UIOptions configuration" together with a "single continuous scale" can't be fulfilled at the same time with the current CSS implementation model in the browsers
[14:05:07 CDT(-0500)] <Bosmon2> So the discussion seems to be about to what extent we are prepared to compromise, and to what end....
[14:06:02 CDT(-0500)] <jameswy> Bosmon2: The key issue is that the browsers aren't returning the quantitative line spacing value--is that correct?
[14:06:45 CDT(-0500)] <jameswy> (Firefox excepted)
[14:06:56 CDT(-0500)] <Bosmon2> jameswy - that's right
[14:08:11 CDT(-0500)] <jameswy> Bosmon2: And the reason that's a problem is because there's no consistency across browsers in their baseline line-height?
[14:08:49 CDT(-0500)] <Bosmon2> jameswy - yes, if you call the baseline what is reported by "normal"
[14:09:12 CDT(-0500)] <jameswy> Yes.
[14:09:13 CDT(-0500)] <Bosmon2> To add insult to injury, there are two further values, which I imagine will also be inconsistently mapped
[14:10:24 CDT(-0500)] <jameswy> Bosmon2: Is it not possible for us to manually discover the normal line heights of browsers so that we know what to multiply against for UIO line height changes?
[14:10:46 CDT(-0500)] <Bosmon2> jameswy - it seems, not in any reasonable way
[14:11:43 CDT(-0500)] <jameswy> Bosmon2: Are there some unreasonable ways to do it?
[14:12:40 CDT(-0500)] <Bosmon2> jameswy - there are a few
[14:13:21 CDT(-0500)] <Bosmon2> We could just try fabricating bits of markup, and then try to make physical positioning measurements based on things in it
[14:13:51 CDT(-0500)] <Bosmon2> This would hurt our already poor startup performance yet further, and still may not work stably - reports on StackOverflow suggest that this is pretty unstable
[14:17:01 CDT(-0500)] <jameswy> Bosmon2: We can't simply dig into WebKit or Gecko and see what their configured values are?
[14:17:19 CDT(-0500)] <Bosmon2> jameswy - I would say not
[14:17:56 CDT(-0500)] <Bosmon2> We could explore for a while, but I think it is extremely unlikely that if the values couldn't be discovered via JS/HTML solutions, that they could be discovered any other wya
[14:18:51 CDT(-0500)] <cindyli> Bosmon2, jameswy, the closest official doc that states about the value of "normal" is https://developer.mozilla.org/en/CSS/line-height
[14:19:01 CDT(-0500)] <cindyli> it says "Depends on the user agent. Desktop browsers (including Firefox) use a default value of roughly 1.2, depending on the element's font-family."
[14:19:08 CDT(-0500)] <cindyli> so, roughly 1.2
[14:19:19 CDT(-0500)] <Bosmon2> Yes - amusingly that is on the site of the browser that actually solves the problem for us, as opposed to the one that is the problem
[14:19:39 CDT(-0500)] <cindyli> i've also been experimenting with ie 6-9, latest version of ff, chrome and safari, using 1em - 1.2em
[14:20:19 CDT(-0500)] <cindyli> it seems so far that only IE8 tends to convert "normal" into a value in between 1em to 1.2em
[14:20:24 CDT(-0500)] <Bosmon2> cindyli - by jameswy's standards of yesterday, even the slightest instability represents an unacceptable result
[14:20:47 CDT(-0500)] <Bosmon2> Since we can't then guarantee that UIO can naturally act in a configuration which leaves the page unchanged
[14:20:56 CDT(-0500)] <Bosmon2> That is, unless we add a special "do nothing" setting to line-height
[14:21:33 CDT(-0500)] <cindyli> umm… as you said, to what extend we want to compromise
[14:22:19 CDT(-0500)] <cindyli> with zero tolerance, we cannot do much
[14:22:38 CDT(-0500)] <Bosmon2> jameswy - which compromise do you regard as the "least unacceptable"?
[14:23:16 CDT(-0500)] <jameswy> Reading.
[14:24:06 CDT(-0500)] <jameswy> Bosmon2: Could you lay out the options explicitly?
[14:26:12 CDT(-0500)] <Bosmon2> jameswy - I see two main options - i) abandon the condition that UIO comes with a natural "do-nothing" setting, and have its "natural zero" appear on the line-height setting of, say 1.2em
[14:26:34 CDT(-0500)] <Bosmon2> or ii) add a separate setting into UIO line-height, represented by something like a tick-box, which is the default, overrides the numerical setting, and corresponds to "normal"
[14:27:26 CDT(-0500)] <jameswy> Bosmon2: Of the two, the former is more acceptable.
[14:27:39 CDT(-0500)] <Bosmon2> Ok
[14:27:43 CDT(-0500)] <jameswy> But both give me wrinkles.
[14:27:46 CDT(-0500)] <Bosmon2> That certainly leads to a simpler implementation
[14:28:05 CDT(-0500)] <Bosmon2> jameswy - one thing I worry about, is that I am not actually sure that your condition i) is even being met by UIO as it is today
[14:28:13 CDT(-0500)] <Bosmon2> I think we don't actually have it explicitly as part of any test plan, Justin_o?
[14:28:27 CDT(-0500)] <Bosmon2> So we need to surface this as an important aspect of the component to be evaluated, if we care about it
[14:29:00 CDT(-0500)] <jameswy> (Justin_o went to get caffeinated with yura and will return in a bit.)
[14:29:05 CDT(-0500)] <Bosmon2> ok
[14:30:06 CDT(-0500)] <Bosmon2> I have this niggling sense that UIO as it is today tends to make the font-size of the page slightly smaller when it is dropped onto it
[14:30:12 CDT(-0500)] <Bosmon2> But I could be just imagining it
[14:30:38 CDT(-0500)] <jameswy> Bosmon2: You may be right. By default, at least in FF, the lines are overlapping.
[14:30:59 CDT(-0500)] <jameswy> You can see it most clearly when you select multiple lines of text.
[14:31:16 CDT(-0500)] <Bosmon2> That could just be line-height, rather than font-size
[14:31:26 CDT(-0500)] <Bosmon2> In which case setting our "zero point" to 1.2em would alleviate it slightly
[14:32:10 CDT(-0500)] <anastasiac> colinclark: could you have a look at http://pastie.org/2612823 ? (fogive the colourization)
[14:41:37 CDT(-0500)] <heidi_> Justin_o does the img gallery server demo not let you upload the same file twice?
[14:45:16 CDT(-0500)] <Justin_o> heidi_: i don't think so
[14:45:21 CDT(-0500)] <Justin_o> cindyli: can you comment on that
[14:45:34 CDT(-0500)] <heidi_> i can upload the same file again after refresh
[14:45:52 CDT(-0500)] <heidi_> but if i have the same file twice in the same queue it puts a checkmark beside one and an x beside the next
[14:46:10 CDT(-0500)] <heidi_> i guess it's sort of a weird thing to do anyway
[14:46:48 CDT(-0500)] <cindyli> as i rmb, the server side no longer checks if one file has been uploaded twice
[14:47:40 CDT(-0500)] <cindyli> heidi_: to help with the uploader at the client easily creates an error case
[14:48:31 CDT(-0500)] <heidi_> cindyli yeah i think it rejects a file that's already been uploaded when in the same queue
[14:49:08 CDT(-0500)] <cindyli> cool.
[14:50:02 CDT(-0500)] <cindyli> heidi_: r u using the image gallery at build site? it doesn't seem working properly on me
[14:50:20 CDT(-0500)] <cindyli> the uploaded images are not displayed underneath the uploader
[14:50:22 CDT(-0500)] <heidi_> cindyli http://build.fluidproject.org/image-gallery/image-gallery.php working ok for me so far
[14:50:27 CDT(-0500)] <heidi_> hm, they do for me
[14:50:55 CDT(-0500)] <cindyli> ok, might be my settings…
[14:51:14 CDT(-0500)] <heidi_> cindyli actually i just uploaded a jpg and instead of putting the thumbnail it has the name of the file
[14:51:18 CDT(-0500)] <heidi_> but two other pics worked
[14:51:35 CDT(-0500)] <cindyli> yes, same here
[14:51:49 CDT(-0500)] <cindyli> all my uploaded images are showed in names rather then the pics
[14:52:02 CDT(-0500)] <Justin_o> michelled: i've made the changes to logging and debugging https://github.com/fluid-project/infusion/pull/176
[14:52:15 CDT(-0500)] <heidi_> cindyli when i view img it says "file not found on the server"
[14:52:35 CDT(-0500)] <cindyli> ok. at least we got an error
[14:53:01 CDT(-0500)] <heidi_> cindyli it seems to be if the filename has a space in it?
[14:53:21 CDT(-0500)] <cindyli> heidi_: i don't have space in the filename
[14:53:44 CDT(-0500)] <heidi_> hm
[14:55:56 CDT(-0500)] <cindyli> Bosmon2, jameswy, regarding line spacing issue, can we say you reach a temp agreement of converting "normal" into "1.2em"
[14:56:23 CDT(-0500)] <jameswy> cindyli, Bosmon2: Yes.
[14:56:41 CDT(-0500)] <cindyli> cool. i can proceed. thanks guys
[14:56:58 CDT(-0500)] <jameswy> michelled ^
[14:57:04 CDT(-0500)] <jameswy> Justin_o ^
[14:57:13 CDT(-0500)] <michelled> thanks!
[14:57:42 CDT(-0500)] <Justin_o> thanks
[14:59:55 CDT(-0500)] <cindyli> heidi_: i will take a look at the image gallery problem later, likely tomorrow morning
[15:00:10 CDT(-0500)] <heidi_> cindyli cool, i don't think it has to do with uploader itself, right?
[15:00:46 CDT(-0500)] <cindyli> heidi_: no, doen't seem like uploader issue
[15:01:02 CDT(-0500)] <cindyli> but need to look further to ensure
[15:02:32 CDT(-0500)] <Justin_o> michelled: here's another pull request for the version numbers this time http://issues.fluidproject.org/browse/FLUID-4249
[15:02:47 CDT(-0500)] <michelled> thx Justin_o
[15:02:53 CDT(-0500)] <Justin_o> michelled: i'll take a look at the copyrights and the licences tomorrow
[15:03:05 CDT(-0500)] <michelled> sounds good
[15:03:37 CDT(-0500)] <michelled> Justin_o: does the demo have a max file size for uploader?
[15:04:00 CDT(-0500)] <Bosmon2> cindyli - the great advantage of this approach is that you can completely ditch that terrible method that has 3 different kinds of browser detection : P
[15:04:01 CDT(-0500)] <Justin_o> um… i think 20mb
[15:05:08 CDT(-0500)] <cindyli> Bosmon2: i probably still need to exclude firefox from the unit test of "normal" line-height
[15:05:27 CDT(-0500)] <cindyli> as i noticed that ff returns 1.19em for certain font family
[15:05:34 CDT(-0500)] <Bosmon2> cindyli - but... there no longer is any kind of thing like "normal" lineheight
[15:05:43 CDT(-0500)] <cindyli> ah, what
[15:05:46 CDT(-0500)] <cindyli> ?
[15:05:47 CDT(-0500)] <Bosmon2> Since we are just going to write fixed values into the document
[15:05:57 CDT(-0500)] <Bosmon2> Well, I believe we decided on a numerical scale, centred on 1.2em?
[15:06:02 CDT(-0500)] <cindyli> yes
[15:06:18 CDT(-0500)] <Bosmon2> So we are no longer troubled by what crazy value we discover in the document at the start
[15:07:11 CDT(-0500)] <Bosmon2> As a result, hopefully this means that we treat every browser the same
[15:08:17 CDT(-0500)] <cindyli> Bosmon2: one case is that line-height has been set on the document, we want to maintain that
[15:08:44 CDT(-0500)] <cindyli> the good thing in this case is that all the browsers will return back the numeric value of "line-height" in px
[15:09:03 CDT(-0500)] <cindyli> the trouble case is the line-height has never been set on the the doc
[15:09:04 CDT(-0500)] <Bosmon2> cindyli - if we pay attention to some kinds of line-height, we need to pay attention to all of them
[15:09:13 CDT(-0500)] <cindyli> exactly
[15:09:16 CDT(-0500)] <Bosmon2> Otherwise we end up with a system that behaves inconsistently on different browsers
[15:09:22 CDT(-0500)] <cindyli> agree
[15:09:23 CDT(-0500)] <Bosmon2> So this suggests to me that we should pay attention to none of them
[15:09:28 CDT(-0500)] <Bosmon2> Since we can't pay attention to all of them
[15:09:34 CDT(-0500)] <cindyli> we can
[15:09:47 CDT(-0500)] <cindyli> by reading the line height valid numbers
[15:09:53 CDT(-0500)] <heidi_> jameswy should "add more" button be disabled when the max # files is reached?
[15:10:05 CDT(-0500)] <cindyli> Bosmon2: the only special case is "normal"
[15:10:24 CDT(-0500)] <jameswy> heidi_: Yes.
[15:10:29 CDT(-0500)] <cindyli> other values could be in px, em, %, and a number
[15:10:29 CDT(-0500)] <jameswy> Hm.
[15:10:33 CDT(-0500)] <jameswy> Rhr'A foosoint.
[15:10:39 CDT(-0500)] <jameswy> I mean, That's a good point.
[15:10:39 CDT(-0500)] <cindyli> Bosmon2: also, "inherit"
[15:10:51 CDT(-0500)] <anastasiac> michelled, I've issued a pull request for the renderer demo text changes: https://github.com/fluid-project/infusion/pull/178
[15:11:05 CDT(-0500)] <heidi_> jameswy k i'll make a jira
[15:11:06 CDT(-0500)] <cindyli> all those cases, either a px number is returned or "normal"
[15:11:07 CDT(-0500)] <Bosmon2> cindyli - if we try to read any of those values, we create a system which can't apply stored preferences consistently
[15:11:20 CDT(-0500)] <cindyli> we don't read them ourselves
[15:11:37 CDT(-0500)] <cindyli> this line - that.container.css("line-height")
[15:11:49 CDT(-0500)] <cindyli> returns us either px value, or "normal"
[15:11:56 CDT(-0500)] <cindyli> browser does the conversion
[15:12:03 CDT(-0500)] <cindyli> but not on "normal" yet
[15:12:08 CDT(-0500)] <Bosmon2> Yes - to me, the fact that it may return "normal" is the reason we need to ignore what value it returns
[15:12:42 CDT(-0500)] <cindyli> aaaa….???
[15:12:46 CDT(-0500)] <cindyli> how can we ignore
[15:13:11 CDT(-0500)] <cindyli> the returned value would be more precise than an assumption as 1.2em
[15:14:34 CDT(-0500)] <Bosmon2> ok
[15:14:39 CDT(-0500)] <cindyli> do i get somewhere wrong?
[15:15:01 CDT(-0500)] <Bosmon2> Well, here's another approach to writing the test cases - you can inject a "test implementation" of the method which reads the line height
[15:15:15 CDT(-0500)] <Bosmon2> And have two implementations of it, one which returns a value, and another which returns "normal"
[15:15:28 CDT(-0500)] <Bosmon2> Similar to the way in which we inject implementations which pretend to be IE in some of our test cases
[15:15:51 CDT(-0500)] <Bosmon2> This only adds more flexibility to the component after all, since it creates a way for the integrator to make their own decisions about how line-height is read
[15:16:14 CDT(-0500)] <cindyli> yes, Bosmon2, that's what i'm trying to do except firefox never returns me "normal"
[15:16:32 CDT(-0500)] <Bosmon2> cindyli - that's why instead of using the raw browser's method, we inject a test stub implementation
[15:16:40 CDT(-0500)] <Bosmon2> That way we can take control of what is tested
[15:16:51 CDT(-0500)] <cindyli> ok. i think i kind of get you
[15:17:01 CDT(-0500)] <Bosmon2> I guess it would be a kind of "invoker"
[15:17:08 CDT(-0500)] <Bosmon2> "readContainerLineHeight" or some such
[15:17:10 CDT(-0500)] <cindyli> haha
[15:17:27 CDT(-0500)] <Bosmon2> with 3 implementations... the raw browser used in the wild, and two stub implementations which always return a particular numerical value, or "normal"
[15:18:26 CDT(-0500)] <cindyli> i see. understand
[15:18:43 CDT(-0500)] <cindyli> 2 mock-up in unit tests
[15:19:23 CDT(-0500)] <cindyli> thanks, Bosmon2. very helpful!
[15:19:32 CDT(-0500)] <Bosmon2> cool
[15:19:42 CDT(-0500)] <Bosmon2> I am excited that we may be able to put our final blocker to bed
[15:19:47 CDT(-0500)] <Bosmon2> This is our last, right?
[15:19:52 CDT(-0500)] <cindyli> yes, for now
[15:20:43 CDT(-0500)] <Bosmon2> Well, that is as good as "the last" ever gets
[15:21:13 CDT(-0500)] <cindyli>
[15:49:25 CDT(-0500)] <colinclark> michelled: I like Anastasiac's new text
[15:53:44 CDT(-0500)] <michelled> great colinclark - do you want to push it or should I?
[15:53:56 CDT(-0500)] <colinclark> it's up to you
[15:55:17 CDT(-0500)] <michelled> I can do it

Browser not supported