Support pathLength via CSS

@shshaw

I'd expected to be able to set this attribute via CSS but turns out that I can't. It was also pointed out here in this tutorial on an svg animation by @shshaw https://youtu.be/7aobRPg7BXI?t=741

I would definitely love to see this supported. Being able to set pathLength with CSS would make stroke effects & animations even easier. I can imagine some great effects by animating pathLength as well: https://codepen.io/shshaw/pen/KKwRMZd?editors=1010

Hm, I'm surprised path-length isn't a geometry property for it, yeah.

I agree that it makes sense to treat pathLength as another geometry property. And I also agree that the logical property name would be path-length (so that the camel-cased DOM version is still style.pathLength.

So the question is: who's interested in implementing it? What spec version should this be targetted for?

Given sufficiently positive signals from other engine vendors, I'd be happy to implement (or aid an implementation of) the property (and presentation attribute mapping) in Blink.

The SVG Working Group just discussed Support pathLength via CSS.

The full IRC log of that discussion

<AmeliaBR> Topic: Support pathLength via CSS
<AmeliaBR> github: https://github.com//issues/773
<krit__> ScribeNick: AmeliaBR
<AmeliaBR> Amelia: Been some blogs & twitter discussion about how pathLength is helpful for stroke effects. But that raised question of why it needs to be an attribute when stroke styles AND geometry are now in CSS.
<AmeliaBR> ... proposal is to make a path-length geometry property.
<AmeliaBR> ... I think it's a good idea. But not sure about adding it to SVG 2. No implementations yet. Is it a priority?
<AmeliaBR> krit: Looks some interest from at least one implementer.
<AmeliaBR> Amelia: Yes, fsoder said he could do the work in Blink. But needs others.
<AmeliaBR> nzimmermann: WebKit doesn't yet do anything with the attribute. It just parses it, doesn't affect rendering. So that still needs to happen. But adding it as a CSS property doesn't seem to make it any more complicated.
<AmeliaBR> Amelia: And might even be easier to do both changes at the same time?
<AmeliaBR> Tav: We (Inkscape) don't appear to implement it (for stroke dashing). But for us, properties and attributes are treated very similarly. Wouldn't make much extra work.
<AmeliaBR> Amelia: So it sounds like first step is get some tests of what pathLength (as attribute) is supposed to do, re stroke dashing and such.
<AmeliaBR> ... Then we can get some feedback on how hard it is to implement.
<AmeliaBR> ... The benefit of adding to CSS depends on it actually affecting rendering!
<AmeliaBR> krit: There is one test. It uses animations.
<AmeliaBR> Amelia: That was the only part explicit in SVG 1. Stroking effect wasn't well defined; that was added in SVG 2.
<AmeliaBR> nzimmermann: One concern is that anything to do with pathLength is very complicated. In WebKit, this is all in the platform-specific underlying code. You tell the backend the path & the stroke pattern.
<AmeliaBR> krit: What you'd need to add is scaling of the stroke pattern.
<AmeliaBR> nzimmermann: Yes, but then you need to ask the backend to calculate a path length. Which isn't trivial.
<AmeliaBR> Amelia: I mean, the purpose of pathLength was to adjust for these underlying differences in path length calculation. But then you do need some back-and-forth between the two code levels.
<AmeliaBR> krit: Original intention was specifically for things like textPath and animation where it is really important to be consistent.
<AmeliaBR> nzimmermann: And for those cases, we already calculate path length on our own, so it's easier to scale. But with stroking we defer to the backend.
<AmeliaBR> ... I'm not sure it's technically possible to get the exact length the underlying code is using for the stroking.
<AmeliaBR> Tav: Is that a big difference?
<AmeliaBR> krit: Maybe, but point is to get rid of that difference, so we need to know it.
<AmeliaBR> Tav: But other use case is just ease for author. To explicitly set length of 100 and then work with that, without having to measure anything.
<AmeliaBR> [more discussions on underlying libraries]
<AmeliaBR> krit: So first thing is to write tests to know if it is implemented at all.
<AmeliaBR> Amelia: Or, implemented consistently in the details.
<AmeliaBR> Tav: And performantly.
<AmeliaBR> krit: We also need buy-in from CSS working group, since this would be a new property.
<AmeliaBR> ... let's ask TabAtkins to bring it up at CSS WG F2F
<AmeliaBR> krit: And for the performance criteria, does that really affect whether it should be in CSS? Or whether it should be there at all?
<AmeliaBR> Amelia: It's not related to CSS. It's whether pathLength should affect stroking that is performance issue.
<AmeliaBR> ... but if we take that out, not much point to add to CSS.
<AmeliaBR> ... Beyond that, only question is can anyone write up some tests?
<AmeliaBR> krit: And writing good tests, considering the subtle differences between implementations.
<AmeliaBR> Amelia: I don't think we need to specifically test *for* those differences. But need to be careful they're not ruining results with pixel differences.
<AmeliaBR> Tav: I can try to write some up.

Consider this a positive signal from WebKit!

The CSS Working Group just discussed Summer meeting dates, and agreed to the following:

RESOLVED: add path-length as a CSS property and make pathLength map to it

The full IRC log of that discussion

<TabAtkins> Topic: Summer meeting dates
<AmeliaBR> I can't hear Rossen, but we now have conflicts both weeks of July 20 (AB meeting) and July 27 (Tantek doesn't want Monday, Rachel Andrew needs to be in UK by Friday)
<AmeliaBR> https://wiki.csswg.org/planning
<AmeliaBR> If we move to the following week, FYI Monday Aug 3 is a holiday in Canada.
<TabAtkins> proposal is Mon-Thu, week of July 27, Houdini on Monday
<emilio> Topic: Path length in CSS
<astearns> github: https://github.com//issues/773
<emilio> TabAtkins: SVG has a pathLength attr supported on <path>
<emilio> ... it allows you to override the length of the path
<AmeliaBR> q+
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<AmeliaBR> q+
<astearns> q+ AmeliaBR
<emilio> ... allows you to set up e.g. exactly 100 dashes or such
<emilio> ... otherwise you'd need to do a bunch of math or use JS
<emilio> ... given you can set the path in CSS
<RossenF2F> Zakim, open queue
<Zakim> ok, RossenF2F, the speaker queue is open
<emilio> ... it seems reasonable to let you set it in CSS as a property alongside d
<emilio> ... in terms of signals, we got positive signals from WebKit and Blink
<emilio> heycam: seems fine too
<emilio> ack AmeliaBR
<astearns> ack AmeliaBR
<emilio> AmeliaBR: originally in svg1 it only had an effect on `<path>`, in SVG2 it affects all shapes
<emilio> ... I think implementation of that is pretty god
<emilio> good*
<emilio> ... but we don't have good implementation of what it actually does
<emilio> ... so we do have some concerns on our last svgwg discussions
<emilio> ... so want to followup with proper testing and ensure we have interop to deal with some patterns
<emilio> ... but kind of a separate issue of whether it should be a pres attr
<emilio> q+
<heycam> q+
<emilio> ... it makes sense to be consistent with the stroke properties and such
<emilio> ... one complication is that this is the first time we use an attribute in mixed-case form
<emilio> ... recommendation is that it becomes hyphenated
<emilio> ... and the mismatch will just be a legacy version
<emilio> TabAtkins: that's my exact suggestion
<emilio> ... and also that means that the style object gets the camel-case object, which is nice
<astearns> ack emilio
<TabAtkins> emilio: Do we need to do something for stuff that takes a path function, like shapes and such?
<emilio> TabAtkins: nothing else lets you go along the path
<emilio> astearns: motion-path
<emilio> TabAtkins: but that allows percents which provides this functionality
<emilio> astearns: for shapes I could see using pathLength to short-circuit some stuff, but it doesn't seem a big use-case
<emilio> TabAtkins: that's not how pathLength works, it just resets the length in the calculations
<RossenF2F> q?
<emilio> myles: doesn't motion-path allow you to describe infinite-length paths or something like that?
<emilio> TabAtkins: it allows you to define ray() but there's a definition for what 100% means
<AmeliaBR> Motion path is one thing where distance along a path is relevant. That was one of the original uses in SVG (for the SMIL motion path)
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<emilio> heycam: an alternative would be to allow percentages in stroke-dasharray/dashoffset
<emilio> ... would make it similar to other CSS things
<emilio> myles: so one of the nice things of path-length would be that you can animate it to have your dashes grow and stretch along the path
<faceless2> q+
<emilio> ... if you have a bunch of percentages you need to animate them individually
<emilio> AmeliaBR: getting percents in stroke-dasharray would be nice, right now they're valid but don't have a useful interpretation
<emilio> ... kinda separate from other use cases for path-length
<emilio> faceless2: path-length is not only about dashes but also precise text positioning around a path
<emilio> chris: the generating tools have an idea of how long the path is
<emilio> ... and by setting it the implementation just agrees to scale it
<emilio> astearns: objections to resolve?
<emilio> RESOLVED: add path-length as a CSS property and make pathLength map to it

