- From: Jasper St. Pierre <jstpierre@mecheye.net>
- Date: Sun, 15 Sep 2013 12:09:08 -0400
- To: David Dailey <ddailey@zoominternet.net>
- Cc: whatwg@whatwg.org
On Sun, Sep 15, 2013 at 12:04 PM, David Dailey <ddailey@zoominternet.net>wrote: > Last I checked applying a clipPath to text in SVG works consistently across > browsers, and there it remains accessible: to screen readers, indexing, > searching, drag-to-select, etc. Why would one want a bunch of pixels that > resemble text? > > Just saying, > David > I have an insane, complex use case, and you'd laugh at me if I told you what it was, but trust me when I say I need an immediate mode drawing API like <canvas> instead of a retained scene graph like SVG. -----Original Message----- > From: whatwg-bounces@lists.whatwg.org > [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Jasper St. Pierre > Sent: Sunday, September 15, 2013 11:38 AM > To: whatwg@whatwg.org > Subject: [whatwg] Clipping text in in canvas > > 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] > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme > nt.html#drawing-text-to-the-bitmap > > -- > Jasper > > > -- Jasper
Received on Sunday, 15 September 2013 16:09:33 UTC