Re: JPEG Quality test

Right, I know it is not required by the specification, but these tests
are still there to test JPEG encoding, and passing someone for not
supporting JPEG is misleading.

 If the point of the test suite is to test only what is required, then
having them at all is nonsensical. And if that's not the point, then
having them pass on something they don't support (even though it's not
required) is misleading.

To me, personally, it would make more sense to have that first
if-statement present in all the tests into a seperate  test, like
toDataURL.jpeg.nonsupported that would check it jpeg fallbacks
correctly to PNG if not supported (much like the "unrecognized" test),
and then maybe also having a general case that just checks if jpeg is
supported. If those tests are present, then failing the JPEG tests if
jpeg is not supported would still provide the same information, but
also properly explain that jpeg is not supported. Running them right
now in, for example Chrome, just gives the false impression that jpeg
is supported. It wasn't until I debugged them that I realized it

Best regards,

On Mon, Nov 29, 2010 at 6:13 PM, James Graham <> wrote:
> On 11/29/2010 06:03 PM, Jakob Nilsson-Ehle wrote:
>> canvas(toDataURL.jpeg.alpha.html ):
>> canvas(toDataURL.jpeg.quality.basic.html ):
>> canvas(toDataURL.jpeg.quality.notnumber.html ):
>> canvas(toDataURL.jpeg.quality.outsiderange.html ):
>> All those tests will automatically pass if the returned data from
>> toDataURL("image/jpeg") does not contain the mime type image/jpeg.
>> That seems like very odd behaviour, since it is the explicit jpeg
>> encoding that is being tested. So my question, once again, is, what is
>> the reason for that? Wouldn't it make more sense to fail a browser if
>> it doesn't do the jpeg encoding?
> Support for image/jpeg is not required by the specification; see [1].
> Arguably the tests should ensure that the image is correctly returned in PNG
> format if JPEG is not supported. At present only [2] tests this.
> [1]
> [2]

Received on Monday, 29 November 2010 17:45:18 UTC