4 ms·

(a) You claimed two codebases before. Switching to "independent implementation" is shifting the goalposts. (b) The reason you fork a codebase is to make it dif

(a) You claimed two codebases before. Switching to "independent implementation" is shifting the goalposts. (b) The reason you fork a codebase is to make it different. They've been forked for eight years or so now. This is longer than many codebases even exist for! I don't know how different they are in practice (especially in the matter of parsing), but I think it's unreasonable to assert that just because they're forked, ipso facto they are not independent. Instead, you should have to show that they are not independent and then explain this in terms of common origin. edit: To add to this point (b), afaik the old Netscape and IE had a common origin, in that they both derived from NCSA Mosaic. But it would be ludicrous to imply that they were in any sense equivalent!

tannhaeuser 5y ago
I'm really not shifting the goalposts at all. The purpose of a spec is that an implementation can be built on it, and any spec worth its salt should be verified for clarity, feasibility, soundness, etc. by implementations. In fact, W3C had a requirement for two independent implementations for any spec to reach recommendation status. So in this context, a fork can't be meaningfully counted as independent implementation; if it were, I could create an empty fork on github and call it a day to satisfy the requirement of two independent implementations. By forking, you inherit a code and test base encoding all quirks and warts (= that which is actually spec-worthy), but don't gain any insight into the spec quality or alignment with a spec at all. Now, of course, we have a much worse problem with web specs: that no browser has been started from scratch since basically forever. Thus, the spec can serve merely as an after-the-fact documentation of existing browser behaviors, or at best record an intent for "browser vendors" to implement some feature. Which is what WHATWG basically is and how it came to be: a platform for "browser vendors" to agree on evolving web standards without the ceremony of a full-blown spec process like W3C's. There's nothing wrong with that; it's just not what should be called "a standard", especially if it doesn't produce a published, versioned document or other deliverable but is always work-in-progress by design.
- sanxiyn 5y ago
  I agree in general, but for HTML5 parsing, Servo implemented HTML5 parsing from scratch directly from specification, and experienced no problems. HTML5 parsing part of specification passes all kinds of tests you can think of about standardization with flying color.

tannhaeuser 5y ago

I'm really not shifting the goalposts at all. The purpose of a spec is that an implementation can be built on it, and any spec worth its salt should be verified for clarity, feasibility, soundness, etc. by implementations. In fact, W3C had a requirement for two independent implementations for any spec to reach recommendation status. So in this context, a fork can't be meaningfully counted as independent implementation; if it were, I could create an empty fork on github and call it a day to satisfy the requirement of two independent implementations. By forking, you inherit a code and test base encoding all quirks and warts (= that which is actually spec-worthy), but don't gain any insight into the spec quality or alignment with a spec at all. Now, of course, we have a much worse problem with web specs: that no browser has been started from scratch since basically forever. Thus, the spec can serve merely as an after-the-fact documentation of existing browser behaviors, or at best record an intent for "browser vendors" to implement some feature. Which is what WHATWG basically is and how it came to be: a platform for "browser vendors" to agree on evolving web standards without the ceremony of a full-blown spec process like W3C's. There's nothing wrong with that; it's just not what should be called "a standard", especially if it doesn't produce a published, versioned document or other deliverable but is always work-in-progress by design.

sanxiyn 5y ago
I agree in general, but for HTML5 parsing, Servo implemented HTML5 parsing from scratch directly from specification, and experienced no problems. HTML5 parsing part of specification passes all kinds of tests you can think of about standardization with flying color.