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

Fri Mar 4 19:23:24 PST 2011

On Sat, Mar 5, 2011 at 3:58 AM, Aryeh Gregor <Simetrical+w3c at gmail.com>wrote:

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

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.

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

As a WebKit contributor, I'm strongly opposed to implement your spec as it
stands now because of the lack of backward compatibility although this is my
personal view and no way represents the WebKit community as a whole.

The issue is that the CSS mode outputs font-weight: bold, while the
> HTML mode outputs <b>.  The default style of <b> 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.
>

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

 > 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'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.  I'd
personally think styleWithCSS was a huge mistake and we should have copied
IE's behavior but we're too late now.

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

Right, but that doesn't tell us that we should not use font element either.
 I don't think we need to be consistent in each mode.  What we want is
consistency between browsers.

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 <font> 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 (<b>, <i>, etc.) if they're conforming, even in CSS
> mode.
>

This breaks backward compatibility.

5) CSS mode should be the default.
>

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

Browsers aren't already consistent with respect to styleWithCSS.  IE
> and Opera ignore it.

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.

Gecko and WebKit both honor it, but in
> substantially different ways.  E.g., with styleWithCSS on, Gecko will
> output something like <p style="font-weight: bold">Foo</p> if you bold
> a paragraph, while WebKit will output something like <p><span
> style="font-weight: bold">Foo</span></p>.
>

In my opinion, they're equivalent and consistent enough although it's nice
to agree on which DOM to produce.

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

Then you should just try to spec the case when styleWithCSS = false, and
deprecate styleWithCSS = true.  I don't think there's need for breaking
styleWithCSS = true.

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.

I'm not sure what you mean by "agree" but to me, hello and hello are
equivalent but aren't equivalent to hello or
hello.

My point is that every browser except WebKit does nothing useful here
> to begin with.  If instead of doing nothing, they add <span
> style=text-decoration-suppress:underline>, 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.
>

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

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

I don't think you should consider cases where text-decoration comes from an
ancestor of the editing host because that's not a realistic situation nor
the case where style comes from CSS rules because CSS selectors can apply
styles based on DOM structures such as div > div > span > em and editing
suddenly becomes an intractable problem.  It'll be nice to eventually
support those cases but I wouldn't consider it as a good argument for always
using new property.

In my opinion, your argument for changing the browser behavior is weak
because you consider some edge case and then conclude that we need to
completely abandon backward compatibility even in the most simple case for
which major browsers agree on the same behavior with some variations.  We
can't do that.  We need to untangle each and every one of those edge cases
rather than overhauling the entire behavior.

- Ryosuke