Re: [whatwg] window.print() when printing is not supported
Robert O'Callahan schrieb: On Tue, Dec 29, 2009 at 6:07 AM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu 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.)
[whatwg] HTMLCanvasElement.toFile()
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] Inconsistent behavior for empty-string URLs
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 img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas Sent: Tuesday, January 05, 2010 12:21 PM To: Simon Pieters; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs Given all of this info, does anyone believe there's further investigation necessary before making a recommendation for this change? -Nicholas __ Commander Lock: Damnit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Simon Pieters Sent: Tuesday, December 22, 2009 2:30 AM To: Nicholas Zakas; Jonas Sicking Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs On Mon, 21 Dec 2009 20:03:01 +0100, Nicholas Zakas nza...@yahoo-inc.com wrote: Here are the results of testing various tags with empty URLs across different browsers. The table below indicates how many requests are sent when the given tag is encountered on the page (curiously, Firefox 3 sometimes sends two extra requests). Even though the link tags don't show it in the table, they all had href=. IE7 IE8 FF3 FF3.5 SF4 Ch3 Op10 img src= 1 1 1 0 1 1 0 link rel=stylesheet 0 0 1 1 1 1 0 link rel=icon 0 0 2 1 1 1 0 link rel=shortcut icon0 0 2 1 1 1 0 link rel=prefetch 0 0 2 0 0 0 0 script src= 0 0 1 1 1 1 0 iframe src= 0 0 0 0 0 0 0 input type=image src= 1 1 1 0 1 1 0 object data= 0 0 1 1 0 0 0 embed src=0 0 0 0 0 0 0 html manifest=0 0 0 0 1 0 0 For the most part, no two browsers act the same. Safari and Chrome are the closest (not surprising). Apply a base URL via base in all cases didn't change the results, except in IE, where it prevented the extra image request from being made. Thanks. IIRC, IE doesn't make a request when using minimized attribute syntax, i.e. img src (because it drops the attribute during parsing). -- Simon Pieters Opera Software
Re: [whatwg] Inconsistent behavior for empty-string URLs
On Thu, Jan 7, 2010 at 1:03 PM, Nicholas Zakas nza...@yahoo-inc.com 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 img, link, script, iframe, audio, video, audio, object, embed, input, html manifest, or frame tag that will result in an automatic download of an external resource must ignore any empty string URL and not download the external resource. This is true even when a base href is applied to the page. Does that sound right? Sounds good to me. / Jonas
Re: [whatwg] HTMLCanvasElement.toFile()
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 canvas 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] HTMLCanvasElement.toFile()
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 canvas and sending via XHR. How about just overloading xhr.send() to handle a canvas element ?
Re: [whatwg] HTMLCanvasElement.toFile()
On Thu, Jan 7, 2010 at 2:22 PM, Maciej Stachowiak m...@apple.com 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 canvas 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()
On Thu, Jan 7, 2010 at 2:27 PM, João Eiras jo...@opera.com 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 canvas and sending via XHR. How about just overloading xhr.send() to handle a canvas 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()
On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 7, 2010 at 2:27 PM, João Eiras jo...@opera.com 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 canvas and sending via XHR. How about just overloading xhr.send() to handle a canvas 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()
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 jo...@sicking.cc wrote: On Thu, Jan 7, 2010 at 3:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 7, 2010 at 2:27 PM, João Eiras jo...@opera.com 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 canvas and sending via XHR. How about just overloading xhr.send() to handle a canvas 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()
On Thu, Jan 7, 2010 at 5:27 PM, Shumpei Shiraishi shumpei.shirai...@gmail.com 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
