Rename 'd' property

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Rename 'd' property

Sebastian Zartner-3
Hi all,

https://www.w3.org/2016/02/03-svg-irc.html#T23-25-17 is talking about the 'd' CSS property as a reflection of the 'd' attribute.

Though that name is really inexpressive. So I wonder, whether it could be renamed to something more meaningful like 'path' when porting it to CSS (or at least introduce it as an alias for 'd').

Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Chris Lilley
Re: Rename 'd' property Hello Sebastian,

Monday, February 8, 2016, 9:38:39 AM, you wrote:


Hi all,

https://www.w3.org/2016/02/03-svg-irc.html#T23-25-17 is talking about the 'd' CSS property as a reflection of the 'd' attribute.

Though that name is really inexpressive.


It is. The attribute was originally called "data" but was shortened to "d" because it is the most common attribute in SVG. A similar proposal to shortn "path" element name to "p" was not adopted :)

I agree it is a bit terse as a property name. On the other hand, having a 1:1 mapping between the names and definitions of properties and presentation attributes can be helpful for authoring.


So I wonder, whether it could be renamed to something more meaningful like 'path' when porting it to CSS (or at least introduce it as an alias for 'd').


I can see advantages and disadvantages.

--
Best regards,
Chris  Lilley
Technical Director, W3C Interaction Domain
Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Kari Pihkala
2016-02-08 17:00 GMT+02:00 Chris Lilley <[hidden email]>:
>
> I agree it is a bit terse as a property name. On the other hand, having a 1:1 mapping between the names and definitions of properties and presentation attributes can be helpful for authoring.


The <stop> element accepts path data for meshes, but the attribute
uses the name 'path'. Could it be renamed to 'd' and promoted to a
property? That way it would be consistent with other properties taking
path data and maybe easier to remember by authors.

Also, the new <hatchpath> element has a 'd' attribute. Could it be a
property so that it is possible to css animate it?

BR,
Kari

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Sebastian Zartner-3
In reply to this post by Chris Lilley
On 8 February 2016 at 16:00, Chris Lilley <[hidden email]> wrote:
Hello Sebastian,

Monday, February 8, 2016, 9:38:39 AM, you wrote:


Hi all,

https://www.w3.org/2016/02/03-svg-irc.html#T23-25-17 is talking about the 'd' CSS property as a reflection of the 'd' attribute.

Though that name is really inexpressive.


It is. The attribute was originally called "data" but was shortened to "d" because it is the most common attribute in SVG. A similar proposal to shortn "path" element name to "p" was not adopted :)

I see. Thank you for the background info on that.
 
I agree it is a bit terse as a property name. On the other hand, having a 1:1 mapping between the names and definitions of properties and presentation attributes can be helpful for authoring.

Sure, that's why my second suggested solution was to create an alias for it, which could be for the CSS property as well as for the attribute.


So I wonder, whether it could be renamed to something more meaningful like 'path' when porting it to CSS (or at least introduce it as an alias for 'd').

I can see advantages and disadvantages.

Can you elaborate on this, please? The advantages I see are better understandability and conformance with the other CSS properties. A disadvantage is that usage will diverge, so people may need to learn that they are aliases. Though they already have to do that, anyway, as mentioned by Kari.
Do you see other advantages or disadvantages?

Sebastian
Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Dr. Olaf Hoffmann
In reply to this post by Sebastian Zartner-3
Hello,

the core disadvantage for renaming something in SVG is, that it is backwards
incompatible to already published viewers and existing content.
For SVG 2 there is a requirement to avoid any backwards incompatibilities.

And as we all know - there is a certain danger, if implementor get a choice to
do something, this typically results in trouble for authors and the audience
;-)

'd' is a nice name both for an attribute and a property.
However, it is questionable to define it as a property, just because in almost
any case the information in it is content and not just decoration.

Olaf

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Sebastian Zartner-3
On 9 February 2016 at 11:27, Dr. Olaf Hoffmann <[hidden email]> wrote:
Hello,

