Does the entire path need to be valid in order to use a path attribute on a textPath

Per https://www.w3.org/TR/SVG2/text.html#TextPathElement

If the ‘path’ attribute contains an error, the ‘href’ attribute must be used.

I can understand that path="" or path="foo" might be ignored.

However, does this also mean that a path="M 100, 100 foo" is ignored? That seems inconsistent with path error handling where it says that they are rendered until an error occurs (https://www.w3.org/TR/SVG2/paths.html#PathDataErrorHandling)

I propose that path attributes be handled the same way as path rendering i.e. as long as the first element in the path is valid, the path would be used.

I agree with your logic, and I don't think we have any implementations yet, so there is no compat risk in changing it.

Furthermore, we have this instruction in the definition of path attribute:

An empty string indicates that there is no path data for the element. This means that the text within the ‘textPath’ does not render or contribute to the bounding box of the ‘text’ element. If the attribute is not specified, the path specified with ‘href’ is used instead.

If that is the desired behavior (similar to an empty d value on a <path> preventing rendering), then I think that should be the invalid value default as well (that is, path="foo" should behave the same as path=""). And then it only makes sense to use partial parsing, too. Basically, if a path attribute is present, href is ignored. Use as much of the path as can be parsed, and then layout as much of the text as fits on that path..

For the summary description, the "If the path contains an error..." sentence could be removed completely.

Aside, when someone makes edits, also fix the typo in the href definition:

or the referenced element is not a ‘path’ element) or basic shape

"or basic shape" should be inside the ")"!

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

@karlcow

For the summary description, the "If the path contains an error..." sentence could be removed completely.

I agree to remove this sentence. Currently, neither Chrome nor Firefox will ignore an incorrect path value.

See also:

@karlcow Do you have time to take a look at this?

https://w3c.github.io/svgwg/svg2-draft/text.html#:~:text=attribute%20contains%20an%20error%2C

The sentences is still in there:

If the ‘path’ attribute contains an error, the ‘href’ attribute must be used.

Yes we could remove it.

From https://w3c.github.io/svgwg/svg2-draft/text.html#TextPathElement

Click on path https://w3c.github.io/svgwg/svg2-draft/text.html#TextPathElementPathAttribute
Click on path data https://w3c.github.io/svgwg/svg2-draft/paths.html#PathDataBNF

At the bottom, it says:

The EBNF allows the path data string in the d property to be empty. An empty path data string disables rendering of the path. Rendering is also disabled when the d property has the value none.

If path data not matching the grammar is encountered, then the path data is in error (see Error Handling).

Click on error handling https://w3c.github.io/svgwg/svg2-draft/paths.html#PathDataErrorHandling

which addresses the issues about invalid path data.

Thank you for the clarification. Additionally, it seems there is currently no corresponding path property in CSS. Should we add one?

Something like: d: path("m 5,5 h 35 L 20,30 z").
However, if it were written as path: path("m 5,5 h 35 L 20,30 z") in CSS, it would seem a bit odd.

This seems a separate issue and for the SVG WG.
fyi, there is a path() in CSS

@yisibl

@yisibl Is there already full coverage of the different scenarios for valid and invalid path in SVG in the context of textPath.

If not, that would be the first steps, create WPT testcases to understand, what browsers are currently doing, and see if there is an interop path possible.

@viralipurbey

@yisibl Is there already full coverage of the different scenarios for valid and invalid path in SVG in the context of textPath.

If not, that would be the first steps, create WPT testcases to understand, what browsers are currently doing, and see if there is an interop path possible.

@viralipurbey I see you've already implemented this feature for Chrome. Can you add WPT test cases?

@dirkschulze

Although we reached a resolution on this issue during the last meeting, I've noticed a few spec details that are causing some confusion about the correct behavior in this case.

Here are the relevant spec links:
https://www.w3.org/TR/SVG2/text.html#TextPathElement:~:text=If%20the%20%E2%80%98path%E2%80%99%20attribute%20contains%20an%20error
and
https://svgwg.org/svg2-draft/paths.html#PathDataErrorHandling

I think there are more issues, and it would be helpful to discuss them again before finalizing the WPTs.
@dirkschulze @karlcow @nikolaszimmermann

Note that I'm preparing a series of tests for paths parsing.
https://github.com/WebKit/WebKit/pull/59882/changes

Bug 2020295 [wpt PR 58166] - Add WPTs for SVG textPath path attribute…

RESOLUTION: If the d attribute would result into an empty path (not specified, no path data or due to an error) we fallback to href. If there is at least some valid path data at the beginning, we will continue to use the path data specified with the d attribute up to the error.

https://www.w3.org/2026/03/12-svg-minutes.html

Update textPath path/href fallback behavior per WG resolution

Update SVG textPath path attribute WPTs per SVG WG resolution (w3c/sv…

Bug 2020295 [wpt PR 58166] - Add WPTs for SVG textPath path attribute…

Update SVG textPath path attribute WPTs per SVG WG resolution (w3c/sv…

Bug 2020295 [wpt PR 58166] - Add WPTs for SVG textPath path attribute…

Navigation Menu

Repository navigation

Does the entire path need to be valid in order to use a path attribute on a textPath #393

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Does the entire path need to be valid in order to use a path attribute on a textPath #393

Description

Activity

AmeliaBR commented on Mar 20, 2018

boggydigital commented on Jun 11, 2018

yisibl commented on Feb 10, 2026

karlcow commented on Feb 10, 2026

yisibl commented on Feb 10, 2026

karlcow commented on Feb 10, 2026

karlcow commented on Feb 13, 2026

yisibl commented on Feb 13, 2026

6 remaining items

viralipurbey commented on Mar 3, 2026

karlcow commented on Mar 5, 2026

dirkschulze commented on Mar 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions