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

Fri Mar 4 10:58:30 PST 2011

On Thu, Mar 3, 2011 at 5:45 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Backward compatibility.  I suspect that there are many web contents that
> depend on styleWithCSS available on WebKit / Gecko.

Generally, I've been assuming that sites that already use
execCommand() will either 1) not depend on particular markup, since
the markup tends to vary so widely between browsers, so any markup
that achieves the same effect is okay; or 2) use browser-sniffing, in
which case they'll break no matter what when things are standardized.
In other words, I think there's going to be some level of
compatibility pain no matter what when browsers converge here.  So I'm
not enthusiastic about complicating things for possibly lessening that
pain unless it's clearly necessary.

I do plan to look at some high-profile execCommand() users at some
point to get an idea of how they use the API.  The nature of the API
is such that relatively few independent authors will use it, compared
to most other HTML features, so I'm optimistic that we can work out
compat issues without too much pain.

Needless to say, though, in the end I'll spec what the implementers
want to implement.

>> data:text/html,<!doctype html>
>> <div style="font-weight: lighter" contenteditable=true>
>>    <p>Hello
>> </div>
>> <div style="font-weight: lighter" contenteditable=true>
>>    <p>Hello
>> </div>
>> <script>
>> document.execCommand("styleWithCSS", null, true);
>> getSelection().selectAllChildren(document.querySelector("p"));
>> document.execCommand("bold", null, null);
>> document.execCommand("styleWithCSS", null, false);
>> getSelection().selectAllChildren(document.querySelector("div + div > p"));
>> document.execCommand("bold", null, null);
>> getSelection().removeAllRanges();
>> </script>
>>
>> In Firefox/Chrome, first "Hello" is bold, second is not.
>
>
> That just sounds like a bug.  I admit that many execCommand implementations
> are buggy but I don't think that'll no way justify dropping a
> feature depended by web contents.

The issue is that the CSS mode outputs font-weight: bold, while the
HTML mode outputs . The default style of is font-weight:
bolder, not font-weight: bold. font-weight: lighter followed by
font-weight: bolder results in font-weight: normal. I don't know if
this can be fairly called a bug. My point is that presentational
elements and CSS work differently in some cases, so you risk weird
mismatches like this in some cases.

> I'm not sure.  IE used to use b for bold, i for italic and so forth but now
> it uses strong and em respectively.  And I'm sure there was a strong
> motivation to do so given b and i are deprecated in HTML4.  And you must
> realize that browsers need to be able to remove em, strong, other
> non-presentational elements added by IE, and style spans added by Gecko and
> WebKit when removing or applying styles for the backward compatibility.
>  Because not being able to remove those elements result in not being able to
> apply style properly.

Yes, the algorithms will definitely be able to handle existing methods
of styling no matter what. When speccing bold, I made a test page
with every way I could think of of making things bold or not bold with
inline style, including , , and various font-weights (bold,
normal, lighter, bolder, 100, 900). I made sure my algorithm could
correctly handle all of them. But that doesn't mean it has to have
multiple *output* modes, when the user adds new styles.

> Also note
> that b and i have semantic meanings and aren't purely presentational in
> HTML5 (after all, that was the justification to add them back).

This issue strikes me as being one of theoretical purity.  What are
the *practical* reasons authors would want CSS-based markup instead of
presentational tags?

> I agree that style spans are verbose and probably undesirable.  However, how
> do you specify font size, font family, and font color?  WebKit currently
> uses font element when styleWithCSS=false.  But font element is deprecated
> and removed from HTML5 already.  How do we support this important feature?

How do you support hiliteColor?  You just have to always use CSS.

>  As far as I can tell, WebKit can't drop the support for stylization by a
> font element due to the backward compatibility because WebKit is also used
> in a mail client and old mail clients doesn't support CSS at all.

Personally, I hoped we wouldn't have to output , because 
is really ugly. Authors shouldn't have to deal with stuff like this:

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value

Or font sizing on a one-to-seven scale that maps to CSS values by
skipping x-small and adding an extra value after xx-large.

But karlcow in #whatwg linked me to this chart:

http://www.campaignmonitor.com/downloads/documents-tools/Campaign_Monitor_Guide_to_CSS_Support_in_Email_April_2010.pdf

Apparently Blackberry, at least, doesn't support font-family or
font-size in e-mail. So it sounds like is still needed for
now, sadly. But we don't want to output it for web pages, where it's
not needed, so I suppose we do need two modes. However, I'd like them
to differ less than they do in the major browsers. How about this:

1) Always use tags (, , etc.) if they're conforming, even in CSS mode.

2) In CSS mode, use CSS where the tag isn't conforming (, etc.)
or there is no tag (like hiliteColor).

3) In non-CSS mode, use tags where available even if not conforming
(, etc.), and only use CSS if there's no tag for the feature
(like hiliteColor).

4) Interpret parameters as consistently as possible between CSS and
non-CSS modes. E.g., for foreColor, output directly as a CSS color in
CSS mode; in non-CSS mode, translate the CSS color to a simple #123456
type color and use that for . (Unless it's a color that 
doesn't support, like with alpha; then I guess use CSS.) This avoids
having the same command achieve different visual effects in different
modes. WebKit already behaves something like this, but Gecko doesn't
(see my earlier color=ff0000 example).

5) CSS mode should be the default.

