d geometric property needs a clear & extensible name

[AmeliaBR]

The edits to make path data a presentation attribute currently use the same d property name for both the shape of a <path> element and the baseline shape of a <textPath>. It is not currently used for other elements (such as <hatchpath> and <stop> elements in a <mesh>) that use path data with the path attribute.

This creates some concerns:

• d is not a particularly expressive property name outside the context of a particular element.
• the same d property is being used to apply two very different features, with only the element tag name determining how (or if) the property has an effect.
• the points attribute of <polygon>/<polyline> elements, which is a natural equivalent to d on a <path>, is not currently reflected in CSS geometric properties.

---

Main discussion on the www-svg mailing list starts here:

• https://lists.w3.org/Archives/Public/www-svg/2016Feb/0013.html

Also relevant is this discussion on the FX mailing list, regarding the path() function syntax, which unfortunately got broken into two threads, only the shorter of which was copied to www-svg:

• https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0027.html
• https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0023.html

[AmeliaBR]

Some rough sketches of a proposal.

See also the discussion from the 3 March 2016 telcon.

I think there is agreement that we need distinct property names for distinct features:

• text path
• geometry of paths & probably other shapes
• maybe geometry path fragments used within the new paint servers (or maybe they could be covered under same property as geometry of paths)

I've written up notes on text path as Issue #59. This issue will focus on shape geometry.

Defining shape geometry in CSS

• There is a desire from the CSS side to use CSS shape functions instead of raw path data strings as the value of the property.

• This already means that there won't be a simple presentation attribute which matches the property syntax. So might as well create a better property, which then pulls in the value of the attribute through the user stylesheet.

• Given this, it should be straightforward to use the same property for path/polygon/polyline. Just use different shape functions and different attr() calls in the default stylesheet. We would need to define a new polyline() function, but that will be useful for CSS motion path as well.

• I had suggested a geometry: <shape-function> as the simple-to-understand syntax.

• Extrapolating to other shapes is a little more complicated, because we need to accommodate the individual geometric attributes (cx, cy, etc.). These have had good implementer & author support. They are also preferable for animation as compared to a single property with a shape function. (For the same reasons that transform is being decomposed into individual properties.)

• I had suggested that geometry could also accept keywords (as opposed to complete functions) circle, ellipse, line, and rect to defer to the individual geometric attributes.

  This would, however, mean that it is possible either to specify geometry: circle(50%) as a complete shape, independent of the geometry attributes, or specify geometry: circle which then uses cx, cy, and r to draw the actual shape. Which is possibly very useful or possibly very confusing. Or both.

Dealing with the DOM interfaces

All this is great and backwards-compatible if you're only looking at the declarative side. However, we also have DOM interfaces which are customized for each shape type.

My approach would be to define a universal shape interface that is the union of the existing shape interfaces. The existing interface names would still exist as subclasses for backwards compatibility, but wouldn't add any unique features.

The shared behavior:

• .pathLength: author-specified path length to use for normalization of stroking, etc.
• .getTotalLength(), .getPointAtLength(distance): everybody's favourite methods for <path>, now available on basic shapes and polygons. (Yay!)
• Some way to get the computed path (or path equivalent for a basic shape) in a useful format, to replace the torn-out path segment API.
• Some way to normalize a computed path value, so that any two identical paths have the same normalized representation.
• .points to access the start and end-points of all segments in the path (e.g., every point at which a marker could be drawn) as an SVGPointList. This would be backwards-compatible with the existing points property in polygon/polyline, but would also be useful in other shapes and paths.
• .x, .y. .width, .height, .cx, and so on, as a way to get the computed value/ set the inline style for the corresponding geometric property as an SVGAnimatedLength (or whatever better backwards-compatible interface we come up with in the future to represent typed lengths).

Path fragments in paint servers

Need to figure out how <hatchPath> and path segments in <mesh> stops fit in.

---

Future wish list:

The following features probably won't be in SVG 2, but should be kept in mind as features we'd like to remain compatible with:

• a concat(<shape>, <shape>, ...) function that combines the path representations of the individual shapes (or path fragments) into a compound path. If the shapes are open paths/polylines, this would just extend the paths. If the shapes are closed, it would create a path with multiple closed sub-paths.

  For example, a donut shape could be created with geometry: concat( circle(5em), circle(3em) ) and the appropriate fill-rule.

  In combination with CSS variables, this could make it much easier to share the geometry of borders between adjacent shapes.

• a reverse(<shape>) function which would reverse the relevant path. The normal clockwise basic shapes would become counterclockwise and custom paths would be measured from the opposite end.

• a transform(<shape>, <transform-list>) function which would create a transformed version of that path fragment which could then be used in a concat() function. In combination with variables this could make it much easier to create symmetrical shapes.

