[motion-1] On path syntax

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

[motion-1] On path syntax

Amelia Bellamy-Royds
Copying this to www-svg because it is relevant for SVG in general as well as FX.  Previous relevant discussion:
To summarize those messages and discussion:

The working group has agreed that the `d` attribute for <path> will be specifiable with CSS in SVG 2. (In other words, like other geometry attributes, it is being upgraded to a presentation attribute.) This is important because it allows non-SMIL declarative animation of shape morphing, using CSS animation syntax.  Declarative animation is important because it means it can run in HTML-as-img. Non-SMIL is important because key user agents have failed to support and/or made plans to remove support for SMIL.  I'm not going to get into the same arguments again about whether or not that's a good thing, I'm just stating it as a reality we are working within.

Multiple CSS modules have already adopted a means of specifying shapes with a function notation: circle(), ellipse(), inset(), and polygon() were all defined in CSS Shapes 1 (for creating non-rectangular floats) and are also used in the clip-path property as defined in CSS Masking 1. A path() function has been added to that list for CSS Motion Path and would also be used in the other properties that accept a shapes function.  The shape of the path would be defined using a path-data string, inside the functional notation, that follows the accepted SVG syntax (and any future extensions to it).

The CSS shapes functions create a complete definition of geometry, including the fill-rule for defining which parts of a polygon or path are "inside" or "outside" the shape.  This is required for that shape to be used as a clip-path or a container for text (shape-inside property in CSS Shapes 2).  The fill-rule is specified by an optional first parameter inside the functional notation, like polygon(evenodd, [list-of-points]) or path(nonzero, [path-data-string]).

Shane and Cameron have proposed that the functional notation for defining a path be used for the `d` attribute when set with CSS.  However, the fill-rule for that path element would still be controlled by the separate fill-rule property.  Shane initially suggested that we could just drop the fill-rule parameter from the path() function, but that would cause problems for the other properties that use shape functions.

Their current proposal is to define a separate path function syntax, with only the path data and no fill-rule, that would represent a different CSS data type from the CSS shapes functions used by clip-path and shape-inside.  Each CSS property would define whether it accepted the full CSS shapes function (with fill-rule) or merely the path outline function (no fill-rule allowed).  Both would still use path(), however, and this causes possible concerns with the general CSS approach to functional notation.  Shane took an action (ACTION-3834) to follow up with the CSS WG.

Alternatives that have been discussed:
  • Just use the plain path data string, like path.triangle {d: M10,0 L0,5 10,10 Z;}
    This is very problematic from the perspective of CSS parsing, since the CSS parser would need to tokenize & determine the validity of the entire path data string in its initial scan. (And we all know path data strings can get very long and complex.)
  • Use the plain path data string as a quoted string in CSS, like  path.triangle {d: "M10,0 L0,5 10,10 Z";}
    I honestly don't think I got a clear answer as to why this would be bad.  However, it would mean that the CSS parser would not do any validity testing on the contents of the string: the value, as far as the CSS parser is concerned, would just be "any string".  In future when new path data commands are introduced (like the bearing command or smooth spline curve command), you would not be able to use @supports or normal CSS error handling to define fallbacks.  Instead, the existing error handling rules (for partially unrecognized path data) would apply.
  • Use the CSS shapes functional notation, with optional fill-rule, but ignore it if specified for the `d` property. 
    This creates a logical conflict if authors are allowed to specify a fill-rule value but it has no effect. 
  • Use the CSS shapes functional notation, with optional fill-rule, and let that fill-rule override the fill-rule property. 
    This makes utter chaos of how the CSS cascade and shorthand properties works, and would be basically impossible to implement.
  • (Not yet discussed, but might as well add it here) use 2 different functional notations, with different names, one to describe path outline versus one used to describe a complete shape, like
    path.triangle.clipped {
      d:             d("M10,0 L0,5 10,10 Z");
      clip-path: path("M2,2 L2,8 8,5Z");
    }
    This makes things easy from a CSS data types/parsing perspective: each function has a clear and distinct data type it returns, and each property has a clear and distinct data type that it accepts.  But, it means that authors would have to remember which property took which type of path function.
