Re: [whatwg] Clipping text in in canvas

Sorry for the noise, my code just had a bug (surprise, surprise).

It was significantly more complicated than this, but the core of the bug
    ctx.rect(0, 0, 100, 100);
    ctx.rect(30, 0, 100, 100);

But I forgot to reset the path before the clip(), meaning that the clip did
nothing at all.

A lack of standard test cases for <canvas> clipping behavior, a
StackOverflow answer [0], and no way to reliably debug this sort of issue
(I couldn't find any way to get or dump the current path on the context)
made me think that the browser behavior was incompatible with the spec.

As penance, I'll find some time today to contribute some tests to the
<canvas> test suite.


On Mon, Sep 16, 2013 at 1:40 PM, Ian Hickson <> wrote:

> On Sun, 15 Sep 2013, Jasper St. Pierre wrote:
> >
> > The canvas specification maintains:
> >
> >     These shapes are painted without affecting the current path, and are
> > subject to shadow effects, global alpha, the clipping region, and global
> > composition operators. [0]
> >
> > But no browsers I tested actually implement the "clipping region" part.
> > Should this be removed for backwards compatibility reasons? Should we
> > introduce a new method of clipping text be introduced, or should we just
> > require users who want to draw clipped text to draw to a scratch canvas
> > and use drawImage to copy the pixels? [0]
> >
> Do you have a test case demonstrating the problem you describe?
> (Note that browsers not following the spec is usually not resolved by
> adding another feature that does the same thing, since there's no reason
> to believe they're any more likely to follow that spec either.)
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


Received on Monday, 16 September 2013 18:04:25 UTC