[09:42:30 CDT(-0500)] <Justin_o> anastasiac: is this still a blocker for the 1.4 release <cindyli> for instance, with BODY <cindyli> if body
[09:42:30 CDT(-0500)] <Justin_o> http://issues.fluidproject.org/browse/FLUID-3716
[09:43:51 CDT(-0500)] <anastasiac> ah. Justin_o, yura has gone over most of the existing IoC docs and ensured that they're up-to-date. I think once he's had a chance to check the last few pages, we can close this one. But yes, I think it should be a blocker, since yura has found some old things in the docs that are no longer correct.
[09:44:08 CDT(-0500)] <colinclark> But should it be a blocker for the release, anastasiac?
[09:44:30 CDT(-0500)] <colinclark> Or should it be something we make sure to finish off in our post-release documentation sprint?
[09:44:50 CDT(-0500)] <anastasiac> personally, I'm not comfortable releasing software with incorrect documentation. incomplete is one thing, but incorrect is another
[09:45:41 CDT(-0500)] <Justin_o> anastasiac, yura: when do you think it will be finished?
[09:47:20 CDT(-0500)] <yura> Justin_o: i could finish that stuff by the end of the week i think, just need to find a spot between the cspace work
[09:56:41 CDT(-0500)] <Justin_o> yura: that would work perfectly.. thanks
[11:54:35 CDT(-0500)] <Justin_o> cindyli: this is all i've found so far in regards to detecting the browser's default font size
[11:54:36 CDT(-0500)] <Justin_o> http://stackoverflow.com/questions/739940/detect-browser-font-size
[11:55:39 CDT(-0500)] <cindyli> Justin_o: yes, i found this one too. so basically, there's no browser property or function to get default font size from
[11:55:57 CDT(-0500)] <Justin_o> cindyli: doesn't look like it
[11:56:00 CDT(-0500)] <cindyli> but writing a script to measure is possible
[11:56:47 CDT(-0500)] <cindyli> i actually found just by detecting the browser's default font size is not enough.
[11:57:04 CDT(-0500)]
[11:57:22 CDT(-0500)] <cindyli> it takes the default 16px down to 10px
[11:58:02 CDT(-0500)] <cindyli> Justin_o: which means so far we found at least 2 factors that affects the default font size
[11:58:09 CDT(-0500)] <cindyli> and might be more
[11:58:38 CDT(-0500)] <cindyli> i'm now thinking maybe we should switch back to use px rather than em
[11:58:41 CDT(-0500)] <Justin_o> cindyli: interesting.. did that come from out base and reset styles
[11:58:59 CDT(-0500)] <cindyli> from my experiment 
[12:00:15 CDT(-0500)] <cindyli> our fss doesn't have but we cannot tell how our users' websites would be
[12:00:35 CDT(-0500)] <cindyli> Justin_o: back to the topic why i think we should switch back to px
[12:00:53 CDT(-0500)] <cindyli> the browser getComputedStyle() take all these factors into account
[12:01:16 CDT(-0500)] <cindyli> rather than re-dectecting those factors from different ways, to convert px back into em
[12:01:40 CDT(-0500)] <cindyli> might be less risky to directly apply px
[12:02:07 CDT(-0500)] <cindyli> unless there are other disadvantages of using px
[12:02:58 CDT(-0500)] <cindyli> any reasons that you can think of why we should not use px, Justin_o
[12:03:51 CDT(-0500)] <Justin_o> cindyli: do you know why we switched to ems… it might help tease out some of the issues with using pxs
[12:04:36 CDT(-0500)] <cindyli> more flexible and proper as heidi suggested
[12:04:49 CDT(-0500)] <cindyli> i suppose
[12:08:38 CDT(-0500)] <cindyli> let me send our discussion to fluid work list, Justin_o. so other ppl can give their comment
[12:09:30 CDT(-0500)] <Justin_o> cindyli: good idea, thanks
[12:09:36 CDT(-0500)] <cindyli> np
[13:46:04 CDT(-0500)] <colinclark> hey michelled
[13:46:09 CDT(-0500)] <colinclark> Can you take on a code review for me?
[13:46:12 CDT(-0500)] <colinclark> Welcome back 
[13:46:17 CDT(-0500)] <michelled> thanks
[13:46:24 CDT(-0500)] <michelled> yes, I'd be happy to do some code review
[13:46:27 CDT(-0500)] <colinclark> https://github.com/fluid-project/infusion/pull/167/commits
[13:46:31 CDT(-0500)] <colinclark> Justin_o has looked at it
[13:46:34 CDT(-0500)] <colinclark> wanted another pair of eyes
[13:46:41 CDT(-0500)] <michelled> ok, I'll take a look
[13:54:22 CDT(-0500)] <colinclark> huslage: how's it going, dude?
[13:54:36 CDT(-0500)] <huslage> feeling like crap
[13:58:35 CDT(-0500)] <colinclark> huslage: That sucks. Do you have a cold?
[13:59:50 CDT(-0500)] <colinclark> hey cindyli can I bug you for a sec with a few quick questions?
[14:00:04 CDT(-0500)] <cindyli> sure, colinclark
[14:00:45 CDT(-0500)] <colinclark> I'm just having a look at FLUID-4445
[14:00:54 CDT(-0500)] <colinclark> I'm embarrassed to admit I've been a little out of the loop
[14:00:58 CDT(-0500)] <colinclark> I don't fully understand the problem
[14:01:00 CDT(-0500)] <colinclark> I see your code
[14:01:02 CDT(-0500)] <colinclark> and see what it's doing
[14:01:05 CDT(-0500)] <colinclark> and it's all cool
[14:01:11 CDT(-0500)] <colinclark> but I think I'm missing some of the history
[14:01:27 CDT(-0500)] <colinclark> So it looks like the problem was that we were boiling and binding event listeners from the Image Gallery to the Uploader...
[14:01:41 CDT(-0500)] <colinclark> but it was doing so even when a single file uploader was present
[14:01:47 CDT(-0500)] <colinclark> when it's only necessary for the multi
[14:01:48 CDT(-0500)] <cindyli> exactly
[14:01:52 CDT(-0500)] <colinclark> My question is simple...
[14:01:59 CDT(-0500)] <colinclark> In practice, what's wrong with doing it for every case?
[14:02:03 CDT(-0500)] <colinclark> Does it cause errors or something?
[14:02:29 CDT(-0500)] <cindyli> yes, ie throws error when flash is uninstalled but js is enabled
[14:02:40 CDT(-0500)] <colinclark> Ah, okay
[14:02:40 CDT(-0500)] <cindyli> in which case, the single uploader is returned
[14:02:45 CDT(-0500)] <colinclark> That's interesting to me
[14:03:05 CDT(-0500)] <cindyli> imageUploader tries to bind the events which are not available
[14:03:37 CDT(-0500)] <colinclark> Bosmon: This is sort of an interesting problem
[14:03:48 CDT(-0500)] <colinclark> I think cindyli's fix looks fine
[14:04:11 CDT(-0500)] <colinclark> but the larger issue of IoC resolving something that doesn't fully match the signature of "an Uploader" is curious
[14:04:18 CDT(-0500)] <colinclark> Is it a design problem in the Uploader itself?
[14:04:28 CDT(-0500)] <colinclark> Something the framework should handle?
[14:04:30 CDT(-0500)] <Bosmon> Let me have a look at the pull request
[14:04:58 CDT(-0500)] <colinclark> I think that cindyli's fix would be a harder issue if we expected users to further override the Image Gallery's options
[14:05:05 CDT(-0500)] <colinclark> which isn't an issue since this is just a demo
[14:05:30 CDT(-0500)] <Bosmon> Oh, there isn't one
[14:05:47 CDT(-0500)] <colinclark> Isn't one what?
[14:05:48 CDT(-0500)] <Bosmon> Can you get me up to speed? I've read the log here but I can't quite grasp the issue yet
[14:05:50 CDT(-0500)] <colinclark> There is
[14:05:55 CDT(-0500)] <colinclark> sorry, it's in the Image Gallery
[14:05:58 CDT(-0500)] <colinclark> I'll send you a link
[14:06:06 CDT(-0500)] <colinclark> https://github.com/cindyli/image-gallery/commit/beeab5e96c7da56d895dbe74bf8f3916c9e38b1e
[14:06:16 CDT(-0500)] <colinclark> You can see half of the fix is just cleaning up from my sloppy mistakes
[14:06:20 CDT(-0500)] <colinclark> when I renamed something
[14:06:48 CDT(-0500)] <colinclark> But the key are these demands blocks at the bottom
[14:07:13 CDT(-0500)] <colinclark> which cindyli rightfully created to ensure that certain options are passed only in the context of a fancy uploader
[14:08:44 CDT(-0500)] <Bosmon> Oh dear...
[14:08:58 CDT(-0500)] <Bosmon> Well, yes, this is just the kind of issue that the framework rewrite is intended to fix ...
[14:09:17 CDT(-0500)] <Bosmon> Firstly... I guess what she has written actually works?
[14:09:45 CDT(-0500)] <colinclark> I'm sure it does
[14:09:55 CDT(-0500)] <colinclark> cindyli is great, but I'll test it just to be super sure
[14:09:58 CDT(-0500)] <Bosmon> The fact that every use of a demands block uses up your one and only allocation of a demands block to use in that situation is a kind of fatal problem with the framework
[14:10:00 CDT(-0500)] <colinclark> the King demands it
[14:10:09 CDT(-0500)] <colinclark> Bosmon: Yes, exactly
[14:10:23 CDT(-0500)] <colinclark> So one could never override this without some further specificity race
[14:10:30 CDT(-0500)] <colinclark> Which we needn't worry about in this concrete case
[14:10:32 CDT(-0500)] <Bosmon> And you are right to worry that this has reduced the potential for users to "re-customise" the uploader once it has already been customised by image gallery
[14:10:36 CDT(-0500)] <colinclark> yes
[14:10:41 CDT(-0500)] <Bosmon> But there isn't really much we can do about that problem right now
[14:10:52 CDT(-0500)] <colinclark> So, is there a design problem in some way with the Uploader?
[14:10:52 CDT(-0500)] <Bosmon> It's not really a problem in the design of the uploader, but a problem in the design of IoC
[14:10:57 CDT(-0500)] <colinclark> okay
[14:11:05 CDT(-0500)] <Bosmon> Not one that we can do much about
[14:11:20 CDT(-0500)] <Bosmon> It uses the awful "alias" system too which only adds confusion into the mix
[14:11:20 CDT(-0500)] <colinclark> So we should assume that the framework can handle the cases where the semantics of a component vary in certain ways from another which may be resolved
[14:11:26 CDT(-0500)] <colinclark> right
[14:11:33 CDT(-0500)] <Bosmon> If cindyli's fix addresses the immediate issue, we should just commit it and move on
[14:11:55 CDT(-0500)] <colinclark> great
[14:12:00 CDT(-0500)] <colinclark> cindyli: thanks so much
[14:12:05 CDT(-0500)] <cindyli> np, colinclark
[14:12:12 CDT(-0500)] <colinclark> the only thing I see in the pull request is the capitalization of the EventOpts variable
[14:12:16 CDT(-0500)] <colinclark> which is exceedingly trivial
[14:12:21 CDT(-0500)] <colinclark> and which I will tidy up for you
[14:12:21 CDT(-0500)] <cindyli> ya, right
[14:12:28 CDT(-0500)] <cindyli> cool. thanks
[14:12:32 CDT(-0500)] <colinclark> it's the least I can do seeing that this pull request is half tidying up from me
[14:12:43 CDT(-0500)] <colinclark> I'll test it now that my shiny new laptop is running PHP again
[14:12:47 CDT(-0500)] <colinclark> and then we'll get it in
[14:12:54 CDT(-0500)] <cindyli> great
[14:13:32 CDT(-0500)] <colinclark> Bosmon: Thanks for your thoughts
[14:15:01 CDT(-0500)] <colinclark> Is it worth kicking up the conversation about cindyli's research for FLUID-4461 here?
[14:15:09 CDT(-0500)] <colinclark> She's clearly learned an awful lot
[14:15:16 CDT(-0500)] <Bosmon> Yes, it is interesting
[14:15:30 CDT(-0500)] <colinclark> and was proposing on the list to just use pixels instead of ems
[14:15:35 CDT(-0500)] <cindyli> ah ha, i'm typing up in the channel regarding it
[14:15:39 CDT(-0500)] <Bosmon> I guess we don't yet have a concrete set of reasoning and calculation as to exactly WHY IE9 returns this value?
[14:15:39 CDT(-0500)] <colinclark> lol
[14:15:42 CDT(-0500)] <cindyli> thanks for bringing it up , colinclark
[14:15:45 CDT(-0500)] <colinclark> sorry cindyli, I stole your thunder
[14:15:54 CDT(-0500)] <cindyli> u r welcome
[14:16:18 CDT(-0500)] <colinclark> Bosmon: I guess there's the second issue of browser changes to em sizes, even in Firefox
[14:16:34 CDT(-0500)] <Bosmon> Which issue is that?
[14:16:42 CDT(-0500)] <colinclark> Did you see her second email to the list?
[14:16:49 CDT(-0500)] <colinclark> "It turns out that it's because I explicitly set the default font size in my ff6 to 24px, which overwrites the original default "16px" and turns 1em === 24px."
[14:17:00 CDT(-0500)] <Bosmon> Yes
[14:17:02 CDT(-0500)] <Bosmon> I did see that
[14:17:06 CDT(-0500)] <colinclark> ok
[14:17:18 CDT(-0500)] <Bosmon> But I'm not sure I grasp why this leads to such a small error
[14:17:18 CDT(-0500)] <colinclark> I'm really too far out of the loop to have any recommendations
[14:17:29 CDT(-0500)] <Bosmon> I mean, that is a change of around 50%
[14:19:01 CDT(-0500)] <Bosmon> Whereas the resulting error is only about 7%
[14:19:28 CDT(-0500)] <cindyli> Bosmon: "a change of 50%"? what r u referring to?
[14:19:41 CDT(-0500)] <Bosmon> Based on colinclark's quotation just there
[14:19:54 CDT(-0500)] <Bosmon> If the original default is 16px and you adjust it to 24px
[14:19:58 CDT(-0500)] <Bosmon> That is an increase of 50%
[14:20:03 CDT(-0500)] <cindyli> right
[14:20:13 CDT(-0500)] <Bosmon> I guess a crucial figure is the one you quote in your most recent email of "0.625 em"
[14:20:46 CDT(-0500)] <cindyli> ok, that's calcualted based on 16px factor
[14:21:36 CDT(-0500)] <Bosmon> Painful though it is, I guess it would be better to try to understand this issue in detail, rather than just launching fullscale into a conversion back into px again : P
[14:21:58 CDT(-0500)] <cindyli> well, it's a separate issue that if adjusting the default font size from 16px to 24px, much more uienhancer unit tests would fail
[14:22:09 CDT(-0500)] <cindyli> i agree, Bosmon
[14:22:55 CDT(-0500)] <cindyli> what i'm trying to make clear in the email is that the px to em factor is quite browser dependent
[14:23:08 CDT(-0500)] <Bosmon> Yes
[14:23:14 CDT(-0500)] <Bosmon> The guides suggested that it was...
[14:23:28 CDT(-0500)] <Bosmon> The question is, why does only IE9 operate this factor differently to all the other browsers?
[14:23:32 CDT(-0500)] <Bosmon> And... what factor does it use?
[14:23:49 CDT(-0500)] <Bosmon> The "px to em" guide page suggested that it was actually on MacOS we could expect the biggest variance in this factor
[14:23:53 CDT(-0500)] <Bosmon> But it seems we have no problem there
[14:24:21 CDT(-0500)] <cindyli> umm. good question, haven't found the answer with ie9 yet
[14:25:29 CDT(-0500)] <Bosmon> cindyli - do you have a calculation that leads to the number "9.93px"?
[14:25:44 CDT(-0500)] <Bosmon> It doesn't matter if we don't understand it... can we even make the numbers come out to that value somehow?
[14:26:34 CDT(-0500)] <colinclark> cindyli: Sorry to distract you from this conversation… one more dumb question. To test your fix, I'll need to test with Flash not installed but JavaScript enabled, correct?
[14:26:46 CDT(-0500)] <cindyli> yes, colinclark
[14:26:58 CDT(-0500)] <colinclark> It's a delight to get to remove Flash from my system
[14:27:49 CDT(-0500)] <cindyli> Bosmon: running uiEnhancer test in ie9 will make out that value. maybe i misundertand you?
[14:28:12 CDT(-0500)] <Bosmon> cindyli - yes
[14:28:18 CDT(-0500)] <Bosmon> I mean - how can we calculate this number?
[14:28:33 CDT(-0500)] <Bosmon> Can you find some sequence of numbers to add and multiply that come out to "9.93px"?
[14:28:48 CDT(-0500)] <cindyli> oh, ic
[14:32:18 CDT(-0500)] <cindyli> Bosmon: 15.888 * 0.625em = 9.93px
[14:32:34 CDT(-0500)] <cindyli> if ie9 detects 15.888 as default font size
[14:32:43 CDT(-0500)] <cindyli> the next question is where 15.888 comes from
[14:32:47 CDT(-0500)] <anastasiac> Justin_o, I just filed a JIRA for Inline Edit: tooltip not showing in Chrome on Win XP. http://issues.fluidproject.org/browse/FLUID-4463
[14:35:00 CDT(-0500)] <Justin_o> anastasiac: thanks, i don't think it's a blocker, but it is pretty wierd
[14:35:07 CDT(-0500)] <anastasiac> yes, odd
[14:35:58 CDT(-0500)] <colinclark> cindyli: I'll test in IE next, but just in case you're curious, your Image Gallery fix works great in Firefox 2 without Flash installed
[14:36:15 CDT(-0500)] <cindyli> cool
[14:36:15 CDT(-0500)] <colinclark> I guess with 8 Gb of RAM, I shouldn't be so hesitant to start up a VM
[14:36:27 CDT(-0500)] <colinclark> Given that Justin_o seems to run 8 of them at once
[14:36:27 CDT(-0500)] <cindyli> agree
[14:36:36 CDT(-0500)] <Bosmon> hahaha
[14:36:44 CDT(-0500)] <Bosmon> I am thinking I will need to step up to 12 GB or something....
[14:36:51 CDT(-0500)] <Bosmon> Yes, cindyli - any ideas about 15.888?
[14:36:54 CDT(-0500)] <Bosmon> It is an extremely strange figure
[14:37:16 CDT(-0500)] <cindyli> not yet. i looked into ie9 css stack, nothing weird
[14:37:25 CDT(-0500)] <colinclark> Bosmon: Justin_o has set us up a Mac Pro with 8 cores and 24 Gb of memory. It's job is to constantly run against TestSwarm with VMs for all our supported environments
[14:37:29 CDT(-0500)] <colinclark> it's quite amazing
[14:38:01 CDT(-0500)] <Bosmon> Are we running TestSwarm continuously now?
[14:39:08 CDT(-0500)] <colinclark> I think so, yes
[14:39:13 CDT(-0500)] <Justin_o> Bosmon: trying to
[14:39:25 CDT(-0500)] <Justin_o> http://swarm.fluidproject.org/user/fluid/
[14:39:36 CDT(-0500)] <Justin_o> although my ie's keep dying
[14:39:51 CDT(-0500)] <colinclark> Justin_o is starving them of memory
[14:39:57 CDT(-0500)] <colinclark> He is a Digital Environmentalist
[14:39:59 CDT(-0500)] <colinclark> which is wicked
[14:40:02 CDT(-0500)] <colinclark> but in this case funny
[14:40:31 CDT(-0500)] <colinclark> Somehow this graph seems sort of uninspiring… no greens
[14:41:04 CDT(-0500)] <Bosmon> Seems pretty odd to me
[14:41:08 CDT(-0500)] <cindyli> Bosmon: even if we figured out the ie9 strange behaviour, it would still be a problem that the user's own browser preference setting will change the conversion factor which UIO won't work porperly
[14:41:08 CDT(-0500)] <Bosmon> We have nothing that passes?
[14:41:10 CDT(-0500)] <Bosmon> What does black represent
[14:41:18 CDT(-0500)] <colinclark> evil?
[14:41:22 CDT(-0500)] <Bosmon> cindyli - can you demonstrate that?
[14:41:23 CDT(-0500)] <colinclark> nap time?
[14:41:55 CDT(-0500)] <cindyli> sure, Bosmon, can you adjust your firefox setting to change the font size
[14:42:15 CDT(-0500)] <cindyli> to a number that is not 16px
[14:42:26 CDT(-0500)] <Bosmon> hmm
[14:42:31 CDT(-0500)] <cindyli> then run uienhancer unit test
[14:42:42 CDT(-0500)] <Bosmon> So 15.888 might just result from an attempt to "zoom" the browser?
[14:42:49 CDT(-0500)] <cindyli> i didn't zoom
[14:42:56 CDT(-0500)] <cindyli> ie9 assumes?!
[14:42:57 CDT(-0500)] <Bosmon> ok well
[14:43:27 CDT(-0500)] <Bosmon> I guess we need to draw out some kind of "workflow" of the browser's calculations
[14:43:40 CDT(-0500)] <Bosmon> Can we detect original font size?
[14:43:58 CDT(-0500)] <Bosmon> Can this "15.888" figure be detected directly?
[14:44:07 CDT(-0500)] <cindyli> no
[14:44:13 CDT(-0500)] <cindyli> well
[14:44:18 CDT(-0500)] <cindyli> we can detect original font size
[14:44:21 CDT(-0500)] <cindyli> but it's always in px
[14:44:37 CDT(-0500)] <cindyli> haven't found out where 15.888 is from
[14:45:17 CDT(-0500)] <Bosmon> Well, it sounds like we just need to add an extra factor into the mix, of "16 / original font size"
[14:45:25 CDT(-0500)] <Bosmon> Assuming we understand where to put it in our calculation
[14:45:26 CDT(-0500)] <cindyli> tried
[14:45:51 CDT(-0500)] <cindyli> the closest thread is: http://stackoverflow.com/questions/739940/detect-browser-font-size
[14:46:23 CDT(-0500)] <cindyli> seems there's no a direct property to retrieve the original font size from
[14:46:42 CDT(-0500)] <cindyli> but some scripting might help:
[14:46:44 CDT(-0500)] <cindyli> var measure= document.createElement('div');
[14:46:44 CDT(-0500)] <cindyli> measure.style.height= '10em';
[14:46:44 CDT(-0500)] <cindyli> document.body.appendChild(measure);
[14:46:44 CDT(-0500)] <cindyli> var size= measure.offsetHeight/10;
[14:46:44 CDT(-0500)] <cindyli> document.body.removeChild(measure);
[14:46:49 CDT(-0500)] <cindyli> it looks pretty hacky tho
[14:46:59 CDT(-0500)] <Bosmon> Ouch
[14:47:02 CDT(-0500)] <Bosmon> AWful...
[14:47:07 CDT(-0500)] <cindyli> haha
[14:47:09 CDT(-0500)] <Bosmon> Just the kind of thing that Alex Russell complains about
[14:47:32 CDT(-0500)] <Bosmon> BUT
[14:47:40 CDT(-0500)] <Bosmon> Perhaps what we should do it just put this code in our test case
[14:47:50 CDT(-0500)] <Bosmon> Since really what we are interested in is being able to predict the numerical effect
[14:47:56 CDT(-0500)] <colinclark> For those who don't know Bosmon, Alex Russell works on the Chrome team, and wrote Dojo http://infrequently.org/
[14:47:58 CDT(-0500)] <Bosmon> And therefore, detect variations from it
[14:48:04 CDT(-0500)] <cindyli> i see
[14:48:23 CDT(-0500)] <colinclark> sorry
[14:48:25 CDT(-0500)] <Bosmon> Perhaps we are actually happy with the practical effect of UIO?
[14:48:26 CDT(-0500)] <colinclark> everyone knows Bosmon
[14:48:30 CDT(-0500)] <colinclark> but they might not know his reference
[14:48:35 CDT(-0500)] <Bosmon> In that it has an effect which is proportional to the base font size?
[14:48:40 CDT(-0500)] <Bosmon> Do we think we are happy with it?
[14:49:11 CDT(-0500)] <cindyli> well, Bosmon, i could try this code with test case later
[14:50:10 CDT(-0500)] <cindyli> but unless we can detect the factor by our own code
[14:50:27 CDT(-0500)] <Bosmon> Well, that code you pasted is I think appropriate to appear in a test case
[14:50:35 CDT(-0500)] <Bosmon> Even if we don't think it is appropriate for the implementation code
[14:50:44 CDT(-0500)] <cindyli> exactly, understand
[14:51:17 CDT(-0500)] <cindyli> Bosmon: since now we know that the original font size is super browser dependent
[14:51:28 CDT(-0500)] <cindyli> we should get rid of px2emFactor
[14:51:39 CDT(-0500)] <cindyli> which doesn't help
[14:51:46 CDT(-0500)] <heidI_> Justin_o fyi http://issues.fluidproject.org/browse/FLUID-4465 re: i.e. 6 and progress tabbing to link
[14:52:28 CDT(-0500)] <Justin_o> colinclark, Bosmon: here's the results from one of the commits http://swarm.fluidproject.org/job/592/
[14:52:44 CDT(-0500)] <cindyli> if we decided to do the conversion, the factor should be detected by our own script. what do u think, Bosmon
[14:52:51 CDT(-0500)] <Bosmon> cindyli - yes
[14:52:57 CDT(-0500)] <Bosmon> Well
[14:52:57 CDT(-0500)] <colinclark> So the black errors are your IE VMs starving from only have 512 MB of RAM, Justin_o?
[14:53:13 CDT(-0500)] <colinclark> The errors, are they related to test naming problems? Or legitimate failures
[14:53:17 CDT(-0500)] <Bosmon> How is it that the px2emFactor doesn't help?
[14:53:21 CDT(-0500)] <Justin_o> they should be fully fed now.. i bumped them up to 2GB of ram each
[14:53:23 CDT(-0500)] <Bosmon> It may not actually represent what it MEANS
[14:53:37 CDT(-0500)] <Bosmon> But presumably our overall calculation is one that we approve
[14:53:42 CDT(-0500)] <Bosmon> Or is it truly irrelevant?
[14:53:53 CDT(-0500)] <cindyli> it's somewhat irrelevant
[14:53:57 CDT(-0500)] <cindyli> ok, example
[14:54:01 CDT(-0500)] <Bosmon> The "px2EmFactor" represents a conversion factor of pixels to ems assuming that the base font size is 16px
[14:54:16 CDT(-0500)] <cindyli> a integrator implements a page by using default factor 16px
[14:54:24 CDT(-0500)] <Bosmon> Which COULD be nonetheless something with a kind of stable meaning, even if it doesn't actually represent a real px to em conversion factor
[14:54:24 CDT(-0500)] <cindyli> this page is retrieved by different users
[14:54:40 CDT(-0500)] <Bosmon> The base question is whether the current behaviour of UIO is something that we want
[14:55:03 CDT(-0500)] <Bosmon> That is, for it to apply effects for texts which are relative to the user's specified base font size
[14:55:12 CDT(-0500)] <Bosmon> Or whether it should in some sense try to apply effects which are "absolute"
[14:55:23 CDT(-0500)] <Bosmon> I'm not quite sure which we want, but I am sort of leaning towards the former
[14:55:32 CDT(-0500)] <Bosmon> Anyone else with opinions on this, fluid-everyone ?
[14:55:49 CDT(-0500)] <colinclark> jameswy should probably make a call here
[14:56:28 CDT(-0500)] <Justin_o> colinclark: this is the test result from a FF run in the swarm.. it died on a fluid.fail message.. which you can see at the bottom
[14:56:28 CDT(-0500)] <Justin_o> http://swarm.fluidproject.org/?state=runresults&run_id=16972&client_id=518
[14:56:53 CDT(-0500)] <colinclark> right
[14:56:56 CDT(-0500)] <colinclark> so a real test failure
[14:57:01 CDT(-0500)] <Justin_o> possible
[14:57:12 CDT(-0500)] <Justin_o> but i'll run it in my ff now and see what happens
[14:57:26 CDT(-0500)] <jameswy> Bosmon: user = implementer/developer?
[14:57:41 CDT(-0500)] <Bosmon> jameswy - I think user is actually use in this case
[14:57:50 CDT(-0500)] <Bosmon> If I understand cindyli's explanation correctly
[14:58:03 CDT(-0500)] <Bosmon> The physical browser embodies a "base font size preference"
[14:58:16 CDT(-0500)] <Bosmon> And the results of UIO currently seem to be expressed relative to this preference
[14:58:37 CDT(-0500)] <jameswy> Bosmon: i.e., 1 em = 100% of the browser's base font size?
[14:58:44 CDT(-0500)] <Justin_o> colinclark: it passes fine on mine.. could have something to do with running in an iframe in the swarm
[14:59:26 CDT(-0500)] <Bosmon> I suspect this is probably too complex a conversation to finish before we get to release
[14:59:41 CDT(-0500)] <Bosmon> Even the phrase "1 em = 100% of the browser's base font size" is making my head spin : P
[15:00:36 CDT(-0500)] <cindyli> not really "1 em = 100% of the browser's base font size", jameswy
[15:00:49 CDT(-0500)] <cindyli> as i mentioned in my 2nd email
[15:01:03 CDT(-0500)]
[15:01:19 CDT(-0500)] <cindyli> 1 em = 90% of the browser's base font size
[15:02:59 CDT(-0500)] <jameswy> Bosmon, cindyli, fluid-everyone: the behaviour of text size effects in UIO should be relative to the implementer's default font size, whatever that may be; Bosmon, cindyli: are you saying that the implementer him/herself doesn't have real control over the default font size?
[15:03:16 CDT(-0500)] <jameswy> implementor* (or -er?)
[15:03:24 CDT(-0500)] <Bosmon> jameswy - who are you referring to now as the implementor?
[15:03:29 CDT(-0500)] <Bosmon> And how can they have a "default font size"?
[15:03:54 CDT(-0500)] <jameswy> Bosmon: implementer = the one who wrote up the styles
[15:04:10 CDT(-0500)] <Bosmon> Yes
[15:04:18 CDT(-0500)] <Bosmon> I'm not sure it seems they can really have one
[15:04:29 CDT(-0500)] <Bosmon> Given the owner of the browser can always have an idea of "default font size" which trumps them
[15:05:00 CDT(-0500)] <jameswy> heidI_: how much say do implementers have on the text size?
[15:08:25 CDT(-0500)] <heidI_> mm, text size in em would be relative to its container's text-size
[15:08:57 CDT(-0500)] <heidI_> if body's text size isn't set, then browser default is used
[15:09:40 CDT(-0500)] <jameswy> Bosmon, cindyli: Okay, so here's how I see proper behaviour being--let me know if this isn't possible:
[15:10:52 CDT(-0500)] <jameswy> Independent of UIO, the end-user is presented with content in some text size, whether it's based on the browser's base font size or an override from the implementer.
[15:10:59 CDT(-0500)] <heidI_> "An em is equal to the current font-size"
[15:11:45 CDT(-0500)] <jameswy> UIO's text effect should give a multiplier on that end-calculated font-size.
[15:12:03 CDT(-0500)] <Bosmon> jameswy - as I understand it now, that is roughly what is happening
[15:12:09 CDT(-0500)] <Bosmon> Does that seem right, cindyli?
[15:12:13 CDT(-0500)] <cindyli> yes
[15:12:19 CDT(-0500)] <Bosmon> The issue is just that when we write a test case, we are expecting a particular numerical value
[15:12:37 CDT(-0500)] <Bosmon> So this is lending further weight to the idea we should just "fix the test case"
[15:12:52 CDT(-0500)] <Bosmon> By adding a base browser font browser detection branch of the kind you got from the StackOverflow article
[15:13:48 CDT(-0500)] <heidI_> i think for unit tests yeah, set the container's font-size (ex 13px) and base calcs off that
[15:14:59 CDT(-0500)] <Bosmon> heidI_ - I think the issue in IE9 is that even if we were to try to set the font-size.... we will get given a different one
[15:15:10 CDT(-0500)] <Bosmon> Although we should have one final experiment with that
[15:15:47 CDT(-0500)] <Bosmon> But as far as cindyli can see right now, the value of "15.888px" appears to just come out of thin air
[15:16:31 CDT(-0500)] <Bosmon> And only in "pure mode" as opposed to its "compatibility rendering mode"
[15:16:38 CDT(-0500)] <Bosmon> THe IE developers are always trying to help us!
[15:16:42 CDT(-0500)] <Bosmon> Right up to the present day
[15:16:49 CDT(-0500)] <cindyli> hahaha
[15:17:05 CDT(-0500)] <Bosmon> As they said in a recent Dr. Who episode.... "This is a kindness!"
[15:17:17 CDT(-0500)] <cindyli> what a kindness...
[15:33:53 CDT(-0500)] <colinclark> For context...
[15:34:01 CDT(-0500)] <colinclark> the kindness was a needle delivered by insane robots
[15:34:07 CDT(-0500)] <Bosmon>
[15:34:10 CDT(-0500)] <Bosmon> Yes, it was
[15:34:14 CDT(-0500)] <colinclark> I guess they were fairly sane
[15:34:23 CDT(-0500)] <colinclark> they just were tasked with inoculating aliens
[15:34:50 CDT(-0500)] <Bosmon> I'm sure developers of IE appear sane to themselves
[15:34:57 CDT(-0500)] <colinclark> lol
[15:35:10 CDT(-0500)] <colinclark> I got to meet a lot of browser developers at the Open Video Conference
[15:35:14 CDT(-0500)] <colinclark> but none from IE
[15:35:29 CDT(-0500)] <colinclark> The guy from Opera was nice enough
[15:47:15 CDT(-0500)] <heidI_> Justin_o fyi http://issues.fluidproject.org/browse/FLUID-4466
[15:49:37 CDT(-0500)] <Justin_o> heidI_: thanks
[16:11:45 CDT(-0500)] <Justin_o> michelled: was there anything else that needed to be done for this http://issues.fluidproject.org/browse/FLUID-4219
[16:12:07 CDT(-0500)] <Justin_o> you had left a comment after merging in my pull request, and I'm wondering if that was done under a different jura somewhere
[16:12:28 CDT(-0500)] <michelled> Justin_o: yes, it was done in a different jira
[16:12:48 CDT(-0500)] <Justin_o> michelled: thanks.. i guess it wasn't actually my branch too
[16:12:59 CDT(-0500)] <michelled>
Unknown macro: {font-size}
Unknown macro: {font-size}
Manage space
Manage content
Integrations