the core disadvantage for renaming something in SVG is, that it is backwards
incompatible to already published viewers and existing content.
For SVG 2 there is a requirement to avoid any backwards incompatibilities.

That's clear. My initial request for renaming only targets the CSS property, which is, as far as I know, not implemented yet.
In case of wanting both the CSS property and the attribute consistently named, only aliasing would be a solution.
 
And as we all know - there is a certain danger, if implementor get a choice to
do something, this typically results in trouble for authors and the audience
;-)

There wouldn't be a choice for the implementors. They would have to support both. The choice would be at the authors.
 
'd' is a nice name both for an attribute and a property.

So, we obviously have different opinions on this. Again, my argument is that 'd' is inexpressive, especially when it is defined somewhere else than at the place where it is used, i.e. as CSS property in a stylesheet instead of a tag attribute.
 
However, it is questionable to define it as a property, just because in almost
any case the information in it is content and not just decoration.

That is a good point, though note that the reason for defining it as CSS property is "because it allows non-SMIL declarative animation of shape morphing, using CSS animation syntax"[1] and letting it work together with Web Animations[2].

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Doug Schepers-3
Hi, folks–

I'm supportive of renaming it as a property.

I'd suggest 'path-data', to give it the clarity of context.

There is no issue of backwards compatibility; the option of setting the
path data via CSS doesn't exist in any current or previous version of
SVG, so there's nothing to be incompatible with. There is the issue of
name correspondence between the attribute and property, for the sake of
the author; if aliasing is allowed in CSS today, then we could have both
'd' and 'path-data' (or whatever).

The issue of style-vs-content is largely irrelevant, since there's no
software that makes a distinction; the most pressing issue there is not
the semantics, but the ease and consistency of API access to the path
data, regardless of where it's defined, and the consistency of
bounding-box results.

Regards–
Doug

On 2/9/16 9:32 AM, Sebastian Zartner wrote:

> On 9 February 2016 at 11:27, Dr. Olaf Hoffmann <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello,
>
>     the core disadvantage for renaming something in SVG is, that it is
>     backwards
>     incompatible to already published viewers and existing content.
>     For SVG 2 there is a requirement to avoid any backwards
>     incompatibilities.
>
>
> That's clear. My initial request for renaming only targets the CSS
> property, which is, as far as I know, not implemented yet.
> In case of wanting both the CSS property and the attribute consistently
> named, only aliasing would be a solution.
>
>     And as we all know - there is a certain danger, if implementor get a
>     choice to
>     do something, this typically results in trouble for authors and the
>     audience
>     ;-)
>
>
> There wouldn't be a choice for the implementors. They would have to
> support both. The choice would be at the authors.
>
>     'd' is a nice name both for an attribute and a property.
>
>
> So, we obviously have different opinions on this. Again, my argument is
> that 'd' is inexpressive, especially when it is defined somewhere else
> than at the place where it is used, i.e. as CSS property in a stylesheet
> instead of a tag attribute.
>
>     However, it is questionable to define it as a property, just because
>     in almost
>     any case the information in it is content and not just decoration.
>
>
> That is a good point, though note that the reason for defining it as CSS
> property is "because it allows non-SMIL declarative animation of shape
> morphing, using CSS animation syntax"[1] and letting it work together
> with Web Animations[2].
>
> Sebastian
>
> [1] https://lists.w3.org/Archives/Public/www-svg/2016Feb/0005.html
> [2]
> https://www.w3.org/2016/02/03-svg-irc.html#T23-18-02<https://lists.w3.org/Archives/Public/www-svg/2016Feb/0005.html>

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Dr. Olaf Hoffmann
Doug Schepers:
> Hi, folks–
>
> I'm supportive of renaming it as a property.
>
> I'd suggest 'path-data', to give it the clarity of context.
>
> There is no issue of backwards compatibility; the option of setting the
> path data via CSS doesn't exist in any current or previous version of
> SVG, so there's nothing to be incompatible with.

Sure, this would be no problem to chose an arbitrary name for some property.
I got the impression, that the idea was to provide an alternative name for the
attribute as well - implicating the complication, what happens, if an author
notes both names with different values and so on.

