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

Re: Properties of Custom Paint

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 19 May 2015 14:57:45 -0400
Message-ID: <CAAWBYDARtfrqFs8CwmQXyNj=ohuNWeeyT=TCSzegLJd2nhwBEg@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Cc: "public-houdini@w3.org" <public-houdini@w3.org>, Ian Kilpatrick <ikilpatrick@chromium.org>
On Tue, May 19, 2015 at 1:54 PM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
> Hello all,
> Custom paint routines have been something I've been thinking about a lot
> myself, in the context of SVG.
> I haven't yet written all my ideas down, but the general approach would be
> based on the web components model.  SVG paint servers are defined with XML
> markup fragments, and therefore have corresponding DOM interfaces.  Why not
> create a generic <paint> element that could be defined by extending the DOM
> interface with a custom paint function that tells the browser what color to
> draw at any given point.  Just like web components, the <paint> element
> could have child content that defines parameters that would be used by the
> interface when building that function.
> I bring this up because of course it would be preferable to have a
> consistent underlying model for defining the paint, regardless of whether it
> was used in CSS or SVG.
> SVG custom paint servers may also be the easier first step towards CSS
> custom paint servers, mostly because you would not have to hack the CSS
> parser.  The CSS declaration for using the paint as SVG fill or stroke would
> be a standard url(#myPaint) reference.  A proof-of-concept (if not very
> performant) polyfill is feasible, that would replace each usage of the
> custom paint server with an SVG <pattern> containing an image copy of the
> canvas rendered by the painting function.
> With respect to the specific requirements outlined on the gist
> (https://gist.github.com/bfgeek/758b54a1cab65dff9d69), I think they can all
> be equally applicable to the SVG model.  Paint would be dependent on any
> layout and style changes to the painted object, but would not affect layout
> or other styles.
> The last point in the "required" list, regarding geometry data, becomes very
> important when talking about painting SVG shapes.  One of the main
> limitations of existing SVG paint is that it always applies to a rectangular
> region, creating a sheet of wallpaper that is then clipped to the shape. To
> create a pattern that follows the shape's contours--even for something as
> simple as having a gradient that follows the direction of a straight
> line--you need to manually define a matched pair of paint server and shape
> with the same coordinates hard-coded.
> I'd be happy to bounce around more ideas to figure out how this might work.
> If there is agreement that an SVG Custom Paint Servers Module would be a
> good first step for testing out custom paint in general, I can bring it up
> in the SVG WG to see if there is support there.

Custom Paint actually goes quite a bit past "custom paint servers".
It's more like, say, what if box-shadow didn't exist, and you wanted
to draw a shadow on a box.  Or say underlines didn't exist, and you
wanted to add them.  Today, these are possible, but *incredibly*
hacky, requiring additional elements and some dumb stuff; Custom Paint
lets you affect how these elements paint and add
shadows/underlines/anything else.

Custom Paint Servers are easy, and already done in spec - just use
<canvas> to draw them, and use element() in CSS to reference them.
This is available today in Firefox via -moz-element().

Received on Tuesday, 19 May 2015 18:58:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 19 May 2015 18:58:39 UTC