On Sat, 28 Aug 2010 03:16:16 +0200, Ojan Vafai wrote:
WebKit has added the input event to contentEditable nodes. That part of
this proposal seemed non-controversial. Do other browser vendors support
changing the description of this event to apply to contentEditable nodes
as well?
Yeah, se
WebKit has added the input event to contentEditable nodes. That part of this
proposal seemed non-controversial. Do other browser vendors support changing
the description of this event to apply to contentEditable nodes as well?
Ojan
On Wed, Jun 16, 2010 at 5:33 PM, Ojan Vafai wrote:
> I've start
I've started a parallel discussion re: textInput on www-dom.
http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html
On Wed, Jun 16, 2010 at 5:13 PM, Ojan Vafai wrote:
> We've given this a bit more thought and come the the conclusion that
> textInput basically does what we want out of b
We've given this a bit more thought and come the the conclusion that
textInput basically does what we want out of beforeInput, except that it
doesn't currently fire for actions like undo/redo. So, basically, we're
proposing that textInput should fire for any DOM modifying event and,
ideally, that i
On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky wrote:
> So I have to ask... Why are events _before_ the edit needed?
>
> If we add these, then you have to define what happens when those event
> handlers modify the state of the DOM in arbitrary ways, including carrying
> out operations that spin th
On 3/4/10 4:11 AM, Ojan Vafai wrote:
WebKit would like to implement this in the (very) near future. Before
proceeding, we'd like to hear from other browser vendors that you're
roughly on board with this direction of adding beforeinput and input events.
Here are the changes I can think of that wo
On 3/3/10 9:31 PM, Daniel Danilatos wrote:
Worth noting, the events should convey the user intent - so, e.g. not
just "delete chars 5 - 8" but "forward word delete, which is chars 5 -
8".
So I have to ask... Why are events _before_ the edit needed?
If we add these, then you have to define what
WebKit would like to implement this in the (very) near future. Before
proceeding, we'd like to hear from other browser vendors that you're roughly
on board with this direction of adding beforeinput and input events.
Here are the changes I can think of that would result from this:
1) Fire "input" e
On Tue, 23 Jun 2009, Ojan Vafai wrote:
>
> Currently, textareas and text inputs support the "oninput" event that
> fires on all user-initiated modifications to their content. We should
> add this event to contentEditable elements as well and add an "action"
> property the specifies what action t
On Wed, Jun 24, 2009 at 11:51 AM, Olli Pettay wrote:
> On 6/24/09 6:49 PM, Anne van Kesteren wrote:
>
>> On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay
>> wrote:
>>
>>> Why would you need "paste"? There is "paste" event
>>> (though, not properly specified anywhere, I think);
>>>
>>
>> I'd think
On Wed, 24 Jun 2009 20:51:27 +0200, Olli Pettay
wrote:
Why would you want to nuke textInput? Perhaps textInput (in some
extended form) could be used for contentEditable and we could deprecate
input event. textInput has the advantage that it has .data
If that is useful why not add .data to t
Michael A. Puls II wrote:
And Mozilla ?
https://developer.mozilla.org/En/DOM_Events#textInput
I tested it on a textarea in Firefox latest trunk before posting. It
didn't fire.
Yeah, that documentation was apparently authored by copy/paste from the
spec...
Fixed it to make it clear that th
On 6/24/09 6:49 PM, Anne van Kesteren wrote:
On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay
wrote:
Why would you need "paste"? There is "paste" event
(though, not properly specified anywhere, I think);
I'd think you want an event that covers all editing actions. Also,
that's what the input e
On Wed, 24 Jun 2009 14:39:55 -0400, Thomas Broyer
wrote:
On Wed, Jun 24, 2009 at 6:41 PM, Michael A. Puls
II wrote:
On Wed, 24 Jun 2009 11:49:27 -0400, Anne van Kesteren
wrote:
By the way, did anyone ever implement textInput from DOM Level 3
Events?
Just Webkit.
And Mozilla ?
https:
On Wed, Jun 24, 2009 at 6:41 PM, Michael A. Puls II wrote:
> On Wed, 24 Jun 2009 11:49:27 -0400, Anne van Kesteren
> wrote:
>
>> By the way, did anyone ever implement textInput from DOM Level 3 Events?
>
> Just Webkit.
And Mozilla ?
https://developer.mozilla.org/En/DOM_Events#textInput
--
Thoma
On Wed, 24 Jun 2009 11:49:27 -0400, Anne van Kesteren
wrote:
By the way, did anyone ever implement textInput from DOM Level 3 Events?
Just Webkit.
--
Michael
On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay
wrote:
Why would you need "paste"? There is "paste" event
(though, not properly specified anywhere, I think);
I'd think you want an event that covers all editing actions. Also, that's
what the input event does for .
By the way, did anyone ev
On Tue, 23 Jun 2009 21:42:18 -0400, Ojan Vafai wrote:
SUMMARY
Currently, textareas and text inputs support the "oninput" event that
fires
on all user-initiated modifications to their content. We should add this
event to contentEditable elements as well and add an "action" property
the
spe
On 6/24/09 4:42 AM, Ojan Vafai wrote:
SUMMARY
Currently, textareas and text inputs support the "oninput" event
The event is "input" ;)
that
fires on all user-initiated modifications to their content. We should
add this event to contentEditable elements as well and add an "action"
property the
SUMMARY
Currently, textareas and text inputs support the "oninput" event that fires
on all user-initiated modifications to their content. We should add this
event to contentEditable elements as well and add an "action" property the
specifies what action the user took that caused the input event.
W
20 matches
Mail list logo
