[09:51:30 CDT(-0500)] <heidi_> Justin_o so it looks like the overflow property for the first layout is getting overridden <heidi_> Justin_o what do you think this style is for: .fl-layout-linear .fl-button-left, .fl-layout-linear .fl-button-right <heidi_> there's also .fl-layout-linear .fl-linearEnabled /* linearization opt in for special cases */ <Justin_o> heidi_: for: .fl-layout-linear .fl-button-left, .fl-layout-linear .fl-button-right
[09:52:12 CDT(-0500)] <heidi_> oh that's right, fl-linear is overriding it..hm
[09:52:13 CDT(-0500)] <Justin_o> heidi_: interesting
[09:52:27 CDT(-0500)] <heidi_> what do you think of the !important 's used here?
[09:52:35 CDT(-0500)] <Justin_o> ah right
[09:53:01 CDT(-0500)] <heidi_> i feel like this needs to be simplified somehow...
[09:53:50 CDT(-0500)] <Justin_o> heidi_: i figure the use of !important is the same as for the rest of the cases.. probably specifically for ui options
[09:54:01 CDT(-0500)] <Justin_o> michelled: do you know for sure?
[09:54:14 CDT(-0500)] <Justin_o> heidi_: are there other options there that you think we could remove?
[09:54:33 CDT(-0500)] <heidi_> Justin_o there are some other issues demonstrated here too... the width:100% is messing up absolute positioned stuff (horiz scrollabar)
[09:54:50 CDT(-0500)] <heidi_> feel like we should maybe start from scratch with the fl-layout-linear ...
[09:54:50 CDT(-0500)] <Justin_o> heidi_: i was wondering about that..
[09:55:19 CDT(-0500)] <Justin_o> heidi_: we could.. we should hunt around for fss docs to see if there is any reasonings there
[09:55:25 CDT(-0500)] <heidi_> ya
[09:56:04 CDT(-0500)] <michelled> Justin_o: It's probably for UI Options but I'm not certain
[09:57:31 CDT(-0500)] <heidi_> Justin_o without UIO i imagine this class would be used for implementing print or mobile layouts, or a11y. !important wouldn't be needed
[09:58:05 CDT(-0500)] <Justin_o> heidi_: that makes sense
[09:58:16 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/FSS+-+Layout#FSS-Layout-Linearization%3AWhyFSSLayoutexists%2Candhowtoundoeverything%5C%21
[09:58:51 CDT(-0500)] <Justin_o> anastasiac: do you know if there are other docs about FSS that might explain intentions and reasons for why things were implemented the way they were
[09:59:15 CDT(-0500)] <anastasiac> hm
[09:59:54 CDT(-0500)] <anastasiac> Justin_o, I don't know of any such thing in particular. Most of the FSS pages are linked in the sidebar on each FSS page, so if you don't see anything there, it probably doesn't exist
[10:00:11 CDT(-0500)] <Justin_o> anastasiac: thanks...
[10:00:35 CDT(-0500)] <heidi_> Justin_o that wiki page doesn't say much. i copied the example into our test page and it works fine
[10:01:57 CDT(-0500)] <anastasiac> Justin_o, try the "overriding fss" page - it has some motivations there
[10:02:44 CDT(-0500)] <Justin_o> anastasiac: thanks
[10:02:47 CDT(-0500)] <Justin_o> i'll take a look there
[10:03:28 CDT(-0500)] <Justin_o> heidi_: yah... not much... here's an interesting comment about fl-fix, seems it's not specifically for clearfix issues.. or maybe i'm just misreading the comment http://wiki.fluidproject.org/display/fluid/FSS+-+Advanced+Layout#FSS-AdvancedLayout-LayoutFix
[10:04:15 CDT(-0500)] <heidi_> Justin_o seems like a veiled disclaimer for scrollbar issue?
[10:05:52 CDT(-0500)] <heidi_> Justin_o we should also test linearizing reorderers
[10:06:38 CDT(-0500)] <Justin_o> heidi_: that should work
[10:06:52 CDT(-0500)] <Justin_o> but the keyboard nav would probably seem weird
[10:06:52 CDT(-0500)] <heidi_> yeah i think so, but prob good to add to test
[10:06:56 CDT(-0500)] <heidi_> ah
[10:07:28 CDT(-0500)] <Justin_o> you can get a feel for it with the uPortal mock-up.. there's a reorderer in one of the portlets, which can get quite narrow
[10:07:37 CDT(-0500)] <heidi_> Justin_o i think linearizing is such a powerful tool, be good to make sure it's really tight
[10:07:51 CDT(-0500)] <Justin_o> yes.. that's true
[10:07:57 CDT(-0500)] <heidi_> cool
[10:08:32 CDT(-0500)] <Justin_o> heidi_: what do you think should happen for the absolute positioned elements.. i guess the other part of that question would be what are the typical cases for using them...
[10:08:39 CDT(-0500)] <heidi_> Justin_o i'm gonna check out the clearfix stuff this afternoon too
[10:08:48 CDT(-0500)] <Justin_o> heidi_: thanks
[10:09:50 CDT(-0500)] <heidi_> Justin_o i think another q should be ... can we do anything for abs positioned stuff? should fl-linear also switch everything to position:relative or something? hm
[10:10:47 CDT(-0500)] <Justin_o> heidi_: that's sort of what i was wondering.. but i guess we'd need to know what people use them for and what effect changing it will have
[10:11:19 CDT(-0500)] <heidi_> Justin_o i think it'll be hard to narrow down when/why ppl use it
[10:11:43 CDT(-0500)] <Justin_o> heidi_: do you think it will be possible to come up with some common use cases
[10:11:59 CDT(-0500)] <Justin_o> i know we won't be able to think of everything
[10:12:08 CDT(-0500)] <heidi_> one really weird thing to play around with someday will be ...you know when a site has a fixed bar/menu that sticks even when scrolling the page?
[10:12:19 CDT(-0500)] <Justin_o> interesting
[10:12:38 CDT(-0500)] <Justin_o> that would suck if it filled up your whole screen and never got out of the way
[10:12:50 CDT(-0500)] <heidi_> common use cases would be good to do, at least for this linearizing example
[10:13:21 CDT(-0500)] <Justin_o> yes.. i think so.
[10:13:43 CDT(-0500)] <Justin_o> we should see if we can work these out somehow into some sort of test page that we can keep around
[10:13:46 CDT(-0500)] <heidi_> Justin_o i think we should create an ordered to-do list for approaching this
[10:14:05 CDT(-0500)] <heidi_> and figure out what exactly we want to test, and what our expected behaviours should be etc
[10:14:09 CDT(-0500)] <Justin_o> heidi_: you mean as a test example.. or to structure our work?
[10:14:14 CDT(-0500)] <heidi_> our work
[10:14:21 CDT(-0500)] <Justin_o> sure sounds good
[10:14:44 CDT(-0500)] <heidi_> maybe we should do the same approach for the clearfix issue as well
[10:14:57 CDT(-0500)] <heidi_> figure out how we can figure out a solution..
[10:15:10 CDT(-0500)] <Justin_o> heidi_: sure
[10:15:22 CDT(-0500)] <Justin_o> you want to try to hammer something out today?
[10:16:14 CDT(-0500)] <heidi_> Justin_o yeah i'll get started on linear, and maybe you can try clearfix and we can skype about it? does that make sense
[10:16:36 CDT(-0500)] <Justin_o> yep sure
[10:18:29 CDT(-0500)] <Justin_o> fluid-everyone: do you think we should start a space in the unit tests for our 3rd party tests.. hopefully this will encourage people to write tests as they come across them
[11:58:00 CDT(-0500)] <heidi_> Justin_o interesting question... if something is centred or aligned right... (ex. tabs), when linearized should they align left?
[11:58:42 CDT(-0500)] <Justin_o> heidi_: that's a good question...
[11:58:47 CDT(-0500)] <Justin_o> jameswy: any thoughts on that
[11:58:58 CDT(-0500)] <heidi_> i kinda pictured everything aligned left
[11:59:15 CDT(-0500)] <Justin_o> i would think centred would still look good centred
[11:59:22 CDT(-0500)] <Justin_o> not sure if aligning right would though
[11:59:38 CDT(-0500)] <heidi_> Justin_o can see the tab ex in the new linear test
[12:00:02 CDT(-0500)] <jameswy> heidi_, Justin_o: When something is linearized, I imagine that they all stick to a single alignment, whether it be all left or all center.
[12:00:30 CDT(-0500)] <heidi_> jameswy interesting, thanks
[12:00:42 CDT(-0500)] <Justin_o> jameswy: what are your thoughts about supporting other languagues
[12:00:49 CDT(-0500)] <Justin_o> ones that align to the right instead of the left
[12:01:10 CDT(-0500)] <Justin_o> which leads me to think we should just leave the alignment as is.. or provide an option to pick one or the other
[12:01:33 CDT(-0500)] <Justin_o> heidi_: do you have thoughts on that?
[12:01:58 CDT(-0500)] <heidi_> i think if i were to linearize a page, what i'm sort of after is one single column of stuff
[12:02:28 CDT(-0500)] <Justin_o> heidi_: so things don't zigzag across the screen
[12:02:30 CDT(-0500)] <heidi_> it'd be weird to have say tabs linearized, but still aligned to the right...
[12:03:22 CDT(-0500)] <heidi_> re: rtl languages.. i think jameswy's thoughts still apply: as long as the alignment is consistent. but it would make more sense to align right or center than left or center then
[12:07:36 CDT(-0500)] <Justin_o> heidi_: so what do you think about having something like .fl-linearize .fl-linearize-right .fl-linearize-left and fl-linearize-centre
[12:07:52 CDT(-0500)] <heidi_> Justin_o i think i like it
[12:08:04 CDT(-0500)] <heidi_> what does fl-linearize do?
[12:08:16 CDT(-0500)] <Justin_o> heidi_: that one won't force any particular alignment
[12:08:31 CDT(-0500)] <Justin_o> so it think we could re-work it to make the other three more composable
[12:08:58 CDT(-0500)] <Justin_o> so it might be ".fl-linearize .fl-right"
[12:09:00 CDT(-0500)] <Justin_o> or something like that
[12:09:34 CDT(-0500)] <heidi_> yeah
[12:11:03 CDT(-0500)]
[12:11:31 CDT(-0500)] <Justin_o> hmm... let me hunt around... i think i've seen the buttons before
[12:11:52 CDT(-0500)]
[12:12:10 CDT(-0500)] <heidi_> will search for linearEnabled .. not sure how that's different
[12:12:14 CDT(-0500)] <Justin_o> heidi_: yah i was looking at that one yesterday
[12:12:38 CDT(-0500)] <heidi_> Justin_o it's not used anywhere in webapp
[12:13:03 CDT(-0500)] <Justin_o> i'm not sure, i guess it adds the display block as well to force something in particular to be linearized
[12:14:15 CDT(-0500)] <Justin_o> heidi_: it looks like it's used in the ui options sakai integration demo
[12:14:31 CDT(-0500)] <Justin_o> http://build.fluidproject.org/infusion/integration-demos/sakai/html/ui-options-fss-sakai.html
[12:16:09 CDT(-0500)] <heidi_> hmmm
[12:16:57 CDT(-0500)] <heidi_> Justin_o when i remove it from that ex nothing happens
[12:18:11 CDT(-0500)] <Justin_o> hmm
[12:18:13 CDT(-0500)] <Justin_o> interesting
[12:22:42 CDT(-0500)]
[12:23:01 CDT(-0500)] <Justin_o> I think it might be so that the button is easier to view when linearized
[12:23:09 CDT(-0500)] <heidi_> like makes it bigger
[12:23:26 CDT(-0500)] <heidi_> that seems kinda weird still
[12:24:45 CDT(-0500)] <Justin_o> i think it makes it so the label is easier to read when the other parts may be so close areound it
[12:24:46 CDT(-0500)] <Justin_o> around
[12:25:16 CDT(-0500)] <heidi_> Justin_o what do you think about that?
[12:26:41 CDT(-0500)] <Justin_o> heidi_: i think it's a good idea to make key parts visually distinct.. whether this is the appropriate way to do that, I don't know
[12:26:49 CDT(-0500)] <Justin_o> i could be off base here too...
[12:28:16 CDT(-0500)] <Justin_o> it's interesting, the highcontrast theme seem to override this behaviour
[12:29:44 CDT(-0500)] <jamon> Justin_o: if you have a moment, mind checking http://swarm.fluidproject.org/JSLint/
[12:30:24 CDT(-0500)] <heidi_> Justin_o i would think an fl- class that makes things "easier to read" would be more useful, to apply to more than just linearized situations and/or make it optional
[12:30:28 CDT(-0500)] <Justin_o> jamon: sure, am checking now
[12:31:52 CDT(-0500)] <heidi_> Justin_o i think in general i prefer classes to not go above and beyond their expected task... the heavy-ish handed stuff kinda bugs me but there's prob an argument for it re: best practices etc
[12:32:08 CDT(-0500)] <Justin_o> jamon: looks good
[12:32:39 CDT(-0500)] <Justin_o> heidi_: interesting comment
[12:32:53 CDT(-0500)] <jamon> Justin_o: k thanks, i'll post to the list
[12:33:17 CDT(-0500)] <Justin_o> if we were writing javascript code then we wouldn't want something to be concerned with mutilple things
[12:33:34 CDT(-0500)] <Justin_o> jamon: thanks... hope you're enjoying your day off
[12:33:56 CDT(-0500)] <Justin_o> heidi_: so i could be wrong about the presentation aspect.. but i'm not sure
[12:34:20 CDT(-0500)] <Justin_o> although if it was a case were something became unreadable because of linearization, then i think i might want something that fixes that part of it by default
[12:34:31 CDT(-0500)] <Justin_o> i'm not convinced that this would fall into that case
[12:34:47 CDT(-0500)] <heidi_> Justin_o what do you think about separating it out to be a separate class that can be applied or not, and also used in non-linear situations
[12:35:24 CDT(-0500)] <Justin_o> heidi_: i suppose first we should try to figure out what exactly it's doing
[12:35:43 CDT(-0500)] <heidi_> Justin_o i'm not convinced linearizing makes buttons unreadable... it just seems like an extra assumption
[12:35:44 CDT(-0500)] <Justin_o> it does seem to mess up the themes when they are linearized and it's not on, but maybe it should just be part of the themes then
[12:36:12 CDT(-0500)] <heidi_> you're right about the js ideal of not combining too many functions together
[12:36:17 CDT(-0500)] <heidi_> hm
[12:36:40 CDT(-0500)] <heidi_> i'll check out linearizing a themed page..
[12:37:30 CDT(-0500)] <Justin_o> heidi_: so i think my vote would be: determine if they are in fact just meant to make themes look better, if so, move it into the themes instead
[12:38:33 CDT(-0500)] <heidi_> when i add fl-layout-linear to the theme demo page... i don't see any reason to affect the style of the buttons
[12:39:23 CDT(-0500)] <Justin_o> heidi_: if you linearize you can see that they look broken
[12:39:33 CDT(-0500)] <Justin_o> you can see this on the ui options sakai mock-up page
[12:39:47 CDT(-0500)] <Justin_o> that's if you remove the 1em padding
[12:40:35 CDT(-0500)] <heidi_> hm, it's fine for me on demos/fss/themes/html/themes.html
[12:40:42 CDT(-0500)] <heidi_> ill check sakai
[12:42:31 CDT(-0500)] <heidi_> Justin_o which buttons break/which browser?
[12:42:52 CDT(-0500)] <Justin_o> i tested in safari
[12:43:18 CDT(-0500)] <Justin_o> so they visually break because one part is bigger than the other
[12:45:32 CDT(-0500)] <heidi_> Justin_o i guess we should figure out what linear is doing to break them
[12:50:48 CDT(-0500)] <heidi_> it's the float:none
[12:51:32 CDT(-0500)] <Justin_o> heidi_: so why does 1em fix that..
[12:52:22 CDT(-0500)] <heidi_> Justin_o not sure... starting to feel like it's hacky
[12:52:49 CDT(-0500)] <Justin_o> heidi_: it does sound like that
[13:17:31 CDT(-0500)] <heidi_> Justin_o taking out the !important s in layout-linear changes things a lot... interesting
[13:17:56 CDT(-0500)] <heidi_> it actually seems to work better, make more sense, which is good
[13:18:09 CDT(-0500)] <heidi_> the col's that weren't linearizing before now do
[13:19:16 CDT(-0500)] <Justin_o> heidi_: that's seems very counter intuitive.. but it's good news
[13:19:24 CDT(-0500)] <heidi_> yeah i'm so confused ha
[13:46:22 CDT(-0500)] <Justin_o> heidi_: i'm just looking at your lastest linearization demo
[13:46:40 CDT(-0500)] <Justin_o> it's kind of funny how the flexible column goes from the middle to the bottom
[13:47:05 CDT(-0500)] <Justin_o> I'm wondering if this could totally mess up someones content
[13:47:51 CDT(-0500)] <heidi_> like the sequence of information? yeah
[13:48:18 CDT(-0500)] <Justin_o> heidi_: yes.. exactly
[13:48:20 CDT(-0500)] <heidi_> Justin_o it's hard to try to fix things but also keep in mind backwards compatibility
[13:48:30 CDT(-0500)] <Justin_o> heidi_: yes.. it's very difficult
[13:48:37 CDT(-0500)] <heidi_> like all those !importants DO something so can't just remove them
[13:48:46 CDT(-0500)] <heidi_> but they also shouldn't be there so..hm
[13:50:47 CDT(-0500)] <Justin_o> heidi_: i think the importants we could remove
[13:50:51 CDT(-0500)] <Justin_o> possibly
[13:51:19 CDT(-0500)] <heidi_> Justin_o yeah i guess, cos we'll fix it so that it'll still work without them (hopefully)
[13:51:44 CDT(-0500)] <Justin_o> 
yes
[13:53:49 CDT(-0500)] <heidi_> Justin_o also removing importants fixes the col's that aren't linearizing ha
[13:53:56 CDT(-0500)] <Justin_o> i think it should be doable... it won't break for people's sites unless they were expecting us to forcibly override their styles
[13:54:06 CDT(-0500)] <Justin_o> heidi_: bonus
[14:25:10 CDT(-0500)] <yura_> so Bosmon mlam and I hit an issue with infinite recursion when instantiating sibling components
[14:25:18 CDT(-0500)] <Bosmon> Yes
[14:25:22 CDT(-0500)] <yura_> one of them references something from the other
[14:25:30 CDT(-0500)] <Bosmon> We constantly work in the framework to make this kind of thing impossible
[14:25:32 CDT(-0500)] <yura_> and that prvokes the execution of the creator function
[14:25:37 CDT(-0500)] <Bosmon> But new cases keep creeping through
[14:25:58 CDT(-0500)] <Bosmon> If this is a true case cyclic reference, the instantiation should fail and terminate immediately with an error message
[14:26:08 CDT(-0500)] <Bosmon> But actually there is no test for that....
[14:26:17 CDT(-0500)] <Bosmon> So the behaviour may well have got lost in recent work
[14:26:22 CDT(-0500)] <Bosmon> Is the reference chain you have cyclic?
[14:27:01 CDT(-0500)] <yura_> well i remember getting an exception before
[14:27:05 CDT(-0500)] <yura_> this is a little different
[14:27:39 CDT(-0500)] <yura_> when it tries to expand an options it fires sibling's creator function, i havent seen that before
[14:32:37 CDT(-0500)] <yura_> Bosmon: so would you have recommendation regarding this? Would createOn... work flow be applicable here?
[15:28:14 CDT(-0500)] <Bosmon> Well, I'm not sure why Uploader performs any deferral at all
[15:28:23 CDT(-0500)] <Bosmon> Ideally the whole tree should construct synchronously
[15:28:43 CDT(-0500)] <Bosmon> But I'm not sure what your sibling situation is exactly
[15:28:46 CDT(-0500)] <Bosmon> Can you characterise it?
[15:36:34 CDT(-0500)] <Bosmon> yura_, mlam ^
[15:39:10 CDT(-0500)] <mlam> Bosmon, yura_ and I made some changes in a local branch . I'm not too familiar with all the IoC terminology yet, so would it be more helpful if i put this branch up on github?
[15:48:48 CDT(-0500)] <Bosmon> Yes, sure
[15:49:50 CDT(-0500)] <mlam> Bosmon: it's not complete, but we made some steps to adapt to the new framework changes
[15:49:54 CDT(-0500)] <mlam> posting now.
[15:50:54 CDT(-0500)] <mlam> https://github.com/mlam/infusion/commits/FLUID-4154
[15:51:21 CDT(-0500)] <mlam> ack, sorry, wrong URL: here's the correct one: https://github.com/mlam/infusion/tree/FLUID-4154
[16:11:27 CDT(-0500)] <Bosmon> Thanks, mlam - and is this the version which fails with an infinite recursion?
[16:11:35 CDT(-0500)] <mlam> Yes, it is
[16:11:43 CDT(-0500)] <Bosmon> Ok
[16:11:53 CDT(-0500)] <Bosmon> Does it occur in the test cases, or just when using a demo?
[16:12:02 CDT(-0500)] <mlam> when using the demo
[16:12:08 CDT(-0500)] <Bosmon> ok, cool
[16:12:12 CDT(-0500)] <Bosmon> I will have a look at it
[16:12:14 CDT(-0500)] <mlam> I didn't even look at the tests yet
[16:12:16 CDT(-0500)] <mlam> ok, thanks
[16:12:29 CDT(-0500)] <Bosmon> The tests seem to run more easily
[16:12:42 CDT(-0500)] <Bosmon> Since it looks like they are not trying to make the "progressive enhancement" workflow work
[16:12:53 CDT(-0500)] <Bosmon> They were certainly running when I left them last night 
[16:13:16 CDT(-0500)] <mlam>
[16:15:26 CDT(-0500)] <colinclark> They were running when I left them earlier last night
Unknown macro: {padding}
Unknown macro: {width}
Unknown macro: {padding}
Manage space
Manage content
Integrations