- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Fri, 24 Apr 2015 12:15:00 +0200
- To: www-svg@w3.org
Smailus, Thomas O: > While one can use stroke-dasharray to get such an effect, it feels like a > misuse semantically, since there is not actually a dash pattern on the > shape, but that distict edges are stroked with a certain style. If one > were to try and do some analysis of the SVG to learn something about the > shape - having it with a dashed stroke would mislead about what the object > represents. > > Thomas > If it is relevant only for content, not just for styling and presentation, one should use subpaths for this to indicate what belongs to the path and what not - this is the essential function of the commands M/m, but as mentioned, it might require a rearrangement of path data, if one converts from one format to another. Obviously either it matters for the path itself (use subpaths and rearrangement) or it is just an option/alternative how to present the path (use stroke-dasharray). As already mentioned by others in this discussion, typically it is styling, if one does not want a fraction of a path to be visible. Both options are available in SVG 1.1 and SVG tiny 1.2, just the styling option with stroke-dasharray is not very comfortable for authors and this use case. Line-joins and line-caps are styling as well currently, if one needs it as content, one has to calculate the outline of the stroke and to note this as a path. And finally, if noted as presentation attributes, not just as properties, this is an indication, that it matters for content, not only for styling. If one uses the stroke-dasharray attribute, it provides information about content, not just about some alternative presentation, however it is possible to add additional styling with a property, if it turns out, that alternative presentations are meaningful as well. A new path comment should have a functionally beyond that of M/m and rearrangement - and if this applies, indeed it would be important to find all such cases for a need to new commands now and to add it to the SVG 2 draft to avoid further backwards incompatibilities with future versions - each time, a command is added, practically the interpretation of path data in old viewers for new documents is broken, therefore better to have this not in each new version ;o) Olaf
Received on Friday, 24 April 2015 10:15:30 UTC