[whatwg] Canvas: Rendering radial gradients beyond the terminal stops

Greetings! The current draft of HTML5 [1] says about rendering radial gradients: "This effectively creates a cone, touched by the two circles defined in the creation of the gradient, with the part of the cone before the start circle (0.0) using the color of the first offset, the part of the co

[whatwg] Application Cache Quota Proposal

Proposal to Add Per-Origin Quotas to Application Cache: --- Application Caches right now do not have any storage limitations. This has clear issues when used on devices with limited storage capacity. Other programmatic client side sto

Re: [whatwg] Canvas transform() and matrix element notation

On Mon, Jul 19, 2010 at 3:54 PM, Boris Zbarsky wrote: > On 7/19/10 4:13 PM, David Flanagan wrote: >> >> The spec describes the transform() method as follows: >> >>> The transform(m11, m12, m21, m22, dx, dy) method must multiply the >>> current transformation matrix with the matrix described by: >>

Re: [whatwg] Canvas transform() and matrix element notation

> Date: Mon, 19 Jul 2010 14:33:01 -0700 > From: da...@davidflanagan.com > To: bzbar...@mit.edu > CC: whatwg@lists.whatwg.org > Subject: Re: [whatwg] Canvas transform() and matrix element notation > > Boris Zbarsky wrote: > > On 7/19/10 4:13 PM, David Flanagan wrote: > >> The spec describes the

Re: [whatwg] Canvas transform() and matrix element notation

Boris Zbarsky wrote: On 7/19/10 4:13 PM, David Flanagan wrote: The spec describes the transform() method as follows: The transform(m11, m12, m21, m22, dx, dy) method must multiply the current transformation matrix with the matrix described by: m11 m21 dx m12 m22 dy 0 0 1 The first number in

Re: [whatwg] Canvas transform() and matrix element notation

Boris Zbarsky wrote: On 7/19/10 4:54 PM, Boris Zbarsky wrote: By the way, 100% agreed that the multiplication order needs to be defined here. Though I would prefer to define it in terms of transformation order (which one takes place first), not left-multiplication vs right-multiplication, si

Re: [whatwg] Canvas transform() and matrix element notation

On 7/19/10 4:54 PM, Boris Zbarsky wrote: While true, if you look at the way one constructs an AffineTransform by passing in the matrix entries [4]: AffineTransform(double m00, double m10, double m01, double m11, double m02, double m12) That should have been: [4] http://download.oracle.com/do

Re: [whatwg] Canvas transform() and matrix element notation

On 7/19/10 4:54 PM, Boris Zbarsky wrote: By the way, 100% agreed that the multiplication order needs to be defined here. Though I would prefer to define it in terms of transformation order (which one takes place first), not left-multiplication vs right-multiplication, since the behavior of th

Re: [whatwg] Canvas transform() and matrix element notation

On 7/19/10 4:13 PM, David Flanagan wrote: The spec describes the transform() method as follows: The transform(m11, m12, m21, m22, dx, dy) method must multiply the current transformation matrix with the matrix described by: m11 m21 dx m12 m22 dy 0 0 1 The first number in these argument names

[whatwg] Canvas transform() method and matrix multiplication order

While I'm harping on the transform() method, I'd like to point out that the current spec text "must multiply the current transformation matrix with the matrix described by..." is ambiguous because matrix multiplication is not commutative. Perhaps an explicit formula that showed the order would

[whatwg] Canvas transform() and matrix element notation

The spec describes the transform() method as follows: The transform(m11, m12, m21, m22, dx, dy) method must multiply the current transformation matrix with the matrix described by: m11 m21 dx m12 m22 dy 0 0 1 The first number in these argument names is the column

Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations

On Mon, Jul 19, 2010 at 5:56 AM, Hallvord R M Steen wrote: > 2010/7/15 Adam Barth : >>  So, I'd prefer >> that we didn't change APIs after shipping them unless necessary.  If >> we keep changing shipping APIs, we'll exhaust early adopters, which is >> bad for the ecosystem. > > I agree with that i

Re: [whatwg] Canvas stroke alignment

Wow, that would be so enormously useful. You make a shape, add a shape inside of it that is 100x100, add a stroke, get the width and it's 101. This "error" cascades, and shifts your items around on redraw. The math workaround is not easy. FWIW, Photoshop uses "position" for this option (I don't

Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations

On 7/19/10 8:56 AM, Hallvord R M Steen wrote: I have no idea when other implementations of postMessage() were written. However, "throw an exception if targetOrigin has a path/query/fragment" is a spec requirement since October 2008 according to this change: http://html5.org/tools/web-apps-tracker

[whatwg] Canvas stroke alignment

Canvas would benefit from a way to set stroke alignment. With the only available alignment being center, which is not very useful, custom paths have to be drawn to mimic inside and outside stroke alignment. That workaround may give unwanted transparency on pixels between a path and its stroke p

Re: [whatwg] application/octet-stream

On 19.07.2010 14:56, Robert O'Callahan wrote: On Mon, Jul 19, 2010 at 11:20 PM, Philip Jägenstedt mailto:phil...@opera.com>> wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types There was some discussion about this, last in

Re: [whatwg] application/octet-stream

On Mon, 19 Jul 2010 14:56:09 +0200, Robert O'Callahan wrote: On Mon, Jul 19, 2010 at 11:20 PM, Philip Jägenstedt wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types There was some discussion about this, last in < http://lists.whatwg.org/htdig.cgi/wha

Re: [whatwg] application/octet-stream

On Mon, Jul 19, 2010 at 11:20 PM, Philip Jägenstedt wrote: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types > > There was some discussion about this, last in < > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-May/026409.html> > > I've tested Firefox 3

Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations

2010/7/15 Adam Barth : >>> Personally, I think we should stop screwing with postMessage and let >>> it be a stable enough API that folks can rely upon it. >> >> Screwing with the spec, or with implementations?  The spec, as currently >> written, is not compatible with the majority of shipped imple

[whatwg] application/octet-stream

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#mime-types There was some discussion about this, last in I've tested Firefox 3.6.4, Firefox 4.0b1 and Chrome 5.0.375.99 and none return "maybe" f