- From: Marcus Geelnard <mage@opera.com>
- Date: Thu, 18 Apr 2013 10:43:28 +0200
- To: "Chris Rogers" <crogers@google.com>, "Robert O'Callahan" <robert@ocallahan.org>
- Cc: "Chris Pike" <chris.pike@bbc.co.uk>, "Chris Lowis" <chris.lowis@bbc.co.uk>, bugzilla@jessica.w3.org, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <op.wvqaiquxm77heq@mage-speeddemon>
Den 2013-04-17 23:21:47 skrev Robert O'Callahan <robert@ocallahan.org>: > This is an area where the Web platform may differ from expectations > you've built up working on other platforms. > > My experience with other Web APIs is that many (but not all) authors and > users are more concerned about consistency across >implementations and > across time than whether one implementation "looks better" than other. > So we'll make a change that we >think improves aesthetics and some (but > not all) authors/users will raise hell because we "broke their site". Or > we'll >implement something differently from other browsers and > authors/users will complain that we're "not doing it right". And of > >course 10% of authors/users being vocally angry and the rest being > quietly satisfied with a small improvement is actually a >loss for us. I > prefer to avoid getting into those situations if we can. And generally, > if author requirements force browsers >to behave a certain way, that > should be written into the spec. I totally agree here. I believe that in general serious developers are mostly concerned with having a consistent platform to target (in this case, "the Web"). Ask any game developer. I think there are roughly two ways for Web developers of handling the issue of audio quality/behavior: 1) Throw something at the browsers, hope that they will do the best of it, and don't care too much about "poor quality" in a few instances ("maybe they will improve in the future"). This usually also implies that you don't care too much about optimal quality. 2) Tune your set up and assets until you get the feel and quality that you're looking for. You typically do this against a specific target. If different browsers behave differently, you'll quickly start seeing "Optimized for [browser X]" in games and Web apps, which is quite the opposite to what we try to achieve here, IMO. I'd say that 2) is the case we should be more concerned about. In any event, having a consistent behavior across browsers seems to me to be the better option. /Marcus > > > If it's an issue where everyone will agree whether one implementation is > better than another, this is less of a problem, but >Chris' answers > suggest that is not the case for HRTF. > > (I mean Chris Rogers. Why is everyone called Chris? It's driving me mad!) > > Rob -- Marcus Geelnard Android Browser Developer Opera Software ASA
Received on Thursday, 18 April 2013 08:48:26 UTC