Re: Detailed proposal for layered fill and stroke

On Tue, May 12, 2015 at 6:42 AM, Amelia Bellamy-Royds
<> wrote:
> -  Particularly for strokes of different widths, it is preferable to allow
> multiple solid color layers without needing hacks such as single color
> gradients or extra markup to create a solidColor paint server element.

This is accomplishable through the image() function; you can omit the
urls and just supply a color, and you'll get a solid-color image.
Easier and less hacky than using a linear-gradient and repeating the

> -  It would be very useful to create paint server elements that can be
> customized by passing a color property at the time they are used.

We have a number of mechanism to accomplish this already;
currentColor, use-color (or whatever it's called), var().  I can't
quite tell, from the proposal, what the "context" stuff is trying to
do. Can you elaborate?

> The idea of the *-index properties came from the need to control the
> layering of three different stacks of paint content (fill, strokes, and
> markers) rather than a single stack for background images.

We already have 'paint-order' for controlling the relative ordering of
fill/stroke/markers.  Within strokes/fills/etc, ordering is controlled
by the order in which they appear.  It seems like the only new thing
added by *-index is the ability to interleave stroke/fill/marker
painting, but that's a rather new thing that hasn't had any use-cases
presented for it, and its functionality directly overlaps with

> If there is a strong desire to add back in the other background properties
> (e.g., *-position, *-origin, *-clip, *-repeat, *-attachment, *-size), I'd be
> happy to hear those arguments.  However, I really think they confuse things
> with unnecessary complexity more than they simplify things with similarity
> to the background shorthand.

They need to be in there.  CSS paint servers are usable with SVG as
well, and proper use of them requires those properties.  Yes, they
more or less overlap with <pattern> use, but having them in a property
form is useful, and keeps them close to the CSS properties we're
deriving these from.

> I'm not sure why there would be a need for CSS WG review first, since these
> would be SVG-specific properties.  However, I would be happy to have
> additional feedback if you want to suggest that group members take a look at
> the proposal.  I definitely want to discuss the *-box properties with those
> active on the FX specs that use SVG graphical effects elements with
> objectBoundingBox vs userSpaceOnUse units.

There's no such thing as "SVG-specific properties".  They're still
CSS, even if they only have an effect on SVG elements, and review by
the CSSWG prevents problems.  We can help ensure that they don't make
common mistakes, and that they are in line with modern design patterns
for properties.

This, in particular, is a big, involved proposal.  I would strongly
object to doing anything with it without extensive CSSWG review and
feedback; there are several points I note from a quick read that
should be changed.  I'll need to spend some time reviewing this more


Received on Wednesday, 13 May 2015 22:59:58 UTC