[whatwg] Ongoing work on an editing commands (execCommand()) specification

Hi everyone.

Firstly, I'm very happy to see some action in this area, and sorry
that I'm catching up with the thread with a delay.  I'll try to
respond to individual messages where I have something to say, to make
following the thread easier.

On 11-03-13 4:46 PM, Aryeh Gregor wrote:
>
> I did some research, looking at three different rich editing suites:
> vBulletin's WYSIWYG editor, jwysiwyg (a jQuery plugin), and TinyMCE
> (used by Wordpress).  I also looked at CKEditor, but I don't think it
> uses execCommand() at all.  My full notes are at
> <http://aryeh.name/spec/editcommands/notes.txt>.  One thing I found is
> that all three set styleWithCSS to false.  This reinforces my theory
> that styleWithCSS = true is not useful (although I'm still open to
> counterexamples).

I don't think this is a useful argument for not supporting the CSS
mode.  But if you're looking for examples, a quick Google search
suggested that elRTE can take advantage of the CSS mode (possibly
among many other rich text editing frameworks).

> I've already gotten a bunch of WebKit feedback, so I'd appreciate
> feedback from Mozilla and Opera.  (And Microsoft, if anyone can tell
> me how to get feedback from them.)  Particular questions I'm currently
> not so sure about:
>
> 1) Is there any reason to keep styleWithCSS/useCSS in its current
> form?  Only Gecko and WebKit support it.  Trident and Presto only
> support the equivalent of styleWithCSS = false, and the three rich
> editors I studied force styleWithCSS to false unconditionally.  I can
> see the value in a mode that doesn't produce invalid markup like
> <font>, but is there any reason to have a mode that produces markup
> like<span style="font-weight: bold">  instead of<b>?

I would argue that both modes are useful, depending on the situation.
Here is a usecase for each of them.

CSS mode: Suppose that you're writing a wiki-like web app, and your
task is to enable editing of individual paragraphs (with a floating
UI, similar to what Aloha does for example) or sections within a large
document.  Let's assume that you don't have much control over the rest
of the page content.  It's possible for the page to contain sanitizing
CSS rules such as b, strong { font-weight: normal }, and you want to
make something bold in a paragraph contained in such a document.  The
easiest way to go around doing that is with the CSS mode, and relying
on the CSS cascading rules to get the desired effect.

Non-CSS mode: Suppose that you're writing a web based email editor.
Your task is to create HTML emails, and automatically format the
plaintext version of the email on the server side using simple rules
such as wrapping bold text with asterisks, or italic text with
underscores.  You can set the client side editor to use the non-CSS
mode, and then use an off-the-shelf Python HTML parser library to
parse the simple HTML tags and replace them with the correct
characters. Having to deal with CSS in that case means that you have
to write a full-blown CSS parser and support style resolution on each
node, which is not trivial.

I can give you more examples for each case, but I think the above two
help me to drive this point home: there are legit usecases for both
cases, and since they've both been around for quite a while, I don't
see the existing implementations drop this support (or even worse,
adopt a mixed mode).  Backwards compatibility is what this boils down
to.

> 2) How much work should we go to to produce nice-looking markup?
> E.g., if the user unbolds "baz" in
>
> <div style="font-weight:bold">
> <p>Foo
> <p>Bar baz
> </div>
>
> should we produce something like
>
> <div>
> <p style="font-weight: bold">Foo
> <p><b>Bar</b>baz
> </div>
>
> like WebKit does, or would it be okay to do
>
> <div style="font-weight:bold">
> <p>Foo
> <p>Bar<span style="font-weight: normal">baz</span>
> </div>
>
> to avoid the complexity, given that this sort of markup shouldn't be
> too common?  I think it's clear that something like "<b>Foo baz
> bar</b>" should become"<b>Foo</b>baz<b>  bar</b>" and not"<b>Foo
> <span style='font-weight: normal'>baz</span>  bar</b>", but how far
> should we go?

I think simpler DOM structures should be preferred, and we can't give
away simple DOM structures for the sake of simpler algorithms.
Browsers tend to have buggier behavior when it comes to editing more
complex DOM structures, and one should also keep in mind that editing
operations are additive: having one command generate a complex DOM
would cause the next one to generate even more complex DOM, and so on.

Cheers,
--
Ehsan Akhgari
Mozilla Corporation
http://ehsanakhgari.org/

Received on Friday, 18 March 2011 23:04:37 UTC