Re: publishing new WD of URL spec

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

Received on Thursday, 11 September 2014 12:47:17 UTC