Re: Detailed proposal for layered fill and stroke

Thinking over Dirk & Tab's comments, I can see the following adjustments:

*For the layered-paint syntax.*  I still think the CSS background syntax is
more complicated than necessary for SVG paint servers.  However, I could
concede the benefit of consistency *if* there was some openness on the CSS
side to allowing SVG paint servers in CSS backgrounds.  In other words, if
the end result was a completely consistent syntax, not an SVG syntax that
was even more complicated than the already complicated background syntax.

Do either of you think that might happen?  Particularly for mesh gradients,
this could be a cool added feature for CSS backgrounds.  You certainly
would not want to define something that complicated in pure CSS.  Also for
transformed patterns and for hatches (faking diagonal stripes with
gradients is currently very hacky, with ugly aliased rendering on Blink!).
The concept could be similar to how filters, masks, and clip-paths now
work: simple effects are defined in pure CSS, more complicated graphical
effects are defined by reference to SVG elements.

If there is openness to this idea, I can take another look to try to figure
out how all the background-* properties could adapt to SVG paint servers.

*For paint order control*, forget the z-index based approach.  I hadn't
realized that both Blink and Firefox had already pushed implementations of
the painting-order property.  But I still think that painting-order as
currently defined is too limiting for layered strokes/fills, let alone for
multiple marker types.  So can we extend it in a consistent manner?
Something like:

painting-order: stroke 2, fill, stroke 1;
  /* Paint the first two stroke layers, then all the fill layers,
     then 1 stroke layer.
     Then paint all remaining layers (additional strokes and
     all markers) in the default order.
  */
painting-order: markers mid, stroke, fill, markers start end;

  /* Paint the mid-markers, then all stroke layers, all fill layers,

     then start and end markers.
     Then any remaining layers (other markers?).
  */

painting-order: markers -start -end, stroke -1, fill, markers, stroke;

  /* Paint all markers *except* start and end markers.

     Paint all stroke layers *except* the last one.

     Paint all fill layers.

     Paint any remaining markers layers.

     Paint any remaining stroke layers.

  */


The markers spec could then extend the property to include keywords for
other marker types.

*For referencing context styles,* I'm leaning towards having a single
approach for all cases, using a context() function notation.  The function
would be similar to var(), including the ability to specify a fallback
value.  However, it could be used to access the computed value of *any*
property, not just custom properties.  Unlike with var, you would not have
to worry about circular logic because you'd be accessing the computed style
from a different element.

I can write up a more detailed explanations for these last two in the wiki,
probably sometime next week.

Before I do any major re-writes, I'd still like some feedback on the
following questions:

   - The overall idea that layered strokes and fills should be implemented
   as a set of properties with a shorthand, even though it means that existing
   properties would not be part of that shorthand.

   - The approach to implementing reference boxes for scaling as
   independent and orthogonal to the scaling method defined in the *Units
   attribute.  We would want consistency with how this is handled in filters
   and masking/clipping (currently not defined clearly in those specs), so
   it's important that there is a consensus on this.

   - The expanded definition of context element.

   - Any of the little issues I call out in the wiki.

Best,
Amelia