- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 25 Sep 2012 12:53:02 +0300
- To: "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Sat, Sep 15, 2012 at 4:10 AM, Maciej Stachowiak <mjs@apple.com> wrote: > == implementation > > A user agent which: (1) implements the "Web browsers and other interactive user agents" conformance class of the specification. (2) is available to the general public. The implementation may be a shipping product or other publicly available version (i.e., beta version, preview release, or “nightly build”). Non-shipping product releases must have implemented the feature(s) for a period of at least one month in order to demonstrate stability. (3) is not experimental (i.e., a version specifically designed to pass the test suite and is not intended for normal usage going forward). Please add: (4) is suitable for a person to use as his/her primary means of accessing the Web. Rationale: The implementability test should happen in the context of real browsers. As important as other implementations are, they are no substitute to testing implementability in browsers, because they aren't subject to just same backwards compatibility pressure and feature integration needs. I believe the above formulation would still allow nightly builds of browsers (I have used nightly builds for my primary means of accessing the Web for years and years) but would exclude implementations of features in e.g. various Apache-hosted Java-based projects that implement pieces of the Web platform (those projects are often very useful but we shouldn't consider implementability in them proof of implementability in the context of a Web browser that combines all the pieces and is subject to more stringent requirements when it comes to compatibility with existing content). If the requirement I’m proposing was applied to SVG, I’d expect Batik to disqualify. If to CSS, I’d expect Prince to disqualify. Both are great pieces of software but aren’t subject to as strict constraints as browser. (Prince, for example, doesn’t need to be performant under interactive DOM manipulation.) > == judgment level > > For features that are well known to be widely implemented and deployed, the Working Group will assume effective real-world interoperability without testing. This scares me when it comes to features that are widely implemented and deployed but for which we don't know how well the spec text matches the implementations (even worse if we don't know that we don't know). For example, browsing contexts and history are widely implemented and deployed, but it's very likely that if someone implemented the spec, the resulting implementation would be Web-compatible. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 25 September 2012 09:55:42 UTC