How does that sound?

> But browsers are already consistent with respect to styleWithCSS.  Why do we
> want to drop this well-supported feature and add completely new third-mode
> that uses both elements and CSS to style text?

Browsers aren't already consistent with respect to styleWithCSS. IE
and Opera ignore it. Gecko and WebKit both honor it, but in
substantially different ways. E.g., with styleWithCSS on, Gecko will
output something like Foo if you bold
a paragraph, while WebKit will output something like Foo.

Actually, browsers are consistent with almost nothing related to
execCommand().  Everyone is going to have to change a lot to converge
on common ground.  All else being equal, asking Gecko and WebKit to
greatly simplify their second mode makes more sense than asking IE and
Opera to implement a more complicated second mode -- it's always
easier to drop features.

> I believe some editors depend on Firefox and WebKit generating CSS-only
> styles when styleWithCSS is set true.

Do you know which editors, and why they depend on that, and how they
handle IE or Opera?  Also, do you know whether those sites also depend
on IE and Opera *not* generating CSS-only styles with styleWithCSS set
to true?  Again, some sites are inevitably going to break when
browsers converge, so this isn't a good argument unless you think the
opposite change will cause less breakage.

It's fair to argue for not changing things when browsers are already
agreed on them, but browsers aren't agreed on this, and it's not
obvious a priori what change will cause the least amount to break. So
I'm going to err on the side of simplification unless there are strong
arguments presented against it. (Which the e-mail argument seems like
it is, but only to a point -- I've still seen no reason anyone would
want instead of .)

> Are you saying that many browsers don't render / interpret HTML generated
> AFTER execCommand is executed by some browser?  It doesn't really matter
> whether or not existing browsers can properly execute commands.  My point
> here is that the resultant HTML should be rendered / interpreted by all
> browsers.

My point is that every browser except WebKit does nothing useful here
to begin with. If instead of doing nothing, they add , and that only works in the
newest browsers -- well, that's an improvement over their previous
behavior. At least it would work in *some* browsers.

> If our implementation has a bug, then we'll fix it.  I don't think bugs in
> the existing implementations are justifications to further break the
> existing features.  Simple algorithm is good only if it's correct.

A complicated algorithm is also good only if it's correct.  But there
are lots of cases where it's impossible to be correct if you're trying
to push down the styles.  Like

<div style="text-decoration:underline"><div
contenteditable=true><p>Try to un-underline me!</div></div>

or

<u id=foo>Un-underline part of this text without duplicating the id or
changing what's contained in the id</u>

etc.  You might be right that this is necessary in the end -- although
only WebKit seems to do it! -- but there will always be cases where
it's just not possible, or inordinately complicated, and some behavior
needs to be available there that's at least potentially correct.

On Fri, Mar 4, 2011 at 1:17 PM, Markus Ernst <derernst at gmx.ch> wrote:
> - I assume that the list of commands is not complete, as some commands given
> in the HTML spec are missing, such as "formatBlock" or "insertHTML" - or is
> it your intention to drop these commands? For better understanding, it might
> be worth to clarify this.

Yes, the entire spec is very incomplete.  I think the Status of this
Document section makes this clear.

> - Please consider adding a generic "formatInline" command for applying all
> kinds of inline elements. A sophisticated RTE might e.g. want to provide
> separate "bold" and "strong" options for authors caring about this
> distinction.
>
> - I'd like a "className" command to be added. Corporate websites usually use
> a restricted set of formattings; in a CMS for such a website it should be
> possible to provide a select box with the respective CSS classes rather than
> font and color menus.
>
> - In the opposite case, where everything is allowed, users might want to
> apply CSS properties not covered by the command list, such as borders, or
> future fancy stuff such as shadows. For these cases, an "applyCSS" command
> could be helpful.

I am not currently contemplating feature requests.  I have enough work
to do defining the commands that browsers already implement.  Once the
spec is stable and interoperably implemented, hopefully within a few
years, it might be worth talking about new features.

> - Some CMS systems use different doctypes than the pages where the edited
> text is finally published. Content edited in an HTML5 page might be
> published in an XHTML page. While it is not too complicated to solve this in
> practice with server-side string editing - would it be possible to specify
> the desired HTML style for the output? (Which could result in different HTML
> styles in a contenteditable area and the surrounding document.)

What do you mean by "HTML style"?  HTML and XHTML are both
serializations of the same DOM-based language, so the same DOM-based
APIs should work for both (provided the markup can be serialized to
both syntaxes).  If you mean that the API should try to accommodate
obsolete languages like XHTML 1.0 or XHTML 2.0, I don't think that's a
valid use-case.

> Generally, I think that
> a future-proof execCommand() specification should rather provide generic
> commands for inline and CSS formatting, and support specific commands such
> as "bold" or "backColor" only for backwards compatibility reasons.

Generic commands actually wouldn't work well in a lot of cases,
because different CSS properties behave very differently.  A
background color cannot be treated the same as bold, for instance,
because they don't inherit the same way.