- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Sun, 14 Feb 2016 14:45:20 -0700
- To: www-svg <www-svg@w3.org>
- Message-ID: <CAFDDJ7z0=zbvhzrMmMaCDH9ZgkV337jG82ebQSw_SkB5CWYyZw@mail.gmail.com>
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
Received on Sunday, 14 February 2016 21:45:48 UTC