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

[Aryeh Gregor]

On Wed, Sep 5, 2012 at 10:37 PM, David Young <dyoung at pobox.com> wrote:
> 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.

See the todo here, at the top:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#additional-requirements

Conceivably, some things could be left unstandardized, with each
implementer choosing how to do it based on platform conventions, etc.
However, based on the unpleasant experience that we've had in the past
when editors leave browser behavior undefined, I chose to err on the
side of precisely specifying as much as possible.  If I get
implementers coming to me and saying that one specific feature should
be allowed to vary because they want to implement it differently, then
I'll add specific exceptions at that point, ideally as narrow as
possible.

> 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*.

This suggests that perhaps the behavior of some of those was just a
bug.  Anyway, what behavior would you suggest as a possible
alternative?  Remember that our hands are tied somewhat here -- we're
restricted to things that can be expressed as one-off DOM mutations.
execCommand() can't persist state other than in the DOM itself.

Also, keep in mind that for web stuff, interop is important in its own
right.  TextEdit and Word are different programs and are meant to have
different functionality.  But the *same* website shouldn't vary in
behavior just because the user uses a different browser, in general.
We want browsers to be as interchangeable as possible, so users can
easily switch between them.  The authors of Word do not highly
prioritize interchangeability with competitors, to put it mildly.  :)

> 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.

In the happy event that we have no fewer than two implementers who
look at the spec and want to implement it to the last detail, I will
be delighted to reconsider this point.  For the time being, no one is
seriously implementing it at all, so I think it's premature to make
changes based on what implementers might possibly think when they do
get around to implementing it.  :)

> 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.

The editing spec doesn't intend to give you tools to write your own
word processor using DOM APIs.  The intent is to write a spec for a
preexisting poorly-designed API that was made up by Microsoft in the
1990s, and subsequently copied inaccurately by other browsers, which
in turn all added their own unspecified extensions and quirks.

I agree that if you were actually trying to write a good editor from
scratch, contenteditable is not what you want at all.  And in fact,
most real-world editors use contenteditable as little as possible, and
execCommand() not at all.  But we still have to spec it.  Browsers
have to support the API for compatibility with existing content,
regardless of how terrible it is as an API.