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

[Simon Pieters]

On Wed, 05 Sep 2012 21:37:58 +0200, David Young <dyoung at pobox.com> wrote:

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

I disagree. The browsers have to do something when the user hits multiple  
times. I would prefer if all browsers ended up with the same result.

If you think the spec's behavior when hitting space multiple times is  
sub-optimal, we can change it to something better.

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

I believe that's something that DOM3Events or its successor should address.

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

Mouse clicks are currently totally undefined in the Web platform. Awaiting  
a spec editor for it.

http://wiki.whatwg.org/wiki/Specs_todo#APIs

> Locating and decorating the
> "soft breaks" on a page was another pain point.

Interesting. I guess this is only needed for editable content? Is an  
arbitrary Unicode character enough for decoration, or do you want to be  
able to use an image? Do you want to be able to style it? If we add this I  
think we should do it in a way such that the decoration cannot affect the  
line breaking algorithm.

cheers
-- 
Simon Pieters
Opera Software