Re: [whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

On Thu, Jan 7, 2010 at 5:27 PM, Shumpei Shiraishi
 wrote:
> Hi.
>
> I think the method name "toFile()" is missleading, because I agree to
> the Maciej's openion.
>
>> I don't think using File for temporary in-memory binary data, as opposed to 
>> a file on disk, makes sense.
>
> So, how about changing the method name to "toBlob()" and signature as follows?
>
> Blob toBlob(in optional DOMString type, in any... args);

This doesn't address my concern that you won't know the mime type of
the blob returned.

/ Jonas

Re: [whatwg] HTMLCanvasElement.toFile()

[Shumpei Shiraishi]

Hi.

I think the method name "toFile()" is missleading, because I agree to
the Maciej's openion.

> I don't think using File for temporary in-memory binary data, as opposed to a 
> file on disk, makes sense.

So, how about changing the method name to "toBlob()" and signature as follows?

Blob toBlob(in optional DOMString type, in any... args);

--Shumpei

On Fri, Jan 8, 2010 at 8:15 AM, Jonas Sicking  wrote:
> On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking  wrote:
>> On Thu, Jan 7, 2010 at 2:27 PM, João Eiras  wrote:
>>>
> This function takes the same arguments as toDataURL(), plus an
> additional 'name' argument. It produces the same result as
> toDataURL(), except that it returns the result as a File object rather
> than as a data-url encoded string. This can then be directly sent
> using XMLHttpRequest.

 I think it would make more sense to have an actual type for binary data
 (for example along the lines of my proposal on public-script-coord and
 es-discuss) and enable getting one from  and sending via XHR.
>>>
>>> How about just overloading xhr.send() to handle a  element ?
>>
>> I'm reluctant to overload the meaning of sending an Element object.
>> When a Document is passed to xhr.send() we already serialize that
>> document into markup, it seems likely to me that in the future we'll
>> want to do the same thing for Elements.
>
> Additionally, this doesn't allow specifying the encoding type, such as
> JPEG or PNG, or encoding parameters, such as JPEG quality.
>
> / Jonas
>

Re: [whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking  wrote:
> On Thu, Jan 7, 2010 at 2:27 PM, João Eiras  wrote:
>>
 This function takes the same arguments as toDataURL(), plus an
 additional 'name' argument. It produces the same result as
 toDataURL(), except that it returns the result as a File object rather
 than as a data-url encoded string. This can then be directly sent
 using XMLHttpRequest.
>>>
>>> I think it would make more sense to have an actual type for binary data
>>> (for example along the lines of my proposal on public-script-coord and
>>> es-discuss) and enable getting one from  and sending via XHR.
>>
>> How about just overloading xhr.send() to handle a  element ?
>
> I'm reluctant to overload the meaning of sending an Element object.
> When a Document is passed to xhr.send() we already serialize that
> document into markup, it seems likely to me that in the future we'll
> want to do the same thing for Elements.

Additionally, this doesn't allow specifying the encoding type, such as
JPEG or PNG, or encoding parameters, such as JPEG quality.

/ Jonas

Re: [whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

On Thu, Jan 7, 2010 at 2:27 PM, João Eiras  wrote:
>
>>> This function takes the same arguments as toDataURL(), plus an
>>> additional 'name' argument. It produces the same result as
>>> toDataURL(), except that it returns the result as a File object rather
>>> than as a data-url encoded string. This can then be directly sent
>>> using XMLHttpRequest.
>>
>> I think it would make more sense to have an actual type for binary data
>> (for example along the lines of my proposal on public-script-coord and
>> es-discuss) and enable getting one from  and sending via XHR.
>
> How about just overloading xhr.send() to handle a  element ?

I'm reluctant to overload the meaning of sending an Element object.
When a Document is passed to xhr.send() we already serialize that
document into markup, it seems likely to me that in the future we'll
want to do the same thing for Elements.

/ Jonas

Re: [whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

On Thu, Jan 7, 2010 at 2:22 PM, Maciej Stachowiak  wrote:
>
> On Jan 7, 2010, at 11:41 AM, Jonas Sicking wrote:
>
>> Hi web fans,
>>
>> So at mozilla we've been implementing and playing around with various
>> File APIs lately. One of the most common use cases today for file
>> manipulation is photo uploaders. For example to sites like flickr,
>> facebook, twitpic and icanhascheezburger. Some of these sites allow
>> additional modifications of the uploaded image, most commonly cropping
>> and rotating the image. But even things like manipulating colors,
>> adding text, and red eye reduction are things that sites do, or would
>> like to do.
>>
>> We do already have a great tool for image manipulation in HTML, the
>> canvas element. However if a site wants to upload the resulting image,
>> after the modifications, things become more painful. Currently you
>> have to call toDataURL(), send that URL using XMLHttpRequest, and then
>> serverside convert to binary data. Things will be a little better once
>> XHR supports sending manually constructed binary data, but you still
>> have to manually convert the data url to binary data in javascript.
>>
>> I suggest we add a function like:
>>
>> File toFile(in DOMString name, in optional DOMString type, in any...
>> args);
>>
>> This function takes the same arguments as toDataURL(), plus an
>> additional 'name' argument. It produces the same result as
>> toDataURL(), except that it returns the result as a File object rather
>> than as a data-url encoded string. This can then be directly sent
>> using XMLHttpRequest.
>
> I think it would make more sense to have an actual type for binary data (for
> example along the lines of my proposal on public-script-coord and
> es-discuss) and enable getting one from  and sending via XHR. I
> don't think using File for temporary in-memory binary data, as opposed to a
> file on disk, makes sense. The File should stick to representing files.
> After all, you would not make a File object to convert something to text for
> uploading. Nor would it make sense to do an asynchronous read from this. And
> under the covers, you would want to pass the actual binary data to the
> upload code, not a file with a file name.

The difference between a binary blob of data, and the image extracted
from a canvas element, is that the latter has a mimetype. This is
extra important here since if you call:

result = canvas.toFile("", "image/jpeg");

you won't know if the data in result is encoded as "image/jpeg", or
"image/png", since support for jpeg encoding is optional.

I don't really feel strongly about if a File object is extracted or
not, but I do think that the mimetype needs to be returned somehow, so
that it can be passed on the the XHR call. Use a File just happens to
be a convenient way to do this.

/ Jonas

Re: [whatwg] HTMLCanvasElement.toFile()

[João Eiras]

This function takes the same arguments as toDataURL(), plus an
additional 'name' argument. It produces the same result as
toDataURL(), except that it returns the result as a File object rather
than as a data-url encoded string. This can then be directly sent
using XMLHttpRequest.


I think it would make more sense to have an actual type for binary data  
(for example along the lines of my proposal on public-script-coord and  
es-discuss) and enable getting one from  and sending via XHR.


How about just overloading xhr.send() to handle a  element ?

Re: [whatwg] HTMLCanvasElement.toFile()

[Maciej Stachowiak]

On Jan 7, 2010, at 11:41 AM, Jonas Sicking wrote:


Hi web fans,

So at mozilla we've been implementing and playing around with various
File APIs lately. One of the most common use cases today for file
manipulation is photo uploaders. For example to sites like flickr,
facebook, twitpic and icanhascheezburger. Some of these sites allow
additional modifications of the uploaded image, most commonly cropping
and rotating the image. But even things like manipulating colors,
adding text, and red eye reduction are things that sites do, or would
like to do.

We do already have a great tool for image manipulation in HTML, the
canvas element. However if a site wants to upload the resulting image,
after the modifications, things become more painful. Currently you
have to call toDataURL(), send that URL using XMLHttpRequest, and then
serverside convert to binary data. Things will be a little better once
XHR supports sending manually constructed binary data, but you still
have to manually convert the data url to binary data in javascript.

I suggest we add a function like:

File toFile(in DOMString name, in optional DOMString type, in any...  
args);


This function takes the same arguments as toDataURL(), plus an
additional 'name' argument. It produces the same result as
toDataURL(), except that it returns the result as a File object rather
than as a data-url encoded string. This can then be directly sent
using XMLHttpRequest.


I think it would make more sense to have an actual type for binary  
data (for example along the lines of my proposal on public-script- 
coord and es-discuss) and enable getting one from  and sending  
via XHR. I don't think using File for temporary in-memory binary data,  
as opposed to a file on disk, makes sense. The File should stick to  
representing files. After all, you would not make a File object to  
convert something to text for uploading. Nor would it make sense to do  
an asynchronous read from this. And under the covers, you would want  
to pass the actual binary data to the upload code, not a file with a  
file name.


Regards,
Maciej

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas  wrote:
> I'm going to take a lack of response to this question as a "no". :)
>
> Given the disparate browser implementations for dealing with empty
> string URLs, it seems unlikely that anyone is relying upon the current
> behaviors, so I'd like to suggest this change be added to HTML5:
>
> For any , , 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

I'm going to take a lack of response to this question as a "no". :)

Given the disparate browser implementations for dealing with empty
string URLs, it seems unlikely that anyone is relying upon the current
behaviors, so I'd like to suggest this change be added to HTML5:

For any , , 

[whatwg] HTMLCanvasElement.toFile()

[Jonas Sicking]

Hi web fans,

So at mozilla we've been implementing and playing around with various
File APIs lately. One of the most common use cases today for file
manipulation is photo uploaders. For example to sites like flickr,
facebook, twitpic and icanhascheezburger. Some of these sites allow
additional modifications of the uploaded image, most commonly cropping
and rotating the image. But even things like manipulating colors,
adding text, and red eye reduction are things that sites do, or would
like to do.

We do already have a great tool for image manipulation in HTML, the
canvas element. However if a site wants to upload the resulting image,
after the modifications, things become more painful. Currently you
have to call toDataURL(), send that URL using XMLHttpRequest, and then
serverside convert to binary data. Things will be a little better once
XHR supports sending manually constructed binary data, but you still
have to manually convert the data url to binary data in javascript.

I suggest we add a function like:

File toFile(in DOMString name, in optional DOMString type, in any... args);

This function takes the same arguments as toDataURL(), plus an
additional 'name' argument. It produces the same result as
toDataURL(), except that it returns the result as a File object rather
than as a data-url encoded string. This can then be directly sent
using XMLHttpRequest.

/ Jonas

Re: [whatwg] window.print() when printing is not supported

[Markus Ernst]

Robert O'Callahan schrieb:
On Tue, Dec 29, 2009 at 6:07 AM, Boris Zbarsky > wrote:


Come to think of it, airline boarding passes are the only case in
which I print things from the web using either print buttons or the
browser's "print" functionality.  Are there other common printing
use cases?  What are they?


I print anything that I might need access to while travelling, since I 
don't have a smartphone and if I did I wouldn't necessarily want to 
depend on its battery lasting the entire time spent in transit.


Some users I know make hard copies of emails and other important 
documents as a form of backup.


I agree to all points mentioned by Robert. And these first two are 
actually cases that are not covered well today, as web mail and map 
applications are often using frames or iframes. Printing from pages 
using frames and iframes is still an annoying part of the web user 
experience. Additionnally, print versions of timetable information i.e. 
for trains are often displayed in toolbar-less popup windows, another 
annoying print experience.


I.e. in Firefox there are no "print preview" and "print preview this 
frame" (or whatever) commands available from the context menu, which 
makes printing from framed pages or toolbar-less popups really 
difficult. (The Mozilla developers do not share this POV anyway: 
https://bugzilla.mozilla.org/show_bug.cgi?id=504305)


While this is not the place to critizise browser implementations, I 
think there is a relation between the importance of print buttons (and 
thus the window.print() function) and the browsers' printing interfaces. 
I am sure that if browsers would provide easy and intuitive printing 
functionalities, the use of window.print() would tend to get marginal 
within some years.


(I understand that this is not a contribution to the original question, 
as the handling of window.print() by kiosk browsers has to be specified 
anyway. It is only a contribution to Boris' question about printing use 
cases.)