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

Re: JPEG Quality test

From: James Graham <jgraham@opera.com>
Date: Mon, 29 Nov 2010 18:13:44 +0100
Message-ID: <4CF3DF48.8020109@opera.com>
To: Jakob Nilsson-Ehle <jnehle@gmail.com>
CC: Kris Krueger <krisk@microsoft.com>, "public-html-testsuite@w3.org" <public-html-testsuite@w3.org>
On 11/29/2010 06:03 PM, Jakob Nilsson-Ehle wrote:

> canvas(toDataURL.jpeg.alpha.html ):
> http://test.w3.org/html/tests/approved/canvas/toDataURL.jpeg.alpha.html
> canvas(toDataURL.jpeg.quality.basic.html ):
> http://test.w3.org/html/tests/approved/canvas/toDataURL.jpeg.quality.basic.html
> canvas(toDataURL.jpeg.quality.notnumber.html ):
> http://test.w3.org/html/tests/approved/canvas/toDataURL.jpeg.quality.notnumber.html
> canvas(toDataURL.jpeg.quality.outsiderange.html ):
> http://test.w3.org/html/tests/approved/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] http://www.whatwg.org/specs/web-apps/current-work/#dom-canvas-todataurl
[2] 
http://philip.html5.org/tests/canvas/suite/tests/toDataURL.unrecognised.html
Received on Monday, 29 November 2010 17:14:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:37 UTC