/
fluid-work IRC Logs-2008-08-05

fluid-work IRC Logs-2008-08-05

Aug 05, 2008

[02:25:24 EDT(-0400)] * ladybug (i=jabber@serafim.cd.chalmers.se) has joined #fluid-work
[03:31:44 EDT(-0400)] * yukiogukio (i=jabber@serafim.cd.chalmers.se) has left #fluid-work
[08:36:46 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:55:17 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[09:55:28 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:07:16 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[10:23:46 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:29:22 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[10:40:20 EDT(-0400)] * jacobfarber (i=opera@142.150.154.106) has joined #fluid-work
[10:42:11 EDT(-0400)] * jacobfarber (i=opera@142.150.154.106) has left #fluid-work
[10:42:21 EDT(-0400)] * jacobfarber (i=opera@142.150.154.106) has joined #fluid-work
[10:48:38 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:51:28 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[11:03:32 EDT(-0400)] <anastasiac> I have a comment about one of the recent changes to the Reorderer options names - michelled, colinclark, jacobfarber, anyone else - got a minute?
[11:03:42 EDT(-0400)] <colinclark> anastasiac: Of course.
[11:03:45 EDT(-0400)] <jacobfarber> yup!
[11:03:47 EDT(-0400)] <anastasiac> the 'role' option has been renames to 'containerRole' but I think that's a misnomer
[11:03:54 EDT(-0400)] <colinclark> anastasiac: Why?
[11:04:12 EDT(-0400)] <anastasiac> the role itself is actually an object that contains two roles, the role for the container and the role for the orderable items within the container
[11:04:34 EDT(-0400)] <anastasiac> so a container role of 'grid' has an item role of 'gridcell'
[11:04:36 EDT(-0400)] <anastasiac> etc
[11:04:42 EDT(-0400)] <anastasiac> am I being pedantic?
[11:05:24 EDT(-0400)] <colinclark> anastasiac: I suspect not.
[11:05:48 EDT(-0400)] <colinclark> "roles" might be a more appropriate name.
[11:06:07 EDT(-0400)] <colinclark> Hopefully Bosmon will be back soon and he can walk us through some of these changes.
[11:06:21 EDT(-0400)] <colinclark> I certainly don't want to get into a renaming war.
[11:06:35 EDT(-0400)] <colinclark> But in this case, I agree with you, anastasiac.
[11:06:51 EDT(-0400)] <anastasiac> it is true that the name of the object containing the two roles is based on the container role... so the grid/gridcell combination is called "fluid.roles.GRID" etc
[11:07:17 EDT(-0400)] <anastasiac> i.e. the choice of a container role basically dictates the item role for reorderer purposes
[11:07:26 EDT(-0400)] <colinclark> I thought we had moved away from using grid/gridcell...
[11:07:27 EDT(-0400)] <colinclark> ?
[11:07:33 EDT(-0400)] <anastasiac> well, not for grids
[11:07:45 EDT(-0400)] <colinclark> Is the Lightbox a grid?
[11:08:06 EDT(-0400)] <anastasiac> lightbox uses grid, the portlets use 'main' and 'article'
[11:08:11 EDT(-0400)] <colinclark> Am I mistaken in thinking that grids, in ARIA's world, should be interpreted as editable tables along the lines of a spreadsheet?
[11:08:13 EDT(-0400)] <anastasiac> and basic lists use 'list/listitem'
[11:08:32 EDT(-0400)] <anastasiac> ugh - maybe this will be a question for clown when he's in this afternoon
[11:08:39 EDT(-0400)] <davidb> anastasiac: hi
[11:08:47 EDT(-0400)] <davidb> yup clown is Mr Grid.
[11:08:47 EDT(-0400)] <anastasiac> hi, davidb
[11:08:52 EDT(-0400)] <anastasiac> the Grid Guru
[11:08:57 EDT(-0400)] <davidb> heh
[11:09:19 EDT(-0400)] <davidb> (i have a filter for "aria" so i got notified of your musing)
[11:09:37 EDT(-0400)] <anastasiac> handy - I have a similar filter for 'fluid' in other rooms
[11:10:04 EDT(-0400)] <colinclark> me too
[11:15:23 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:27:19 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has left #fluid-work
[11:31:00 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-135-247.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:01:57 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[12:01:57 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[12:01:57 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[12:02:22 EDT(-0400)] * theclown_afk (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[12:02:22 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[12:02:22 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[12:02:22 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-135-247.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:02:22 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[12:02:35 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[12:02:35 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:02:49 EDT(-0400)] <jacobfarber> ecochran: want to catch up about the css html stuff?
[12:02:56 EDT(-0400)] <Bosmon> Welcome back, splitters
[12:03:06 EDT(-0400)] <Bosmon> It's the People's Front of Judea....
[12:03:06 EDT(-0400)] <colinclark> split is over!
[12:03:29 EDT(-0400)] <anastasiac> hm... alternate reality...
[12:03:30 EDT(-0400)] <jacobfarber> im dizzy
[12:03:36 EDT(-0400)] <michelled> that was disconcerting
[12:03:38 EDT(-0400)] <colinclark> We're back!
[12:03:52 EDT(-0400)] <ecochran> jacobfarber: yes, in a bit... I haven't done much
[12:04:06 EDT(-0400)] <ecochran> colinclark: yes, that was strange
[12:04:35 EDT(-0400)] <Bosmon> So... the next destruction I was planning was to rename cssClasses (again!) to "styles" so that it agrees with the conventions we have in InlineEdit and Undo
[12:04:50 EDT(-0400)] <Bosmon> And also to scour around and find things scattered around the place we coud use the DOM binder on
[12:05:19 EDT(-0400)] * jhung (n=Administ@142.150.154.101) has joined #fluid-work
[12:05:29 EDT(-0400)] <colinclark> ecochran: Terminology is a funny thing...
[12:05:32 EDT(-0400)] <Bosmon> Since it looks the way the Reorderer "finds itself" is a bit "ad hoc" at the moment....
[12:05:54 EDT(-0400)] <jacobfarber> ecochran: any time
[12:06:02 EDT(-0400)] <colinclark> ecochran: Some ideas: sample markup, "starting points", "spring boards," etc.
[12:06:35 EDT(-0400)] <michelled> Boson: I wouldn't want to call them 'styles' until we do the split we were talking about for styling and state.
[12:06:36 EDT(-0400)] <colinclark> colinclark: Canonical implies that there is "one true markup," but I think in this case we know that these examples are built to be great but to be modified, changed, and adapted.
[12:06:43 EDT(-0400)] <Bosmon> This "findItems" monstrous must die...
[12:06:44 EDT(-0400)] <ecochran> canonical: accepted as being accurate and authoritative
[12:07:04 EDT(-0400)] <ecochran> or
[12:07:54 EDT(-0400)] <ecochran> laws
[12:08:20 EDT(-0400)] <Bosmon> "According to the rules of canon, in canon form."
[12:08:22 EDT(-0400)] <colinclark> ecochran: I think canonical markup should be reserved for solid templates. Until we're further along with the template renderer, the best we can give is great cut-and-paste style markup spring boards.
[12:08:28 EDT(-0400)] <michelled> how are you planning to kill "findItems"? I agree it's monstrous and predates the use of selectors everywhere.
[12:08:36 EDT(-0400)] <Bosmon> "(b) the hours (now from 8 a.m. to 3 p.m.) within which marriage can be legally performed in a parish church in England;"
[12:08:48 EDT(-0400)] <ecochran> colinclark: I think I'm struggling with what makes them different than the current examples
[12:08:57 EDT(-0400)] <ecochran> but sample markup will do
[12:10:35 EDT(-0400)] <colinclark> ecochran: The only thing that's different here is that will be a good one for each component. They will embody good markup, a basic and consistent look and feel, etc.
[12:11:09 EDT(-0400)] <colinclark> The point here is that we don't have any default markup or styles that ship with components like the LayoutCustomizer. So it becomes really hard to know where to start when faced with the sort examples we currently have.
[12:11:41 EDT(-0400)] <colinclark> Which are either too complex and visually specific (the uP3 example) or too simple to be useful (the super-minimal draggable squares)
[12:11:54 EDT(-0400)] <colinclark> ecochran, jacobfarber: Make sense?
[12:12:03 EDT(-0400)] <ecochran> colinclark: yes
[12:12:04 EDT(-0400)] <michelled> colinclark, ecochran, isn't the other different context? the samples we currently have try to context to the ocmponents where I think what we want for cut and paste templates are contextless.
[12:12:21 EDT(-0400)] <colinclark> michelled: yep, exactly.
[12:12:27 EDT(-0400)] <ecochran> michelled: yes, absolutely
[12:13:05 EDT(-0400)] <Bosmon> colinclark: It appears to me that everything currently in "cssClasses" is what in our current "standard" we call "styles"
[12:13:11 EDT(-0400)] <ecochran> I think that we will need to clearly distinguish all of our different "samples" so that folks who trip over them know what they are looking at
[12:13:19 EDT(-0400)] <Bosmon> Whereas, everything that is currently in "findItems" is what we would want to turn into "selectors"
[12:13:29 EDT(-0400)] <colinclark> Bosmon: michelled is probably better suited to confirming that.
[12:13:41 EDT(-0400)] <colinclark> But yes, my general sense is that the item finders idiom is a direct predecessor to the dom binder
[12:13:45 EDT(-0400)] <michelled> Bosmon, colinclark: the difference with the reorderer is that we look at those classes to determine the state of the component as well
[12:13:51 EDT(-0400)] <Bosmon> Oh
[12:14:03 EDT(-0400)] <michelled> colinclark, yes
[12:14:04 EDT(-0400)] <Bosmon> That is rather unfortunate
[12:14:13 EDT(-0400)] <Bosmon> Perhaps we should "modellise" this component too, whilst we are at it...
[12:14:23 EDT(-0400)] <michelled> that would be awesome!!!
[12:14:30 EDT(-0400)] <colinclark> Bosmon: You are feeling ambitious today.
[12:14:33 EDT(-0400)] <michelled> I've been wanting to rip it to shreds for months!
[12:14:56 EDT(-0400)] <michelled> One of the problems with major refactorings is that we don't have automated tests for mouse DnD
[12:15:02 EDT(-0400)] <colinclark> Bosmon: Could we have a brief terminology conversation while you're here?
[12:15:10 EDT(-0400)] <Bosmon> michelled: So I discovered
[12:15:15 EDT(-0400)] <Bosmon> Is there any chance we can create any?
[12:15:18 EDT(-0400)] <michelled> Justin_o is looking into writing some
[12:15:40 EDT(-0400)] <michelled> Actually, I think we can write some unit tests now that we're using jqUnit
[12:15:44 EDT(-0400)] <colinclark> It's a really hard problem. michelled struggled to find reliable ways to do in-browser mouse synthesis
[12:15:47 EDT(-0400)] <ecochran> colinclark: in the wiki, should this go under Component Development, or Development Resources?
[12:15:51 EDT(-0400)] <Bosmon> colinclark: ecochran asked me about "blat" only the other day
[12:15:51 EDT(-0400)] <michelled> It was close to impossible (perhaps impossible) with jsUnit
[12:15:59 EDT(-0400)] <Bosmon> But we think it could be possible now?
[12:16:01 EDT(-0400)] <colinclark> jsUnit was awful.
[12:16:02 EDT(-0400)] <ecochran> seems like Component Developement
[12:16:07 EDT(-0400)] <colinclark> ecochran: Let me check, one sec.
[12:16:17 EDT(-0400)] <Bosmon> How do we synthesise a "drag" event.... I guess it could only be "partially realistic"
[12:16:37 EDT(-0400)] <Bosmon> I mean, we aren't going to get a whole bunch of intercalated "mouseover/mouseleave" events as the thing waves around
[12:16:49 EDT(-0400)] <Bosmon> But hopefully at least it could prevent howlers of the sort I made last night....
[12:17:12 EDT(-0400)] <michelled> well, we have some hope with Selenium and WindMill for end to end DnD testing.
[12:17:23 EDT(-0400)] <colinclark> ecochran: Resources are links to useful information. Component Development is appropriate. The whole Development page is thoroughly out of date, but this is a great use of the Component Development header.
[12:17:24 EDT(-0400)] <michelled> Not sure how far along Justin_o is
[12:17:47 EDT(-0400)] <ecochran> colinclark: cool
[12:18:31 EDT(-0400)] <colinclark> Bosmon: I have a couple of questions. Do you have a second?
[12:18:34 EDT(-0400)] <michelled> as for unit tests - I was hoping we could at least test bits of the functionality. We can simulate events using jQuery simulate. It's not fool proof but I have hope.
[12:19:04 EDT(-0400)] <colinclark> Bosmon: fluid.utils.computeAbsolutePosition(). Is it actually used anywhere?
[12:19:14 EDT(-0400)] <Bosmon> colinclark: Not currently
[12:19:23 EDT(-0400)] <Bosmon> I was imagining it might shortly become used in InlineEdit
[12:19:31 EDT(-0400)] <colinclark> How?
[12:19:36 EDT(-0400)] <Bosmon> Depending whether we adopt a strategy based on "occlusive warping"....
[12:20:01 EDT(-0400)] <colinclark> Bosmon: dude.
[12:20:15 EDT(-0400)] <colinclark> You will have to translate.
[12:20:35 EDT(-0400)] <jacobfarber> you mean show whats behind it?
[12:20:58 EDT(-0400)] <colinclark> I mean, translate "occlusive warping."
[12:21:13 EDT(-0400)] <Bosmon> The idea that the inline edit component might simply "warp" to "cover up" whatever it is that is the "display" version of itself
[12:21:28 EDT(-0400)] <Bosmon> Allison and I are having a discussion about it on the "anti-seethe" JIRA
[12:21:39 EDT(-0400)] <colinclark> As for computeAbsolutePosition(). Reading it, I think curtop is sneaking in as a global declaration. Even if not, it's a little snarly.
[12:21:50 EDT(-0400)] <Bosmon> Ooh dear
[12:21:55 EDT(-0400)] <colinclark> Isn't this something that jQuery or jQuery UI might provide for us?
[12:22:17 EDT(-0400)] <Bosmon> I didn't seem to find one...
[12:22:56 EDT(-0400)] <colinclark> Bosmon: I also find the assignment within the do...while loop a bit confusing. On first glance, it looks like an error.
[12:23:02 EDT(-0400)] <michelled> do you have a JIRA number for the 'anti-seethe' JIRA?
[12:23:03 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-957
[12:23:15 EDT(-0400)] <michelled> thanks
[12:23:19 EDT(-0400)] <colinclark> Does it ultimately do a falsey check on element after the assignment?
[12:24:10 EDT(-0400)] <Bosmon> Yes
[12:24:24 EDT(-0400)] <Bosmon> We can easily "restyle" its idiom
[12:24:30 EDT(-0400)] <colinclark> Bosmon: Do you mind if I tidy it up a bit?
[12:24:31 EDT(-0400)] <Bosmon> Assuming we still think we might need it...
[12:24:43 EDT(-0400)] <Bosmon> Not in the least, I just cut and pasted it from quirks mode as is
[12:24:46 EDT(-0400)] <colinclark> Or shall we omit it until we are actually using it/
[12:24:47 EDT(-0400)] <colinclark> ?
[12:24:56 EDT(-0400)] <colinclark> What is the license on quirks mode examples, anyway?
[12:27:09 EDT(-0400)] <Bosmon> "You may
[12:27:10 EDT(-0400)] <Bosmon> You may copy, tweak, rewrite, sell or lease any code example on this site, with one single exception."
[12:27:18 EDT(-0400)] <Bosmon> I am not clear whether this constitutes a form of "licence"
[12:27:39 EDT(-0400)] <colinclark> A sort of informal one, it appears.
[12:29:36 EDT(-0400)] <colinclark> Bosmon: So terminology.
[12:29:40 EDT(-0400)] <Bosmon> Yes, that
[12:29:49 EDT(-0400)] <colinclark> I've been playing with ways to make the DOM binder clearer.
[12:30:02 EDT(-0400)] <colinclark> First, I'm thinking about initialiseThat().
[12:30:34 EDT(-0400)] <colinclark> I'd like to to treat units that are concerned with managing chunks of the DOM as "Views."
[12:31:16 EDT(-0400)] <colinclark> Partly, I feel like we should be careful about how we refer to "that," since it can be pretty abstract.
[12:31:24 EDT(-0400)] <Bosmon> Yes
[12:31:40 EDT(-0400)] <colinclark> So, in a sense the job of initialiseThat() is to produce a healthy, DOM-bound View unit.
[12:32:03 EDT(-0400)] <Bosmon> So, you plan to rename it "initialiseHealthyCatt"?
[12:32:12 EDT(-0400)] <colinclark> Could we simply treat it like a creator function... view()?
[12:32:16 EDT(-0400)] <colinclark> lol
[12:32:21 EDT(-0400)] <Bosmon> Glarg
[12:32:26 EDT(-0400)] <colinclark>
[12:32:31 EDT(-0400)] <colinclark> Your complaint?
[12:32:33 EDT(-0400)] <Bosmon> I hate your one-word ambiguously transitive names
[12:32:47 EDT(-0400)] <colinclark> bindView()?
[12:32:54 EDT(-0400)] <colinclark> setupView()?
[12:32:55 EDT(-0400)] <Bosmon> view().... does it cause a view? create one? view a view?
[12:33:05 EDT(-0400)] <colinclark> Yes, good point.
[12:33:20 EDT(-0400)] <colinclark> Do either of the above strike your fancy?
[12:33:24 EDT(-0400)] <Bosmon> Well, I was thinking you were going to suggest "initialiseView"
[12:33:48 EDT(-0400)] <Bosmon> "initView"
[12:34:01 EDT(-0400)] <colinclark> I'd go with initView().
[12:34:06 EDT(-0400)] <colinclark> Any other suggestions?
[12:34:20 EDT(-0400)] <Bosmon> We want to reinforce the idiom that this is something that is expected to be called very early, if not the very first line of the that method
[12:34:40 EDT(-0400)] <Bosmon> I discovered there was a bit of a wrinkle in "Undo"
[12:35:04 EDT(-0400)] <Bosmon> Since it cannot grab its container until it has properly discovered the other "that" you are trying to bind it to
[12:35:18 EDT(-0400)] <Bosmon> At the moment it somewhat unsatisfactorily accepts "null" as the container and expects you to fluid.container it later
[12:35:39 EDT(-0400)] <Bosmon> "initComponent"?
[12:35:48 EDT(-0400)] <ecochran> michelled: allison wants to IM you something but you are showing as away
[12:37:44 EDT(-0400)] <colinclark> Bosmon: My goal in emphasizing the concept of Views as distinct units is to encourage their use within the creation of a component.
[12:37:53 EDT(-0400)] <Bosmon> Ah
[12:37:58 EDT(-0400)] <colinclark> Our biggest architectural problem tends to be conceiving of a component as an atomic entity...
[12:38:04 EDT(-0400)] <colinclark> rather than as a composition of little view units.
[12:38:06 EDT(-0400)] <Bosmon> But is it not really the "model" whose use needs to be encouraged?
[12:38:19 EDT(-0400)] <colinclark> That too.
[12:38:28 EDT(-0400)] <Bosmon> Since the default strategy for constructing a component typically results in a "model-less mess", like initial InlineEdit or Reorderer
[12:38:29 EDT(-0400)] <colinclark> They're both essential.
[12:39:16 EDT(-0400)] <michelled> thanks ecochran - I was just at another machine
[12:39:18 EDT(-0400)] <Bosmon> Well right, so how does calling something a "View" encourage people to either i) create several views, or ii) create a model?
[12:39:32 EDT(-0400)] <Bosmon> All you are doing is give a name to the thing they are just going to create anyway
[12:39:56 EDT(-0400)] <Bosmon> I suppose it does mildly encourage them with ii)
[12:39:57 EDT(-0400)] <colinclark> Bosmon: Well, this initialiseThat() function is the sort of thing that should be called by each individual view...
[12:40:10 EDT(-0400)] <Bosmon> Yes, certainly initialiseThat() is a bad name
[12:40:16 EDT(-0400)] <Bosmon> If only because everything is a "that"
[12:40:18 EDT(-0400)] <colinclark> The components job is to initialize a set of views, connect them with the model, and do its thing.
[12:40:21 EDT(-0400)] <Bosmon> Including now, LayoutManagers, etc.
[12:40:24 EDT(-0400)] <colinclark> Bosmon: Yes, exactly.
[12:41:08 EDT(-0400)] <colinclark> Things that require being bound to the DOM should be considered as Views.
[12:41:12 EDT(-0400)] <Bosmon> I hate having to find names for things
[12:41:18 EDT(-0400)] <colinclark> And should be considered as things that aren't Models.
[12:41:32 EDT(-0400)] <colinclark> Naming is our biggest challenge over the next little while./
[12:41:39 EDT(-0400)] <colinclark> I'll go with initView() if you're cool with it.
[12:41:44 EDT(-0400)] <Bosmon> Naming has been our biggest challenge since the START OF TIME
[12:41:58 EDT(-0400)] <Bosmon> ok, go for initView
[12:42:12 EDT(-0400)] <colinclark> Cool.
[12:42:21 EDT(-0400)] <Bosmon> So, I am planning to destroy all this "findItem" malarky in place of the DOM binder
[12:42:23 EDT(-0400)] <colinclark> One more terminology question, but I have to make a phone call first.
[12:42:29 EDT(-0400)] <Bosmon> Do you see anything even slightly problematic about that?
[12:44:26 EDT(-0400)] <Bosmon> "Of or belonging to an ecclesiastical chapter, or to one of its members"
[12:44:34 EDT(-0400)] <Bosmon> "1881 FREEMAN Subj. Lands Venice, Parenzo, Among the canonical buildings on the south side of the church."
[12:45:22 EDT(-0400)] <ecochran> jacobfarber: more thinking about canonical CSS (sorry, I just love the word "canonical")
[12:45:36 EDT(-0400)] <colinclark> Bosmon: replacing the findItems approach with the DOM binder is a good idea.
[12:46:00 EDT(-0400)] <ecochran> in the past I have had trouble with browsers (IE6) with div.className.anotherClassName
[12:46:20 EDT(-0400)] <ecochran> have you have luck with that pattern?
[12:46:39 EDT(-0400)] <ecochran> makes is hard to do something like a.button.disabled
[12:46:45 EDT(-0400)] <jacobfarber> no, I dont think it would work (seeing how the "." is reserved)
[12:46:58 EDT(-0400)] <jacobfarber> does it actually work elsewhere?
[12:47:21 EDT(-0400)] <jacobfarber> I just use dashes (its recommdeded, I think, as a vendor-based approach)
[12:47:24 EDT(-0400)] <ecochran> it's just a way of saying element with class className and class anotherClassnme
[12:47:42 EDT(-0400)] <jacobfarber> oh, you mean " className className" ?
[12:47:54 EDT(-0400)] <jacobfarber> and then accessing it in the css file?
[12:48:01 EDT(-0400)] <ecochran> same as foo#id.className
[12:48:15 EDT(-0400)] <ecochran> which works
[12:48:35 EDT(-0400)] <jacobfarber> oh, so I havent seen a solution t odeclaring 2 or more different classnames in a single line
[12:48:45 EDT(-0400)] <jacobfarber> its a little paradoxical, in the end
[12:49:03 EDT(-0400)] <jacobfarber> like saying var a,b,c = "foo";
[12:49:09 EDT(-0400)] <Bosmon> div.class1.class2 is certainly part of the CSS standard
[12:49:15 EDT(-0400)] <Bosmon> It is dismal if IE can't operate it correctly
[12:49:19 EDT(-0400)] <ecochran> I'm just trying to figure out how <div class="button disabled"> would work
[12:49:31 EDT(-0400)] <jacobfarber> in the CSS file?
[12:49:37 EDT(-0400)] <jacobfarber> it would be somehting like
[12:49:45 EDT(-0400)] <jacobfarber> div.button, div.disabled
[12:49:47 EDT(-0400)] <jacobfarber> {}
[12:49:49 EDT(-0400)] <jacobfarber> right?
[12:50:06 EDT(-0400)] <Bosmon> Right but doesn't comma signify "union" rather than "intersection"?
[12:50:18 EDT(-0400)] <ecochran> no, because that would be div.button or div.disabled not div.button and .disabled
[12:50:26 EDT(-0400)] <Bosmon> Yes
[12:50:33 EDT(-0400)] <ecochran> Bosmon: I think that IE7 handles it
[12:50:36 EDT(-0400)] <ecochran> just not IE6
[12:50:39 EDT(-0400)] <Bosmon> Still no good
[12:50:46 EDT(-0400)] <Bosmon> IE6 will be with us TILL DOOMSDAY
[12:50:58 EDT(-0400)] <ecochran> BTW there is a growing movement to drop IE6
[12:51:04 EDT(-0400)] <Bosmon> Let it grow
[12:51:07 EDT(-0400)] <jacobfarber> at least facebook is pushing them off the earth
[12:51:21 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has left #fluid-work
[12:51:25 EDT(-0400)] <ecochran> Apple, 37 Signals have joined the cause
[12:52:01 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:52:02 EDT(-0400)] <jacobfarber> i still dont understand why IE just forces a replacement already through automatic updates.....
[12:52:05 EDT(-0400)] <Bosmon> Glarg
[12:52:08 EDT(-0400)] <Bosmon> did I leave just then?
[12:52:11 EDT(-0400)] <jacobfarber> yes
[12:52:12 EDT(-0400)] <ecochran> yes
[12:52:21 EDT(-0400)] <ecochran> I thought it was something I said
[12:52:32 EDT(-0400)] <Bosmon> So, we are needing to write intersections of CSS classes in style sheets
[12:52:43 EDT(-0400)] <Bosmon> And we are concerned that IE6 just doesn't support it at all...
[12:52:45 EDT(-0400)] <ecochran> that's our thought
[12:54:59 EDT(-0400)] <Bosmon> http://archivist.incutio.com/viewlist/css-discuss/35256
[12:55:14 EDT(-0400)] <Bosmon> It seems that we are doomed
[12:56:00 EDT(-0400)] <Bosmon> http://sonspring.com/index.php?id=102
[12:56:08 EDT(-0400)] <ecochran> I think that we're good as long as our patter is: elementName.stateClass but the minute we have to do elementName.selectorClass.stateClass our plan falls apart
[12:56:49 EDT(-0400)] <Bosmon> Well, there is a reason we are particularly careful to namespace the selectors we use for styling extremely thoroughly
[12:57:01 EDT(-0400)] <Bosmon> But unfortunately it seems to put paid largely to the purpose of the initial plan
[12:58:58 EDT(-0400)] <ecochran> "to put paid"?
[12:59:02 EDT(-0400)] <Bosmon> http://www.maxdesign.com.au/presentation/multiple-classes/
[12:59:04 EDT(-0400)] <Bosmon> To destroy
[12:59:06 EDT(-0400)] <Bosmon> Lay waste
[12:59:22 EDT(-0400)] <ecochran> ah, an English-ism which has escaped me
[12:59:30 EDT(-0400)] <jacobfarber> unfortunately, i think the only way to make this work is by re-designing declarations
[13:01:08 EDT(-0400)] <Bosmon> http://archive.gulfnews.com/indepth/uselections/more_stories/10209461.html
[13:01:31 EDT(-0400)] <jacobfarber> http://www.ryanbrill.com/archives/multiple-classes-in-ie/
[13:01:40 EDT(-0400)] <ecochran> Bosmon: you are a master googler
[13:02:55 EDT(-0400)] <ecochran> brb
[13:04:45 EDT(-0400)] <ecochran> back
[13:10:15 EDT(-0400)] <anastasiac> I think I've found an issue with our use of jQuery extend() in deep mode
[13:10:39 EDT(-0400)] <anastasiac> it seems that deep mode is inappropriate for how we want keysets to be handled
[13:11:13 EDT(-0400)] <anastasiac> we want user-supplied keysets to completely replace any defaults, but with extend() in deep mode, that's not what it does - it individually replaces and extends each keyset found in the array
[13:15:25 EDT(-0400)] <Bosmon> glarg
[13:15:37 EDT(-0400)] <colinclark> anastasiac: So the point here is that some things within the options list shouldn't be deep copied, while others should.
[13:15:41 EDT(-0400)] <colinclark> And we have no way of identifying this.
[13:15:54 EDT(-0400)] <anastasiac> that's right
[13:15:59 EDT(-0400)] <Bosmon> Today is a bad day
[13:16:08 EDT(-0400)] <anastasiac> for the css classes, for example, the deep extend is exactly what we want
[13:16:28 EDT(-0400)] <colinclark> Slightly tangential to this issue is the fact that I'd like to provide a unified, all-component way of introspecting and modifying keyboard bindings.
[13:16:37 EDT(-0400)] <colinclark> The "key binder" if you will.
[13:16:49 EDT(-0400)] <Bosmon> This is really very unfortunate...
[13:18:49 EDT(-0400)] <Bosmon> I mean, it is not so much the "deep copy" that we want to prevent
[13:19:01 EDT(-0400)] <Bosmon> but the retention/destruction of things at particular depths
[13:19:09 EDT(-0400)] <Bosmon> A kind of "conditional contund"...
[13:19:38 EDT(-0400)] <Bosmon> E.g. "if there is any object at path X on the RHS, destroy the LHS before copying"
[13:19:39 EDT(-0400)] <colinclark> I was going to ask about the cotund() method.
[13:20:01 EDT(-0400)] <Bosmon> Unfortunately there is nothing we can do about this without abolishing our use of jQuery.extend and writing a custom method
[13:20:10 EDT(-0400)] <Bosmon> Which is a really dismal thing to do
[13:20:20 EDT(-0400)] <anastasiac> yes
[13:20:43 EDT(-0400)] <Bosmon> keysets, keysets...
[13:23:25 EDT(-0400)] <Bosmon> Well then
[13:23:27 EDT(-0400)] <ecochran> jacobfarber: OK, I've got a strawman page up for our editing: http://wiki.fluidproject.org/display/fluid/Fluid+Component+Sample+Code
[13:23:34 EDT(-0400)] <Bosmon> We will just have to write our own
[13:23:55 EDT(-0400)] <ecochran> I'm going to have to go into a Design Planning meeting at 10:30
[13:24:01 EDT(-0400)] <ecochran> first I have to make Hannah toast
[13:24:04 EDT(-0400)] <Bosmon> Luckily I have to hand michelled's version that was just trashed from testUtils
[13:24:45 EDT(-0400)] <jacobfarber> ecochran: awesome, im writing up a working example
[13:24:50 EDT(-0400)] <colinclark> I hate writing our own.
[13:25:02 EDT(-0400)] <Bosmon> can you think of an answer?
[13:25:16 EDT(-0400)] <colinclark> Not immediately, no.
[13:25:23 EDT(-0400)] <colinclark>
[13:25:27 EDT(-0400)] <Bosmon> I have sat staring into space for a bit
[13:25:37 EDT(-0400)] <Bosmon> The best strategy seems to be to accept as a further argument a "policy" object [13:26:10 EDT(-0400)] <colinclark> staring into space is the best solution [13:26:13 EDT(-0400)] <colinclark> to almost every problem [13:26:23 EDT(-0400)] <colinclark> what will the policy object convey? [13:26:27 EDT(-0400)]