W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 11 Jan 2012 16:35:39 -0800
Message-ID: <CANMdWTvWhxi821Uig2NLUrcGEPSPGr8kWda+-1EzxxQCW0s_Ug@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Charles Pritchard <chuck@jumis.com>, WebApps WG <public-webapps@w3.org>
On Wed, Jan 11, 2012 at 8:15 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard <chuck@jumis.com>
> wrote:
> > Historically, one of my biggest frustrations with contentEditable is that
>
> you have to take it all or none. The lack of configurability is
> frustrating
> > as a developer. Maybe the solution is to come up with a lower level set
> of
> > editing primitives in place of contentEditable instead of trying to
> extend
> > it though.
>
> Yes, that's definitely something we need to do.  There are algorithms
> I've defined that would probably be really useful to web authors, like
> "wrap a list of nodes" or some version of "set the value of the
> selection" (= inline formatting algorithm).  I've been holding off on
> exposing these to authors because I don't know if these algorithms are
> correct yet, and I don't want implementers jumping the gun and
> exposing them before using them internally so they're well-tested.  I
> expect they'll need to be refactored a bunch once implementers try
> actually reimplementing their editing commands in terms of them, and
> don't want to break them for authors when that happens.
>

Yup. Make sense. I agree that with editing we're not at a point where it's
at all clear what a good lower-level API would be.
Received on Thursday, 12 January 2012 00:36:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT