- From: David Young <dyoung@pobox.com>
- Date: Wed, 5 Sep 2012 14:37:58 -0500
- To: whatwg@lists.whatwg.org
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@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@pobox.com Urbana, IL (217) 721-9981
Received on Wednesday, 5 September 2012 19:38:27 UTC