W3C home > Mailing lists > Public > public-html-testsuite@w3.org > June 2010

RE: Canvas, Audio, Video Test Submission

From: Kris Krueger <krisk@microsoft.com>
Date: Fri, 25 Jun 2010 23:19:02 +0000
To: James Graham <jgraham@opera.com>
CC: Simon Pieters <simonp@opera.com>, Matthew Gregan <kinetik@flim.org>, "'public-html-testsuite@w3.org' (public-html-testsuite@w3.org)" <public-html-testsuite@w3.org>
Message-ID: <FA9085650D2F8B4A9D501ED9D9706E9A1256B645@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
OK - I'll take a peek at making this change, in theory everyone is properly returning null when they don't support a codec.

Though this is really a bad api design...
If one implemented malloc that maybe returned a valid pointer or probably returned a valid pointer.
The consumers of this malloc would be doomed to failure.

-Kris

-----Original Message-----
From: James Graham [mailto:jgraham@opera.com] 
Sent: Friday, June 25, 2010 9:18 AM
To: Kris Krueger
Cc: Simon Pieters; Matthew Gregan; 'public-html-testsuite@w3.org' (public-html-testsuite@w3.org)
Subject: RE: Canvas, Audio, Video Test Submission



On Fri, 25 Jun 2010, Kris Krueger wrote:

> I understand that though the reason we didn't choose to use this was 
> that the canPlayType call may not actually lead to media being able to 
> be played. For example when a UA returns probably it doesn't actually 
> mean that the media will play.
>
> If we want to use this then I would encourage to have this api changed 
> to be binary (yes/no) so that a web dev can be confident that an end 
> user will actually see media playing.

The reason that the API isn't like this is that the UA might not know which types it can play without just trying to play them. Nevertheless the problems with having UA sniffing in tests are far greater than the problem that a UA might think it is able to play a type that it cannot.
Received on Friday, 25 June 2010 23:19:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 June 2010 23:19:46 GMT