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

[Aryeh Gregor]

On Fri, Mar 4, 2011 at 10:23 PM, Ryosuke Niwa <rniwa at webkit.org> 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 don't think editing behavior of browsers is consistent in any
meaningful way.  Even the simplest command produces different output
in every engine by default.  For instance, bolding a simple span of
text uses <b> in WebKit, <span style="font-weight: bold"> in Gecko,
and <strong> in IE/Opera by default.  We have to pick one behavior, so
WebKit's is as good as any.

Similarly, styleWithCSS is ignored in IE and Opera.  So sites already
cannot rely on CSS styles being produced after styleWithCSS being set
to true.  Even if they special-case Gecko and WebKit, those still
produce different markup in many very common cases.  So I really find
it hard to believe that many authors are relying on the specific
markup produced.  If they are, they're going to be either targeting
only a single browser or browser-sniffing, and their site will *have*
to break when browsers converge.

Anyway, of course I agree that we should not break existing sites if
we can possibly avoid it.  I'll research some high-profile software
that uses execCommand() and try to figure out what behavior it depends
on.  If you know of specific sites that, e.g., rely on styleWithCSS
and will break if it doesn't work (so they already break in IE and
Opera?), that would be very helpful information.

In case it wasn't clear, I'm okay with speccing styleWithCSS if either
1) there's specific evidence it will break sites if we don't, or 2)
there's a good use-case for it.  However, I'm not okay with speccing
it just because two engines already happen to implement it, if there's
no other reason than that.

> But this is a behavior agreed by most browsers.  What is the point in
> changing it now?

It's not "most" browsers, it's only Gecko and WebKit.  The point in
changing it now is that all browsers will have to rewrite their
execCommand() implementations to match the spec anyway, no matter what
spec we produce, so we should make the spec simpler where possible.
There's no point wasting specification and implementation resources on
a useless feature.

> I'd personally prefer Internet Explorer's behavior most.  When I bold text,
> I don't really mean to bold it.  I mean to emphasize the text so putting
> strong element makes a lot more sense than b or font-weight:bold style.

Well, I disagree, but it's not an important difference in the end.

> This breaks backward compatibility.

Do you know of specific sites it would break, or other evidence that
makes you think it would break sites?  I looked at the WebKit bug
<https://bugs.webkit.org/show_bug.cgi?id=13490>, and as far as I can
tell, users were really only complaining about the verbose CSS-based
markup WebKit generated.  No commenter seemed to want the CSS-based
markup, they all wanted tags, and they just asked for styleWithCSS so
they could set it to false.

> I'm almost certain we had a reason to default to non-CSS mode in WebKit but
> I need to check.

Please tell me if you find anything.

> Of course, but how can you blame them if they don't support the feature?
>  It's like saying that we should remove many of CSS3 properties because they
> aren't supported by major browsers.

We should remove *useless* CSS3 properties if they aren't supported by
major browsers.

> It already works in some browser, namely WebKit.  And markup generated by
> WebKit can be rendered properly by other browsers.

Yes, that's true.  I'll try to spec something that handles at least
reasonable/common cases correctly, and maybe falls back to doing
nothing in complicated or hard cases.