- From: David (Standards) Singer <singer@apple.com>
- Date: Thu, 11 Sep 2014 09:17:00 -0700
- To: Arthur Barstow <art.barstow@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, Philippe Le Hegaret <plh@w3.org>, public-w3process@w3.org
Can someone tell me please what this has to do with revising the W3C process? If you direct discussions here, please take a moment to point out what problem or opportunity in the w3c process document(s) you want to raise. Thanks On Sep 11, 2014, at 5:57 , Arthur Barstow <art.barstow@gmail.com> wrote: > [ Just changing the Subject; please `carry on` ... ] > > On 9/11/14 8:46 AM, Boris Zbarsky wrote: >> On 9/11/14, 5:50 AM, Philippe Le Hegaret wrote: >>> Unless we missed it, I don't think that we ignored the feedback. >> >> The working group sure did. http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0003.html is the relevant feedback. This was implementor feedback during the CR period, and very definitely ignored. >> >>> Without doing a deep search in the history here, I'm guessing that what happened >>> here was that webperf decided to ship the spec while leaving some part >>> incomplete/undefined. >> >> What happened is that explicit implementor feedback about the spec not being compatible with either implementations or what developers wanted was provided during CR and ignored. There wasn't any decision; there wasn't any discussion I'm aware of, there weren't any replies to the feedback, nothing. Pretty normal, all of it. >> >>> But we published a report at the time about the >>> implementations and tried to make it as complete as possible: >>> http://www.w3.org/2012/04/navigation_timing_cr_results.html >> >> This report only tested the things in the spec, not the things that should have been in the spec but weren't. Convenient. ;) >> >>> Most (all?) specifications have a list of issues where some of them are >>> known to take years to resolve and make them incomplete in some ways. >> >> While true, the fact that you have to have a whole new specification level, taking years, to add a single line of IDL that was requested over two years ago, complete with the editors having not clue and not reading the previous mails on the topic (see thread starting <http://lists.w3.org/Archives/Public/public-web-perf/2014Aug/0000.html>) is precisely the thing that makes the W3C so frustrating for me to work with as an implementor. It basically means the W3C specs are near-useless as a guide to implementation, and instead I have to go reverse-engineer other browsers when implementing. >> >>> It's an iterative process. The Group has been working on Navigation >>> Timing 2 since then with the intent of replacing the first version of >>> Navigation Timing. Granted, we're not moving fast on Navigation Timing 2 >>> and that's frustrating for some (and I share some of the blame for that >>> due to lack of cycles) >> >> Adding stringifiers to this family of interfaces is not a matter of "cycles": it's a trivial job. It's a matter of policy and will to actually have your specs be useful to implementors. >> >> This is why servo is relying on the WHATWG specs, not the W3C ones, by the way. They tried using the latter and discovered that this led to them having implementations of things that are not web-compatible. Needless to say, this is not helpful when trying to write a browser engine. >> >> -Boris >> > > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 11 September 2014 16:18:14 UTC