- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Sat, 2 Feb 2008 20:10:30 +0000
On 31/01/2008, Ian Hickson <ian at hixie.ch> wrote: > I've made toDataURL() return "data:," if it's faced with a 0-pixel image. > It's arbitrary, but I guess it represents the image, at least! That makes the "Note: When trying to use types other than image/png, authors can check if the image was really returned in the requested format by checking to see if the returned string starts with one the exact strings "data:image/png," or "data:image/png;"." now incorrect. The non-image/png format might be unsupported, but someone might be drawing a 0-pixel image and they'll get back something that doesn't start with data:image/png[,;]. It does seem pretty weird to return text/plain content when asked for an image. But I guess it's safer than e.g. returning an empty string, since it won't get misinterpreted as a relative address when people do img.src=canvas.toDataURL(), and I can't think of a better idea. > User agents may impose implementation-specific limits on otherwise > unconstrained inputs, e.g. to prevent denial of service attacks, to guard > against running out of memory, or to work around platform-specific > limitations. (See ...#hardwareLimitations.) Does anything say that those limitations should be imposed by throwing an exception, and not by e.g. returning null or aborting the entire script? > I'm assuming that the DOM Bindings > for JS spec will define how 'undefined' really means 'null' Hmm, I can imagine 'undefined' converted to a DOMString becoming the string "undefined". (That's at least what document.createTextNode(undefined) does). But I can just assume for now it's meant to work like null. -- Philip Taylor excors at gmail.com
Received on Saturday, 2 February 2008 12:10:30 UTC