Re: [whatwg] Interpretation of video poster attribute
On Thu, 2008-06-12 at 07:15 +, Ian Hickson wrote: So, to summarise, an img represents its src=, and a video represents its poster=. So use the same mechanism (stretching the image to fit the box dimensions) for both. Fair enough. This isn't currently defined (even without a poster, as far as I can tell), but my intention would be to not make the poster affect the intrinsic dimensions, and for the default, in the absence of video data, is 300x150. The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. That the element may be resized twice is not a problem, at least not implementation-wise. As some container formats allow changing the video frame size mid-stream (notably chained Ogg streams, so called sequential multiplexing) the UA could possibly resize the video element an unlimited number of times, so handling that is necessary anyway. On that note, perhaps an event to notify JavaScript UIs of such changes would be useful/necessary. Perhaps reusing resize event would be the best, other names could be videochange or sizechange. Should aspect ratio correction be done for poster images? What if different videos have different aspect ratios? It would be bad for the poster frame to be rendered at different ratios as the UA tries each video in turn. Good point, assuming 1:1 pixel ratio for poster images makes more sense, even if it means tools for automatically generating poster images will have to perform aspect ratio correction. HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) cause the user agent to ignore the poster attribute. Well what else are they going to do? HTTP already requires this as far as I can tell. It appears that Safari shows a little X symbol instead, but perhaps specifying this behavior is not necessary. We will likely ignore the poster attribute entirely instead. I'm not sure a fake button (which wouldn't actually work anyway) is a natural interpretation of poster frame. :-) As long as it's mentioned somewhere there can be no misunderstanding. -- Philip Jägenstedt Opera Software
Re: [whatwg] HTMLMediaElement buffered/bufferedBytes
On Tue, 10 Jun 2008, Philip J�genstedt wrote: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: [s/downloaded/buffered/] [allow unbuffering] Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Change request: rules for pixel ratio
On Tue, 10 Jun 2008, Philip J�genstedt wrote: http://www.w3.org/html/wg/html5/#pixelratio Incidentally, you may prefer this version of the spec: http://whatwg.org/html5 It has a style sheet optimised for this specification instead of using the W3C style sheet. (It's otherwise identical.) The pixelratio attribute allows the author to specify the pixel ratio of anamorphic media resources that do not self-describe their pixel ratio. [...] The default value, if the attribute is omitted or cannot be parsed, is 1.0. This seems more than strange. Should this be taken to mean that the pixelratio attribute is defaulted to 1.0 even for media resources that DO NOT self-describe their pixel ratio? Yes, but that doesn't mean what you think it means. (I've clarified this in the spec.) The only way the default is used is in deciding what number to return for pixelRatio in the DOM when the content attribute is missing. If the content attribute is omitted, then the user agent doesn't adjust the intrinsic width of the video at all; the intrinsic dimensions and the intrinsic pixel ratio of the video are honoured. It is also worth noting that when the pixel ratio is 1.0 it will make more sense for the user agent to adjust the height than the width if no width/height attributes have been set. This could be pointed out in the rendering section eventually. I've allowed this explicitly now. On Tue, 10 Jun 2008, Ralph Giles wrote: Does this mean the implementation must retrieve the self-described pixel aspect ratio from the stream and supply it as part of the DOM? On Tue, 10 Jun 2008, Charles wrote: Offhand, I can't think of any use cases where it'd be useful to expose pixel aspect ratio. On Wed, 11 Jun 2008, Philip J�genstedt wrote: Exposing pixel ratio as readonly float videoPixelRatio in HTMLVideoElement might be a good idea. If the media resource doesn't self-describe its pixel ratio (many formats don't) it should be assumed to be 1.0. I'm not convinced it is necessary as content authors who want to be very explicit will probably set the pixelratio manually. Still, it is trivial to expose and might make life easier for those who want this information for low-level control of the video element size via the DOM. I don't see a good reason to expose it, so I haven't added a way to do that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: target=_tab
Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. I will happily discuss specific issues that you have with this but please, I think we have seen enough generic statements in this thread. Regards, Borek - Original Message From: João Eiras [EMAIL PROTECTED] To: Kristof Zelechovski [EMAIL PROTECTED]; Borek Bernard [EMAIL PROTECTED]; Ian Hickson [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Wednesday, 11 June, 2008 9:15:47 PM Subject: Re: [whatwg] Proposal: target=_tab As mentioned multiple times, that up to the user agent, or browser if you prefer, to control. Users with browsers with tabbed interface want tabs and that it. Leaving such usability in control of a webpage is bad. All browser that support tabs allow the user to choose if they want the browser to open new windows of just tabs. Na , Kristof Zelechovski [EMAIL PROTECTED] escreveu: You can use A.click instead of window.open. I have ignored the keyboard shortcut requirement because it is irrelevant. I agree that modifying window.open to support tabs would be more consistent; I just wanted to make you realize that neither is it strictly necessary nor does it require any support from JS itself (your postulated modification of the window.open interface method is perfectly suited for the current JS language, I hope?). HTH, Chris -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:27 AM To: Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi Kristof, my knowledge of JS is limited but how would you handle this situation: in your web app, you want to provide a keyboard shortcut for opening current item into a new tab. You need to invoke this action from JavaScript so setting CSS to some DOM element is not enough (AFAIK). I think window.open() would need some new optional parameter or something similar to support this. --- Borek __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
Re: [whatwg] Change request: rules for pixel ratio
I see that I made a rather serious typo in my original message. I meant to ask Should this be taken to mean that the pixelratio attribute is defaulted to 1.0 even for media resources that *DO* self-describe their pixel ratio? Still, my meaning seems to have gotten across and the new phrasing is much better. Philip On Thu, 2008-06-12 at 09:18 +, Ian Hickson wrote: On Tue, 10 Jun 2008, Philip Jgenstedt wrote: http://www.w3.org/html/wg/html5/#pixelratio Incidentally, you may prefer this version of the spec: http://whatwg.org/html5 It has a style sheet optimised for this specification instead of using the W3C style sheet. (It's otherwise identical.) The pixelratio attribute allows the author to specify the pixel ratio of anamorphic media resources that do not self-describe their pixel ratio. [...] The default value, if the attribute is omitted or cannot be parsed, is 1.0. This seems more than strange. Should this be taken to mean that the pixelratio attribute is defaulted to 1.0 even for media resources that DO NOT self-describe their pixel ratio? Yes, but that doesn't mean what you think it means. (I've clarified this in the spec.) The only way the default is used is in deciding what number to return for pixelRatio in the DOM when the content attribute is missing. If the content attribute is omitted, then the user agent doesn't adjust the intrinsic width of the video at all; the intrinsic dimensions and the intrinsic pixel ratio of the video are honoured. It is also worth noting that when the pixel ratio is 1.0 it will make more sense for the user agent to adjust the height than the width if no width/height attributes have been set. This could be pointed out in the rendering section eventually. I've allowed this explicitly now. On Tue, 10 Jun 2008, Ralph Giles wrote: Does this mean the implementation must retrieve the self-described pixel aspect ratio from the stream and supply it as part of the DOM? On Tue, 10 Jun 2008, Charles wrote: Offhand, I can't think of any use cases where it'd be useful to expose pixel aspect ratio. On Wed, 11 Jun 2008, Philip Jgenstedt wrote: Exposing pixel ratio as readonly float videoPixelRatio in HTMLVideoElement might be a good idea. If the media resource doesn't self-describe its pixel ratio (many formats don't) it should be assumed to be 1.0. I'm not convinced it is necessary as content authors who want to be very explicit will probably set the pixelratio manually. Still, it is trivial to expose and might make life easier for those who want this information for low-level control of the video element size via the DOM. I don't see a good reason to expose it, so I haven't added a way to do that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Philip Jägenstedt Opera Software
Re: [whatwg] Interpretation of video poster attribute
On Thu, 12 Jun 2008, Philip J�genstedt wrote: This isn't currently defined (even without a poster, as far as I can tell), but my intention would be to not make the poster affect the intrinsic dimensions, and for the default, in the absence of video data, is 300x150. This is defined now by the way. The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. Why? The posted would be displayed in the default 300x150 box. That the element may be resized twice is not a problem, at least not implementation-wise. That it's resized at all is a terrible problem; that it woul resize twice would be a disaster, UI-wise. As some container formats allow changing the video frame size mid-stream (notably chained Ogg streams, so called sequential multiplexing) the UA could possibly resize the video element an unlimited number of times, so handling that is necessary anyway. That's not the common case, though; a poster is. On that note, perhaps an event to notify JavaScript UIs of such changes would be useful/necessary. Perhaps reusing resize event would be the best, other names could be videochange or sizechange. I've noted this for a v3 feature. HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) cause the user agent to ignore the poster attribute. Well what else are they going to do? HTTP already requires this as far as I can tell. It appears that Safari shows a little X symbol instead, but perhaps specifying this behavior is not necessary. We will likely ignore the poster attribute entirely instead. Showing a red X seems contrary to the spec (which says that the video element represents the poster, the video, or nothing), but really rendering things are out of scope of the spec. In any case, in a few years we'll probably look at what implementations do and specify what the implementations have converged on. I'm not sure a fake button (which wouldn't actually work anyway) is a natural interpretation of poster frame. :-) As long as it's mentioned somewhere there can be no misunderstanding. Ok, added a note. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interpretation of video poster attribute
On Thu, 2008-06-12 at 09:56 +, Ian Hickson wrote: The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. Why? The posted would be displayed in the default 300x150 box. video poster=image_of_unknown_dimension src=video_of_unknown_but_same_dimension/video This is a probable and reasonable scenario, but currently it's impossible to use a poster image without knowing its dimensions. That the element may be resized twice is not a problem, at least not implementation-wise. That it's resized at all is a terrible problem; that it woul resize twice would be a disaster, UI-wise. Since the poster image will only be displayed until the video starts playing, the options when width/height is not given are: 1. the poster image is displayed at size 300x150 for several seconds while the video is loading, after which the video element takes the size of the video 2. the poster image is displayed at its native size for several seconds while the video is loading, after which the video element takes the size of the video (which will often be the same size) Since a resize is possible in both cases (but less likely in case 2) both are equally problematic UI-wise, except that the image will actually be displayed with its correct dimensions in case 2. This is just to provide sane defaults for authors who trust the browser to do the right things in absence of width/height. Safari already uses the intrinsic dimensions of the poster image and then resizes to the intrinsic dimensions of the video, which is exactly the behavior we want to implement. -- Philip Jägenstedt Opera Software
Re: [whatwg] Focus management
Ian Hickson wrote: window.focus() isn't in HTML5 as there doesn't appear to be a valid use case for it and it is too abusable, and thus shouldn't be supported. If pages depend on it being supported we could make it a no-op, I guess. I would think the opposite. Being able to pop a browser window to front is quite useful, and I have used it f ex in notifier windows that sit in some kind of loop checking for a condition (possibly minimized) and pop up to front when there is new data. And I wouldn't want to use alert() in these cases. Then maybe this functionality really should have another function name, popToFront() or something, but I don't think there is enough reason to change it. Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. I think the opposite about this one too, I guess it shows how different web users may think about their visual experience ;-) Popping a window to front on every programmatic element focusing would make windows pop to front more often than needed. Windows should be forced to front as little as possible as this is messing with the user's desktop experience. Also regard users that don't use the standard Windows focus model (click to focus = focused window on top) but rather the X-mouse-model (focus follows mouse = focused window may be partially obscured). If they are typing data into a partially obscured browser window that then calls elem.focus() to move keyboard focus, they will get an undesired window raise. So, I think it is desired to distinguish between element keyboard focus and window raising, and only let the latter be done explicitly and not as a side-effect of doing the former. Lastly, I guess if deprecating window.focus() devs would start using myDummyElem.focus() instead, to achieve the same result? Best regards Mike Wilson
Re: [whatwg] Interpretation of video poster attribute
On Thu, 12 Jun 2008 13:22:40 +0200, Chris Double [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 10:36 PM, Philip Jägenstedt [EMAIL PROTECTED] wrote: This is just to provide sane defaults for authors who trust the browser to do the right things in absence of width/height. Safari already uses the intrinsic dimensions of the poster image and then resizes to the intrinsic dimensions of the video, which is exactly the behavior we want to implement. This is the behaviour I was planning to implement for poster too btw. As a user of the video element it seemed the most logical to me. I agree. In the absence of a poster attribute does Safari load the first frame of the video and display that? Yes. I seem to recall it did when using a quicktime movie but not with a Theora movie using the XiphQT plugin. Is displaying the first frame of the video something that's useful? Well, I think it is. :-) In the Firefox implementation I display the first frame, but I should be displaying nothing, right? Why? The spec says: When a video element is paused and the current playback position is the first frame of video, the element represents either the frame of video corresponding to the current playback position or the image given by the poster attribute, at the discretion of the user agent. -- Simon Pieters Opera Software
Re: [whatwg] Proposal: target=_tab
Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
Re: [whatwg] Proposal: target=_tab
Hi ! I didn't saw that reply. I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. You're not understanding me: when I say browser, obviously I mean client, client-side, browser, user or whatever you want to call it, as opposed to web application or server-side Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it. Then we're going to bloat a specification due to browser idiosyncrasies ? Allowing a page to control such behavior would be bad. Currently browsers with tabbed interface manage to unclutter the taskbar and desktop, while aggregate pages inside a single window, which is overall good for the user's experience, good for performance, good usability. We'd be providing a mechanism that is not backwards compatible with the current state of the art user agents, although we've seen that new features heavily demanded get implemented quickly, and we'd be providing, again, authors with mechanism to degrade the user's experience. I can't honestly come up with a single reason why a webpage should open a new window instead of tab. All use cases you can come up fit better if new tabs are open. If you don't like the fact that a tab fits the entire window, you can either detach it, your use a user agent that support MDI interface. With all this say now your going to tell me I'm contradicting myself by supporting windows now. No, you'd be wrong. I'd expect a browser to always open tabs if there's a _blank target. Having _target and_tab would require UA's to support two different way of opening new pages: tabbed and detached ones. For me it's all a matter of letting the user control the web page. Considering this discussion is still going to last a bit, and everything significant that could be said by me and others was said, I rest my case. Cheers. 2008/6/12 Kristof Zelechovski [EMAIL PROTECTED]: Programmatically controlling the containment of a new window is a two-edged sword: you can provide for the lame user agent but you can also override user settings. The latter possibility is more painful; upgrading the browser is easier than dealing with an impertinent Web site. IMHO, Chris P.S.: If you want your answer to go to João only, just send it exclusively to him. -Original Message- From: Borek Bernard [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:25 AM To: Joao Eiras; Kristof Zelechovski; Ian Hickson; whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal: target=_tab Hi João, I'm not sure why you keep insisting that it's up to the browser -- IMO, it's up to the USER. Please read all my arguments before, it's not true that a user using a tabbed browser always prefers opening new tabs instead of new windows. That's just your user preference. Also, having means to open new tabs as opposed to new windows in the specs is nothing against the user preference, in fact, it helps to express the user preference if the browser fails to provide it.
[whatwg] are relative values of CanvasRenderingContext2D.font live to style changes?
I'm looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas.html#text which currently says: # When the 'font-size' component is set to lengths using # percentages, 'em' or 'ex' units, or the 'larger' or 'smaller' # keywords, these must be interpreted relative to the computed # value of the 'font-size' property of the corresponding canvas # element. When the 'font-weight' component is set to the relative # values 'bolder' and 'lighter', these must be interpreted # relative to the computed value of the 'font-weight' property of # the corresponding canvas element. If the computed values are # undefined for a particular case (e.g. because the canvas element # is not in a document), then the relative keywords must be # interpreted relative to the normal-weight 10px sans-serif # default. Suppose that the computed style of the corresponding canvas element changes between when the font DOM attribute is set and text is drawn. Based on the text above, it's not clear to me whether values like '1em' or 'lighter' should be relative to the canvas's values at the time the font is set or the time the text is drawn. In other words: var canvas = document.getElementById(mycanvaselement); var ctx = canvas.getContext(2d); canvas.style.fontSize = 16px; ctx.font = 0.75em sans-serif; // 12px, for now at least canvas.style.fontSize = 32px; ctx.fillText(hello world, 0, 0); // 12px text or 24px text? The text above: # The font DOM attribute, on setting, must be parsed the same way # as the 'font' property of CSS (but without supporting # property-independent stylesheet syntax like 'inherit'), and the # resulting font must be assigned to the context, with the # 'line-height' component forced to 'normal'. [CSS] could *perhaps* be interpreted to mean that it doesn't dynamically update, but it's not clear. I'd prefer if it were static, because for Mozilla, we'd either have to add new infrastructure to handle dynamic style changes for elements inside something that's display:none or we'd have to recompute the style for every text operation (probably the latter). -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] drawImage with non-existent images
On Sun, 17 Feb 2008, Jeff Walden wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-the-canvas.html#drawimage: If the image argument is an HTMLImageElement object whose complete attribute is false, then the implementation must raise an INVALID_STATE_ERR exception. This is all well and good in the case where the image being drawn has the same origin as the document where the canvas resides, but if the two have different origins, this makes it possible to determine the existence of an image on a foreign server. This exception must only be thrown if the image element's origin is the same as that of the document containing the canvas being modified. (You can already determine image existence by seeing how an image affects page layout, but this still seems like a reasonable behavior anyway.) There's all kinds of ways to determine if a remote resource is present or not -- onload/onerror on img or iframe, importing a script from that host, layout effects of an image, layout effects of a style sheet... I think that ship has sailed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas ath construction over save/restore boundaries
On Fri, 7 Mar 2008, Oliver Hunt wrote: Hi all, while working on a bug in our canvas implementation I've noticed that there's a difference in behaviour between Opera and Firefox when handling path construction over save/restore boundaries. Section 3.12.11.1.1 says that the canvas path is not part of the state that is effected by save/restore, unfortunately Opera and Firefox disagree on what this actually means. Firefox appears to treat restore() (effectively) as a transform that undoes the any transformations performed in the current state, so given the example: context.beginPath(); context.save() context.translate(100,100) context.rect(0,0,10,10) context.restore() context.fill() Firefox behaves as though the set of operations was context.beginPath(); context.translate(100,100) context.rect(0,0,10,10) context.translate(-100,-100) context.fill() which, given 3.12.11.1.8., results in the fill operation still drawing a 10x10 rect at (100,100). Opera meanwhile treats the path as being completely independent of the canvas state, and so draws the rect at (0,0). What I want to know is which behaviour the spec actually intends on providing. The current transformation matrix doesn't change the position at which the current path is filled. That is, assuming the fill style is a solid color, the following: context.beginPath(); context.save() context.translate(100,100) context.rect(0,0,10,10) context.restore() context.fill() ...must render the same as: context.beginPath(); context.save() context.translate(100,100) context.rect(0,0,10,10) //context.restore() context.fill() Similarly the following: context.beginPath(); context.translate(100,100) context.rect(0,0,10,10) context.translate(-100,-100) context.fill() ...must render the same as: context.beginPath(); context.translate(100,100) context.rect(0,0,10,10) //context.translate(-100,-100) context.fill() Thus the two examples you give must both render the same as: context.beginPath(); context.translate(100,100) context.rect(0,0,10,10) context.fill() ...which is the same as: context.beginPath(); context.rect(100,100,10,10) context.fill() ...which is the same as: context.fillRect(100,100,10,10) ...so Opera is wrong. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas ath construction over save/restore boundaries
On Jun 12, 2008, at 3:47 PM, Ian Hickson wrote: On Fri, 7 Mar 2008, Oliver Hunt wrote: Hi all, while working on a bug in our canvas implementation I've noticed that there's a difference in behaviour between Opera and Firefox when ... Removing a vast rambing initial email from myself ...so Opera is wrong. Yeah I came to that conclusion and webkit now matches that behaviour *sigh* We really need a separate path object :-/ --Oliver HTH, -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
