Re: Detailed proposal for layered fill and stroke

Thanks for the notes Tab.  A couple clarifications below.

On a more general note, I know that what I've written is a grand, and
possibly over-reaching, proposal.  But it came from looking at what was
currently in the spec & trying to make it make sense.  I wanted to get a
discussion started about how this will work, and what it is trying to
achieve.

The fact is, there isn't enough detail right now for how SVG paint servers
will work with the CSS-background syntax.  Or even about how images as fill
will work.  Let alone things like background attachment and clip and
<shape-box> values on an SVG shape.

If someone wants to write it all out, that would be very a useful point of
comparison.

What would something like `fill: linear-gradient(red,blue) fixed bottom/50%
20em padding-box fill-box` look like?  Is there a use case for it?  Will
implementations really be able to re-use existing code or would this just
complicate things further?

I'm a big advocate of not re-inventing the wheel, but I'm also a big
advocate of keep it simple, s'il vous plait!  I really feel that if we
start with CSS background syntax and try to adapt it for SVG, we'll end up
with something that is much more complicated than it needs to be, without
addressing many of the more interesting use cases.

ABR


On 13 May 2015 at 16:59, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, May 12, 2015 at 6:42 AM, Amelia Bellamy-Royds
> <amelia.bellamy.royds@gmail.com> 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
> color.
>

Sure, if anyone implemented image().  I think it is still hanging on
support for #xywh=.

I know: it's in the spec, and it's coming, so it is an option.  I would
certainly advocate for it ahead of creating any custom function notation.
But, it would be nice to be able to dispense with extra function notations
altogether when all we need are a list of colors.


>
> > -  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 problem is that paint servers *do not* inherit CSS styles from the
shape that they are painting.  Neither do markers according to the spec (IE
implements it otherwise, with messy results if you forget to over-ride the
inherited stroke on your arrowheads!).  So you can't use currentColor and
you can't use var().  (I don't think useColor actually exists anywhere, it
got standardized away to currentColor.)

The idea of the context keywords is to allow basic coordinate of markers
and shapes, and it has been adopted as an official requirement for SVG 2 --
but without any clear details on how it would work with paint servers
(e.g., is it the original shape's bounding box that is used?  Or the box
for the marker and with layered paint servers in particular.

Tav brought up the idea of being able to use a context-color like keyword
for patterns and hatches.  The main benefit would be to reduce the amount
of markup you require for data viz and other mapping and other situations
where you have a lot of variations on a pattern that differ by color.

But that brings up the problem of circular references.  It also begs the
question of, if you can parameterize by color, why not by other styles?
>From an implementation perspective, once you allow one it is no extra
burden to allow others -- either way you have to re-render the paint server
content for each context.  And already, if paint servers are correctly
implemented they need to be customizable to the context because of
percentages and userSpaceOnUse units (there are bugs last I checked in
Blink/Webkit with respect to this).

I wrote more on the potential issues a few months back:
https://lists.w3.org/Archives/Public/www-svg/2015Jan/0012.html

This was my attempt to address those issues while also maximizing
functionality.


> > 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
> 'paint-order'.
>

Pretty much, yes.  This was an "instead of paint-order" idea.  I hadn't
actually realized that anyone had implemented paint-order yet.  I think
paint-order as it is currently proposed is going to be a very unfortunate
constraint as we move forward with advanced markers and strokes, in
addition to the very practical use of being able to interleave strokes and
fills.

If you haven't seen use cases yet, it is because people haven't started
playing around with multiple fills and strokes.  I am quite confident that
when they do, the paint-order approach will become an annoyance just like
the current strokes-on-top rule.


>
> > 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 think your last line says it all.  I'm really arguing that we should be
looking at SVG use cases and working from there, rather than making SVG a
derivative of CSS.  I don't think these properties would be bad, I just
think they add a lot of complexity without a lot of benefit, both for
authors and for SVG implementations that don't already implement CSS layout.


> > 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
> thoroughly.
>
>  Fair enough.  Looking forward to additional comments.  But I would also
like to have some feedback from the SVG side.  What do people want this
feature to accomplish?  How can we make it easier to use?  How can we make
it something useful and distinct from CSS-formatted HTML?