fluid-work IRC Logs-2008-11-07

[08:18:07 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:25:17 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:25:35 EST(-0500)] * ptmahent (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[08:49:05 EST(-0500)] * athena7 (n=athena7@adsl-99-130-147-23.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:12:30 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:12:38 EST(-0500)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:23:12 EST(-0500)] * ptmahent__ (n=ptmahent@net1.senecac.on.ca) has joined #fluid-work
[09:31:08 EST(-0500)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[09:39:17 EST(-0500)] * ptmahent (n=ptmahent@kb-v832-130-63-234-498.airyork.yorku.ca) has joined #fluid-work
[09:44:44 EST(-0500)] <colinclark> jacobfarber: Got a second to answer a couple of questions?
[09:44:48 EST(-0500)] * michelled (n=michelle@142.150.154.197) has joined #fluid-work
[09:44:48 EST(-0500)] <jacobfarber> yup
[09:45:06 EST(-0500)] <Bosmo1> pling
[09:45:27 EST(-0500)] <michelled> pluck
[09:45:31 EST(-0500)] <colinclark> jacobfarber: I think we may have suffered a bad branch merge last night.
[09:45:42 EST(-0500)] <colinclark> Two skin-related files were deleted.
[09:45:54 EST(-0500)] <colinclark> D /fluid/components/trunk/src/webapp/fluid-components/css/fluid.text.css
[09:45:54 EST(-0500)] <colinclark> D /fluid/components/trunk/src/webapp/fluid-components/css/fluid.theme.debug.css
[09:46:04 EST(-0500)] <colinclark> I assume these should legitimately be in the repository, right?
[09:47:18 EST(-0500)] <colinclark> jacobfarber: The only reason I'm asking you is because they're files you've worked on recently. Don't worry, you didn't cause any problems with them.
[09:47:27 EST(-0500)] <jacobfarber> yech
[09:47:48 EST(-0500)] <jacobfarber> yes, they're important
[09:47:50 EST(-0500)] <colinclark> Ok.
[09:47:54 EST(-0500)] <Bosmo1> glarg
[09:47:56 EST(-0500)] <jacobfarber> the debug one, though
[09:48:04 EST(-0500)] <colinclark> It looks like those were the only casualties.
[09:48:04 EST(-0500)] <jacobfarber> isnt really out there yet
[09:48:13 EST(-0500)] <jacobfarber> the text one is critical though
[09:48:19 EST(-0500)] <colinclark> jacobfarber: "Out there?"
[09:48:19 EST(-0500)] <Bosmo1> I think we will buy jacobfarber a copy of the Red Book for christmas
[09:48:25 EST(-0500)] <colinclark> Bosmo1: No, no.
[09:48:30 EST(-0500)] <colinclark> It wasn't jacobfarber.
[09:48:35 EST(-0500)] <colinclark> Please, don't misunderstand.
[09:48:36 EST(-0500)] <Bosmo1> ah
[09:48:37 EST(-0500)] <Bosmo1>
[09:48:39 EST(-0500)] <Bosmo1> Sorry
[09:48:40 EST(-0500)] <jacobfarber> Red Book?
[09:48:42 EST(-0500)] <colinclark> I won't name names here. You can read the commits list.
[09:48:44 EST(-0500)] <colinclark>
[09:48:46 EST(-0500)] <jacobfarber> sounds dangerous
[09:48:51 EST(-0500)] <colinclark> jacobfarber: It's awesome.
[09:48:59 EST(-0500)] <jacobfarber> awesomely dangersou?
[09:49:01 EST(-0500)] <colinclark> http://svnbook.red-bean.com/
[09:49:05 EST(-0500)] <jacobfarber> *dangerous?
[09:49:25 EST(-0500)] <Bosmo1> ooh
[09:49:29 EST(-0500)] <Bosmo1> Uploader2 is now live
[09:49:32 EST(-0500)] <Bosmo1> IT'S ALIIIIVE
[09:49:42 EST(-0500)] <jacobfarber> so....is it safe for me to update here?
[09:51:22 EST(-0500)] * jacobfarber nudges colinclark ^
[09:51:42 EST(-0500)] <colinclark> jacobfarber: You can update, you'll just temporarily lose those two files.
[09:51:48 EST(-0500)] <colinclark> I will bring them back from the dead.
[09:51:53 EST(-0500)] <jacobfarber> thank you
[09:52:36 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:54:15 EST(-0500)] <colinclark> Bosmo1: What sorts of events are you struggling to simulate in the browser?
[09:55:16 EST(-0500)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[09:55:32 EST(-0500)] <Bosmo1> I am trying to actually simulate the process of typing text into a field
[09:55:46 EST(-0500)] <colinclark> Bosmo1: Aha, yes.
[09:55:50 EST(-0500)] <Bosmo1> Simply simulate(keypress) seems to really have no effect
[09:55:59 EST(-0500)] <Bosmo1> This page explains this same issue, from the point of view of Selenium
[09:56:01 EST(-0500)] <colinclark> You're in Robot or Selenium territory, I suspect.
[09:56:04 EST(-0500)] <Bosmo1> http://blogs.telerik.com/KonstantinPetkov/Posts/07-08-12/Pressing_keys_simulation_in_Selenium_RadInput_on_fire.aspx
[09:56:15 EST(-0500)] <Bosmo1> But Selenium would have just the same limitations that we do, as I understand it
[09:56:32 EST(-0500)] <Bosmo1> So any solution that works in Selenium should be accessible to us without the robot
[09:56:35 EST(-0500)] <Bosmo1> Is this correct?
[09:56:53 EST(-0500)] <colinclark> It is a shame that we can't do this properly from within unit tests, since the robot tests really need to be fairly coarse-grained to be effective.
[09:57:05 EST(-0500)] <colinclark> Bosmo1: Probably not, no.
[09:57:20 EST(-0500)] <Bosmo1> Does Selenium have some WAKy STUF (TM) too?
[09:57:25 EST(-0500)] <Bosmo1> I thought it was just javascript
[09:57:25 EST(-0500)] <colinclark> Yes.
[09:57:32 EST(-0500)] <colinclark> Selenium is a browser plugin.
[09:57:36 EST(-0500)] <Bosmo1> bah
[09:57:40 EST(-0500)] <Bosmo1> Sods
[09:57:41 EST(-0500)] <colinclark> Right, michelled?
[09:59:46 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:59:47 EST(-0500)] <michelled> well, there is a browser plugin as part of selenium but that's only for FF and they do claim that the tests can be run against IE
[10:00:03 EST(-0500)] <Bosmo1> So, in theory we could look at their source...
[10:00:07 EST(-0500)] * michelled wishes she had a better memory
[10:00:44 EST(-0500)] <michelled> but I did run into problems with simulating particular key presses in selenium
[10:00:59 EST(-0500)] <Bosmo1> gah
[10:00:59 EST(-0500)] <michelled> particularly arrow keys and modifier keys
[10:01:13 EST(-0500)] <Justin_o> I believe that selenium can be driven by several languages including java, but i believe it interacts inside the browser via javascript ( i could be wrong on this )
[10:01:17 EST(-0500)] <michelled> this was a long time ago now though
[10:02:34 EST(-0500)] <Justin_o> Bosmo1: http://dojotoolkit.org/2008/08/11/doh-robot-automating-web-ui-unit-tests-real-user-events
[10:02:56 EST(-0500)] <Justin_o> that article explains some of the issues with synthetic events in browsers...
[10:03:02 EST(-0500)] <Justin_o> very briefly explains
[10:03:17 EST(-0500)] <michelled> theclown: what do you do for automated keyboard only testing in dojo? how do you simulate keypresses?
[10:04:12 EST(-0500)] <theclown> michelled: talking with colinclark on ICQ – just a second.
[10:04:25 EST(-0500)] <theclown> oh, that's simple. I use doh.robot
[10:04:29 EST(-0500)] <colinclark> I am distracting him!
[10:04:54 EST(-0500)] <theclown> or michelled is distracting me, depending on who gets dibs for my time.
[10:05:02 EST(-0500)] <colinclark> michelled wins
[10:05:08 EST(-0500)] <Bosmo1> Thanks, Justin_o
[10:05:32 EST(-0500)] <Justin_o> Bosmo1: np
[10:05:57 EST(-0500)] <theclown> michelled, specifically, doh.robot.keyPress(...);
[10:06:03 EST(-0500)] <Bosmo1> Yes
[10:06:06 EST(-0500)] <theclown> do you need more detail than that?
[10:06:08 EST(-0500)] <Bosmo1> This confirms my results
[10:06:35 EST(-0500)] <Bosmo1> And explains why I have so far not succeeded in being able to test tab focus and submission issues...
[10:06:39 EST(-0500)] <Bosmo1> Amongst other things
[10:06:45 EST(-0500)] <Bosmo1> "But the problem with synthetic events is that browsers don't trust synthetic events enough to let them execute their default action. "
[10:07:49 EST(-0500)] <theclown> Bosmo1: that's why they wrote the robot. they are not synthethic events. they are real. heck, even if you switch out of the browser, your mouse, keyboard are owned by the robot (you get to fight with it).
[10:07:56 EST(-0500)] <Bosmo1> Yes
[10:08:01 EST(-0500)] <Bosmo1> Unfortunately I need something that works NOW
[10:08:02 EST(-0500)] <Bosmo1>
[10:08:09 EST(-0500)] <Bosmo1> That is, in our existing testing framework
[10:08:40 EST(-0500)] <colinclark> Bosmo1: Short of finally doing the work to integrate the robot with QUnit, I'm not sure what we can do.
[10:08:43 EST(-0500)] <theclown> oh. I thought that Justin was using some form of the robot (doh.robot at least, and/or dojo.robot as well).
[10:08:47 EST(-0500)] <Bosmo1> He is
[10:09:00 EST(-0500)] <Bosmo1> But it is currently not integrated with our existing approach
[10:09:08 EST(-0500)] <Bosmo1> We have plans for doing this, but it is quite complex
[10:09:08 EST(-0500)] <colinclark> And even then, it's vaguely problematic to use acceptance-level testing in our unit tests. I mean, it can be very fragile.
[10:09:10 EST(-0500)] <theclown> mal
[10:09:27 EST(-0500)] <Bosmo1> Doh.robot is extremely prescriptive about lifecycle issues, etc. in a way which jqUnit is not
[10:09:40 EST(-0500)] <colinclark> "Don't move your mouse or touch the keyboard while you run these unit tests, or they will fail or possible start randomly typing into unintended places."
[10:09:47 EST(-0500)] <Bosmo1> Yes
[10:09:51 EST(-0500)] <theclown> yes
[10:09:53 EST(-0500)] <Bosmo1> THat is another awkward issue
[10:09:54 EST(-0500)] <Bosmo1>
[10:10:14 EST(-0500)] <colinclark> I think that ultimately, we should make use event synthesis as much as possible...
[10:10:30 EST(-0500)] <colinclark> and then make sure that coverage for real events is covered in Justin's acceptance tests.
[10:10:49 EST(-0500)] <Bosmo1> http://issues.fluidproject.org/browse/FLUID-1767
[10:10:49 EST(-0500)] <colinclark> This is awkward, because one truly wants unit-level tests for events and the like.
[10:10:53 EST(-0500)] <Bosmo1> But for example this issue
[10:11:01 EST(-0500)] <Bosmo1> As a result of this, is something I could never test automatically
[10:11:26 EST(-0500)] <Bosmo1> Well, maybe I could...
[10:11:56 EST(-0500)] <colinclark> You could certainly fire a synthetic key event for the Enter key...
[10:12:10 EST(-0500)] <colinclark> Bosmo1: Didn't you tell me that there's actually an underlying issue here?
[10:12:26 EST(-0500)] <colinclark> Nico says that he can't hit enter because we automatically switch to view mode upon Enter...
[10:12:29 EST(-0500)] <colinclark> which I expected.
[10:12:36 EST(-0500)] <colinclark> But you said that you uncovered a deeper issue?
[10:12:45 EST(-0500)] <colinclark> That we just don't work with textareas somehow?
[10:14:24 EST(-0500)] <theclown> i doubt that this is very relevant but to address the "fragile" nature of acceptance testing, i don't rely on knowledge of the test file, but rather the API of the widget therein. For example, given a tree, I use tree API calls to calculate the number of types of key strokes to get to the first leaf (say), then issue exaclty those key strokes. If the test markup changes, the test will still work.
[10:17:42 EST(-0500)] <colinclark> theclown: Cool, that makes sense.
[10:19:14 EST(-0500)] <jessm> re: the topic
[10:19:21 EST(-0500)] <jessm> is the water that rolls back down broken?
[10:19:35 EST(-0500)] <jessm> or is it just the case that after a wave has broken water rolls down?
[10:19:43 EST(-0500)] <colinclark> the latter
[10:19:54 EST(-0500)] <jessm> ah
[10:19:59 EST(-0500)] <colinclark> This is the definition of "backwash."
[10:20:06 EST(-0500)] <jessm> ew
[10:20:09 EST(-0500)] <colinclark> Or, at least, the more savory one.
[10:20:11 EST(-0500)] <colinclark> Yes, that's what I said.
[10:20:15 EST(-0500)] <jessm> i guess that's better than having broken water
[10:20:21 EST(-0500)] <jessm> i was worried for a second
[10:22:08 EST(-0500)] <Bosmo1> ....
[10:22:27 EST(-0500)] <Bosmo1> colinclark: I think we don't work with textareas
[10:22:31 EST(-0500)] <Bosmo1> But I may be wrong
[10:22:38 EST(-0500)] <colinclark> Bosmo1: Hm
[10:22:41 EST(-0500)] <Bosmo1> All I can say is, we don't work with textareas, in the testing environment
[10:22:41 EST(-0500)] <Bosmo1>
[10:23:00 EST(-0500)] <Bosmo1> It looks like I will need to make a "real" test
[10:23:10 EST(-0500)] <colinclark> To be clear, we entirely expected Nico's bug, since we explicitly register a handler that listens for the Enter key and treats it as a blur.
[10:23:24 EST(-0500)] <colinclark> Assuming that is configurable, do we still not work with textareas in some way?
[10:23:37 EST(-0500)] <Bosmo1> Yes
[10:23:46 EST(-0500)] <Bosmo1> We have some issues acquiring and setting their values
[10:23:51 EST(-0500)] <colinclark> Aha.
[10:24:03 EST(-0500)] <colinclark> The same problem I encountered when adding rich text support.
[10:24:07 EST(-0500)] <colinclark> Can you comment on the bug, explaining the nature of the issue?
[10:24:14 EST(-0500)] <Bosmo1> Now, I read that textarea really "does" have a "value" property
[10:24:16 EST(-0500)] <colinclark> Or, actually, perhaps file a related bug.
[10:24:21 EST(-0500)] <Bosmo1> Which means that "in theory", jQuery.val() might work
[10:24:31 EST(-0500)] <colinclark> Bosmo1: I'm fairly certain it did when I tried it.
[10:24:36 EST(-0500)] <Bosmo1> But I have found in many cases this property can somehow become "desynchronised" with its actual contents
[10:24:41 EST(-0500)] <Bosmo1> If there are manipulated by some other means
[10:24:52 EST(-0500)] <colinclark> I could have sworn that, when adding TinyMCE, I first tested with a straight up textarea.
[10:24:59 EST(-0500)] <colinclark> But I wasn't using Undo...
[10:25:03 EST(-0500)] <Bosmo1> For example, you can clear out a textarea by means of jQuery.empty(), but it seems that its value doesn't change
[10:25:10 EST(-0500)] <colinclark> Hmm
[10:25:17 EST(-0500)] <Bosmo1> It makes me mad
[10:25:19 EST(-0500)] <colinclark> This seems like it's got to be a jQuery bug.
[10:25:25 EST(-0500)] <Bosmo1> I'm not convinced
[10:25:29 EST(-0500)] <colinclark> Why not?
[10:25:35 EST(-0500)] <Bosmo1> The maintenance of the "value" property seems to be a browser-side thing
[10:25:41 EST(-0500)] <Bosmo1> It's not quite clear what the real contract is on it
[10:25:52 EST(-0500)] <colinclark> Hmm
[10:33:02 EST(-0500)] <colinclark> jessm, michelled: Hey, do you think we should just merge our two related articles for the Hinnovic blog?
[10:33:15 EST(-0500)] <colinclark> I'd like to encourage the TransformAble-is-Fluid mindset, anyway.
[10:33:21 EST(-0500)] <colinclark> I'm not sure what Jorge needs.
[10:34:14 EST(-0500)] <jessm> colinclark: i'm all in favor of combo
[10:34:24 EST(-0500)] <michelled> fine with me
[10:34:38 EST(-0500)] <colinclark> michelled: Since you're in the office, do you want to double check with Jorge?
[10:36:47 EST(-0500)] <michelled> I just did
[10:36:54 EST(-0500)] <michelled> he's fine with a single blog entry
[10:37:22 EST(-0500)] <michelled> he thinks standards like a4a are an important thing to mention in the article
[10:37:54 EST(-0500)] <michelled> that was why he had asked for the transformable blog entry
[10:37:58 EST(-0500)] <theclown> Bosmo, colinclark : just catching up. if it's an bona fide "<input type='text' ... >" element that jQuery.empty() is changing, my understanding was the text field emitted an "onchange" event. If that's not cross browser, then I've learned something.
[10:38:25 EST(-0500)] <Bosmo1> Events are fine
[10:38:32 EST(-0500)] <Bosmo1> I am talking about the "observed value"
[10:38:39 EST(-0500)] <Bosmo1> In particular, for a <textarea
[10:38:45 EST(-0500)] <michelled> colinclark, jessm, who wants to take on the blog article?
[10:38:48 EST(-0500)] <theclown> clarify: what is an "observed value"?
[10:39:01 EST(-0500)] <Bosmo1> The textarea has a "synthesised property"... named "value"
[10:39:11 EST(-0500)] <Bosmo1> Which appears somehow derived from its nested material
[10:39:27 EST(-0500)] <colinclark> michelled: Why don't you continue with the part you were working on, and then I'll add some transformable stuff with anastasiac, and then jess can take a peek at it all?
[10:39:28 EST(-0500)] <theclown> okay, so we aren't talking about a text field.
[10:40:19 EST(-0500)] <colinclark> theclown: Yep. In this case, it's a textarea.
[10:40:54 EST(-0500)] <michelled> sure
[10:40:57 EST(-0500)] * theclown is not sure if textareas (1) emit change events (2) have a value attribute.
[10:42:45 EST(-0500)] * theclown has confirmed that textarea does emit change events according to W3C.
[10:44:50 EST(-0500)] * theclown has confirmed that the dom object for textarea has a value property
[10:47:35 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:48:44 EST(-0500)] * theclown has confirmed that text area does not have a value attribute (unlike text field).
[10:49:15 EST(-0500)] * theclown presumes the 'value' is got via 'innerHTML', or some such.
[10:51:46 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:55:24 EST(-0500)] <colinclark> Bosmo1: So based on theclown's confirmations, you're seeing problems with the way this value property is synthesized from the actual contents of the textarea?
[11:03:52 EST(-0500)] <colinclark> Okay, everyone. I have resurrected our deleted skin files in trunk.
[11:04:14 EST(-0500)] <colinclark> jacobfarber: You can update again and your skins will be back.
[11:04:38 EST(-0500)] <jacobfarber> awesome
[11:04:40 EST(-0500)] <jacobfarber> thanks
[11:31:02 EST(-0500)] <Bosmo1> Textareas are screwed
[11:31:04 EST(-0500)] <Bosmo1> http://lists.kde.org/?l=kfm-devel&amp;m=118372980800774&amp;w=2
[11:32:13 EST(-0500)] <jacobfarber> Bosmo1: could you summarize problem - why are they screwed?
[11:32:20 EST(-0500)] <jacobfarber> I see there is a very large discussion about it
[11:32:27 EST(-0500)] <Bosmo1> Well
[11:32:33 EST(-0500)] <Bosmo1> They are just not "symmetric"
[11:32:51 EST(-0500)] <jacobfarber> like node = value ?
[11:32:59 EST(-0500)] <jacobfarber> sorry
[11:33:03 EST(-0500)] <jacobfarber> that doesnt look right
[11:33:03 EST(-0500)] <Bosmo1> They accept stuff via what "would" be innerText, but only as it is found when the document is originally written
[11:33:18 EST(-0500)] <Bosmo1> When the document is "live", it seems they essentially have licence to ignore anything done to their child nodes
[11:33:52 EST(-0500)] <jacobfarber> are you thinking about this in context with a rich inline editor?
[11:33:59 EST(-0500)] <Bosmo1> I'm not sure
[11:35:45 EST(-0500)] <jacobfarber> so your trying to put actual elements within a textarea?
[11:37:09 EST(-0500)] <jacobfarber> brb
[11:37:22 EST(-0500)] <Bosmo1> colinclark: Which behaviour would you prefer
[11:37:34 EST(-0500)] <Bosmo1> That the user has to explictly set an option disabling "submit-on-enter"
[11:37:46 EST(-0500)] <Bosmo1> Or that this is automatically inferred by detecting an edit container with nodename "textarea"?
[11:38:26 EST(-0500)] <colinclark> Bosmo1: I'd actually prefer both.
[11:38:51 EST(-0500)] <colinclark> Since we expect that there will be other types of elements that also don't involve submit-on-enter behaviour.
[11:38:51 EST(-0500)] <Bosmo1> ok
[11:38:55 EST(-0500)] <Bosmo1> We have an additional problem
[11:38:57 EST(-0500)] <colinclark> eg. the TinyMCE example.
[11:39:11 EST(-0500)] <colinclark> So if the option is set, it should always win.
[11:39:12 EST(-0500)] <Bosmo1> Of creating some extra capability of causing submission
[11:39:17 EST(-0500)] <colinclark> If it's not set, we should infer.
[11:39:19 EST(-0500)] <Bosmo1> But I guess this is the user's responsibility
[11:39:20 EST(-0500)] <colinclark> Tell me more.
[11:39:32 EST(-0500)] <Bosmo1> Well... it relates to our earlier uploader discussion
[11:39:45 EST(-0500)] <Bosmo1> For example, should it comprise the functionality to "destroy" itself
[11:39:48 EST(-0500)] <Bosmo1> This is somewhat similar
[11:40:07 EST(-0500)] <Bosmo1> In this "unsubmitting mode", there would become nothing within the control itself which could actually cause it to stop editing
[11:40:23 EST(-0500)] <Bosmo1> And it seems unclear whether it is worth providing anything
[11:40:37 EST(-0500)] <Bosmo1> It would be piss-easy for the user to make their own button and bind an event handler to it which calls "finish"
[11:40:43 EST(-0500)] <Bosmo1> Of course they would need to know to do this
[11:41:13 EST(-0500)] <Bosmo1> Well ok, we also currently have "submit on blur"
[11:41:24 EST(-0500)] <Bosmo1> Gah
[11:41:33 EST(-0500)] <Bosmo1> The more I look at this component, the more I see it is really not very configurable at all
[11:41:50 EST(-0500)] * ecochran (n=ecochran@dhcp-169-229-212-31.LIPS.Berkeley.EDU) has joined #fluid-work
[11:42:19 EST(-0500)] <Bosmo1> Surely our user and design community didn't tell us that "submit on blur" is always desirable
[11:42:52 EST(-0500)] <Bosmo1> Oh wow.... this cadenza is DEFINITELY in meantone
[13:14:43 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:21:53 EST(-0500)] <colinclark> Bosmo1: I've been in a meeting and am just catching up on your comments.
[13:23:04 EST(-0500)] <colinclark> Bosmo1: The designers were clear that for the simple text editing, "submit on blur" was exactly right. But if you look at the other flavours of Inline Edit, it's clear that this should be an option.
[13:23:14 EST(-0500)] <colinclark> In my TinyMCE mockup, I had save and cancel buttons available.
[13:23:23 EST(-0500)] <colinclark> And interestingly, it seemed to not properly fire blur events anyway.
[13:23:59 EST(-0500)] <colinclark> There are public methods on Inline Edit that would allow users to bind their own buttons; finish() and cancel().
[13:24:27 EST(-0500)] <colinclark> I expect that we'll supply this markup and bindings for some of the pre-baked flavours of Inline Edit.
[13:24:33 EST(-0500)] <colinclark> Users will of course be free to customize or roll their own.
[13:32:11 EST(-0500)] <Bosmo1> OK
[13:32:18 EST(-0500)] <Bosmo1> I have now added an option for "submitOnEnter"
[13:32:28 EST(-0500)] <Bosmo1> And I will now make another one for "submitOnBlur"
[13:32:48 EST(-0500)] <colinclark> That makes sense to me.
[13:33:05 EST(-0500)] <Bosmo1> A "first pass" "view-ized" InlineEdit is now in trunk
[13:33:12 EST(-0500)] <colinclark> I saw the commit. I'll take a look.
[13:33:15 EST(-0500)] <Bosmo1> More of the code needs to be folded into the "view"
[13:33:26 EST(-0500)] <Bosmo1> For example, all this crazy nonsense relating to "showNothing" etc.
[13:33:56 EST(-0500)] <colinclark> Bosmo1: Yes, exactly.
[13:34:20 EST(-0500)] <colinclark> It's not such crazy nonsense. But it will be less hairy when it has been folded into the View.
[13:34:26 EST(-0500)] <Bosmo1> Well
[13:34:28 EST(-0500)] <colinclark> No quotes necessary.
[13:34:35 EST(-0500)] <Bosmo1> It is somewhat crazy in that it is not correct
[13:34:44 EST(-0500)] <colinclark> How is it not correct?
[13:35:02 EST(-0500)] <Bosmo1> it is not correct because it checks the actual contents of the element in order to see whether it should be considered default text
[13:35:13 EST(-0500)] <Bosmo1> Justin made a bug for it a couple of months back...
[13:35:25 EST(-0500)] <colinclark> aha
[13:35:40 EST(-0500)] <colinclark> You use the term "correct" somewhat like a blunt instrument.
[13:35:46 EST(-0500)] <Bosmo1>
[13:35:53 EST(-0500)] <colinclark> I suppose correctness is something special for mathematicians.
[13:36:04 EST(-0500)] <Bosmo1> http://issues.fluidproject.org/browse/FLUID-1320
[13:36:05 EST(-0500)] <Bosmo1> Here, this
[13:36:08 EST(-0500)] <colinclark> Cool, thanks.
[13:36:19 EST(-0500)] <colinclark> haha
[13:36:23 EST(-0500)] <colinclark> Yes, this one is hilarious.
[13:36:33 EST(-0500)] <Bosmo1> I don't know, don't you feel something could be considered "not correct" if it has an open JIRA against it?
[13:37:04 EST(-0500)] <colinclark> It's one of those bugs that is both silly in that it exists, and silly that it would actually occur in reality.
[13:37:16 EST(-0500)] <Bosmo1> Yes
[13:37:24 EST(-0500)] <colinclark> Well, correctness aside, it might be clearer if you simply described it as "having a bug."
[13:37:32 EST(-0500)] <Bosmo1> ...
[13:37:34 EST(-0500)] <colinclark> I believe that phrase is uniquely correct in this situation. ;P
[13:37:45 EST(-0500)] <Bosmo1> Not really
[13:37:56 EST(-0500)] <colinclark> I am just teasing you, anyway.
[13:38:02 EST(-0500)] <Bosmo1> It possibly incorrectly constrains the number of bugs that may be present in the implementation
[13:38:14 EST(-0500)] <colinclark>
[13:38:52 EST(-0500)] <Bosmo1> Rather than "incorrect", Steve Lay here sometimes likes to refer to features or implementations as "unsuitable"
[13:39:00 EST(-0500)] <Bosmo1> I am not sure if this is any clearer or not
[13:39:10 EST(-0500)] <colinclark> I find that terminology appealing.
[13:39:22 EST(-0500)] <Bosmo1> Yes
[13:39:30 EST(-0500)] <Bosmo1> It is a bit like your definition of "inaccessible"
[13:39:38 EST(-0500)] <colinclark> haha
[14:36:46 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[15:40:24 EST(-0500)] <Bosmo1> I am spending a very long time trying to resolve FLUID-1326
[15:40:26 EST(-0500)] <Bosmo1> http://www.quirksmode.org/dom/range_intro.html
[15:40:34 EST(-0500)] <Bosmo1> This page is one of the most helpful I have come across so far
[15:40:42 EST(-0500)] <Bosmo1> But still not enough to build a working solution
[15:42:03 EST(-0500)] <Bosmo1> http://www.quirksmode.org/dom/w3c_range.html
[15:42:16 EST(-0500)] <Bosmo1> And this page, which he admits only tests function to the extent of "does this method throw an error"
[15:51:05 EST(-0500)] * Justin_o_ (n=Justin@142.150.154.101) has joined #fluid-work
[18:00:12 EST(-0500)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work