Re: Rename 'd' property

The superpath functionality is a good reason for using a function notation
to describe shape geometry, as it can be more easily extended to include
other functions.  For example, functions to invert a path string or to
concatenate the paths defined by multiple url() references.

The other points are good reason to think carefully about the purpose of
the path data string for each element, and to use a property name that
reflects the purpose, not merely the data type.

"path data" should be seen as a data type—like length, color, or alpha
value—not as a style property. The style property should define what you're
doing with that value.

The path data for a textPath element has quite a different effect than path
data for a <path> itself.  And if we eventually want to add a function so
that textPath elements can have multiple paths aligned to different
baselines (to stretch and squish letters, another feature I know David
would like to see), it becomes all the more important that it has its own
property and syntax.

We've been happily "upgrading" attributes to style properties one at a
time, for the convenience of being able to assign them using CSS selectors
and modify them using media queries or CSS animations & transitions. But in
doing so, we've created a bit of a Frankenstein construct with no clear
logical model underlying it.

The geometric attributes in SVG 1 are each defined in the context of a
particular element. Attributes of the same name can have different meaning,
and even different allowed values, because they are never assessed without
their context.

CSS properties, in contrast, are universal.  Their effect may vary based on
interactions between multiple properties, but should be consistent across
all element types.

We've already run into this issue with `x` and `y` for text versus
rectangular objects, and with the geometry attributes on gradients. So far
the approach has been to exclude those attributes on those particular
elements from the impact of CSS properties. But that's avoiding the issue
by adding inconsistency and confusion to the spec.

A rough draft of a cohesive approach:

A new property "geometry" defines the shape which will be filled and
stroked.  It can accept a shape function, such as path(…) or polygon(…) or
ellipse(…), but it can also take simple keywords `circle`, `ellipse`, or
`rect`, which mean "use the computed values for the
cx/cy/r/rx/ry/x/y/width/height properties, as appropriate". Geometry can
also be `text` or `children`, the final value being appropriate for <g> or
<svg> elements.

The user agent stylesheet defines how the standard geometry is extracted
from the standard attributes:

path      { geometry: path( attr("d") ); }
polygon   { geometry: polygon( attr("points") ); }
polyline  { geometry: polyline( attr("points") ); }
circle {
  geometry: circle;
  cx: attr("cx");
  cy: attr("cy");
   r: attr("r");
}
/* etc. */

A text path is something completely different, and would have its own
property, whose value (for now) could either be a shape function, directly
defining the path, or a url() reference to another element, in which case
use the computed geometry for that element.  Default stylesheet would look
something like this:

textPath {
  geometry: text;
  text-path: path( attr("d") );
}
textPath:not([d]) {
  text-path: attr("href" url, none); /* use the href attribute as a url()
instead */
}
textPath:not([d]):not([href]) {
  text-path: attr("xlink:href" url, none);
    /* use the xlink:href as a URL if neither higher-priority attribute is
present */
}

(I've probably got the syntax wrong for the attr() function and namespaced
attributes. But I hope you get the idea.)


We then need one final master property to turn on all these SVG-specific
rendering commands. Something I've talked with Tab about previously is to
do this with the `display` property. `display` is currently a hodgepodge of
two different concepts: (1) is an element rendered or not, and (2) if the
element is rendered AND it uses a CSS box model, which box model type
should it use. Divide those two concepts into separate properties, and make
`display` a shorthand for them both:

display-mode: none | box-model | svg  ;
  /* default box-model, but all SVG namespace elements have it set to `svg`
*/
  /* maybe need another value for mathML? Or can math be described with the
box model? */
display-box-type: inline | block | list-item | table | … ;
  /* all the other values, default inline */

This is of course a matter for the CSS WG to approve, but it would address
major complaints with how `display` currently works, allowing you to toggle
display on/off without changing the box model type.

It would also enable the original plan from SVG 1.1, that an alternative
stylesheet should be able to make SVG title+desc text visible instead of
graphics.

This may all be too different and complicated for SVG 2, but I would at the
least like to consider the possibility, so we don't create new conflicts
like using a single `d` property to define completely different features on
<path> versus <textPath>

~ABR



On 14 February 2016 at 21:16, David Dailey <ddailey@zoominternet.net> wrote:

> 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
>
>
>