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

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?

I don't think we need to keep it.  First of all, it complicates both
authoring and implementation to have an extra mode.  Second of all,
both IE and Opera haven't seen the need to support it so far.  And
third of all, it will inevitably result in subtle differences between
the modes, with particular commands working differently depending on
CSS vs. tag markup, like:

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

data:text/html,<!doctype html>
<div contenteditable=true>
    <p>Hello
</div>
<div contenteditable=true>
    <p>Hello
</div>
<script>
document.execCommand("styleWithCSS", null, true);
getSelection().selectAllChildren(document.querySelector("p"));
document.execCommand("foreColor", null, "ff0000");
document.execCommand("styleWithCSS", null, false);
getSelection().selectAllChildren(document.querySelector("div + div > p"));
document.execCommand("foreColor", null, "ff0000");
getSelection().removeAllRanges();
</script>

In Firefox (although not Chrome), the first "Hello" is black, the
second is red.  (WebKit seems to process the colors somehow before
outputting them, which avoids the inconsistency but adds more
complexity.)

Etc.  This added complexity and inconsistency needs justification to
be added to the standard.

> In any case, spans with inline styles are much less likely to conflict with
> other styling

I'm not sure what you mean by this.  Functionally, in what way is
<span style="font-style: italic"> less likely to conflict with other
styling than <i>, for instance?  Possibly some authors do things like
i { color: green }, but they might do the same for span as well --
either seems equally unlikely to me.

> 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.  If there were demand for it, semantic commands
could be added, but currently I'm assuming the use-case is only
presentational markup.  If someone would like to argue that there's
substantial author demand or implementer interest in adding semantic
commands, we could do that, but they'd have to be separate features,
and we'd still have to deal with the commands that are presentational
only.

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.

> Paraphrasing Julie's point
> from our original exchange: you want to be consistent to make it easy to
> hand-edit the resultant HTML (by the user, say), or for server-side
> post-processing. For these purposes pure markup is often easier. OTOH, in
> general, styles are more powerful.

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.

> Mixing both arbitrarily, however, is
> making things just complicated for everyone who has to use or process the
> result.
> That is: conversely I would ask what is the benefit (to the user) of mixing
> markup and styles?

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

> You seem to argue (in your mails and follow-ups
> on?http://lists.w3.org/Archives/Public/www-style/2011Feb/0641.html)?that
> contentEditable and execCommand are for visual markup only rather than also
> addressing semantic concerns. If so, why not be consequent and argue for -
> and use - styles only (i.e., argue for making "styleWithCSS" the default and
> deprecate styleWithCSS=false)?

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">.
Thus my algorithm treats them that way, and inserts them instead of
the corresponding spans so as to shorten the markup.  Maybe you
disagree with that (I know Hixie does), but I'm being consistent, at
least.  :)

As I said, though, I'm inclined to move toward using only elements for
properties where that's possible.  Is there some reason authors would
want to have CSS output instead?

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>

only WebKit successfully removes the underline out of the four major
browser engines.  So non-WebKit browsers have no backward
compatibility issue: they don't work anyway.  Note that this markup is
exactly what Firefox will generate by default if you highlight a whole
paragraph and underline it, so this isn't a theoretical case.

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.

Received on Thursday, 3 March 2011 11:53:47 UTC