> There is the issue of
> name correspondence between the attribute and property, for the sake of
> the author; if aliasing is allowed in CSS today, then we could have both
> 'd' and 'path-data' (or whatever).

Yes, this is remaining, it can be slightly confusing for authors to have a
different property name than attribute name, if used at all.
Because it seems to be intended to use the property not only for data
of a path attribute in CSS, 'path-data' could be surprising for other use
cases as well. However, the content should be always data about a path
for whatever purpose, this name would be suggestive.


>
> The issue of style-vs-content is largely irrelevant, since there's no
> software that makes a distinction; the most pressing issue there is not
> the semantics, but the ease and consistency of API access to the path
> data, regardless of where it's defined, and the consistency of
> bounding-box results.

Due to the typically low implementation quality of current viewers, I do not
worry much about how they present documents now.
Maybe they do  the best they can.
It is more relevant, how it is noted in documents, because in ten or hundred
years there will be other viewers, but some documents may remain and
if we assume, that our current digital episode of mankind has some cultural
relevance, it is quite important to have meaningful documents for the future,
not just tag soup and an arbitrary mix of decoration and maybe content, maybe
bugs.
If formats like SVG or XHTML are borked today, this has longer consequences
for the future. Poor quality of current viewers do not have such big
consequences, because they change much faster than content.


Olaf

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Amelia Bellamy-Royds
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
Reply | Threaded
Open this post in threaded view
|

RE: Rename 'd' property

David Dailey

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

 

From: Amelia Bellamy-Royds [mailto:[hidden email]]
Sent: Sunday, February 14, 2016 4:45 PM
To: www-svg
Subject: Re: Rename 'd' property

 

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

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Amelia Bellamy-Royds
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 <[hidden email]> 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

 

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Sebastian Zartner-3
On 15 February 2016 at 08:53, Amelia Bellamy-Royds <[hidden email]> 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
On 14 February 2016 at 21:16, David Dailey <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Tab Atkins Jr.
In reply to this post by Amelia Bellamy-Royds
On Sun, Feb 14, 2016 at 11:53 PM, Amelia Bellamy-Royds
<[hidden email]> wrote:
> 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.

Can't do it, or at least not in any sane way.  A <circle> isn't just
rendered as a circle, it's also backed by an SVGCircleElement object.
If you changed the 'geometry' for an element, its backing object no
longer makes any sense, and its JS properties no longer correspond to
anything useful (except perhaps by accident, if both shapes share a
given attribute).  (And we can't swap out the backing object based on
CSS, believe me, or else Custom Elements would be a lot easier in many
ways.)

So as much as I like the idea of 'geometry' theoretically, the shapes
of SVG elements and the properties they use are based on the element
name, nothing else.

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

Three, actually - whether it generates a box, how it lays out its
children, and how it interacts with the layout of its parent.  We've
already split out the "do you generate a box" property in the Display
module <https://drafts.csswg.org/css-display/#box-suppress>, and have
decided to only semi-split the latter two - they're split at the value
level, but still operate in a single property so we can control the
combinations a little better.

When I write the SVG Layout module (eventually) we will need a
property to opt an element into it - SVG layout is just a slight
variant on abspos. Unfortunately this can't be 'display', for legacy
reasons - right now, you can set any 'display' value on an SVG element
and it sets the property but has no effect.  We'll need to invent
something new, unfortunately, which sucks. :/

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

Once the SVG Layout spec is done, this shouldn't be too hard
theoretically. It should be okay to swap a SVG element to generating a
CSS box instead of an SVG shape, because we don't expect any SVG
properties to affect CSS layout.  (In other words, this doesn't suffer
from the same problem that 'geometry' does. The backing object will
have some useless properties, but the element can still be fully
controlled with CSS as usual for CSS boxes.)

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

>From now on we'll just never reuse an attribute unless it's identical.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Philip Rogers-2
Are folks generally in favor of having 'd' be an alias, in addition to a better name?

On Mon, Feb 15, 2016 at 6:37 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Sun, Feb 14, 2016 at 11:53 PM, Amelia Bellamy-Royds
<[hidden email]> wrote:
> 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.

