[whatwg] Ongoing work on an editing commands (execCommand()) specification
ehsan at mozilla.com
Fri Mar 18 23:09:11 PDT 2011
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
> This breaks backward compatibility.
> 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).
> 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.
More information about the whatwg