Is the path() function allowed for the d property?

[graouts]

The spec for the d property says:

The <string> value specifies a shape using a path data string. The contents of the <string> value must match the svg-path EBNF grammar defined below, and errors within the string are handled according to the rules in the Path Data Error Handling section. If the path data string contains no valid commands, then the behavior is the same as the none value.

Looking at the grammar I do not see any mention of the path() function. However, the bulk of the WPT coverage for the d property use the path() function and Chrome and Firefox support it.

Am I misreading the spec? Should the SVG spec allow the path() function to be used? Should the WPT coverage be updated to not use the path() function?

[JeremiePat]

This is the definition of the d property used as a DOM attribute for the <path> element. In that case, yes, the CSS path() function is not supported. To my knowledge, no browser will render the following SVG document :

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">
  <path d="path('M1,1 9,1 9,9 1,9z')" />
</svg>

The CSS path function is only allowed when the d property is used as a CSS property within a stylesheet (it's actually mandatory for parsing reasons, if I remember correctly the discussion at the CSS working group... years ago :-/ ), which make that document okay to be rendered :

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">
  <style>
    path {
      d: path('M1,1 9,1 9,9 1,9z');
    }
  </style>
  <path />
</svg>

Not that currently, Safari doesn't support the d property as a CSS property while Chrome and Firefox do.

That said, to my knowledge there is no clear spec that summarize that behavior in CSS, and FWIW, the current SVG2 spec, even if it is the most accurate SVG spec currently available, doesn't really reflect the actual state of implementation of SVG within browsers... especially when it comes to CSS.

[graouts]

Not that currently, Safari doesn't support the d property as a CSS property while Chrome and Firefox do.

That's correct, but keep an eye out on WebKit bug 234227.

That said, to my knowledge there is no clear spec that summarize that behavior in CSS, and FWIW, the current SVG2 spec, even if it is the most accurate SVG spec currently available, doesn't really reflect the actual state of implementation of SVG within browsers... especially when it comes to CSS.

That's concerning! I hope this issue yields a clear specification.