[prlbr]

I’ve got a comprehension question: You aren’t suggesting to rename the d attribute in the <path /> element, so that <path d="…" /> won’t work in SVG2 anymore, are you?

[nikosandronikos]

@prlbr No, the 'd' attribute will remain.

[AmeliaBR]

Yes, we wouldn't want to change that! There is precedent for having a name mis-match between the attribute and the corresponding CSS property: the patternTransform and gradientTransform attributes now map to the standard transform property.

[prlbr]

Thanks!

[progers]

In blink-land we are trying to decide what to do with the 'd' property. The work is done to wire up css path animations through the 'd' property, but I definitely don't want to jump the gun on the spec. Is 'd' still being proposed as an alias of a future better name, or is css path animation still up in the air (https://lists.w3.org/Archives/Public/www-svg/2016Feb/0033.html)?

[tabatkins]

So I think I like this. It lets us somewhat explain how the different elements get rendered; rather than "based on tagname", which doesn't exist anywhere else in CSS, it's "based on 'geometry'". Which properties get used is based on the 'geometry' value, which is no different than 'display' controlling whether 'flex-basis' or 'grid-template' get used.

I thus support the idea that circle, rect, etc be keywords on geometry, meaning "use the appropriate properties to render as a circle/rect/etc". This preserves the authoring/animation convenience of having separate properties for their component bits.

I presume that <path>, <polygon>, and <polyline> can desugar straight to presentational hints for geometry: path(...); functions, since they don't have any independently-controllable bits, just a single attribute defining their entire geometry. Alternately we can have 'd' and 'points' properties, and give 'geometry' path/polygon/polyline keywords that make the element pay attention to those properties, but less properties is better in general I think.

(I'm gonna talk with Shane and pdr on Wednesday about this so we can get a unified Blink opinion.)

[AmeliaBR]

I think if we can decide on a name for the property, it should be safe to implement it for <path> and then generalize it later.

And yes, I agree with @tabatkins' arguments for why it makes sense to have sub-properties for circle, rect, etc, but not for path d versus polygon points.

[BigBadaboom]

For those of us in the cheap seats, is it the suggestion that d="" would be a shortcut property equivalent to geometry="path()"? And <polygon points=""> would be equivalent to <path geometry="polygon()">?

And you could do something like the following?

<path geometry="circle() circle()" ..>

if we can decide on a name for the property

Given all the mentioned elements are defined as "shape" in the spec, could that be an acceptable name for the property? It's a little shorter and would save some bytes. Perhaps a little more overloaded than geometry though :)

[nikosandronikos]

I like 'shape', simply because it's a little shorter than 'geometry'.

[AmeliaBR]

I think I avoided shape because of shape-inside/shape-outside. It would seem like a shorthand property, but it's something different entirely, since those properties are both about text layout, not SVG fill and stroke.

@BigBadaboom Your interpretation is pretty much equivalent, except that I was suggesting that we'd need to define explicit new functions to concatenate multiple shapes into a single compound path. Which keeps things straightforward at the CSS parser level and opens up the possibility that the new functions could be used in any CSS property that accepts a shape function. But that's something to explore in the advanced Paths module.

[AmeliaBR]

New idea after a full night's sleep:

With CSS WG approval, we could define a property shape-paint (the shape that is used for fill and stroke) and a shorthand shape that sets, shape-inside, shape-outside, and shape-paint all to the same value.

All three properties would not be active on the same element, but you would often want to set shape-outside to the same value as either shape-inside (if it is a floated or excluded text element) or as shape-paint (if it is an SVG shape that you're going to use as an exclusion area for a text element with shape-substract).

We might want to rename shape-subtract to make it clear that it's not re-set by the shorthand (it sets the list of excluded elements, it doesn't define a shape for this element).

[tabatkins]

Actually, I suspect we do want shape-subtract to be reset. Setting shape to something should set you to that shape, not "that shape, minus some other stuff because you forgot to reset another property too".

@BigBadaboom

For those of us in the cheap seats, is it the suggestion that d="" would be a shortcut property equivalent to geometry="path()"?

I'm not intending for this property to exist as an attribute on SVG elements. They already have everything they need - <path> has d="", <circle> just has its tagname dictating that it's a circle, etc. If you do want to invoke this explicitly, set the style attribute.

The idea is that, for example, <path d="..."> is a presentation attribute for geometry: path("...");. As Amelia said earlier, this is similar to patternTransform="..." being a presentation attribute for transform: ...;.

And <polygon points=""> would be equivalent to <path geometry="polygon()">?

Equivalent to <path style="geometry: polygon(...)">.

[nikosandronikos]

For now, we're going to make d a presentation attribute that takes path data as a string.
#119

We're open to the above proposal, but would like to tackle that as a separate module.