fluid-work IRC Logs-2008-07-22

[02:02:14 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[02:29:15 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[07:58:57 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has joined #fluid-work
[09:00:02 EDT(-0400)] * Jacob1 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:30:21 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:54:20 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:16:41 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:44:20 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:44:46 EDT(-0400)] <colinclark> Jacob1: I'm here now.
[10:50:57 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[11:42:18 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:53:46 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[12:20:39 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:21:12 EDT(-0400)] <Bosmon> So... could I reconfirm from yesterday, that we have decided to revise fluid.container - so that it interprets its string argument as a selector, not an id?
[12:21:30 EDT(-0400)] <Bosmon> Any ideas on the full set of things which need to be revised to reflect this?
[12:22:14 EDT(-0400)] <anastasiac> Bosmon, yes - fluid.container should interpret a string parameter as a selector, not an id
[12:22:28 EDT(-0400)] <anastasiac> as far as I know, Inline Edit is the only thing that actually uses fluid.container() yet
[12:22:41 EDT(-0400)] <anastasiac> I did a search for the string, and that was the only thing that came up
[12:22:58 EDT(-0400)] <anastasiac> but hopefully, the unit tests would find any other problems - that's what unit tests are good for!
[12:23:42 EDT(-0400)] <colinclark> Bosmon, anastasiac: Yes, we should modify fluid.container() to, as you say, interpret a string argument as a selector, not an id.
[12:23:49 EDT(-0400)] <colinclark> This fix should be pretty straightforward...
[12:24:04 EDT(-0400)] <colinclark> At the moment, we pass the string argument to fluid.jById().
[12:24:36 EDT(-0400)] <Bosmon> ok
[12:24:38 EDT(-0400)] <colinclark> Instead, we should just simplify the code path to essentially just wrap any argument we get in a jQuery and retain the sanity checks that will throw an exception if we get more than one item returned for the container.
[12:24:52 EDT(-0400)] <Bosmon> Yes, or indeed "none"
[12:24:54 EDT(-0400)] <Bosmon> Being the damn document
[12:24:54 EDT(-0400)] <colinclark> InlineEdit is indeed the only piece of code that uses fluid.container().
[12:24:57 EDT(-0400)] <colinclark> Yes, exactly.
[12:25:02 EDT(-0400)] <Bosmon> That is really never a desirable behaviour
[12:25:12 EDT(-0400)]

[12:25:13 EDT(-0400)] <Bosmon> A rare misstep for JQuery sanity....
[12:25:23 EDT(-0400)] <colinclark>
[12:25:44 EDT(-0400)] <colinclark> There should be a reasonable set of unit tests for fluid.container() in the FluidJSTests file.
[12:25:49 EDT(-0400)] <Bosmon> Well, the "sanity check" in jById used to be straightforward
[12:25:56 EDT(-0400)] <Bosmon> Now we have a slightly more complex one to do...
[12:26:34 EDT(-0400)] <anastasiac> note that the unit tests for container will have to be updated
[12:27:01 EDT(-0400)] <colinclark> So one question about this:
[12:27:20 EDT(-0400)] <colinclark> fluid.jById() was there to ensure that people didn't end up using id-based selectors that tend to break:
[12:27:24 EDT(-0400)] <colinclark> ie. #myId
[12:27:49 EDT(-0400)] <colinclark> Since, with certain ids which may contain selector-ish characters, this will break.
[12:28:03 EDT(-0400)] <colinclark> Would we end up modifying container() to re-write such selectors?
[12:28:13 EDT(-0400)] <colinclark> into the "[id=myId]" form?
[12:28:26 EDT(-0400)] <colinclark> Bosmon, anastasiac: ^
[12:29:41 EDT(-0400)] <anastasiac> I'm not sure I understand the issue - why would "#myId" tend to break?
[12:30:47 EDT(-0400)] <colinclark> anastasiac: Like I say, when an id contains unescaped characters that can be interpreted as part of the selector itself...
[12:30:52 EDT(-0400)] <colinclark> colons, for example
[12:31:33 EDT(-0400)] <colinclark> The # form will break. Remember we discovered this quite awhile ago? That's why we wrote jById()... to ensure we always use the safer form of [id=foo].
[12:31:52 EDT(-0400)] <anastasiac> oh, right - now I remember
[12:32:19 EDT(-0400)] <Jacob1> anyone want to talk progress bars?
[12:32:37 EDT(-0400)] <anastasiac> sure
[12:33:39 EDT(-0400)] <Jacob1>
[12:33:39 EDT(-0400)] <Jacob1> it turns out progressbar is a child role of status, which makes it a live region
[12:36:14 EDT(-0400)] <anastasiac> I don't know much about live regions - what are the implications of this fact?
[12:38:31 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-100.LIPS.Berkeley.EDU) has joined #fluid-work
[12:38:32 EDT(-0400)] <Jacob1> I will have to get back to you on that
[12:38:38 EDT(-0400)] <anastasiac>
[12:39:10 EDT(-0400)] <Jacob1> Colin wanted to know specifically about the parent/child relationship bewteen progressbar and everythign else, so I need to do more research!
[12:39:22 EDT(-0400)] <ecochran> this is a very tricky question, especially since the progress bars are embedded in the uploader
[12:40:35 EDT(-0400)] <anastasiac> well, ARIA support is about adding the right roles and states, so whether or not it is embedded shouldn't be too much of an issue
[12:40:58 EDT(-0400)] <anastasiac> we need to understand the roles and states that are relevant, and when they should be set to what
[12:41:32 EDT(-0400)] <anastasiac> hopefully, the best practices doc will have some help: http://www.w3.org/TR/wai-aria-practices/
[12:41:35 EDT(-0400)] <ecochran> I guess what I'm concerned with is that the progress is displayed within the row in the filequeue, so does the row change its state or role?
[12:41:59 EDT(-0400)] <Jacob1> it might
[12:42:09 EDT(-0400)] <anastasiac> well, if the row is a progress bar, then the initial answer is 'yes'
[12:42:24 EDT(-0400)] <ecochran> that's a good question
[12:42:34 EDT(-0400)] <anastasiac> more questions are: would there be another aria role on the row, related to its role in the uploader itself
[12:42:39 EDT(-0400)] <anastasiac> can things have multiple ARIA roles?
[12:42:41 EDT(-0400)] <ecochran> the progress container is the row
[12:42:46 EDT(-0400)] <anastasiac> I think so...
[12:42:48 EDT(-0400)] <Jacob1> Colin and I were talking about this
[12:42:51 EDT(-0400)] <ecochran> and the progress indicator is separate
[12:43:01 EDT(-0400)] <ecochran> so perhaps the role is just on the indicator
[12:43:15 EDT(-0400)] <Jacob1> we were thinking it more semantically correct (and to assist in kyboard a11y) to separate things more clearly
[12:43:22 EDT(-0400)] <anastasiac> what is the distinction between the 'bar' and the 'indicator'??
[12:43:23 EDT(-0400)] <ecochran> colin was asking me if Progress was a live region
[12:43:32 EDT(-0400)] <Jacob1> it looks like it is
[12:43:47 EDT(-0400)] <Jacob1> due to its parent role's properties
[12:43:47 EDT(-0400)] <ecochran> the bar is a combination of the container and indicator
[12:43:49 EDT(-0400)] <Jacob1> status
[12:44:00 EDT(-0400)] <Jacob1> http://www.w3.org/TR/wai-aria/#status
[12:44:02 EDT(-0400)] <anastasiac> ok, got it
[12:44:17 EDT(-0400)] <ecochran> visually the container shows the maximum state
[12:44:26 EDT(-0400)] <ecochran> while the indicator shows the current state
[12:44:41 EDT(-0400)] <ecochran> but that does really apply for a audible state
[12:44:58 EDT(-0400)] <anastasiac> so we'll need to learn more about what ARIA properties are associated with the progress bar, to understand which element the info should be attached to
[12:45:03 EDT(-0400)] <ecochran> in the audible state all that is important is the percent complete
[12:45:17 EDT(-0400)] <colinclark> At the bottom of the page, you can see a little sketch of the parts of a progress bar: http://wiki.fluidproject.org/display/fluid/Architecture+Sketches
[12:45:17 EDT(-0400)] <anastasiac> I'm going to guess that it'll be on the container, since it has all the info (effectively)
[12:45:19 EDT(-0400)] <ecochran> IMHO
[12:45:43 EDT(-0400)] <colinclark> ecochran: In effect, the container is the progress bar, and will but updated with new states and properties as the progress changes.
[12:45:48 EDT(-0400)] <colinclark> As far as I know.
[12:45:59 EDT(-0400)] <colinclark> "will be updated"
[12:46:11 EDT(-0400)] <ecochran> I think so
[12:47:06 EDT(-0400)] <ecochran> but it might make more sense audibly if the indicator was the progress bar that contained all the information for the spoken state
[12:47:13 EDT(-0400)] <ecochran> which would also separate it from the row
[12:47:20 EDT(-0400)] <ecochran> and keep the row a constant
[12:47:28 EDT(-0400)] <ecochran> does that make sense
[12:47:29 EDT(-0400)] <ecochran> ?
[12:47:41 EDT(-0400)] <colinclark> I'm not sure.
[12:48:29 EDT(-0400)] * anastasiac goes to look a the diagram and the Progress bar code to better understand the parts
[12:50:18 EDT(-0400)] <colinclark> ecochran: I've read over your point again (I'm multitasking in a board meeting at the moment) and I'm not sure I understand you.
[12:51:22 EDT(-0400)] <ecochran> colinclark: I'll see if I can make it clearer
[12:51:25 EDT(-0400)] <colinclark>
[12:53:27 EDT(-0400)] <ecochran> I guess what I'm trying to get my head around is whether it make sense from a screen reader point of view is whether the role and state for a progress bar should be set on the container or the indicator (aka. progressor).
[12:53:45 EDT(-0400)] <ecochran> If it is on the container then the role and state for the row need to change since they are the container
[12:53:51 EDT(-0400)] <ecochran> it is the container
[12:54:21 EDT(-0400)] <ecochran> but if it is on the indicator then the row stays the same
[12:54:34 EDT(-0400)] <ecochran> as the indicator updates so will the state
[12:55:04 EDT(-0400)] <ecochran> however the indicator might need to carry some extra information on it to identify which file is being updated
[12:57:26 EDT(-0400)] <ecochran> OK, I spoke too soon...
[12:57:28 EDT(-0400)] <anastasiac> oh, now I'm more confused than ever :-/
[12:57:38 EDT(-0400)] <Jacob1> i think your right though
[12:57:38 EDT(-0400)] <ecochran> the indicator is not a child of the row
[12:57:52 EDT(-0400)] <ecochran> it is separate
[12:57:56 EDT(-0400)] <Jacob1> just using the global progressor to indicate a slew of data should suffice, right?
[12:58:10 EDT(-0400)] <ecochran> because i put it behind the table
[12:58:13 EDT(-0400)] <ecochran> yes
[12:58:32 EDT(-0400)] <ecochran> makes sense to have just one global indicator for screen readers
[12:58:43 EDT(-0400)] <ecochran> otherwise they are trying to parse two live regions
[12:58:51 EDT(-0400)] <Jacob1> right, and we can overload that with all the necessary info
[12:59:15 EDT(-0400)] <Jacob1> and all the attributes of a live region can handle when/what to speak, right?
[12:59:17 EDT(-0400)] <Jacob1> http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/#LiveRegions
[12:59:17 EDT(-0400)] <anastasiac> I think whether we put roles and states on the progressor itself or on the container will depend on what the various properties and states are, and what info they need to be set to, and what component/element has that info
[13:00:02 EDT(-0400)] <ecochran> right now the file progress indicator carries text which indicates the percentage although the text is not displayed
[13:00:37 EDT(-0400)] <anastasiac> I think progressor vs. container is a different question than individual row/file progress vs. total progress
[13:00:46 EDT(-0400)] <ecochran> to me, seems that the Total progress is actually more useful
[13:01:07 EDT(-0400)] <ecochran> especially if it contained a little more context (only for screen readers)
[13:01:12 EDT(-0400)] <Jacob1> for sure
[13:01:18 EDT(-0400)] <anastasiac> ecochran, you might be right - it certainly would be confusing to hear two progress bars talking simultaneously
[13:01:29 EDT(-0400)] <Jacob1> you never would though
[13:01:45 EDT(-0400)] <Jacob1> using live attr. as "polite" it waits for cues
[13:01:48 EDT(-0400)] <Jacob1> as you see fit
[13:02:02 EDT(-0400)] <anastasiac> so if we wanted both to talk, which one would wait for the other?
[13:02:11 EDT(-0400)] <Jacob1> you define the order
[13:02:13 EDT(-0400)] <Jacob1> and priority
[13:02:19 EDT(-0400)] <colinclark> Sorry, I was focused on the meeting here...
[13:02:22 EDT(-0400)] <Jacob1> using things like atomic
[13:02:26 EDT(-0400)] <ecochran> I think that we should avoid having both talk
[13:02:38 EDT(-0400)] <colinclark> But I do like the notion of "hiding" the individual progress bars and using the total progress as our primary conduit for AT users.
[13:03:00 EDT(-0400)] <colinclark> There are problematic aspects to this approach. We have to be careful not to reduce the problem of ARIA to just screen readers.
[13:03:07 EDT(-0400)] <colinclark> This is not only about how things will "sound."
[13:03:29 EDT(-0400)] <anastasiac> colinclark, good point, thanks
[13:03:37 EDT(-0400)] <colinclark> So there is a huge benefit to ensuring that roles and states are reflected for all the progress bars.
[13:03:54 EDT(-0400)] <colinclark> Even if the individual file bars are set to be so polite as to defer to the total progress bar entirely.
[13:04:10 EDT(-0400)] <Jacob1> we can set them to live=off
[13:04:13 EDT(-0400)] <ecochran> that makes sense
[13:04:21 EDT(-0400)] <anastasiac> what does 'live=off' do?
[13:04:36 EDT(-0400)] <colinclark> It effectively squelches the live region.
[13:04:44 EDT(-0400)] <Jacob1> it would not speak the semantics of the region, but you can load it up with other info
[13:04:56 EDT(-0400)] <anastasiac> ok, then, that sounds ideal to me
[13:05:10 EDT(-0400)] <colinclark> It would read the semantics (ie. the role), but would not necessarily provide live updates.
[13:05:11 EDT(-0400)] <anastasiac> all progress bars have all the necessary info, but only the 'total' one is live
[13:05:14 EDT(-0400)] <colinclark> yes
[13:05:25 EDT(-0400)] <Jacob1> ok
[13:05:26 EDT(-0400)] <colinclark> I think that's a fairly sensible approach.
[13:05:32 EDT(-0400)] <Jacob1> so I think we're all on the same page here
[13:05:44 EDT(-0400)] <Jacob1> but its coming as a torrent of info blended with ideas
[13:05:49 EDT(-0400)] <anastasiac>
[13:05:52 EDT(-0400)] <Jacob1> if I can sum up, I think:
[13:06:02 EDT(-0400)] <colinclark> please summarize, yes.
[13:06:24 EDT(-0400)] <Jacob1> each progressbar should be defined as such, inside a larger live region (the uploader)
[13:06:36 EDT(-0400)] <Jacob1> only the global progressor is read aloud
[13:06:45 EDT(-0400)] <Jacob1> and it would be done so as live="polite"
[13:06:50 EDT(-0400)] <Jacob1> however
[13:07:09 EDT(-0400)] <Jacob1> scratch that last line
[13:07:23 EDT(-0400)] <Jacob1> as a polite progressbar, it would be read aloud only on idle
[13:07:23 EDT(-0400)] <colinclark> can you clarify what you mean by "inside a larger live region (the uploader)"?
[13:07:47 EDT(-0400)] <colinclark> It seems to me that each progress bar itself is a live region, no/
[13:07:48 EDT(-0400)] <colinclark> ?
[13:08:05 EDT(-0400)] <anastasiac> yeah - is the uploader itself also a live region??
[13:08:08 EDT(-0400)] <Jacob1> we can define the uploader as a live region, with all its sub-elements as progressbars
[13:08:16 EDT(-0400)] <anastasiac> do we want to do that??
[13:08:31 EDT(-0400)] <Jacob1> its just one approach, as opposed to splitting it up I think
[13:08:34 EDT(-0400)] * anastasiac thinks she needs to learn about live regions
[13:08:36 EDT(-0400)] <Jacob1> into many live regions
[13:08:39 EDT(-0400)] <Jacob1> hold on
[13:08:44 EDT(-0400)] <Jacob1> http://juicystudio.com/article/wai-aria-live-regions.php
[13:08:52 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[13:08:56 EDT(-0400)] <ecochran> I need to read up too
[13:09:21 EDT(-0400)] <colinclark> Here's an example from MDC:
[13:09:23 EDT(-0400)] <colinclark> http://www.mozilla.org/access/dhtml/progressbar
[13:09:32 EDT(-0400)] <Jacob1> ok, so if I got that mixed up and each element is defined as its own live region, either way the smaller progressbars would be silent
[13:09:34 EDT(-0400)] <colinclark> They're situating the progress bar inside a live region as Jacob suggests.
[13:09:38 EDT(-0400)] <Jacob1> but the global one would be "polite"
[13:09:46 EDT(-0400)] <Jacob1> right
[13:09:58 EDT(-0400)] <ecochran> hmm
[13:10:02 EDT(-0400)] <Jacob1> and you use live region alongside being atomic
[13:10:47 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:11:01 EDT(-0400)] <colinclark> This is all very fascinating. We're learning something today.
[13:11:09 EDT(-0400)] <Bosmon> "Water doesn't burn"?
[13:11:11 EDT(-0400)] <Bosmon>
[13:11:17 EDT(-0400)] <anastasiac> it seems to me that live regions are intended for regions that will be updating outside the control of the user, i.e. changes in the ui will not happen in response to user actions (and hence there needs to be some other way to inform the user)
[13:11:21 EDT(-0400)] <anastasiac> is that right?
[13:11:29 EDT(-0400)] <colinclark> Yes, that's correct.
[13:11:38 EDT(-0400)] <ecochran> thinking aloud > addding and removing files from the queue is done by user action
[13:11:56 EDT(-0400)] <ecochran> however the state of the rows changes outside of user action on upload
[13:12:05 EDT(-0400)] <colinclark> ecochran: Exactly.
[13:12:15 EDT(-0400)] <ecochran> so that would argue for the whole uploader being live
[13:12:27 EDT(-0400)] <anastasiac> my first impression of the uploader as a whole is that any changes are the result of user actions
[13:12:30 EDT(-0400)] <anastasiac> except the progress
[13:12:45 EDT(-0400)] <anastasiac> I was going to argue for the uploader not being live
[13:13:15 EDT(-0400)] <colinclark> I wonder if this has been covered in a of the PFG meetings. The case of multiple progress bars.
[13:13:23 EDT(-0400)] <anastasiac> the state of a row doesn't really change externally, it changes because I click 'upload'
[13:13:27 EDT(-0400)] <ecochran> except progress changes the state of both the rows and the buttons in the uploader (buttons disable, enable, etc, depending on the number of items in the queue, or the completeness of the upload)
[13:13:38 EDT(-0400)] <colinclark> Perhaps when theclown_afk becomes un-_afk, he will have some ideas.
[13:14:23 EDT(-0400)] <ecochran> except that the state of the row depends on things outside of the users control such as success or error
[13:14:30 EDT(-0400)] <ecochran> but maybe i'm missing the point
[13:14:34 EDT(-0400)] * anastasiac mulls
[13:14:52 EDT(-0400)] * anastasiac can easily be convinced by good arguments
[13:14:56 EDT(-0400)] <colinclark>
[13:15:09 EDT(-0400)] <colinclark> We are all for Good Arguments.
[13:15:17 EDT(-0400)] <ecochran> anastasiac is quite reasonable
[13:15:27 EDT(-0400)] <Bosmon> Like " -rf"?
[13:16:06 EDT(-0400)] * colinclark laughs.
[13:16:41 EDT(-0400)] <ecochran> eli is bewildered
[13:16:54 EDT(-0400)] <anastasiac> Bosmon has that effect
[13:17:36 EDT(-0400)] <colinclark> The Bewildering Effect?
[13:17:56 EDT(-0400)] <Bosmon> element.hide("bewilder")
[13:18:16 EDT(-0400)] <Jacob1> here's what I think - correct me if im wrong
[13:18:31 EDT(-0400)] <Jacob1> wrong! ok, just kidding
[13:18:34 EDT(-0400)] <Jacob1> anyways
[13:18:44 EDT(-0400)] <Jacob1> I think if the entire uploader was a live region
[13:18:57 EDT(-0400)] <Jacob1> we can help the screenreaders experience
[13:19:10 EDT(-0400)] <Jacob1> by reducing the amount of redundant aria info
[13:19:20 EDT(-0400)] <Jacob1> for all the repeated elements
[13:19:49 EDT(-0400)] <Jacob1> and therefore hilight just the few main "things of interest" in the experience
[13:20:00 EDT(-0400)] <Jacob1> that being all the buttons and the global progressor
[13:20:02 EDT(-0400)] <Jacob1> otherwise
[13:20:26 EDT(-0400)] <Jacob1> you might need to constantly assign the relevancy and channel aaa: attributes
[13:20:30 EDT(-0400)] <Jacob1> for each live region
[13:20:50 EDT(-0400)] <Jacob1> when they can all be done inside a single live region
[13:21:00 EDT(-0400)] <anastasiac> ok, I think I'm coming over to the side of 'the whole Uploader is a live region'
[13:23:16 EDT(-0400)] <Jacob1> i think this is what the whole point of the atomic attribute
[13:23:20 EDT(-0400)] <anastasiac> but I still need to learn a bit more
[13:23:28 EDT(-0400)] <Bosmon> I was just reading about this...
[13:23:30 EDT(-0400)] <Jacob1> to define a lr as a whole or as a series of parts
[13:23:45 EDT(-0400)] <Bosmon> At least, the atomic attribute is at least what makes the approach of a "entirely live uploader" even feasible
[13:25:04 EDT(-0400)] <Jacob1> I think its right in line with our case
[13:27:34 EDT(-0400)] <Bosmon> http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions
[13:27:41 EDT(-0400)] <Bosmon> Is this a reasonable place to be looking for an explanation?
[13:27:47 EDT(-0400)] <Bosmon> I am somewhat puzzled by the bare "role" attribute...
[13:27:58 EDT(-0400)] <Bosmon> "role="timer", "log", "marquee" or "status""
[13:28:13 EDT(-0400)] <Bosmon> These do look potentially relevant to the case of describing "progress"
[13:28:13 EDT(-0400)] <anastasiac> Bosmon, try http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/#LiveRegions
[13:28:14 EDT(-0400)] <Jacob1> have a look http://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/#LiveRegions
[13:28:20 EDT(-0400)] <anastasiac> and its link to the actual spec
[13:28:54 EDT(-0400)] <Bosmon> Hmm
[13:29:01 EDT(-0400)] <Bosmon> Unfortunately this section is not present in the real spec
[13:29:08 EDT(-0400)] <anastasiac> Jacob1, hi
[13:30:21 EDT(-0400)] <Bosmon> OK, looks like this part has now become section 5.3 of the spec, and "timer" and "marquee" have gone missing
[13:30:38 EDT(-0400)] <Bosmon> Leaving just "status" for our case..
[13:31:10 EDT(-0400)] <Bosmon> Gah, this is strangely confused
[13:31:23 EDT(-0400)] <Bosmon> Now the entire concept of "liveness" is grafted as being a peer of these categories...
[13:31:52 EDT(-0400)] <Bosmon> Fine, excuse me "learning out loud" what the live-regions spec actually says
[14:04:32 EDT(-0400)] <Bosmon> So, new ideas - how to find the "model" for a component
[14:05:16 EDT(-0400)] <Bosmon> The problem where the model is just a "string", as it is for InlineEdit, is that it is damn immutable
[14:05:32 EDT(-0400)] <Bosmon> But then if you put the model in something larger, how do you know where it is....
[14:05:48 EDT(-0400)] <Bosmon> This implies that even non-self-rendered components will need to have something like the "binding bolus"
[14:33:14 EDT(-0400)] * jessm (n=Jess@rrcs-70-63-141-143.midsouth.biz.rr.com) has joined #fluid-work
[15:20:20 EDT(-0400)] <Bosmon> New maundering section on the wiki:
[15:20:33 EDT(-0400)] <Bosmon> http://wiki.fluidproject.org/display/fluid/Component+Model+Interactions+and+API
[15:21:26 EDT(-0400)] <anastasiac> Bosmon, cool! Thanks so much for putting all these maunderings on the wiki
[15:26:32 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[15:27:07 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[16:19:20 EDT(-0400)] * Justin_o (n=Justin@142.150.154.235) has left #fluid-work
[16:30:48 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[16:30:58 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has left #fluid-work
[16:58:21 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has left #fluid-work
[17:30:39 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[19:05:01 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[19:06:22 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work
[19:17:19 EDT(-0400)] * jessm (n=Jess@rrcs-70-63-141-143.midsouth.biz.rr.com) has joined #fluid-work
[20:06:12 EDT(-0400)] * phiggins (n=dante@12.157.240.2) has joined #fluid-work