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

Thu Mar 3 14:45:25 PST 2011

Great discussions!

On Fri, Mar 4, 2011 at 4:53 AM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

> On Wed, Mar 2, 2011 at 8:27 PM, Brett Zamir <brettz9 at yahoo.com> wrote:
> > Maybe the use of non-CSS mode was for backward-compatibility with earlier
> > versions or for easier overriding of styling in the target document
> (e.g.,
> > "b {color:red;}").
> >
> > Using CSS might have been added by Mozilla since [etc. . . .]
>
> This might or might not be the historical reason, but I'm really more
> interested in the future: should the spec support this option, or
> should we recommend that everyone just drop it?  What are reasons that
> we should keep it in the spec?
>

Backward compatibility.  I suspect that there are many web contents that
depend on styleWithCSS available on WebKit / Gecko.

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.

> If one wishes to allow convenient export of the internally generated
> mark-up
> > for the sake of the user (e.g., to allow them to copy the markup for use
> on
> > their own site), it is nice for there to be choice at least between
> > non-formatting-committal (semantic) markup and non-semantically-committal
> > (formatted) mark-up
>
> The commands we have are clearly presentational.  E.g., we have an
> "italic" command, and don't have "emphasize" or "citation" or
> "variable" commands.

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.

On Thu, Mar 3, 2011 at 12:51 AM, Roland Steiner
> <rolandsteiner at google.com> wrote:
> > But how do you know what is the desired result?
>
> I'm assuming that the desired result is "make the selected text
> bold/italic/purple/etc.".  After all, that's how the commands are
> named, it's how they're described in browser documentation, and it's
> the only thing they do consistently between browsers.  "bold" creates
> <strong>, <b>, or <span style="font-weight: bold"> depending on the
> browser, and the only thing those have in common is presentation.
>

Again, each browser needs to recognize all of that as equivalent.  Or
otherwise, it fails to remove styles added by other browsers.  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).

I get the hand-editing argument.  <b> is much nicer to hand-edit than
> <span style="font-weight: bold">, and also fewer bytes.  But why would
> anyone want <span style="font-weight: bold">?  Styles are more
> powerful in general, but that's not a reason to prefer them in the
> specific cases where they aren't more powerful.
>

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

Well, you can't do hiliteColor (for instance) without CSS.  I assume
> you mean that for any *particular* command, we should either always
> use tags or always use CSS.  So if the user hits "bold", it should
> either make <b> elements or add font-weight: bold, not some mix of the
> two.  This would be more consistent in some sense, and I can see what
> you're saying.
>

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?

But currently I'm inclined to say that it would be best to use tags
> wherever possible, just because it's usually simpler and shorter.
> This would match non-Gecko browsers' defaults, except I'd avoid
> invalid tags like <font> (which aren't much shorter than <span style>
> anyway, and have weird behavior).  If that's what the spec said, would
> there be any good reason to give authors an option to switch to
> CSS-only styles?  If so, what is it?
>

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

Well, in my opinion, elements like <i> or <sup> are just as
> presentational as CSS, and are just shorthands for <span
> style="font-style: italic"> or <span style="vertical-align: sup">.
>

They are not as far as HTML5 spec is concerned.

 On Thu, Mar 3, 2011 at 1:09 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> > But contenteditable is used in many CMS and we can't ignore the backward
> > compatibilities. In HTML editing, It's not enough that one browser
> generates
> > and renders contenteditable properly. Whatever HTML / CSS one browser
> > generates must be understood by other browsers.  For example, if I edit a
> > blog article by a new browser that supports the properties you proposed,
> I'd
> > expect the edited article will look same on other browsers that may or
> may
> > not support the proposed properties.
>
> Hmm, that's a very good point.  We don't want to rely on fancy new
> features that not every browser supports.  But as it happens, most
> browsers don't work in tricky cases anyway.  If you look at even a
> simple case like
>
> data:text/html,<!doctype html>
> <button onclick="execCommand('underline', false, null)"><u>U</u></button>
> <div contenteditable=true>
> <p style="text-decoration: underline">Hello there!
> </div>
>

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.

Suppose your proposed CSS properties for text decorations are added to CSS3
or CSS4 or whatever CSS it is.  Then further suppose that it's supported by
some newer version of Firefox and WebKit.  But those properties aren't
supported by older browsers and we can't generate HTML relying on those
properties because old browsers will render / interpret incorrectly.  So
your properties are practically useless in the editing purposes at least for
the next several years.  We MUST push down text decorations like I wrote in
earlier replies whether you like or not.

I'm very reluctant to spec something as complicated as what WebKit
> does here.  It's not only harder to implement, it's going to result in
> unintuitive or buggy behavior in some cases, like the case I gave
> earlier where the underline changes color.
>

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.

- Ryosuke