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

[Ehsan Akhgari]

On 11-03-04 10:23 PM, Ryosuke Niwa wrote:
>
> 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.

I agree with Ryosuke here.

>> 1) Always use tags (<b>,<i>, etc.) if they're conforming, even in CSS
>> mode.
>>
>
> This breaks backward compatibility.

Seconded.

> 2) In CSS mode, use CSS where the tag isn't conforming (<font>, etc.)
> or there is no tag (like hiliteColor).

I would argue that in CSS mode, we should always use inline CSS styles.

> 3) In non-CSS mode, use tags where available even if not conforming
> (<font>, etc.), and only use CSS if there's no tag for the feature
> (like hiliteColor).

Agreed.

> 4) Interpret parameters as consistently as possible between CSS and
> non-CSS modes.  E.g., for foreColor, output directly as a CSS color in
> CSS mode; in non-CSS mode, translate the CSS color to a simple #123456
> type color and use that for<font>.  (Unless it's a color that<font>
> doesn't support, like with alpha; then I guess use CSS.)  This avoids
> having the same command achieve different visual effects in different
> modes.  WebKit already behaves something like this, but Gecko doesn't
> (see my earlier color=ff0000 example).

This makes sense to me.

> 5) CSS mode should be the default.

I haven't made up my mind on this one yet...

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

I agree with Ryosuke here as well.

--
Ehsan Akhgari
Mozilla Corporation
http://ehsanakhgari.org/