W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: Purpose of ring 0 and vendor prefixes (was: Re: Ringmark is now open source)

From: Marcos Caceres <w3c@marcosc.com>
Date: Tue, 24 Apr 2012 13:35:30 +0100
To: "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <415B59366C9740A5B22952E67C032FA2@marcosc.com>

On Tuesday, April 24, 2012 at 12:06 PM, Charles McCathieNevile wrote:

> > I think it is important for the spec to mention clearly (but non
> > normatively) which standard features are potentially only available
> > prefixed on existing devices as it will considerably lighten developer
> > burden.
> I would avoid doing that. I think we should include things we think are
> reliable enough for developers to build apps on them, and let people like
> caniuse.com (http://caniuse.com) do the hard ongoing work of tracking what exists when.
> Changing coremob 0 every time a new browser revision appears would be a
> major distraction.

I strongly agree with Charles here - but would go further: Having been involved in a number of these kinds of efforts, they've all failed to keep up. Best to let the market/outside-community handle these: if you look at history, we once would turn to PPK's compat tables, now we turn to caniuse.com, MDN, etc. tomorrow it's going to be something else and I doubt very much it will be Core Mob (I don't think anyone has ever turned to a standards body for this kind of information - too understaffed to keep up … even ACID1-3 were done outside the W3C). I think Core Mob should only focus on lobbying vendors to prioritize interoperability issues based on solid evidence and use cases reflected in Ring-N, and should leave developer information to developers; and to the dev relations teams of browser vendors, which already get paid to promote new things full-time and do it wonderfully. Remember that realistically the actual people who will be actively contributing to this effort will likely range between 2-10 (at best!).

If Core Mob succeeds in getting priorities and fixes occurring in browsers, then those will automatically be reflected at caniuse.com and friends. It's one less thing the group needs to worry about and makes the focus more clear: making the underlying platform better suited for application development through direct interaction with browser vendors. If even one good fix results from this effort, then it will automagically reverberate to developers through existing/well-established channels - and we get it for free. I think the ACID tests are good model to go from: there was no "standard" or "spec" that accompanied Acid3, just some lose documentation: *the tests were the spec*.

So some sirloin and rump steak: stop trying to tell developer what "caniuse.com", and just show browser vendors "what we need"™ through the tests.

Marcos Caceres
Received on Tuesday, 24 April 2012 12:36:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC