the previous version worked fine.

anyway, thanks for the knowledge-sharing

Thanks for the analysis. You’re right about hitting the ENTER key, looks like I broke something in a recent change.

The Save callback is where you should put your save logic. The idea is that this widget simply enhances a plain text area to allow editing. Whether one decides to do an Ajax post or save values to a hidden field is up to the developer to decide in the Save callback. A demo to show this is a good idea. I’ll give that a think.

this.value() is used to centralize getting/setting the current value. The value is set on init and also set whenever a change is made. Additionally the benefit of being a UI widget is the options value could be changed programmatically at anytime:

$('#editable').inlineEdit('option', 'value', 'My Value');

This is a great concept for a jQuery UI plugin, but I ran into a few glitches I’m trying to solve.

- The “ENTER” key doesn’t behave like “Save” as the feature list suggests, in IE it posts the dynamically constructed form, in FF it doesn’t do anything. This true of the demo as well.

- The demo also doesn’t save any values you enter, I’m not sure if that’s because you’re supposed to provide your own save implementation in a hook, and if so, can the demo show a simple changing of values on the client-side? It looks to me like the intention is to change the value of the .editable element, but this is not happening.

- It appears the widget intialization code takes the value of the .editable element on init, but in my case that may have changed dynamically before inline editing takes place. I think this can be solved by changing the “_uiInlineEditHtml” function to use “this.element.text();” rather than “this.value()” since this will grab the options value that was set on load, and not necessarily what the element’s value is now.