New issue
Advanced search Search tips
Starred by 5 users

Issue metadata

Status: WontFix
Closed: Dec 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Compat

Sign in to add a comment

Issue 652822: Update SVG d CSS property to match final SVG 2 spec

Reported by, Oct 4 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36

Example URL:

Steps to reproduce the problem:
The experimental Chrome implementation of SVG path data as a CSS property used a syntax based on CSS shapes path function.

The SVG WG after discussion decided this didn't make sense.  Unless the syntax was going to allow any <shape> CSS data type, there was no reason to use the path() function wrapper.

See discussion on the spec issue here:

What is the expected behavior?
The value of the property should be a CSS string containing the path data.  CSS parsers are still not expected to validate the path data; error handling is done by the SVG renderer, the same as for the attribute.

What went wrong?
Chrome 53 supports a non-standard syntax, and doesn't support the syntax in the spec.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? N/A 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 53.0.2785.116  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 23.0 r0

Comment 1 by, Dec 9 2016

Components: Blink>SVG

Comment 2 by, Dec 9 2016

Status: Available (was: Unconfirmed)

Comment 3 by, Dec 9 2016

Status: Assigned (was: Available)

Comment 4 by, May 27 2017

I think the easiest way to achieve this would be to add a "origin label" ("from string" / "from path()") to CSSPathValue and then switch on that to serialize correctly. Adding a CSSPathStringValue would be another option (if that doesn't end up generating too much duplicated code.) (Using a plain CSSStringValue means we would lose the ability to share the parsed path data.)

Comment 5 by, May 27 2017

I did a search of the May 1st 2017 httparchive data[1] and found no usage yet: of the 5 pages that reference offset-path, 3 are css property testers and 2 no longer exist. If we do decide to switch, I suspect it'll be smooth sailing. We may be able to do a usecounter (to confirm users aren't affected) in parallel with the fix to avoid a drawn-out process.

[1] SELECT url, body FROM [httparchive:har.2017_05_01_chrome_requests_bodies] WHERE REGEXP_MATCH(body, r'offset-path');

Comment 6 by, May 29 2017

I don't think we can or should switch offset-path() though, it uses the basic-shapes version of SVG paths which are still specified as being path() functions (not raw strings).

We'd need to look for pages that specify the "d" property.

Comment 7 by, Sep 1 2017

Status: ExternalDependency (was: Assigned)
I created an issue for cross-browser-vendor discussion:

Comment 8 by, Dec 12 2017

Status: WontFix (was: ExternalDependency)
The spec is being changed to use the path() function.

Sign in to add a comment