Enable the preference by default on all channels.

This should be documented at https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d.

Sebastian

https://hg.mozilla.org/mozilla-central/rev/c69e6c0ebaba

FF97 Docs work for this can be tracked in: https://github.com/mdn/content/issues/11597#issuecomment-1009508674

For the browser compatibility data part I have done this: https://github.com/mdn/browser-compat-data/pull/14498
Prior to this update support is marked as partial with the note:

Only supported on the <code>clip-path</code> and <code>offset-path</code> properties.".

After this, I have changed that to:

From version 91 it can be used on the <code>d</code> SVG presentation attribute. For earlier versions it is only supported on the <code>clip-path</code> and <code>offset-path</code> properties.

Is the second statement true? i.e. is this this implementation partial, and is that a correct representation of where you can use it on FF98?

(In reply to Hamish Willee from comment #5)

From version 91 it can be used on the <code>d</code> SVG presentation attribute. For earlier versions it is only supported on the <code>clip-path</code> and <code>offset-path</code> properties.

Is the second statement true? i.e. is this this implementation partial, and is that a correct representation of where you can use it on FF98?
Yes. Yes.

The 2nd statement is true because d property support path() as well (i.e. the same syntax as offset-path).
Note: the syntax of path() is a little bit different between offset-path[1] and clip-path[2].

[1] path( <string> ), from https://drafts.fxtf.org/motion-1/#funcdef-offsetpath-pathfunc-path
[2] path( [<'fill-rule'>,]? <string> ), from https://drafts.csswg.org/css-shapes-1/#funcdef-path

FF98 ships CSS d property, and we accept path() function but not path <string>, which matches the behavior in Chrome. There is a spec issue talking about the possible acceptable strings for CSS d property: https://github.com/w3c/svgwg/pull/374. IIRC, Eric would like to let d property accepts only path() or none, but other spec editors would like to support SVG path <string> as well (for backward compatibility). The current SVG2 spec only defines <string>. Appearally, it's a spec issue. If we would like to follow other spec editors' ideas, we should also support SVG path string CSS d property. So I think this is "partial" implementation. We can remove partial once the spec becomes clearer. (If the meaning of "partial" matches what I'm thinking. :))

Please let me know if you have other questions. Thanks for updating MDN for this.

Thank very much @Boris - really helpful! Sorry for delay, just back from holidays. I did most of the work on this before I went aways.

Following this comment I've clarified the difference between clip-path and offset-path + d use of path() in https://github.com/mdn/content/pull/12705.

I am not planning on updating the compatibility data for d supporting a string until either someone implements that or the spec settles that it must be supported. I'm confirming that is OK with BCD in point 6 of https://github.com/mdn/browser-compat-data/pull/14498#issuecomment-1025296723

Thanks again!

Awesome. These look good to me. Thanks for updating MDN for this.