Re: Bug 11239

On Thu, Apr 28, 2011 at 8:10 AM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> Nobody should be given carte blanche to write whatever they please in
> the HTML specification without process approval. If Ian wants to make
> changes like this he should submit a bug later on.

You may notice that what you reviewed was a proposed patch, sent to
solicit precisely this kind of feedback.


> 1. Ian's patch introduces technical extrapolations, leading to inaccuracies,
> in the following comments. Also, not all applications require you to enter
> text need to do all of what he is stating such as implementing drag and
> drop. Also, contenteditable sections or standard UI controls don't do all of
> what is needed in HTML. Take this one: http://www.lucidchart.com/ How does
> one enter text in a drawing object with out editable text in the canvas?
> This is not an application you would create with a contenteditable section
> of HTML. No drag and drop is required. No copy and paste is required, etc. I
> could go on but this editorial comment is so limited in scope (full blown
> rich text editing) that it should not be in the spec. in the first place.
> Worse, this does not reflect the chairs decision.
>
> Ian's editorial comments in the draft:
>
> "Authors should avoid implementing text editing controls using the + canvas
> element. Doing so has a large number of + disadvantages:
> + +
>
> + +
> Mouse placement of the caret has to be reimplemented. + +
> Keyboard movement of the caret has to be reimplemented (possibly across
> lines, for multiline text input). + +
> Scrolling of the text field has to be implemented (horizontally for long
> lines, vertically for multiline input). + +
> Native features such as copy-and-paste have to be reimplemented. + +
> Native features such as spell-checking have to be reimplemented. + +
> Native features such as drag-and-drop have to be reimplemented. + +
> Native features specific to the user, for example custom text + services,
> have to be reimplemented. This is close to impossible + since each user
> might have different services installed, and there + is an unbounded set of
> possible such services. + +
> Bidirectional text editing has to be reimplemented. + +
> Text selection has to be reimplemented. + +
> Dragging of bidirectional text selections has to be reimplemented. + +
> Platform-native keyboard shortcuts have to be reimplemented. + +
> Platform-native input method editors (IMEs) have to be reimplemented. + +
> Undo and redo functionality has to be reimplemented. + +
> Accessibility features such as magnification following the + caret or
> selection have to be reimplemented. + +
>
> + +
>
> This is a huge amount of work, and authors are most strongly + encouraged to
> avoid doing any of it by instead using the + input element, the textarea
> element, or + the contenteditable + attribute.
> + +
>
> Authors that eschew these existing solutions and instead take on + the
> monumental task of implementing a text editor from scratch must + expose the
> position of the caret and selection using the setCaretSelectionPos() +
> method. "

Every single point in Ian's comment is correct.  Text editting is one
of those things that appears very simple when you first look at it
(just draw a rectangle and a carat, and put the letters in as the user
types) but is actually ridiculously complex and difficult to get
right.  You claim that LucidChart doesn't need DnD or C&P.  This is
probably wrong (C&P is always useful) and it also ignores all the
other points that Ian makes.  If I'm making a chart in Chinese and use
an IME to input characters, I'd be pretty unhappy if the app creator
decided they desperately needed to implement their own text control
and thus my IME doesn't work.  Similar points for if I'm using mixed
English and Arabic - the app author almost certainly isn't going to
reimplement the bidi formatting algorithm, which means my text is
going to look messed up.

In general, you should never implement a text editor yourself.  It's a
silly amount of work that the browsers have already done for you.


> 4. This was not in the chairs decision either. I have no idea where this
> came from:
>
> -<span>Navigator</span> implements <span>NavigatorStorageUtils</span>;</pre>
> +<span>Navigator</span> implements <span>NavigatorStorageUtils</span>;
> +<span>Navigator</span> implements
> <span>NavigatorUserPreferences</span>;</pre>

I believe NavigatorUserPreferences is the interface that exposes
caretBlinkPeriod.

~TJ

Received on Thursday, 28 April 2011 16:11:06 UTC