[whatwg] content editing (was Re: Request for new DOM property textarea.selectionText)

[David Young]

On Mon, Apr 30, 2012 at 08:55:04AM +0300, Aryeh Gregor wrote:
> On Sun, Apr 29, 2012 at 11:39 PM, David Young <dyoung at pobox.com> wrote:
> > I'm curious what advantages document.execCommand() has over the
> > customary DOM API for adding/deleting/moving nodes?
> 
> execCommand() does vastly more complicated things than the DOM APIs.
> See the spec for details:
> 
> http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

First off, I have only skimmed this and, you could say, tested it
against my knowledge and experience of trying to create a word processor
using JavaScript.

I have to say that I'm uneasy with the way that this API wavers between
answering interaction-design questions and telling what ought to happen
to the DOM under, say, an execCommand('insertText').  Just for example,
lots of words are spent on just what to do when the user inserts two or
more consecutive whitespace characters where the white-space property
is 'normal' instead of 'pre-wrap'.  That seems like a question to leave
to the interaction designer.  Different word processors through the
years have treated consecutive spaces differently, especially in tricky
contexts like the right margin.

I say that it should be left to the interaction designer because when an
intern and I explored the idea of embedding a word-processor directly
into a web pages using JavaScript/DOM, I remember discovering no fewer
than three different right-margin behaviors in a survey of Apple's
TextEdit application, MS Word, the Canon Cat (an "information appliance"
from 1987).  Then I invented a fourth behavior.  There was not an
obstacle to implementing each in the DOM.  I'm sure that each behavior
must have its fans and its detractors, but when I demonstrated the
differences in a staff meeting, the behavior of MS Word so defied the
expectations of one MS Word-using engineer that he protested that it
*could not be*.

So, anyway, I question the wisdom of standardizing such fine points of
the UA behavior as what two taps of the spacebar will do: I believe that
reasonable people can disagree, and setting a standard seems premature.

There do seem to be a couple of areas where web standards seem
to be lacking if you aspire to write a JavaScript/DOM word
processor.  One area is keyboard input: we had to use a table of
keycode->letter/function correspondences, (at least) one per browser, to
interpret keypresses consistently.  Another area is locating the precise
character position where a mouse click occurred: we found it doable by
binary search, but it was kind of a pain.  Locating and decorating the
"soft breaks" on a page was another pain point.

Dave

-- 
David Young
dyoung at pobox.com    Urbana, IL    (217) 721-9981