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

Mon Mar 21 10:25:40 PDT 2011

On Sat, Mar 19, 2011 at 1:23 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com> wrote:
> 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).

As I said, I looked at three rich-text frameworks that used
execCommand(), and all three forced styleWithCSS to false.  You're
right that elRTE has a styleWithCSS option, but it defaults to false,
so by default elRTE also forces styleWithCSS off.  Theoretically a
site using it could re-enable it, but are you aware of any site
actually doing so?  Just because the software supports it doesn't mean
anyone uses the feature.

(I looked through their source control, and the ability to force
styleWithCSS on/off was present in the first public release, but with
no default setting, so browsers just output default markup.  Later on,
a user complained about inconsistent markup between browsers, and a
developer defaulted the setting to false.)

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

In the face of arbitrary non-inline CSS rules, you can't rely on
cascading to work either.  What my current spec does is first try to
wrap things with tags, because that produces the nicest markup.  It
then checks if the desired style is actually present, and if not,
forces it using additional tags or inline CSS.  For instance, when
bolding

  Foo<span class="notbold">bar</span>baz

(where there's a rule .notbold { font-weight: normal }) I produce

  <b>Foo<span class="notbold"><b>bar</b></span>baz</b>

while WebKit and Gecko both produce

  <b>Foo<span class="notbold">bar</span>baz</b>

which gives incorrect appearance.  In styleWithCSS mode, Gecko and
WebKit respectively produce

  <div style="font-weight: bold;">Foo<span class="notbold">bar</span>baz</div>

(applying the style to the container) and

  <span class="Apple-style-span" style="font-weight: bold;">Foo<span
class="notbold">bar</span>baz</span>

which again both give incorrect appearance.

If I add b, strong { font-weight: normal } to my stylesheet, my
algorithm starts using , which works just
as well as and is slightly shorter.

So, I don't think this is a legitimate use-case.  Whether in CSS mode
or not, the algorithm should be robust enough to deal with conflicting
style rules -- the issue you raise is orthogonal.

> 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 agree that there are use-cases for not relying on CSS. I also agree
that there are use-cases for producing only conforming markup.
However, I don't see the use-cases for outputting instead of (et al.).

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

In the end I'm going to have to go with what implementers want to
implement here, but I'm still going to argue a bit more. :) The four
execCommand()-using rich text editors I've looked at so far all force
styleWithCSS to false. I'm planning to also look at some major
webmail clients' use of execCommand(), but I'm practically certain
they'll also force styleWithCSS false, because otherwise their mail
won't display right in (at least) Blackberry. Likewise, if you look
at the bug requesting that WebKit support styleWithCSS
<https://bugs.webkit.org/show_bug.cgi?id=13490>, it seems clear that
what the users there want is for WebKit to output things like 
instead of CSS, i.e., they just want WebKit to support it so they can
set it to false.

So I see lots of users who want styleWithCSS false, and not a single
one yet who wants it true.  I can't see a backward-compatibility issue
when there are no known sites that use of the feature, *and* when IE
and Opera have never supported it.

You probably know better than me, but I'm guessing the history of this
feature went something like this:

* In September 1997, Microsoft introduces the API in IE4. CSS is a
new technology that only cutting-edge browsers have support for, so
they output only tags like and , not CSS.
* In March 2003, Mozilla clones the API in Mozilla 1.3. CSS is now
well-established and widely supported, and tags like and 
are banned in HTML 4 Strict and XHTML 1 Strict. XHTML 2 removes them
from the language entirely. Thus Mozilla uses CSS instead. For
compatibility with IE or due to author demand or something, they also
add a useCSS feature to let you use deprecated tags instead, if you
don't care about conformance or use transitional formats.

If this is the case, the fact that styleWithCSS doesn't output tags
like or is because they happened not to be valid when it was
first devised. This is no longer relevant today. But there will be
authors today who want conforming markup that's *also* as short as
possible, which is what my proposed revision of styleWithCSS = true
gives -- something that's demonstrably useful.

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

I've rewritten my algorithm to produce (IMO) better markup in all
cases than any existing browsers.  There are only a few cases I've
thrown at it where it produces markup that's worse than I'd produce by
hand, like

  <i><b>Foo</b></i>bar<i><b>baz</b></i>

becoming (when you bold "bar")

  <i><b>Foo</b></i><b>bar</b><i><b>baz</b></i>

instead of

  <b><i>Foo</i>bar<i>baz</i></b>

but no browser I've looked at handles that better.  (Maybe I'll update
the algorithm to handle it, too -- it's probably not that uncommon in
practice.)

On Sat, Mar 19, 2011 at 1:39 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com> wrote:
>> I disagree.  The editing behaviors of browsers are fairly consistent
>> across
>> browsers as of now even though they fail to deal with many edge cases.
>>  While we should try to spec and agree on those edge cases, we shouldn't
>> suddenly change the overall editing behavior of execCommand at this point.
>
> I agree with Ryosuke here.

I also agree, in cases where browsers are actually consistent.  Where
browsers agree, I won't spec anything different without compelling
reason.  But browsers don't agree on styleWithCSS -- IE and Opera
don't implement it.