[svg-native] How should currentColor be handled?

[litherum]

The currentColor keyword (when used as an attribute value) should probably be supported because this is how OpenType files specify that some part of the glyph should match the surrounding text color.

However, I don't think that an SVG being able to modify currentColor (via the color attribute) is necessary, because all the places where it's referred to in the subtree can just specify the desired value directly.

Getting currentColor's interaction with all the other values and the <use> element is tricky.

[dirkschulze]

color is an inherited property. Even if specified as attribute on a ancestor element it inherits its value down to the element using currentColor.

To the <use> element: Not necessarily if you keep in mind how the element behaves. The referenced element is part of the use-elements subtree. So while processing the use-element you keep up building your "render tree". Of course it depends on the actual implementation. I am not a fan of support use in SVG Naitve.

[dirkschulze]

@litherum Do you have objections to supporting the color CSS property and currentColor? It is probably hard to estimate how often color is actually used in SVG. In SVG it only makes sense in combination with currrentColor IIRC.

[litherum]

No objection, just mild disapproval

[dirkschulze]

@litherum currentColor get promoted on the semi-official OpenType-SVG spec. My fear is that we get inconsistent and incompatible with existing content.

What is your disapproval based on? Is it based on implementation complexity? Since an implementation (probably) needs to support property inheritance, is it significantly more complex to implement currentColor?

[AmeliaBR]

So, to clarify Myles: you support currentcolor as a value, but want to continue to forbid color as a presentation attribute?

I see two use cases this blocks (given other constraints we've agreed to for SVG Native):

• Using color/currentcolor as a poor man's CSS variable (since we've forbid any way to directly set true custom properties) for <use> element clones.
• Setting color to a var() expression with fallback, and then using the result many places with currentcolor without having to repeat the fallback each time.

[svgeesus]

I understand the drawbacks mentioned by @AmeliaBR but still think that the correct course of action here is to:

• allow the currentColor value to be used
• disallow the color property to be set.

That makes currentColor handling a simple, root-element import from the environment (or, if no such value is passed in, you get black).

[dirkschulze]

@svgeesus My general concern is that OT SVG does support currentColor and color. The "spec" even points it out in an example.

If SVG Native does not support color and OT implementations pick up an SVG Native parser/renderer, would we see problems? How is the support for color in shipping implementations? Adobe products do support color on import and rendering (even for OT SVG fonts) but doesn't export color. What about OT SVG platform implementations in macOS/iOS/Windows?

Would removing color even break a single OT SVG font? Majority of SVG material for fonts likely got created with authoring tools. Not aware of authoring tools that actively export color.

[css-meeting-bot]

The SVG Working Group just discussed How should currentColor be handled?, and agreed to the following:

• RESOLUTION: Conformant SVG Native documents must not set the color property and a UA should not support the color property.
• RESOLUTION: currentcolor for SVG Native is set by the initial value of the color property of the environment.

The full IRC log of that discussion

<krit> topic: How should currentColor be handled?
<krit> GitHub: How should currentColor be handled?
<krit> chris: my proposal would be to allow currentColor but do not require the color property.
<krit> myles: matches what I imagined.
<krit> AmeliaBR: it would be consistent with variables.
<krit> krit: should not? Must not? (support color)
<krit> AmeliaBR: myles: Conformant doc must not support color and a UI should not support color
<myles> s/UI/UA/
<AmeliaBR> https://docs.microsoft.com/en-us/typography/opentype/spec/svg#colors
<krit> AmeliaBR: There was a question about color supported in OT SVG fonts. Any input if there is content affected by the new decision?
<AmeliaBR> github: https://github.com//issues/678
<krit> krit: Authoring tools likely don't support color but manual created SVG documents might. Testing/tracking required on the platform layer to be sure.
<krit> AmeliaBR: Seems like it is not explicitly forbidden in the OT spec.
<krit> sairus: It is an implication.
<krit> myles: Apple's implementation does not support the color property.
<krit> krit: If there is one major platform that does not support color than my concern is less relevant.
<krit> AmeliaBR: maybe it should at least be added to the avoided list on the OT spec.
<krit> AmeliaBR: sairus, could you follow up?
<krit> sairus: will do.
<krit> RESOLUTION: Conformant SVG Native documents must not set the color property and a UA should not support the color property.
<krit> myles: Our implementation actually DOES support color. Was minuted wrong. We just don't have fonts in our repository that do use the color property.
<krit> sairus: it is recommended that currentcolor should not appear in an SVG Native document?
<krit> chris: that is right
<AmeliaBR> s/currentcolor/color attribute or property/
<krit> proposed res: currentcolor for SVG Native is set by the initial value of the color property of the environment.
<krit> RESOLUTION: currentcolor for SVG Native is set by the initial value of the color property of the environment.