Can't do it, or at least not in any sane way.  A <circle> isn't just
rendered as a circle, it's also backed by an SVGCircleElement object.
If you changed the 'geometry' for an element, its backing object no
longer makes any sense, and its JS properties no longer correspond to
anything useful (except perhaps by accident, if both shapes share a
given attribute).  (And we can't swap out the backing object based on
CSS, believe me, or else Custom Elements would be a lot easier in many
ways.)

So as much as I like the idea of 'geometry' theoretically, the shapes
of SVG elements and the properties they use are based on the element
name, nothing else.

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

Three, actually - whether it generates a box, how it lays out its
children, and how it interacts with the layout of its parent.  We've
already split out the "do you generate a box" property in the Display
module <https://drafts.csswg.org/css-display/#box-suppress>, and have
decided to only semi-split the latter two - they're split at the value
level, but still operate in a single property so we can control the
combinations a little better.

When I write the SVG Layout module (eventually) we will need a
property to opt an element into it - SVG layout is just a slight
variant on abspos. Unfortunately this can't be 'display', for legacy
reasons - right now, you can set any 'display' value on an SVG element
and it sets the property but has no effect.  We'll need to invent
something new, unfortunately, which sucks. :/

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

Once the SVG Layout spec is done, this shouldn't be too hard
theoretically. It should be okay to swap a SVG element to generating a
CSS box instead of an SVG shape, because we don't expect any SVG
properties to affect CSS layout.  (In other words, this doesn't suffer
from the same problem that 'geometry' does. The backing object will
have some useless properties, but the element can still be fully
controlled with CSS as usual for CSS boxes.)

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

>From now on we'll just never reuse an attribute unless it's identical.

~TJ


Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Amelia Bellamy-Royds
In reply to this post by Sebastian Zartner-3
[Replies to Sebastian Zartner's comments]

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));
}

The `cx`, `cy`, `r` properties, etc., have already shipped in at least two browsers (WebKit & Chromium). So any new property would need to reference them.  

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);
}

The way I was thinking of it, it would actually turn into a circle.  Except without the useful DOM object attached (as Tab mentioned in his comments).  It would nonetheless be something to discourage as a poor authoring practice, similar to using nothing but <blockquote> in an HTML document and overriding styles to create the appearance of structure.
 
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.
...
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?

Yes, it is related, and definitely stretches outside of the scope of SVG. A different approach than the `box-suppress` method described in CSS Display, but it would address the same goal. But it would also address the issue that most of the `display` values are completely irrelevant and ignored for SVG, while providing a way for SVG-namespaced elements to "opt-in" to the CSS box layout model as part of an alternative textual display.

 
Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Amelia Bellamy-Royds
In reply to this post by Tab Atkins Jr.
[replies to Tab Atkins' comments]

Can't do it, or at least not in any sane way.  A <circle> isn't just
rendered as a circle, it's also backed by an SVGCircleElement object.
If you changed the 'geometry' for an element, its backing object no
longer makes any sense, and its JS properties no longer correspond to
anything useful (except perhaps by accident, if both shapes share a
given attribute).  (And we can't swap out the backing object based on
CSS, believe me, or else Custom Elements would be a lot easier in many
ways.)

So as much as I like the idea of 'geometry' theoretically, the shapes
of SVG elements and the properties they use are based on the element
name, nothing else.

The DOM interfaces are definitely an obstacle, though not necessarily an insurmountable one. 

By upgrading the geometry attributes to CSS properties, we have already effectively made the corresponding DOM properties into aliases for CSSOM getComputedStyle calls with type coersion.  The CSSOM properties will be available on all elements, whether or not the aliases are.

The only other unique properties/methods on SVG shape elements are those that relate to getting data about path length, and I'd really like to see those generalized to all shapes, anyway. (Also the now-deprecated methods for building a path by segment; they're replacement could be generalized!)

In other words, once all data about the shape of a SVG element is in CSS, all the meaningful DOM interfaces could also be defined on a generic interface, with the existing interfaces (based on the element tag name) defined as subclasses for backwards-compatibility.

