W3C home > Mailing lists > Public > public-houdini@w3.org > May 2015

Re: Properties of Custom Paint

From: Dean Jackson <dino@apple.com>
Date: Fri, 22 May 2015 05:48:45 +1000
Cc: Ian Kilpatrick <ikilpatrick@chromium.org>, "public-houdini@w3.org" <public-houdini@w3.org>, Robert O'Callahan <robert@ocallahan.org>
Message-Id: <47812D61-2F10-4DA8-A47E-87F47BCBF810@apple.com>
To: Shane Stephens <shans@google.com>

> On 22 May 2015, at 5:38 am, Shane Stephens <shans@google.com> wrote:
> As I've said to Shane and Ian offline, I think that a variant on the element() feature can address many of the requirements for custom paint with a few API modifications (allowing it to be used in more places, in addition to default rendering, responding to layout updates, etc). We've found -webkit-canvas to be especially useful in this manner (we use it for the custom rendering of our scrubber bar in media controls).
> One concern I have with this is that if you register the same canvas to multiple elements, you're stuck with a single canvas size. So you can't really build a custom painter that e.g. paints a fancy border for any given size input - instead, you'd need to create a new <canvas> element that shadows every fancy border instance, so that each could be responsive independently to layout.
> In fact, I'd like to propose an extra "Required Property" for Ian's list:
> Custom Paint functions can be shared across multiple elements
> One potential solution is to either allow element() to reference paint functions directly (rather than just out-of-dom canvases), or to add a new CSS function for this purpose (e.g. paint()).

Yes, I completely agree with this requirement.

As you say, there are a few potential solutions. One of the downsides to element() over canvas() was that it makes it difficult to extend the function to indicate that maybe you want a shared canvas vs a per-instance canvas.

Received on Thursday, 21 May 2015 19:49:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 21 May 2015 19:49:19 UTC