- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 19 May 2015 14:57:45 -0400
- 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(). ~TJ
Received on Tuesday, 19 May 2015 18:58:38 UTC