On Wed, 05 Sep 2012 21:37:58 +0200, David Young <dyo...@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 <dyo...@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
