- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Wed, 23 Mar 2011 13:50:51 -0400
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.
Received on Wednesday, 23 March 2011 10:50:51 UTC