[whatwg] Unsubscibe
Please unsubscribe mahtaba...@gmail.com. Thanks, Mahtab
Re: [whatwg] Serving up Theora video in the real world
Robert O'Callahan wrote: On Fri, Jul 10, 2009 at 7:36 PM, James Graham jgra...@opera.com wrote: Is there a good reason to return the empty string rather than false? The empty string seems very unhelpful to authors since it doesn't play nicely with debugging prompts and is non-obvious to infer meaning from, which is likely to confuse novices who are e.g. playing with the API in an interactive console session. Returning false makes it difficult to bind to languages other than JS. What would you write for the return type in IDL? Is there any good reason to worry about languages other than javascript? Writing APIs that work well in the one language implemnented in web browsers seems better than writing mediocre APIs that can be used in many other languages. I'm not sure what is needed for IDL to cope with this though.
[whatwg] [EventSource] Garbage collection rules
I've been reviewing the new EventSource draft. I'm very pleased to see it converted into a separate object, rather than being tacked onto everything that implements EventTarget. This is a huge improvement. However, there are some issues that I think need to be addressed, specifically in the area of lifetime management. The GC rules in section 9 seem overly permissive - if there is a listener for message events but the script forgets to call close() when the user navigates away, then the resources it is consuming cannot be reclaimed. There is a small chance that it may be reclaimed if the server terminates the connection and a GC occurs before the UA is able to re-establish the connection (i.e. during the reconnection delay or the reconnection), but I don't think it's wise to rely on this as it would allow malicious scripts to consume resource with no way for the user agent to recover. The simplest way to prevent this would be to modify the condition in section 9 slightly to insist that the event listener is callable, drawing on the text from HTML5's Calling scripts section 6.5.3.2#1. i.e. modify the text to say: An EventSource object with an open connection must not be garbage collected if there are any event listeners registered for message events and at least one of those listeners' global object is a Window object whose Document object is fully active. In other words, the automatic marking of the EventSource now requires that at least one of the event listeners must be callable. The only difference that this makes, I *think*, is that pages in the history lose unreferenced EventSource objects. Is this true and would it actually be a problem? -- Stewart Brodie Software Engineer ANT Software Limited
[whatwg] Non-ecmascript bindings (was Re: Serving up Theora video in the real world)
James Graham wrote: Is there any good reason to worry about languages other than javascript? Writing APIs that work well in the one language implemnented in web browsers seems better than writing mediocre APIs that can be used in many other languages. I'm not sure what is needed for IDL to cope with this though. I've noticed this question come up frequently (happened for XHR as well). All the major browsers don't care about other languages, but please keep in mind that some other browsers do. For instance, the BlackBerry browser, which I work on, is written almost entirely in Java. We allow the rendering engine to be embedded inside other applications written for our devices, and for those apps, make the DOM available via both Java and ECMAScript interfaces so that client apps can manipulate it as they wish. Having APIs that are Java-friendly is critical to this. Really, it's not that much work to make sure the API can have bindings in other languages. As long as you can write WebIDL for it (and provide relevant DOM feature strings wherever necessary), you should get it for free. I would also argue that considering other languages forces you to think more about how the API may be (ab)used and therefore results in a better and more robust API, even if it is never actually implemented in other languages. Cheers, kats
Re: [whatwg] Serving up Theora video in the real world
On Fri, Jul 10, 2009 at 4:57 AM, Robert O'Callahanrob...@ocallahan.org wrote: The way we've implemented in Firefox, we'll return yes if you specify a codecs parameter and we support every codec in your list. So v.canPlayType(video/ogg; codecs=vorbis,theora) returns probably in Firefox 3.5. I think this is reasonable because I believe that, modulo bugs in our implementation, we support the full Theora and Vorbis specs. On the other hand, we will return maybe for v.canPlayType(video/ogg). I think this distinction will be useful. In what use-case would an author want to make use of the distinction? In either case, your only course of action is to try playing the video. Maybe you'd try testing all the video types you support, and if one is maybe while another is probably you'd go with probably? That seems like a pretty marginal use case to help for the sake of such a confusing API. Programmers expect binary logic, not ternary (look at the complaints about SQL's NULL).
Re: [whatwg] Serving up Theora video in the real world
On Fri, 10 Jul 2009 19:23:44 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Fri, Jul 10, 2009 at 4:57 AM, Robert O'Callahanrob...@ocallahan.org
wrote:
The way we've implemented in Firefox, we'll return yes if you specify
a
codecs parameter and we support every codec in your list. So
v.canPlayType(video/ogg; codecs=vorbis,theora) returns probably in
Firefox 3.5. I think this is reasonable because I believe that, modulo
bugs
in our implementation, we support the full Theora and Vorbis specs. On
the
other hand, we will return maybe for v.canPlayType(video/ogg). I
think
this distinction will be useful.
In what use-case would an author want to make use of the distinction?
In either case, your only course of action is to try playing the
video. Maybe you'd try testing all the video types you support, and
if one is maybe while another is probably you'd go with
probably? That seems like a pretty marginal use case to help for
the sake of such a confusing API. Programmers expect binary logic,
not ternary (look at the complaints about SQL's NULL).
I agree that the current interface is ugly and quite fail to see what the
use for it is. With a boolean return value, canPlayType(application/ogg)
would return true if one can demux Ogg streams.
canPlayType(application/ogg; codecs=vorbis,dirac) would return true if
one can demux Ogg and decode vorbis + dirac. Differentiating between
maybe/probably really seems like an edge use case, but you could if
you really wanted to:
function tertiaryCanPlayType(mime) {
[container, codecs] = mime.split(;);
if (canPlayType(mime)) {
return codecs ? probably : maybe;
} else {
// if there are codecs, canPlayType(container) would tell you if
problem is with the container format or the codecs
return ; // was no
}
}
Unless there's some compelling use case that can't be handled with the
above I'd support canPlayType returning a boolean. The only issue I can
see is that canPlayType(foo)==true might be interpreted as a strong
promise of playability which can't be given. In that case just rename the
function to wouldTryTypeInResourceSelection (no, not really).
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Serving up Theora video in the real world
On Fri, 10 Jul 2009 23:26:40 +0200, Philip Jagenstedt phil...@opera.com
wrote:
On Fri, 10 Jul 2009 19:23:44 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Fri, Jul 10, 2009 at 4:57 AM, Robert
O'Callahanrob...@ocallahan.org wrote:
The way we've implemented in Firefox, we'll return yes if you
specify a
codecs parameter and we support every codec in your list. So
v.canPlayType(video/ogg; codecs=vorbis,theora) returns probably in
Firefox 3.5. I think this is reasonable because I believe that, modulo
bugs
in our implementation, we support the full Theora and Vorbis specs. On
the
other hand, we will return maybe for v.canPlayType(video/ogg). I
think
this distinction will be useful.
In what use-case would an author want to make use of the distinction?
In either case, your only course of action is to try playing the
video. Maybe you'd try testing all the video types you support, and
if one is maybe while another is probably you'd go with
probably? That seems like a pretty marginal use case to help for
the sake of such a confusing API. Programmers expect binary logic,
not ternary (look at the complaints about SQL's NULL).
I agree that the current interface is ugly and quite fail to see what the
use for it is. With a boolean return value,
canPlayType(application/ogg)
would return true if one can demux Ogg streams.
canPlayType(application/ogg; codecs=vorbis,dirac) would return true if
one can demux Ogg and decode vorbis + dirac. Differentiating between
maybe/probably really seems like an edge use case, but you could if
you really wanted to:
function tertiaryCanPlayType(mime) {
[container, codecs] = mime.split(;);
if (canPlayType(mime)) {
return codecs ? probably : maybe;
} else {
// if there are codecs, canPlayType(container) would tell you if
problem is with the container format or the codecs
return ; // was no
}
}
Before someone conjures up an example where this doesn't exactly match the
current behavior, the point is simply that calling canPlayType without out
a codecs list or with specific codecs, you can learn exactly what is
supported and not out of the container formats and codecs you are
interested in, without the need for the strange probably/maybe/ API.
Unless there's some compelling use case that can't be handled with the
above I'd support canPlayType returning a boolean. The only issue I can
see is that canPlayType(foo)==true might be interpreted as a strong
promise of playability which can't be given. In that case just rename the
function to wouldTryTypeInResourceSelection (no, not really).
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Proposal: JavaScript stack traces
On Fri, 12 Jun 2009, Jordan Osete wrote: I've wondered for some time if it weren't possible to harmonize stack traces across browsers. As Patrick Mueller mentioned, this is probably better handled by the JavaScript working group. I encourage you to bring this up with them; I think it's a good idea personally. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Non-ecmascript bindings (was Re: Serving up Theora video in the real world)
Quoting Kartikaya Gupta lists.wha...@stakface.com: Really, it's not that much work to make sure the API can have bindings in other languages. As long as you can write WebIDL for it (and provide relevant DOM feature strings wherever necessary), you should get it for free. I would also argue that considering other languages forces you to think more about how the API may be (ab)used and therefore results in a better and more robust API, even if it is never actually implemented in other languages. It's not about whether it is a lot of work; it's about whether the API matches the typical programming style and feature set of the target language. Where this doesn't happen (as in much of the DOM), the API ends up feeling clunky and difficult to use. My experience with dom-equivalent APIs that have been designed to fully take advantage of the target language capabilities is that they are much more pleasant to use than the equivalent DOM APIs. Indeed one of the first things that most javascript libraries do is replace most of the DOM with their own API. This hardly seems like a ringing endorsement of the design strategy that gave us the DOM. I don't think it is sensible to optimise for the few people for whom the cross-language* approach is convenient at the expense of the many or whom it is bad. Sadly it seems that canPlayType is going to be another hacky-feeling API because of cross-language considerations and because the problems with it were not picked up soon enough :( *I idly note that DOM seems entirely unsuited to some languages so it is only really cross-language to the extent that it can be implemented in any language where you can mimic the style of java.
Re: [whatwg] Non-ecmascript bindings (was Re: Serving up Theora video in the real world)
On Jul 10, 2009, at 3:27 PM, James Graham wrote: Quoting Kartikaya Gupta lists.wha...@stakface.com: Really, it's not that much work to make sure the API can have bindings in other languages. As long as you can write WebIDL for it (and provide relevant DOM feature strings wherever necessary), you should get it for free. I would also argue that considering other languages forces you to think more about how the API may be (ab)used and therefore results in a better and more robust API, even if it is never actually implemented in other languages. It's not about whether it is a lot of work; it's about whether the API matches the typical programming style and feature set of the target language. Where this doesn't happen (as in much of the DOM), the API ends up feeling clunky and difficult to use. My experience with dom-equivalent APIs that have been designed to fully take advantage of the target language capabilities is that they are much more pleasant to use than the equivalent DOM APIs. Indeed one of the first things that most javascript libraries do is replace most of the DOM with their own API. This hardly seems like a ringing endorsement of the design strategy that gave us the DOM. I don't think it is sensible to optimise for the few people for whom the cross-language* approach is convenient at the expense of the many or whom it is bad. Sadly it seems that canPlayType is going to be another hacky-feeling API because of cross-language considerations and because the problems with it were not picked up soon enough :( We added support for the updated canPlayType API to WebKit last night -- eg. the empty string is returned instead of no -- this is now present in the latest nightlies and seems to work for the use case we are looking at eg. if (video.canPlayType(..)) ... now succeeds if support is possible, and fails otherwise. *I idly note that DOM seems entirely unsuited to some languages so it is only really cross-language to the extent that it can be implemented in any language where you can mimic the style of java. I don't buy this -- WebKit generates DOM bindings for JS, Obj-C, and C+ + and has work in progress on a C binding -- while you can argue that these are all imperative languages and no one has made bindings for (say) Haskell, I cannot myself see any reason why such would not be possible. --Oliver
Re: [whatwg] getImageData/putImageData comments
On Fri, 12 Jun 2009, Boris Zbarsky wrote: Ian Hickson wrote: 2) The description of putImageData says it Paints the data from the given ImageData object onto the canvas. It may be worth specifying that this uses the SOURCE operator, though this is clear later on when defining what the method _really_ does. That's the author description, which is non-normative and trades precision for accessibility, so I've not added this text. I recommend not reading those sections as an implementor. I was reading it as an author; as an author I assumed that if I'm painting data with an alpha 1 I'll see things under it (which is not hthe case with PutImageData). Ah, ok. Fixed. The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. OK. This was sort of discussed in a follow-on thread to my mail, but my last comment about there being two fundamentally different use cases for PutImageData never got any responses... [...] It was the first use I tried to put canvas to: visualizing something by computing color values for pixels and then painting to the canvas (in my case Julia sets). Yeah, I guess if you want to generate low-res bitmap data using an array-like API, the current canvas doesn't really help you. The putImageData() API is really intended for filters and generated patterns, both of which would want to be as high-res as possible. People are using it for things that are not filters or generated patterns as we speak... And generally getting it wrong (in the sense that their stuff will break on high-res displays). Not much we can do about that yet. On Sat, 13 Jun 2009, Boris Zbarsky wrote: It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. The hard part is realizing you have to do it... And in particular, the fact that it's not just filling in multiple pixels in a square... For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. If we want to shrink by one CSS pixel, so we can actually draw the canvas, then each shrink step needs to apply the algorithm N times, right? But what if N is, say, 2.5, as it can be in Safari? It's been pointed out before that 1 css pixel can map to a fractional number of device pixels there... That algorithm can't very well be applied 2.5 times. Of course my Julia set example would also need to do something a lot more interesting than just fill in multiple pixels in a square when the css-to-device pixel ratio is non-integral. Note that I don't have a proposed solution here; I'm just pointing out that the authoring pitfalls here are a lot more complicated than you seem to give them credit for. Yeah, I can see that there are cases that are a lot more complex than it would first seem. I don't know what we can do about it either, though. On Sat, 13 Jun 2009, Robert O'Callahan wrote: On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. The difference to me as an implementor is that as the spec stands, I have to choose between 1) Implement high-resolution canvas backing store and implementing image data per spec, breaking most of
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. You apparently didn't look at the linked-to page. It's basically applying a graphical filter to an image that results in a smaller image. It's explicitly NOT trying to resize the image using whatever algorithm the browser happens to implement; it's implementing its own image-resizing algorithm (one that arguably produces much better results at the cost of a lot more computation). I don't know what we can do about it either, though. I'll think about this some more... I'm not too hopeful, though. :( Especially for that image-resizing case, where we basically need to be able to create a canvas with fractional CSS pixel dimensions or something. -Boris
Re: [whatwg] getImageData/putImageData comments
On Fri, 10 Jul 2009, Boris Zbarsky wrote: Ian Hickson wrote: For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. You apparently didn't look at the linked-to page. It's basically applying a graphical filter to an image that results in a smaller image. It's explicitly NOT trying to resize the image using whatever algorithm the browser happens to implement; it's implementing its own image-resizing algorithm (one that arguably produces much better results at the cost of a lot more computation). Hm, neat. I don't see why the imagedata API isn't suitable for that. It's not like if you're painting that on the canvas you'll want to leave the last row or column unaffected. You'll want to clear it or some such, in practice. I think this use case works fine with the current API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 video tag questions
On Sun, 14 Jun 2009 jjcogliati-wha...@yahoo.com wrote: I read section 4.8.7 The video element and I have some questions: 1. What happens if the user agent supports the video tag but does not support the particular video codec that the video file has? Should it display the fallback content in that case, and if so, can a video tag be put inside another video tag? You can use the source element for fallback. If none of the available videos are supported, the video element just sits there doing nothing, and an 'error' event fires in the script. The fallback contents are not shown if the element is supported; they are only intended for other browsers that don't support video at all. 2. What is the recommended way for website authors to determine what video and audio codecs and containers are supported by a user agent? The canPlayType() method. On Sun, 14 Jun 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: I don't see why the imagedata API isn't suitable for that. It's not like if you're painting that on the canvas you'll want to leave the last row or column unaffected. You'll want to clear it or some such, in practice. I believe in this case the page actually wants to create a canvas for each intermediate state, so needs to create canvases sized 1 imagedata pixel smaller than a given canvas Just painting to a canvas of the old size isn't right, since it'll then take too much space in the layout. -Boris
Re: [whatwg] HTML 5 video tag questions
On Fri, Jul 10, 2009 at 5:44 PM, Ian Hicksoni...@hixie.ch wrote: On Sun, 14 Jun 2009, Jonas Sicking wrote: Hmm.. is that good? What if you want to use an object (to use flash or java) or a img as fallback? Then you do it with script. The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. I agree that the current design makes sense once there is a common codec supported across all browsers. However currently it seems like we might not reach that point until after all major browsers support video. What would be the downside of displaying the fallback contents if none of the videos can be displayed due to unsupported codecs? / Jonas
Re: [whatwg] HTML 5 video tag questions
On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) Jeff
Re: [whatwg] Serving up Theora video in the real world
On Sat, Jul 11, 2009 at 5:23 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: Maybe you'd try testing all the video types you support, and if one is maybe while another is probably you'd go with probably? Right. Or you might have plugin-based fallback you can use if you get maybe. Other authors with no plugin-based fallback would go ahead if they get maybe. Programmers expect binary logic, not ternary (look at the complaints about SQL's NULL). I agree. In the past I argued for two boolean functions. Anyway, it's a little late now to change canPlayType more than we just did. There is already deployed content checking for probably/maybe. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Serving up Theora video in the real world
On Sat, Jul 11, 2009 at 9:37 AM, Philip Jagenstedt phil...@opera.comwrote: the point is simply that calling canPlayType without out a codecs list or with specific codecs, you can learn exactly what is supported and not out of the container formats and codecs you are interested in, without the need for the strange probably/maybe/ API. I think it would be somewhat counterintuitive for canPlayType(video/ogg) to return true, but canPlayType(video/ogg; codecs=dirac) to return false. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas context.drawImage clarification
On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt oli...@apple.com wrote: Inconsistency doesn't lead to no one depending on a behaviour, it just means sites only work in one browser. Your suggesting would result in sites being broken in all browsers -- the only options from here on out are either nothing gets drawn (as in gecko and presto), or the destination is normalised (as in webkit). Or making it consistent when the DOCTYPE is set to something. API behaviour is not effected by the DOCTYPE, only parsing. Unfortunately you can't change a DOM API that has existed for years to something contradictory. I guess I don't understand. I'm new to the list so forgive me but I thought HTML5 was still a working draft and that the canvas tag was part of that draft. How is a draft immutable? Also, I don't follow the logic here: Your suggesting would result in sites being broken in all browsers -- the only options from here on out are either nothing gets drawn (as in gecko and presto), or the destination is normalised (as in webkit). I don't see how breaking some very small percentage of Webkit sites, or breaking some very small percentage of Gecko/Presto sites is better than from breaking some very small percentage of sites in all of them to make the function useful and the spec specific. (1) The number of sites that use cavnas is exceeding small at this point and the number of those that count on negative width and height behavior being one way or the other is and exceedingly small percent of those (2) breaking some apps is the same as breaking some apps where some #1 is X and some #2 is Y. So what if X Y if both X and Y are less than 0.01% of websites. Consistency and usefulness should win in this case. There is the chance to make the spec unambiguous and more useful before canvas becomes widely used. Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas? There are 2 issues here I brought up 1) What happens at the edges. The results are VASTLY different now. Unless this works consistently it would be hard to make canvas graphics work across browsers and expect get reproducible results. The 2x2 pixel example I gave, one browser ends up scaling with translucency even though there is no translucent pixels in the source image. This is just an artifact of scaling, and you agree below that scaling is implementation dependent. I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If I take a 1x1 pixel image and attempt to use it to cover up something in another image by scaling it it will not cover up that other image. Only the very center pixel will be opaque, all other pixels will be some percentage translucent, showing whatever was previously drawn on the canvas. That's a much bigger issue than whether the scaled pixels are blocky or smooth. If you believe that to be the case then you can always file a bug at bugs.webkit.org . I can't claim it's a bug if the spec doesn't define what the correct behavior is. Here's a webpage showing the issue. http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html --Oliver
Re: [whatwg] Canvas context.drawImage clarification
On Jul 10, 2009, at 6:38 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt oli...@apple.com wrote: Inconsistency doesn't lead to no one depending on a behaviour, it just means sites only work in one browser. Your suggesting would result in sites being broken in all browsers -- the only options from here on out are either nothing gets drawn (as in gecko and presto), or the destination is normalised (as in webkit). Or making it consistent when the DOCTYPE is set to something. API behaviour is not effected by the DOCTYPE, only parsing. Unfortunately you can't change a DOM API that has existed for years to something contradictory. I guess I don't understand. I'm new to the list so forgive me but I thought HTML5 was still a working draft and that the canvas tag was part of that draft. How is a draft immutable? A reasonable amount of HTML5 is also defining existing behaviour -- Canvas has been shipping in browsers for years now, it was introduced in Safari *2*, so there is actually existing content. ... Consistency and usefulness should win in this case. There is the chance to make the spec unambiguous and more useful before canvas becomes widely used. I'm not arguing that i should not have specified behaviour, i'm merely saying that it needs to specify one of the actually accepted behaviour, it can't introduce a new one. I can't claim it's a bug if the spec doesn't define what the correct behavior is. I can't speak for the gecko canvas implementor, but if this were an issue in webkit i would want a bug so that the behavioural difference was recorded somewhere :D --Oliver
