W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [editing] CommandEvent and contentEditable=minimal Explainer

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 20 Jun 2014 20:53:18 -0700
Cc: Julie Parent <jparent@google.com>, Olivier F <teleclimber@gmail.com>, Ben Peters <Ben.Peters@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <0CC4253E-604D-4126-9755-D5C2DAB02FE2@apple.com>
To: Piotr Koszuliński <p.koszulinski@cksource.com>

On Jun 17, 2014, at 9:00 AM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:

> 
> On Tue, Jun 17, 2014 at 2:39 AM, Julie Parent <jparent@google.com> wrote:
> I certainly understand the concern that it would be impossible to properly catch and cancel all events.
> 
> I'm not concerned only about this. I'm concerned about the fact that currently existing commands and editable-related features does not fit in a simple command APIs.
>  
>  But I think that is somewhat the point - it forces browser vendors to get these parts right.
> 
> The spec should guide engines' developers, because there's a single spec and many engines. Even if all browser vendors will get these parts right, they may choose different paths. And then, in general, this will be not right and it will be a pain for developers.
>  
>  All changes to an editable dom must fire an event before the modifications are made, and must be cancelable. Further, I'd say that if the number of events you would need to preventDefault on grows larger than selection, command, and maybe clipboard then that implies that we are not building the right APIs.
> 
> 
> I don't think that number of events implies that we are building a bad API. Dozen of well defined events is better than three that do too much in an unclear way.
> 
> Besides that, as an editor author I'm not only interested in preventing default action of features I don't want. I also want to hide them - remove them from browser UI like context menus, menu bar, or other widgets like special toolbar appearing over contenteditable on iOS. This makes the situation which spec has to describe much more complex. That's why I think it's better to focus on basics (http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0918.html) than on trying to make specification for every feature that was introduced in any engine in any away.

This makes me think that we want something like a white list of editing features to enable in a given editable element or perhaps * to enable them all.

e.g. <div contenteditable="inline-style copy paste dragdrop"></div>

- R. Niwa


Received on Saturday, 21 June 2014 03:54:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC