Re: [whatwg] Proposal: toDataURL “image/png” compression control

2014-05-28 Thread Rik Cabanier
On Wed, May 28, 2014 at 10:36 PM, Noel Gordon  wrote:

> .toDataURL supports an optional quality argument for the
> “image/jpeg” mime type to control image compression. Developers have no
> control over “image/png” compression.
>
> “image/png” is a lossless image compression format and the proposal is to
> allow developers some control over the compression process. For example, a
> developer might request maximum compression once their art work is complete
> to minimize the encoded image size for transmission or storage. Encoding
> speed might be more important while creating the work, and less compression
> (faster encoding) could be requested in that case.
>
> An optional toDataURL parameter on [0.0 ... 1.0], similar to the optional
> quality argument used for "image/jpeg", could be defined for “image/png” to
> control compression:
>
>.toDataURL(“image/png”, [compression-control-value]);
>
> The default value, and how the browser controls the image encoder to gain
> more compression with increasing values, would be internal implementation
> details of the browser.
>

This has been requested before. ie
http://lists.whatwg.org/pipermail/help-whatwg.org/2013-May/001209.html
The conclusion was that this can be accomplished using JavaScript. There
are JS libraries that can compress images and performance is very good
these days.

If you're worried about blocking the main thread, you can use workers to do
offline processing.


[whatwg] Proposal: toDataURL “image/png” compression control

2014-05-28 Thread Noel Gordon
.toDataURL supports an optional quality argument for the
“image/jpeg” mime type to control image compression. Developers have no
control over “image/png” compression.

“image/png” is a lossless image compression format and the proposal is to
allow developers some control over the compression process. For example, a
developer might request maximum compression once their art work is complete
to minimize the encoded image size for transmission or storage. Encoding
speed might be more important while creating the work, and less compression
(faster encoding) could be requested in that case.

An optional toDataURL parameter on [0.0 ... 1.0], similar to the optional
quality argument used for "image/jpeg", could be defined for “image/png” to
control compression:

   .toDataURL(“image/png”, [compression-control-value]);

The default value, and how the browser controls the image encoder to gain
more compression with increasing values, would be internal implementation
details of the browser.

~noel


Re: [whatwg] HTTP status code from JavaScript

2014-05-28 Thread Joshua Peek
Exposing would be very useful to web application developers.

Just to add some use cases.

The Ruby on Rails framework automatically sets a header called
"X-Runtime" to the number of milliseconds it took to render the body.
Its pretty handily to get this value in JS and do a window.performance
stats comparison against the backend render time.

Today, you have to inject this stat into the footer of the html to
expose it to JS.

On Thu, May 22, 2014 at 10:36 PM, Michael Heuberger
 wrote:
> Hello WhatWG
>
> There is a need to obtain the HTTP status code for the page itself from
> JavaScript:
> https://bugzilla.mozilla.org/show_bug.cgi?id=999886
>
> I think this would be a great feature to save additional traffic in an
> already congested internet. Because I see lots of queries made by
> XMLHttpRequest solely to obtain the HTTP status code of the same URL.
>
> If the global browser variable (JavaScript) would already hold the
> status code, then these queries would become obsolete and the internet
> becomes a bit less blocked.
>
> Let me know how to proceed with my proposal within WhatWG.
>
> Greetings from Auckland,
> Michael
>
> --
>
> Binary Kitchen
> Michael Heuberger
> 4c Dunbar Road
> Mt Eden
> Auckland 1024
> (New Zealand)
>
> Mobile (text only) ...  +64 21 261 89 81
> Email   mich...@binarykitchen.com
> Website ..  http://www.binarykitchen.com
>