I've done some basic testing. The attribute 'pathLength' is supported by Firefox and Chrome, not by Safari and Edge. Inkscape does not support 'pathLength' but it shouldn't be hard to implement.

The attached zip file contains tests of stroke dashing using 'pathLength':

path_length.svg: Tests basic support on path, rectangle, circle.
path_length2.svg: Tests support on a very long spiral path consisting of cubic Beziers. Firefox and Chrome differ in the calculation of the path length by about 0.1% (14px out of 11760px). They both agree within 0.2% of my naive calculation of the path length.
path_length3.svg: A SMIL animation on the spiral path, with and without using 'pathLength'. There is no indication of a problem with computation time.

I see no problems in adding 'path-length' as a CSS property.

path_length.zip

@Tavmjong

Chromium/Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1045430

I looked at what tests existed for the pathLength attribute:

https://wpt.fyi/results/svg?label=master&label=experimental&aligned&q=pathlength

That seemed to cover the visual tests, and there are a few related to SVGGeometryElement APIs in types/scripted/.

I'm in the process of exporting some of Blink's tests as well (ought show up in the above query when the export has completed). And I see that (while I was writing this =P) @Tavmjong has drafted a few more test.

Add path-length CSS property definition (Section 9.6.1)

Bug 2021220 [wpt PR 58280] - [SVG] Support path-length as a CSS prope…

