Intent to Ship: Support external SVG resources for 'clip-path', 'fill', 'stroke' and 'marker-*' properties

[Chromestatus]

Contact emails

f...@opera.com

Explainer

None

Specification

https://svgwg.org/svg2-draft/linking.html#URLReference

Summary

Allow external references for clip paths, markers, and paint servers (for the 'fill' and 'stroke' properties). For example, clip-path: url("resources.svg#myPath").

Blink component

Blink>SVG

Search tags

svg

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The main interoperability risk is that these properties still do not support referencing external resource document in all browsers (not supported in WebKit yet). No compatibility issues are known from similar cases (for example 'mask-image'), and it's assumed that the support in these additional set of properties will be similar.

Gecko: Shipped/Shipping Has been shipping for a long time. No attempt was made to dig up the ancient scrolls containing the relevant release notes.

WebKit: No signal

Web developers: Strongly positive Has 123 stars/+1s when this is being written.

Other signals:

Security

Requests the resources in the same way as similar properties - for example 'mask-image' (same-origin credentials mode).

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

Supported the same way as any other resource referenced via CSS.

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

https://wpt.fyi/results/css/css-masking/clip-path/clip-path-url-reference-external.html https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-001.sub.svg https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-002.sub.svg https://wpt.fyi/results/svg/painting/reftests/gradient-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/marker-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/pattern-external-reference.svg

Flag name on chrome://flags

Finch feature name

SvgExternalResources

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/40134477

Estimated milestones

Shipping on desktop	131
Shipping on Android	131
Shipping on WebView	131

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/5198862739046400?gate=5157993826746368

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

This looks like a great straightforward way of making the platform more consistent. Just a few minor questions for the intent before approving...

On Fri, Oct 4, 2024 at 5:18 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

f...@opera.com

Explainer

None

Can you write up a quick paragraph or two explaining this feature, and why web developers are excited about it?

 

Specification

https://svgwg.org/svg2-draft/linking.html#URLReference

Summary

Allow external references for clip paths, markers, and paint servers (for the 'fill' and 'stroke' properties). For example, clip-path: url("resources.svg#myPath").

Blink component

Blink>SVG

Search tags

svg

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The main interoperability risk is that these properties still do not support referencing external resource document in all browsers (not supported in WebKit yet). No compatibility issues are known from similar cases (for example 'mask-image'), and it's assumed that the support in these additional set of properties will be similar.

Gecko: Shipped/Shipping Has been shipping for a long time. No attempt was made to dig up the ancient scrolls containing the relevant release notes.

WebKit: No signal

Can you file for signals?

 

Web developers: Strongly positive Has 123 stars/+1s when this is being written.

Other signals:

Security

Requests the resources in the same way as similar properties - for example 'mask-image' (same-origin credentials mode).

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

Supported the same way as any other resource referenced via CSS.

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

https://wpt.fyi/results/css/css-masking/clip-path/clip-path-url-reference-external.html https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-001.sub.svg https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-002.sub.svg https://wpt.fyi/results/svg/painting/reftests/gradient-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/marker-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/pattern-external-reference.svg

A few of these fail in Gecko, and one of them passes in WebKit, which doesn't quite match the claimed interop status. (Also, the first one shows as failing even in Chrome.) Can you help reassure us that the test coverage here is solid?

 

Flag name on chrome://flags

Finch feature name

SvgExternalResources

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/40134477

Estimated milestones

Shipping on desktop	131
Shipping on Android	131
Shipping on WebView	131

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/5198862739046400?gate=5157993826746368

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/66ffa4bf.2b0a0220.d54b7.1474.GAE%40google.com.

[Fredrik Söderquist]

On Mon, Oct 7, 2024 at 6:15 AM Domenic Denicola <dom...@chromium.org> wrote:

This looks like a great straightforward way of making the platform more consistent. Just a few minor questions for the intent before approving...

On Fri, Oct 4, 2024 at 5:18 PM Chromestatus <ad...@cr-status.appspotmail.com> wrote:

Contact emails

f...@opera.com

Explainer

None

Can you write up a quick paragraph or two explaining this feature, and why web developers are excited about it?

This is what I wrote in the "Motivation" field:

"This feature allows easily sharing SVG paint servers, clip paths and markers between different documents, and, for example, having a library of such resources."

This allows creating reusable "components" in the form of clip paths, gradients, patterns and markers. This is in a way similar to how you, today, can have an external SVG with "symbols" that can be reused via <use>.

 

Specification

https://svgwg.org/svg2-draft/linking.html#URLReference

Summary

Allow external references for clip paths, markers, and paint servers (for the 'fill' and 'stroke' properties). For example, clip-path: url("resources.svg#myPath").

Blink component

Blink>SVG

Search tags

svg

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The main interoperability risk is that these properties still do not support referencing external resource document in all browsers (not supported in WebKit yet). No compatibility issues are known from similar cases (for example 'mask-image'), and it's assumed that the support in these additional set of properties will be similar.

Gecko: Shipped/Shipping Has been shipping for a long time. No attempt was made to dig up the ancient scrolls containing the relevant release notes.

WebKit: No signal

Can you file for signals?

 https://github.com/WebKit/standards-positions/issues/411

 

Web developers: Strongly positive Has 123 stars/+1s when this is being written.

Other signals:

Security

Requests the resources in the same way as similar properties - for example 'mask-image' (same-origin credentials mode).

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

Supported the same way as any other resource referenced via CSS.

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

https://wpt.fyi/results/css/css-masking/clip-path/clip-path-url-reference-external.html https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-001.sub.svg https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-002.sub.svg https://wpt.fyi/results/svg/painting/reftests/gradient-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/marker-external-reference.svg https://wpt.fyi/results/svg/painting/reftests/pattern-external-reference.svg

A few of these fail in Gecko, and one of them passes in WebKit, which doesn't quite match the claimed interop status. (Also, the first one shows as failing even in Chrome.) Can you help reassure us that the test coverage here is solid?

https://wpt.fyi/results/css/css-masking/clip-path/clip-path-url-reference-external.html

This test seems to have minor rendering differences between the two different test runners (for Chrome), and also Gecko. I guess we'll need to add some fuzziness parameters.

https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-001.sub.svg

This is testing "anonymous" state for CORS. Looks like there could be disagreement there. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1923109 for discussion.

https://wpt.fyi/results/svg/linking/reftests/url-processing-fetch-properties-002.sub.svg

This passes everywhere because it tests that a resource is not allowed to load (and thus the fallback color is used instead).

/fs

[Yoav Weiss (@Shopify)]

LGTM1

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

[Mike Taylor]

LGTM2

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/8e5ca4c3-2143-4499-9be6-56413cae199an%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ad8a1aa-cda6-4f0d-8fd4-46a9480d9450%40chromium.org.