-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[svg-native] How should currentColor be handled? #678
Comments
To the |
@litherum Do you have objections to supporting the |
No objection, just mild disapproval |
@litherum 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 |
So, to clarify Myles: you support I see two use cases this blocks (given other constraints we've agreed to for SVG Native):
|
I understand the drawbacks mentioned by @AmeliaBR but still think that the correct course of action here is to:
That makes currentColor handling a simple, root-element import from the environment (or, if no such value is passed in, you get black). |
@svgeesus My general concern is that OT SVG does support If SVG Native does not support Would removing |
The SVG Working Group just discussed
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. |
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 thecolor
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.The text was updated successfully, but these errors were encountered: