Re: Ill-defined programs

On Mon, Nov 13, 2017 at 12:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Nov 13, 2017, at 11:44 AM, Dzmitry Malyshau <dmalyshau@mozilla.com>
> wrote:
>
> Yes. Strong objection. If behavior of any programs is not fully specified,
> then web developers will start to accidentally depend on the behavior of one
> browser (usually whichever is most popular), and then browsers will have to
> reverse-engineer each others' behavior. This has happened so many times in
> the course of web standards development that it's almost a running joke.
> Every once in a while someone says "hey, let's just not define error
> handling, we only need to define the behavior for valid content" it happens.
> The first time was HTML, Browsers ended up reverse-engineering each other's
> error handling until finally they got sick of the W3C not defining this and
> formed the WHATWG to create HTML5, which fully specified parsing behavior
> for all invalid documents. CSS, JavaScript and WebAssembly also have fully
> interoperable behavior by spec, even in "invalid" or "error" or
> "ill-defined" cases.
>
> Let's not make this rookie mistake. We must fully define the behavior of all
> programs.

We can fully define it without requiring exact behavior. It's not a
rookie mistake to make compromises here. There are a variety of ways
in which our API here, like WebGL, differs greatly from the parsing
deviations in early HTML. It is not white and black. Short of proved
code, there will always be accidental portability problems, even if
from nothing other than cargo-culting. We should make smart
compromises here, using all the tools and avenues available to us,
rather than have a knee-jerk requirement for maximum portability.
(absolute portability is not even possible with our base graphics
APIs)

Received on Monday, 13 November 2017 23:22:15 UTC