Some other aspects that have been briefly discussed:
  • If a path function notation is used for `d` in CSS, should that also be allowed in the `d` attribute?  (The existing notation would of course continue to be supported in the attribute.)  Does this cause parsing problems?
  • If the `d` attribute accepts a standard or modified CSS shapes function, should it also accept the other shapes functions, such as polygon(), circle() or ellipse()?

I think that covers most of the main arguments & issues.

~Amelia





Reply | Threaded
Open this post in threaded view
|

Re: [motion-1] On path syntax

Shane Stephens-2
Thanks for this detailed summary.

To avoid confusion, please note that in my original email I did not propose that we could just drop the fill-rule parameter from the path() function. I proposed creating two variants of the path() function, which I think is what has been labelled as 'the current proposal' as well.

Could I ask that any discussion take place on the original public-fx thread, to keep our thoughts and ideas in one place? If necessary we can cc: www-svg on that thread. Amelia - would you mind reposting this summary to that thread?

Sincerely,
    -Shane Stephens

On Fri, Feb 5, 2016 at 9:51 AM Amelia Bellamy-Royds <[hidden email]> wrote:
Copying this to www-svg because it is relevant for SVG in general as well as FX.  Previous relevant discussion:
To summarize those messages and discussion:

The working group has agreed that the `d` attribute for <path> will be specifiable with CSS in SVG 2. (In other words, like other geometry attributes, it is being upgraded to a presentation attribute.) This is important because it allows non-SMIL declarative animation of shape morphing, using CSS animation syntax.  Declarative animation is important because it means it can run in HTML-as-img. Non-SMIL is important because key user agents have failed to support and/or made plans to remove support for SMIL.  I'm not going to get into the same arguments again about whether or not that's a good thing, I'm just stating it as a reality we are working within.

Multiple CSS modules have already adopted a means of specifying shapes with a function notation: circle(), ellipse(), inset(), and polygon() were all defined in CSS Shapes 1 (for creating non-rectangular floats) and are also used in the clip-path property as defined in CSS Masking 1. A path() function has been added to that list for CSS Motion Path and would also be used in the other properties that accept a shapes function.  The shape of the path would be defined using a path-data string, inside the functional notation, that follows the accepted SVG syntax (and any future extensions to it).

The CSS shapes functions create a complete definition of geometry, including the fill-rule for defining which parts of a polygon or path are "inside" or "outside" the shape.  This is required for that shape to be used as a clip-path or a container for text (shape-inside property in CSS Shapes 2).  The fill-rule is specified by an optional first parameter inside the functional notation, like polygon(evenodd, [list-of-points]) or path(nonzero, [path-data-string]).

Shane and Cameron have proposed that the functional notation for defining a path be used for the `d` attribute when set with CSS.  However, the fill-rule for that path element would still be controlled by the separate fill-rule property.  Shane initially suggested that we could just drop the fill-rule parameter from the path() function, but that would cause problems for the other properties that use shape functions.

Their current proposal is to define a separate path function syntax, with only the path data and no fill-rule, that would represent a different CSS data type from the CSS shapes functions used by clip-path and shape-inside.  Each CSS property would define whether it accepted the full CSS shapes function (with fill-rule) or merely the path outline function (no fill-rule allowed).  Both would still use path(), however, and this causes possible concerns with the general CSS approach to functional notation.  Shane took an action (ACTION-3834) to follow up with the CSS WG.

