Intent to Ship: SVG context-fill and context-stroke
Stefan Zager
Contact emails
sza...@chromium.orgExplainer
NoneSpecification
https://svgwg.org/svg2-draft/painting.html#context-paintSummary
Implements an existing SVG feature that allows the keywords 'context-fill' and 'context-stroke' when specifying fill and stroke properties: https://svgwg.org/svg2-draft/painting.html#context-paint This only affects SVG sub-trees that are instantiated via a <use> element, and <marker> elements that are instantiated via the 'marker' property on a <path> element. In those circumstances, 'context-fill' and 'context-stroke' are resolved to the value of the 'fill' and 'stroke' properties on the <use> or <path>.
Blink component
Blink>SVGTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
None
Gecko: Shipped/Shipping
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name on chrome://flags
NoneFinch feature name
NoneNon-finch justification
NoneRequires code in //chrome?
FalseLaunch bug
https://issues.chromium.org/issues/40362923Estimated milestones
| Shipping on desktop | 124 |
| Shipping on Android | 124 |
| Shipping on WebView | 124 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
NoneLink to entry on the Chrome Platform Status
https://chromestatus.com/feature/5146558556536832
Mike Taylor
On 3/14/24 1:17 PM, Stefan Zager wrote:
Contact emails
sza...@chromium.org
Explainer
None
Specification
https://svgwg.org/svg2-draft/painting.html#context-paint
Summary
Implements an existing SVG feature that allows the keywords 'context-fill' and 'context-stroke' when specifying fill and stroke properties: https://svgwg.org/svg2-draft/painting.html#context-paint This only affects SVG sub-trees that are instantiated via a <use> element, and <marker> elements that are instantiated via the 'marker' property on a <path> element. In those circumstances, 'context-fill' and 'context-stroke' are resolved to the value of the 'fill' and 'stroke' properties on the <use> or <path>.
Blink component
Blink>SVG
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
None
Gecko: Shipped/Shipping
Can we request a signal?
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name on chrome://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Launch bug
https://issues.chromium.org/issues/40362923
Estimated milestones
Shipping on desktop 124
Shipping on Android 124
Shipping on WebView 124
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5146558556536832
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHOQ7J-4E-nJJ2-pcUUDLxB2pRjOmYF0fKk%2BBjqeXZmuv1uVKw%40mail.gmail.com.
Stefan Zager
On 3/14/24 1:17 PM, Stefan Zager wrote:
Is there a reason we think a TAG review would not be useful here? Alternately, has TAG reviewed the SVG2 draft in any capacity before?Contact emails
sza...@chromium.org
Explainer
None
Specification
https://svgwg.org/svg2-draft/painting.html#context-paint
Summary
Implements an existing SVG feature that allows the keywords 'context-fill' and 'context-stroke' when specifying fill and stroke properties: https://svgwg.org/svg2-draft/painting.html#context-paint This only affects SVG sub-trees that are instantiated via a <use> element, and <marker> elements that are instantiated via the 'marker' property on a <path> element. In those circumstances, 'context-fill' and 'context-stroke' are resolved to the value of the 'fill' and 'stroke' properties on the <use> or <path>.
Blink component
Blink>SVG
TAG review
None
TAG review status
Not applicable
Do you happen to know what milestone this shipped in?
Risks
Interoperability and Compatibility
None
Gecko: Shipped/Shipping
Can we request a signal?
WebKit: No signal
Presumably this is behind a feature flag, correct?
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name on chrome://flags
None
Finch feature name
None
一丝
Chrome's current implementation doesn't seem to include gradients/patterns, resvg supports them. Any plans to implement it before shipping?
If gradients/patterns are not implemented, it would be recommended to change the title of `chromestatus` to reflect this, it would be important for developers.
Also here's a regression to look at: https://issues.chromium.org/issues/40362923#comment31
Stefan Zager
Stefan Zager
Nice work, this feature is a great addition to SVG, and Rust-based resvg also implemented it a while ago: https://github.com/RazrFalcon/resvg/pull/665
Chrome's current implementation doesn't seem to include gradients/patterns, resvg supports them. Any plans to implement it before shipping?
If gradients/patterns are not implemented, it would be recommended to change the title of `chromestatus` to reflect this, it would be important for developers.
Also here's a regression to look at: https://issues.chromium.org/issues/40362923#comment31
Mike Taylor
On 3/14/24 6:29 PM, Stefan Zager wrote:
On Thu, Mar 14, 2024, 3:13 PM Mike Taylor <mike...@chromium.org> wrote:
On 3/14/24 1:17 PM, Stefan Zager wrote:
Is there a reason we think a TAG review would not be useful here? Alternately, has TAG reviewed the SVG2 draft in any capacity before?Contact emails
sza...@chromium.org
Explainer
None
Specification
https://svgwg.org/svg2-draft/painting.html#context-paint
Summary
Implements an existing SVG feature that allows the keywords 'context-fill' and 'context-stroke' when specifying fill and stroke properties: https://svgwg.org/svg2-draft/painting.html#context-paint This only affects SVG sub-trees that are instantiated via a <use> element, and <marker> elements that are instantiated via the 'marker' property on a <path> element. In those circumstances, 'context-fill' and 'context-stroke' are resolved to the value of the 'fill' and 'stroke' properties on the <use> or <path>.
Blink component
Blink>SVG
TAG review
None
TAG review status
Not applicable
I didn't think this merited a TAG review. Do you think it does?
According to our process, we either need to request a TAG review,
or explain why we think it doesn't require a TAG review. But I've
just reminded myself of the exceptions at
https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/
- and I think you're good given the first exemption.
Do you happen to know what milestone this shipped in?
Risks
Interoperability and Compatibility
None
Gecko: Shipped/Shipping
I don't know the milestone, but it was in 2017.Can we request a signal?
WebKit: No signal
It strikes me as odd to request a position on a mature, long since published spec, but if you think it's appropriate I will do so.
I think it serves as a good signal that WebKit should prioritize shipping here as well, if they'll be the only engine without support - and if they have strong feelings as to why something should change before we do ship it, now is the time for them to provide that input before it's too late.
Presumably this is behind a feature flag, correct?
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name on chrome://flags
None
Finch feature name
None
No it isn't. Again, I didn't think this merited that kind of treatment.
Can you explain why you think this should be exempt, per
https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md?
In the future, you can avoid these kinds of questions if you give
a little bit more justification. :)
Stefan Zager
On 3/14/24 6:29 PM, Stefan Zager wrote:
On Thu, Mar 14, 2024, 3:13 PM Mike Taylor <mike...@chromium.org> wrote:
On 3/14/24 1:17 PM, Stefan Zager wrote:
Can we request a signal?WebKit: No signal
It strikes me as odd to request a position on a mature, long since published spec, but if you think it's appropriate I will do so.I think it serves as a good signal that WebKit should prioritize shipping here as well, if they'll be the only engine without support - and if they have strong feelings as to why something should change before we do ship it, now is the time for them to provide that input before it's too late.
Presumably this is behind a feature flag, correct?
No it isn't. Again, I didn't think this merited that kind of treatment.Can you explain why you think this should be exempt, per https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md?
In the future, you can avoid these kinds of questions if you give a little bit more justification. :)
Mike Taylor
Thanks on both fronts, Stefan!
Mike Taylor
LGTM1
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d27afdeb-d8d3-4e45-ba33-15476a9ddc17%40chromium.org.
Yoav Weiss (@Shopify)
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Stefan Zager
LGTM3 assuming that the gradients bug mentioned upthread is resolved in https://issues.chromium.org/issues/40362923#comment36
On Friday, March 22, 2024 at 8:00:56 PM UTC+1 Chris Harrelson wrote:
LGTM2On Fri, Mar 22, 2024 at 11:47 AM Mike Taylor <mike...@chromium.org> wrote:LGTM1
On 3/18/24 10:53 AM, Mike Taylor wrote:
Thanks on both fronts, Stefan!
On 3/15/24 8:37 PM, Stefan Zager wrote:
On Fri, Mar 15, 2024 at 6:29 AM Mike Taylor <mike...@chromium.org> wrote:
On 3/14/24 6:29 PM, Stefan Zager wrote:
On Thu, Mar 14, 2024, 3:13 PM Mike Taylor <mike...@chromium.org> wrote:
On 3/14/24 1:17 PM, Stefan Zager wrote:
Can we request a signal?WebKit: No signal
It strikes me as odd to request a position on a mature, long since published spec, but if you think it's appropriate I will do so.I think it serves as a good signal that WebKit should prioritize shipping here as well, if they'll be the only engine without support - and if they have strong feelings as to why something should change before we do ship it, now is the time for them to provide that input before it's too late.
I opened a webkit standards position issue.
Presumably this is behind a feature flag, correct?
No it isn't. Again, I didn't think this merited that kind of treatment.Can you explain why you think this should be exempt, per https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md?
In the future, you can avoid these kinds of questions if you give a little bit more justification. :)
Sorry, the process requirements have expanded quite a bit since I last shipped web-exposed features. I will retrofit a feature flag (CL).--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.