- From: Shane Stephens <shans@google.com>
- Date: Thu, 04 Feb 2016 23:03:42 +0000
- To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, www-svg <www-svg@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAGTfzwS8E+v-8LQKkw9sfTKQaVgbGxTWH0iwHojv36Mswk4YLQ@mail.gmail.com>
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 < amelia.bellamy.royds@gmail.com> wrote: > Copying this to www-svg because it is relevant for SVG in general as well > as FX. Previous relevant discussion: > > - "On path syntax" from public-fx, starting with Shane Stephen's > questions here: > https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0023.html > - "SVG-ACTION-3834: Ask csswg if disallowing fill rule in path() for d > is good" Comments by Dirk Schulze in response to the action notification on > the internal SVG WG list: > https://lists.w3.org/Archives/Public/public-svg-wg/2016JanMar/0006.html > - "Topic: initial value of 'd' property" at the Sydney Face to Face, 4 > February 2016 Sydney time, starting 23:18 GMT on the IRC log: > https://www.w3.org/2016/02/03-svg-irc.html#T23-18-02 > > 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 > > > > > >
Received on Thursday, 4 February 2016 23:04:22 UTC