Alternatives that have been discussed:
  • Just use the plain path data string, like path.triangle {d: M10,0 L0,5 10,10 Z;}
    This is very problematic from the perspective of CSS parsing, since the CSS parser would need to tokenize & determine the validity of the entire path data string in its initial scan. (And we all know path data strings can get very long and complex.)
  • Use the plain path data string as a quoted string in CSS, like  path.triangle {d: "M10,0 L0,5 10,10 Z";}
    I honestly don't think I got a clear answer as to why this would be bad.  However, it would mean that the CSS parser would not do any validity testing on the contents of the string: the value, as far as the CSS parser is concerned, would just be "any string".  In future when new path data commands are introduced (like the bearing command or smooth spline curve command), you would not be able to use @supports or normal CSS error handling to define fallbacks.  Instead, the existing error handling rules (for partially unrecognized path data) would apply.
  • Use the CSS shapes functional notation, with optional fill-rule, but ignore it if specified for the `d` property. 
    This creates a logical conflict if authors are allowed to specify a fill-rule value but it has no effect. 
  • Use the CSS shapes functional notation, with optional fill-rule, and let that fill-rule override the fill-rule property. 
    This makes utter chaos of how the CSS cascade and shorthand properties works, and would be basically impossible to implement.
  • (Not yet discussed, but might as well add it here) use 2 different functional notations, with different names, one to describe path outline versus one used to describe a complete shape, like
    path.triangle.clipped {
      d:             d("M10,0 L0,5 10,10 Z");
      clip-path: path("M2,2 L2,8 8,5Z");
    }
    This makes things easy from a CSS data types/parsing perspective: each function has a clear and distinct data type it returns, and each property has a clear and distinct data type that it accepts.  But, it means that authors would have to remember which property took which type of path function.
Some other aspects that have been briefly discussed:
  • If a path function notation is used for `d` in CSS, should that also be allowed in the `d` attribute?  (The existing notation would of course continue to be supported in the attribute.)  Does this cause parsing problems?
  • If the `d` attribute accepts a standard or modified CSS shapes function, should it also accept the other shapes functions, such as polygon(), circle() or ellipse()?

I think that covers most of the main arguments & issues.

~Amelia





Reply | Threaded
Open this post in threaded view
|

RE: [motion-1] On path syntax

David Dailey
In reply to this post by Amelia Bellamy-Royds

 

 


On Thursday, February 04, 2016 5:50 PM
Amelia Bellamy-Royds wrote summary of lots of things.

 

Copying this to www-svg because it is relevant for SVG in general as well as FX.  Previous relevant discussion:

Thanks Amelia!

 

Reading through, it seems clear that lots of people are working hard to make sure that SVG2 will remain somewhat palatable to those of us who actually like SVG. Thanks for the strong efforts by so many! Too bad that time rushes things along.

 

As the N working groups (it’s always a prime number, isn’t it?) sprinkling SVG into ever new places, think about path syntax and moving it into CSS and fx and such, I see that people are keeping an eye open to the notion that path syntax, might actually, one day, expand. I just hope that people do keep in mind that SVG 1.2 had in vector effects something called vePath (which Professor Moissinac has called “superpath”) [1] that allows for pieces of paths shared by adjacent regions (like borders on a map, or joints between parts of an animated figure) to be identified, and thence reused. Since <superpath> and equivalent functionality has been a part of SVG since 2003 (estimated from pub-date of SVG1.2 [2]), it is worth keeping in mind as things move forward, since the rationale for such a thing has merely grown, rather than evaporated in the intervening decade.

 

I see that the folks thinking about putting path animation into CSS have remained cognizant of the potential growth over time, of path syntax. I should note that in addition to the topological and graph theoretic constructs intrinsic to <superpath>, additional abstraction of a topological nature will undoubtedly be suggested as SVG (or a suitably rich vector drawing standard with animation) becomes more widely known in the academic community, particularly in the topological and graph theoretic communities. Abstracting away the geometry to reveal the topological layer (somewhat akin to connectors) unveils a layer of semantics of relationship between inferential constructs (in the sense of the semantic web) for which the plane is a far better metaphor for implicative expression than text and hypertext could hope to convey. Please keep in mind that SVG1.1 (or even the more ambitious 1.2) was not an end-point in the description of plane geometry, and was but a hint of what spatial semantics could be.

 

One other quick note: I see that ya’ll seem to like the idea of moving public discussions of SVG to github. It is certainly a way to restrict public input, if that is a desirable outcome.

 

Regards

David

 

 

[1] http://play.presetc.com/Xplay.asp?PUId=f6a7c052-6906-11e5-aae0-001cc0a62bc3

[2] https://www.w3.org/TR/2004/WD-SVG12-20041027/