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

[Stefan Zager]

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

[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

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]

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.

[一丝]

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]

Patterns and gradients are supported in chromium, if you have a counter example please file a bug and assign to me.

[Stefan Zager]

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]

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]

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]

Thanks on both fronts, Stefan!

[Mike Taylor]

LGTM1

[Chris Harrelson]

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.

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)]

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]

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.