RE: Rename 'd' property

I think these are all good points to keep in mind. Remember also, that at some point in the future (SVG5?) something like <superpath> or <vePath> will inevitably be specced (again). Fingers can only be kept in dams so long. At such time, the ability to refer to subpaths, and oriented collections of subpaths will be needed. And when the SVG WG actually starts undertaking new features again, assuming there is light at the end of this tunnel, then allowing attributes other than x and y to receive data from bivariate or multivariate path-like (or grid-like) objects to control other variables such as hue, width, dur, stdDeviation, etc. will be a logical extension of path data to contexts other than pure geometry.  One could always look at the <replicate> proposals for proof-of-concept of these multivariate ideas, [even if one doesn’t care for <replicate>, as it is has been rumored that some don’t].

 

Cheers

David

 

From: Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com] 
Sent: Sunday, February 14, 2016 4:45 PM
To: www-svg
Subject: Re: Rename 'd' property

 

I am inclined to agree with the concern about the `d` as a property name in CSS style sheets. Removed from the immediate context of a <path> element, the letter d has little meaning.

 

An equal concern, for me, is the existing & increasing inconsistency in the attribute names that reference path data. In SVG 1.1, there were two elements that directly accepted path data, with 2 different attribute names:

* path element - d attribute
* animateMotion element - path attribute

In the current SVG 2 spec, we also have:

* hatchpath element - d attribute
* stop element (in a mesh) - path attribute
* textPath element - d attribute

In each case the path data represents a different aspect of rendering, so having different names is not necessarily a problem.  But the names should be consistent as far as what they represent. A mesh path and a hatchpath seem logically similar, while motion path seems closer to text path, but the names are arbitrary.

 

A related question is what to do with `points` on polygon and polyline.  It seems silly not to have these also controllable from CSS, but it would be redundant to create another CSS property.  Since we are using a path() function notation to convert a string of path data into a shape, it seems logical to simply use a polygon() / polyline() function to do the same for the points list.  A more generic property name could apply to all three elements.

 

~ABR