Context stroke and fill keywords

Regarding the SVG WG agenda request:

* 'context-fill', 'context-color' should apply to <pattern> and <hatch>
(Tav)

This is a great idea, making patterns and hatches much more flexible.  I
would recommend just generalizing it to apply to any XML element that is
referenced through a style property of another element: <marker>,
<pattern>, <hatch>, <gradient>, <filter>, and conceivably <solidColor> and
<mask> (although I'm not sure of the use cases for those).

However, in order to use the keywords for paint server elements, the
context fill/stroke values would need to be defined in a way that prevents
circular references to the paint server itself.

Since fill and stroke allow fallback colors, the logical solution is that
the keywords reference these colors instead of the paint server.

Questions than become:

   - Is there a use case for keywords that reference the context paint
   server instead of the context paint color fallback?  If so there would need
   to be multiple keywords:
   - contextStrokeColor, contextFillColor, and contextColor for color
      values that you could safely reference from within a paint server
      - contextStrokePaint, contextFillPaint for color OR paint server
      values that you could reference from with a marker (or within a
      non-circular reference paint server, e.g. referencing contextStrokePaint
      from within a paint server used for the element's fill)

      - If both keyword types are adopted, how should circular reference
   errors be handled?

   - Should the fill / stroke properties be converted into CSS shorthand
   properties, allowing you to set `stroke-color` and `fill-color` directly,
   separately from `stroke-paint` and `fill-paint` ?  These would be useful in
   data viz, in that it allows you to set a pattern/hatch design using one CSS
   class, and then control the color with a separate set of classes.
   Following CSS rules, setting the shorthand property (`fill` or `stroke`)
   would reset both constituent properties (color and paint), so current
   behavior would be maintained.

   - If separate properties are used, would SVG-specific color types count
   as a `color` value or as a `paint` value?  I'm not talking about references
   to a <solidColor> element (these would always count as a paint server), but
   about references to ICC profile colors and other color descriptors that
   aren't supported in CSS.


While on the topic, some more general questions about the context keywords
are:

   - What would be the result of using one of the context keywords in a
   situation where there is no "context"?  Options are to use a the initial
   value for the property (black/none), to use the actual element's value for
   the same property (e.g., elements are their own context), or to use the
   inherited value for the property.  Or use the element's value for the
   property, except when that would result in a circular reference (e.g.
   `stroke: contextStrokeColor`), in which case use the inherited value.

   - Should the context keywords have a special meaning for graphics in a
   `<use>` element (given that normal style inheritance already works in this
   case)?

   - Should there be a way to reference custom CSS variables from the
   context element?  E.g., by defining a `context-var(--variable)` function
   that is otherwise equivalent to the `var(--variable)` function from the CSS
   variables spec?


AmeliaBR