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

Tue Mar 22 16:51:22 PDT 2011

On Mon, Mar 21, 2011 at 7:51 PM, Ehsan Akhgari <eakhgari at mozilla.com> wrote:
> You're proposing to remove something from Gecko and Webkit which has been supported for many years (about 8 years for Gecko).  We do not have the ability to make sure that nobody is relying on this in any of the billions of available web sites.  Unless you have a very strong argument on why we should remove support for an API as old as this one, I'm not sure that we're going to do that, and I think that Webkit might have similar constraints as well.  So far, the argument that you've proposed is extrapolating the assumption that this API doesn't have any users from three implementations which use the editing APIs.  I'm afraid you should have a _much_ larger sample if you want to draw this conclusion.
>
> I would personally very much like to get one of the two modes killed in favor of the other, since that means an easier spec to implement, less code to maintain, and easier life for me.  But I think we should carefully think about what this would means for potential users who are using the CSS mode in their applications.

Okay, so I've thought about this a bit, and realized my dislike for
the current behavior of styleWithCSS was because of a combination of
two things:

1) There is no reason I can see that anyone would actually want
s instead of s, except XHTML 1.0 Strict conformance, which we
shouldn't care about.

2) There's a good reason to want markup that is both compact and
conforming, which styleWithCSS doesn't currently give -- it's more
verbose than necessary to conform to HTML5.

Thus I felt it would be more useful if the mode didn't affect bold and
italic (and maybe underline if that becomes valid again). But then I
realized that authors who want markup that's both compact and
conforming could just switch styleWithCSS on or off before running
each particular command -- e.g., leave it on generally, but switch off
immediately before executing bold or italic. So now I have no problem
with the status quo, and am happy to spec styleWithCSS/useCSS.
Changing it as I proposed wouldn't really help anyone, but would
remove some power from authors (in case anyone does want for some bizarre reason) in addition to the
compatibility and consistency issues.

> It's not orthogonal, in fact.  I was talking about the case where you don't have control (or knowledge) of the target page's CSS rules.  Your algorithm works based on this knowledge.  The correct solution to your first example is this markup, FWIW:
>
> <span style="font-weight: bold">Foo<span class="notbold" style="font-weight: bold">bar</span>baz</span>

This doesn't really matter now, but -- in that case, you'd have to
ensure that every single text node is the child of an element with the
inline style applied, so bolding

Hi there, this is some text.
Go look at <a href=foo>some other page</a>.

would have to result in

Hi there, this is some text.
Go look at <a style="font-weight: bold"
href=foo>some other page</a>.

which nobody does or should do in any mode. And if you were doing
that, there's still no reason you should want to output instead of ,
because the latter will work even in non-CSS UAs and is also shorter.
Unless you're aiming for HTML 4 Strict or XHTML 1.0 Strict
conformance, which I suspect was the original motivation.

> Unfortunately, most rich text editing applications on the web have lots of browser specific hacks to work around the bugs in the implementations, so they may easily maintain Gecko/Webkit specific code.

If they depend on the exact markup produced based on browser-sniffing,
however, they'll have to break in some browsers when browsers
converge, no matter what we do. For what it's worth, I'm pretty sure
all these sites are forcing styleWithCSS to false solely so that
Firefox outputs more similar markup to everyone else (except the
e-mail clients, which really want and such).

> Something that I meant to mention elsewhere in the thread: simpler DOM structure is for sure better, but I'm not sure there's much value to try to make the string representation of the generated DOM as short as possible.

One person from Google who gave me private feedback said that one
reason some Google sites moved away from using execCommand() was
because of the messy markup it often produced, and specifically cited
the number of bytes on the wire and ease of hand-editing as two of the
problems. is much better than 
from both perspectives. But you can have the best of both worlds by
toggling styleWithCSS selectively, so it's no big deal in the end.

> Yes, I actually think that this is a nice optimization to have in the algorithm.

I'll add it tomorrow.

On Mon, Mar 21, 2011 at 11:48 PM, Robert O'Callahan
<robert at ocallahan.org> wrote:
> We can deprecate the CSS mode and leave it unspecified, without removing it
> from Webkit and Gecko. That won't hurt interop since anyone using it is
> probably UA-sniffing already.
>
> If sometime in the future we decide that a "CSS mode" is worth having, then
> someone can start writing a spec for it then.

That seems silly, since it's very simple to spec and implement.  I'll
just add it to the spec.

On Tue, Mar 22, 2011 at 3:37 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> One thing we might want to consider is to merge elements when forcing style
> or pushing down style.  For example, if we had "<b>hello </b>world" and
> bolded "world", I'd expect to get "<b>hello world</b>" instead of "<b>hello
> </b><b>world</b>".  While it's not that much of an improvement in this very
> simple case, the effect is obvious when the applied on more complicated
> markup.

That's the first step in "Forcing the style of a node".  It's really
necessary the way I've written the algorithm, because the way I've
written it, you style each node successively and independently.  So
it's very common that there's a preceding node to use, since styling
the previous node likely created it.

(Gecko and WebKit both also do this to a limited extent. See the
tests I just added to
<http://aryeh.name/spec/editcommands/autoimplementation.html#bold>,
beginning with foobar[baz].)

> Yes, it addresses most of my current concerns except StyleWithCSS.  I think
> we should just obsolete StyleWithCSS and let it unspecified so that we can
> keep it backward compatible.

I'll spec it instead.  I'm generally not happy with just leaving
things unspecced if browsers aren't willing to drop support.