Re: Does PATH need a new attribute?

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