Intent to Ship: SVG context-fill and context-stroke

464 views
Skip to first unread message

Stefan Zager

unread,
Mar 14, 2024, 1:18:06 PMMar 14
to blink-dev

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

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 desktop124
Shipping on Android124
Shipping on WebView124


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.

Mike Taylor

unread,
Mar 14, 2024, 6:13:57 PMMar 14
to Stefan Zager, blink-dev

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
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?


Risks



Interoperability and Compatibility

None



Gecko: Shipped/Shipping
Do you happen to know what milestone this shipped in?

WebKit: No signal
Can we request a 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
Presumably this is behind a feature flag, correct?

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

unread,
Mar 14, 2024, 6:29:40 PMMar 14
to Mike Taylor, Stefan Zager, blink-dev


On Thu, Mar 14, 2024, 3:13 PM Mike Taylor <mike...@chromium.org> wrote:

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
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?

I didn't think this merited a TAG review. Do you think it does?



Risks



Interoperability and Compatibility

None



Gecko: Shipped/Shipping
Do you happen to know what milestone this shipped in?

I don't know the milestone, but it was in 2017.

WebKit: No signal
Can we request a 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.

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
Presumably this is behind a feature flag, correct?

No it isn't. Again, I didn't think this merited that kind of treatment.

一丝

unread,
Mar 14, 2024, 11:23:23 PMMar 14
to blink-dev, Stefan Zager, blink-dev, mike...@chromium.org
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

Stefan Zager

unread,
Mar 14, 2024, 11:35:12 PMMar 14
to 一丝, blink-dev, Stefan Zager, mike...@chromium.org
Patterns and gradients are supported in chromium, if you have a counter example please file a bug and assign to me.

Stefan Zager

unread,
Mar 14, 2024, 11:50:10 PMMar 14
to 一丝, blink-dev, Stefan Zager, mike...@chromium.org
On Thu, Mar 14, 2024 at 8:23 PM 一丝 <yio...@gmail.com> wrote:
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

I'm investigating the regression you mentioned on the tracking bug, I'll respond there.

Mike Taylor

unread,
Mar 15, 2024, 9:29:46 AMMar 15
to Stefan Zager, blink-dev

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:

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
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?

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.



Risks



Interoperability and Compatibility

None



Gecko: Shipped/Shipping
Do you happen to know what milestone this shipped in?

I don't know the milestone, but it was in 2017.

WebKit: No signal
Can we request a 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.


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
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. :)

Stefan Zager

unread,
Mar 15, 2024, 8:37:41 PMMar 15
to Mike Taylor, Stefan Zager, blink-dev
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:

WebKit: No signal
Can we request a 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).

Mike Taylor

unread,
Mar 18, 2024, 10:54:11 AMMar 18
to Stefan Zager, blink-dev

Thanks on both fronts, Stefan!

Mike Taylor

unread,
Mar 22, 2024, 2:47:58 PMMar 22
to Stefan Zager, blink-dev

LGTM1

Chris Harrelson

unread,
Mar 22, 2024, 3:00:56 PMMar 22
to Mike Taylor, Stefan Zager, blink-dev
LGTM2

--
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.

Yoav Weiss (@Shopify)

unread,
Mar 26, 2024, 1:33:13 PMMar 26
to blink-dev, Chris Harrelson, Stefan Zager, blink-dev, Mike Taylor
LGTM3 assuming that the gradients bug mentioned upthread is resolved in https://issues.chromium.org/issues/40362923#comment36 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Stefan Zager

unread,
Mar 26, 2024, 1:46:42 PMMar 26
to Yoav Weiss (@Shopify), blink-dev, Chris Harrelson, Stefan Zager, Mike Taylor
On Tue, Mar 26, 2024 at 10:33 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:
LGTM3 assuming that the gradients bug mentioned upthread is resolved in https://issues.chromium.org/issues/40362923#comment36 

Yes, it is fixed.

 

On Friday, March 22, 2024 at 8:00:56 PM UTC+1 Chris Harrelson wrote:
LGTM2

On 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:

WebKit: No signal
Can we request a 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.
Reply all
Reply to author
Forward
0 new messages