Re: [HTMLWG] CR Exit Criteria redux

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