Re: Rename 'd' property

On 15 February 2016 at 08:53, Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> [snip]
>
> 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.
>

Well explained!
The last point about CSS being universal is one point of what I had in mind
in my previous mail.

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. */
>

I like the idea of the 'geometry' property, though I dislike the
overlapping of function and keyword names for circle, ellipse and rect. I
believe it would be better to reuse the functions defined in the CSS Shapes
module[1].

E.g. the UA stylesheet rule for <circle> elements may look like this then:

circle {
  geometry: circle(attr(r) at attr(cx) attr(cy));
}

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 */
> }
>

Regarding the statement above about CSS being universal, it needs to be
clarified what happens when an author defines this for example:

textPath {
  geometry: circle(10cm at 5cm 5cm);
}

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

I assume this discussion is related to the CSS Display module[2], right? It
sounds like this point is out of scope of this discussion to be talked
about separately.

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

Can you elaborate a bit more on this? What is the problem of being able to
toggle the display off without changing the box model?

Sebastian

[1] https://drafts.csswg.org/css-shapes/
[2] https://drafts.csswg.org/css-display/

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