W3C home > Mailing lists > Public > public-gpu@w3.org > November 2017

Re: Ill-defined programs

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 13 Nov 2017 15:29:40 -0800
Cc: Dzmitry Malyshau <dmalyshau@mozilla.com>, public-gpu <public-gpu@w3.org>
Message-id: <88F04482-C5C5-4075-BCA4-606C848A42FB@apple.com>
To: Jeff Gilbert <jgilbert@mozilla.com>

> On Nov 13, 2017, at 3:21 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> 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.

I'm not sure what that means. Are you suggesting a menu choice of one of N behaviors? Then the most popular behavior will become a de facto standard.

> It's not a rookie mistake to make compromises here.

It totally is. I can't think of a time we've done this on the web and it has been ok in the long run. I gave you a very notable failure example. Can you cite any past successes for the strategy of sacrificing interoperability on the web?

> 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)

It's my impression that, historically, graphics programmers have accepted a much lower bar for portability than the standard we strive for on the web. I believe we should shoot for something much closer to the web bar for portability. Accidental portability problems from cargo-culting are exactly the kind of problems I am worried about. The more we create the opportunity for such problems, the more likely that in 5-10 years we'll all have to reverse engineer Chrome for Windows and Safari for iOS behavior for desktop and mobile respectively.

Received on Monday, 13 November 2017 23:30:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:22 UTC