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

[Aryeh Gregor]

On Wed, Mar 23, 2011 at 1:36 AM, Robert O'Callahan <robert at ocallahan.org> wrote:
> So it has valid use cases after all?

I always felt it had valid use-cases in *some* form -- namely, some
authors want conforming content, which means no <font>, while some
authors want markup that will work in crippled HTML processors like
Blackberry's e-mail client, which means they want <font>.  The only
question was whether there was a use-case for <span
style="font-weight: bold">/<span style="font-style: italic"> instead
of <b>/<i>.  I still don't think there is, but I realized it really
makes no difference -- authors can opt into CSS styling selectively on
a per-command basis, so it doesn't hurt to allow it.

> I think this is unwise. Given that some browsers are unwilling to drop
> support for almost anything, that would mean we need to spec a superset of
> every experimental feature those engines add, at least those that are
> unprefixed, even if they're barely used on the Web. It's especially
> problematic when the same feature is implemented differently in different
> browsers. Then you end up speccing a feature for the sake of interop, but
> whatever you spec can't give you interop.
>
> IMHO we should spec features if and only if there are use-cases (not
> reasonably covered by existing features), or if needed for interop with
> existing content.

I agree if the features are at all hard to spec or implement.  In this
case, we want to support some form of styleWithCSS anyway, and in that
case it's not really any harder to match Gecko's/WebKit's existing
behavior than to spec different behavior.  If the entire feature had
no use-cases, then I'd agree that we should only spec it if other
browsers are interested in implementing it, and otherwise encourage
Gecko and WebKit to evaluate the feasibility of dropping it.