So possible, but a complete model is not likely to be worked out and ready to go in the next few months. Hence my main point: let's try not to do anything now that will make it difficult to overlay a comprehensive logical model in the future.



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

Three, actually - whether it generates a box, how it lays out its
children, and how it interacts with the layout of its parent.  We've
already split out the "do you generate a box" property in the Display
module <https://drafts.csswg.org/css-display/#box-suppress>, and have
decided to only semi-split the latter two - they're split at the value
level, but still operate in a single property so we can control the
combinations a little better.

When I write the SVG Layout module (eventually) we will need a
property to opt an element into it - SVG layout is just a slight
variant on abspos. Unfortunately this can't be 'display', for legacy
reasons - right now, you can set any 'display' value on an SVG element
and it sets the property but has no effect.  We'll need to invent
something new, unfortunately, which sucks. :/


I had thought of this, but somehow overlooked the key detail when I wrote up my "rough draft".  You need an `auto` default value for `display-mode` that means set the mode based on element namespace. 

That way, if you set display without specifying a display-mode keyword, you get the auto value:

display: none; 
/* equivalent to display-mode: none; display-box-type: inline;  
   nothing is displayed, so box-type is irrelevant */

display: block; 
/* equivalent to display-mode: auto; display-box-type: block;  
   for SVG element, it's now in SVG mode, box-type is again irrelevant */

display: svg; 
/* could be used to create an SVG shape out of an HTML element or box-model pseudo-element, instead of generating an SVG data URI background image */

display: box-model block; 
/* used to turn an SVG element into a block container */


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

Once the SVG Layout spec is done, this shouldn't be too hard
theoretically. It should be okay to swap a SVG element to generating a
CSS box instead of an SVG shape, because we don't expect any SVG
properties to affect CSS layout.  (In other words, this doesn't suffer
from the same problem that 'geometry' does. The backing object will
have some useless properties, but the element can still be fully
controlled with CSS as usual for CSS boxes.)

This all would of course merge into the SVG Layout spec idea, based on the parent element's display mode versus the child element. E.g., if a child element with `display-mode: box-model` is inside a parent with `display-mode: svg`, define what the containing block is, and how the x/y/width/height properties affect it. 

Another reason why this was just a rough sketch of an idea, which stills need work to create a complete model.
 

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

From now on we'll just never reuse an attribute unless it's identical.

That's an important part of ensuring clarity in the future, but gets us back to the original question. Should we use a generic name like `d` as a property, and if so should we use it for multiple different features (path geometry, text-path baseline shape, possibly others)?

Reply | Threaded
Open this post in threaded view
|

Re: Rename 'd' property

Sebastian Zartner-3
In reply to this post by Amelia Bellamy-Royds
On 17 February 2016 at 20:57, Amelia Bellamy-Royds <[hidden email]> wrote:
[Replies to Sebastian Zartner's comments]

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));
}

The `cx`, `cy`, `r` properties, etc., have already shipped in at least two browsers (WebKit & Chromium). So any new property would need to reference them.

The requirements for using the above syntax is in what extent the 'cx', 'cy' and 'r' properties are already used by content and whether implementors are willing to replace them in favor of 'geometry' and allowing shape functions in it.
Btw., 'cx', 'cy', 'r', 'rx' and 'ry' are also good candidates for renaming (or aliasing), as their meaning as CSS property names (outside of the context of their related SVG elements) is unclear.

Regarding the 'geometry' property, if it's not possible to reuse the shape functions, the keywords should be changed to resolve the naming conflict with the shape functions.

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

Yes, it is related, and definitely stretches outside of the scope of SVG. A different approach than the `box-suppress` method described in CSS Display, but it would address the same goal. But it would also address the issue that most of the `display` values are completely irrelevant and ignored for SVG, while providing a way for SVG-namespaced elements to "opt-in" to the CSS box layout model as part of an alternative textual display.

Ah, right. Now I remember the discussion and the obstacles about 'display' currently serving multiple purposes.

Sebastian