RESOLUTION: pathLength attribute will get a presentation attribute with the CSS property being path-length taking a number unit only for now
https://www.w3.org/2026/03/26-svg-minutes.html

I think the CSSWG will also need to review this property and potentially change its syntax to align with unit type conventions in CSS. See comment here.

Adding the resolution to the right issue.
RESOLUTION: Follow the suggestion of the CSS WG and let pathLength take a length value rather than a number value.

https://www.w3.org/2026/05/21-svg-minutes.html

What work remains for this issue?

In SVG 2, nothing: §9.6.2 The path-length property was merged on 2026-04-23 (#1073) and already takes none | <length>, per the 2026-05-21 resolution.

The rest is not in SVG 2.

The SVG Paths module, which says it replaces the Paths chapter, has no path-length at all.
The WPT tests (wpt#58280) are all still .tentative.
WebKit's standards position (Support path-length CSS property for SVG path elements WebKit/standards-positions#621) was closed as "invalid" because it was not filed with the template. Nobody has refiled it (Microsoft to do).
longsonr's 2023 point is unanswered:

Currently the path for a textPath can be display: none and it's OK. If you make pathLength a CSS property then display:none paths used for textPath that have pathLength set will no longer work as expected.

On the browsers side:

Chrome has it behind a flag (SvgPathLengthCssProperty). On wpt.fyi only Edge has results: parsing 27/27, interpolation 32/32.
Firefox has no implementation (no longhand in Servo).
WebKit: bug 309321

I propose to

close Support pathLength via CSS #773 as done in SVG 2?
And track the Paths module copy. Open a new issue? The fix is a svgwg PR that copies SVG 2 9.6.2 (The path-length property (https://w3c.github.io/svgwg/svg2-draft/paths.html#PathLengthProperty)) into specs/paths/ and updates the pathLength row to "maps to path-length, unitless value read as px". (I could do that in the bikeshed version too. See other issue about it)
remove .tentative extensions separately.
- svg/path/parsing/path-length-{valid,invalid,computed}.tentative.svg
- svg/path/distance/path-length-css-{property,overrides-presentation-attribute,zero,zoom}.tentative.svg and their -ref files
- svg/path/animations/path-length-interpolation.tentative.html

@longsonr

@longsonr about #773 (comment)

If you make pathLength a CSS property then display:none paths used for textPath that have pathLength set will no longer work as expected.

There is now a WPT test for this case, by @viralipurbey:
https://wpt.fyi/results/svg/text/reftests/textpath-pathlength-css-display-none.tentative.svg

<defs>
  <path id="path1" d="M10 60 L210 60" style="display:none; path-length:10px"/>
</defs>
<text><textPath href="#path1" startOffset="5">X</textPath></text>
<!-- matches startOffset="100": the X is halfway along the line -->

Chrome 157 canary	Edge 157	Firefox 160	Safari 254 preview
pass	pass	fail	fail

wpt.fyi experimental runs of 2026-10-12, so path-length is on behind its flag in Chrome. Firefox and Safari do not implement path-length yet, so their failure says nothing about display: none.

In Chromium, textPath asks the referenced path for its author length, and the path computes its style on demand when it has none, the same way getComputedStyle() works on a display: none element:

const ComputedStyle* style =
    const_cast<SVGGeometryElement*>(this)->EnsureComputedStyle();

On the spec side, display: none elements still have computed values. https://drafts.csswg.org/css-cascade-5/#value-stages

Every element has exactly one computed value per property.

Does that address your concern, or did you have another case in mind?

RESOLUTION: close issue 773 as completed
https://www.w3.org/2026/10/13-svg-minutes.html#0f6c

Bug 2021220 [wpt PR 58280] - [SVG] Support path-length as a CSS prope…

Navigation Menu

Repository navigation

Support pathLength via CSS #773

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support pathLength via CSS #773

Description

Activity

shshaw commented on Jan 10, 2020

tabatkins commented on Jan 10, 2020

AmeliaBR commented on Jan 10, 2020

fsoder commented on Jan 12, 2020

css-meeting-bot commented on Jan 15, 2020

grorg commented on Jan 15, 2020

css-meeting-bot commented on Jan 22, 2020

Tavmjong commented on Jan 24, 2020

fsoder commented on Jan 24, 2020

8 remaining items

dirkschulze commented on Mar 26, 2026

chrishtr commented on May 8, 2026

viralipurbey commented on May 21, 2026

SteveBeckerMSFT commented on Oct 9, 2026

karlcow commented on Oct 13, 2026

karlcow commented on Oct 13, 2026

karlcow commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions