contenteditable is not 2-way-bound

[pYr0x]

this example shows two each loops.
first one with a contenteditable div
second one with a standard inputfield
http://jsbin.com/zuxececoce/1/edit?js,console,output

the first editable div is not working, while the standard input field is working live expected
cc @phillipskevin

[chasenlehara]

Here’s a slightly more simple example that doesn’t use a DefineList or #each: https://jsbin.com/wihobujere/1/edit?js,console,output

[bmomberger-bitovi]

After some discussion on the Gitter channel we've discovered that the presence of jQuery in the example JSBins is the thing causing this breakage. When jQuery is removed, the correct 2-way binding behavior happens.

Why jQuery causes this, is as yet unknown

[pYr0x]

really strange...
i dont know how canjs today implemented the change event on a contenteditable div.
but it seems, that the input-event is also fired for contenteditable elements.
see: https://developer.mozilla.org/en-US/docs/Web/Events/input
maybe we have to implement a sepical case for contenteditable elements

[pYr0x]

maybe this is the right solution.
https://jsbin.com/cowucix/1/edit?js,console,output
not to use the innerHTML change event. instead use the blur event.

here are some examples:
https://jsbin.com/giyexun/1/edit?js,console,output -> with contenteditable and the blur event. this is the same behaviour like an input element
https://jsbin.com/pugitow/1/edit?js,console,output -> standard input value binding.

typeahead:
https://jsbin.com/yehonud/1/edit?js,console,output -> if you want a input-element and a typeahead behaviour then this is pretty standard with canjs.
https://jsbin.com/gozoxof/1/edit?js,console,output -> typeahead with contenteditable is not that easy like the input example.

@phillipskevin is there a way to add some syntactic suger for the cotentedtiable element. or is the better way to create a custom element with that logic (e.g. typeahead with range-selection)

[phillipskevin]

@pYr0x I can't quite remember what we talked about, but for this example:

<div contenteditable="true" on:blur="change(~this.name, scope.element)">

did you not want to use this instead?

<div contenteditable="true" on:blur:innerHTML:to="name">

[bmomberger-bitovi]

Did something change around the on:...:to syntax recently? Last I understood it, on:event:X:to only works for X =value