W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: hit testing and retained graphics

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Tue, 12 Jul 2011 18:38:53 -0400
Message-ID: <CAKA+Axk7c3Kbfz63JhyHggtBwjAEBBxOy2zLx38iigfRTSy+sA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: John Foliot <jfoliot@stanford.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On Thu, Jul 7, 2011 at 10:55 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> "rich text editing"
> I think that the only good solution here is to severely improve
> contentEditable. Currently contentEditable is a pain for authors to
> use because it doesn't provide a low level API, only high-level things
> like execCommand. It also works dramatically different in different
> browsers and with lots of different bugs in all browsers. It's really
> quite terrible. It's not surprising that some developers have said
> "screw it" and attempted to do better using canvas.
>
> There's been some ideas floating around within mozilla for what type
> of API we should expose, but so far no one has had the time to
> prototype anything. I really think this needs to be made a higher
> priority on the web platform in general. Not just to make text editing
> more accessible for AT users, but for non-AT users as well.

I missed this before, but let me add: currently I'm more or less done
writing a preliminary specification for execCommand() and friends,
including certain aspects of contenteditable behavior
<http://aryeh.name/spec/editcommands/editcommands.html>.  It specifies
basically all the commands that browsers actually support, plus some
further things like how to handle some types of user input (text
input, Enter, Shift-Enter, Delete, Backspace).  I'm in the process of
cleaning it up and fixing some remaining details, and when I'm done
with that it should be ready for serious implementer review and
initial implementation.

This will lay the groundwork for consistent contenteditable behavior
across browsers (and consistent execCommand() behavior especially),
which should eventually remove one of the biggest impediments to
serious use of contenteditable.  As time permits, I intend to specify
more features of how contenteditable works to allow still further
interoperability.  And although I haven't attempted to add any
significant new features in the current draft, I do think it would be
pretty easy to add low-level primitives that let authors create their
own commands, as soon as I'm confident that the underlying algorithms
are all stable.

So I'm just pointing out that there's some real progress being made on
this front.  Of course, it's not good for much until implementation
starts.
Received on Tuesday, 12 July 2011 22:39:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:36 GMT