- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Aug 2018 21:03:53 +0000
- To: public-svg-issues@w3.org
The Working Group just discussed `d property value`, and agreed to the following:
* `RESOLUTION: d property only supports path() for now but potentially will support other CSS shape function`
* `RESOLUTION: The d property will support the shape function path() only for now. The d attribute will only support SVG path string an no functional notation. d will be a presentation attribute and contributes into the CSS styling hierarchy as other presentation attributes.`
* `RESOLUTION: Discuss winding rule issue of polygon() and path() with CSS WG. Especially with regards of use in different properties like offset-path, d and clip-path.`
* `RESOLUTION: Keep path() without fill rule on d property for now.`
<details><summary>The full IRC log of that discussion</summary>
<krit> topic: d property value<br>
<krit> GitHub: https://github.com/w3c/svgwg/issues/320<br>
<krit> krit: So we only support the path CSS function and the none keyword on the CSS property but not the path string directly?<br>
<krit> ericwilligers: that is correct.<br>
<krit> Tav: we treat the attribute and property the same. So for us this is difficult.<br>
<krit> ericwilligers: but we still support the old syntax on the attribute.<br>
<krit> ericwilligers: what is the implementation issue?<br>
<krit> krit: WebKit and Blink usually use the same parser for the attribute and property on presentation attributes.<br>
<krit> AmeliaBR: there are some difference in implementations already like unit less length value support for attributes and properties.<br>
<krit> krit: but this is just a flag in the cSS parser for implementations.<br>
<krit> AmeliaBR: then we have the difference on transform attribute.<br>
<krit> krit: here again... there is the problem of how transforms get stored internally. It works for browsers but maybe not for d property. Maybe it does though.<br>
<krit> AmeliaBR: my concern is mostly about the different flavour of the CSS shape function.<br>
<krit> krit: I think there are 2 issues... 1) there is the fill-rule value as part of path() shape function. and 2) the missing other shape functions.<br>
<krit> ericwilligers: that is right, that is missing.<br>
<krit> AmeliaBR: yes, that is another concern.<br>
<krit> krit: do we think we can spec something in SVG2 or should we put it in other spec?<br>
<krit> AmeliaBR: implementations just don't know what to do. Otherwise they would do it.<br>
<krit> Tav: We implemented the d property read-only<br>
<krit> krit: with the CSS function path?<br>
<krit> Tav: yes and that is reasonly because we treat attributes and properties the same way.<br>
<krit> AmeliaBR: one option would be to extend the syntax of the attribute.<br>
<ericwilligers> Custom property use case: https://jsfiddle.net/ericwilligers/jq2af341/<br>
<krit> krit: I wanted to get to this as well... should we add everything from the property to the attribute as well?<br>
<krit> krit: lets start with the discussion if we want to defer or if we can finalise for SVG 2<br>
<krit> AmeliaBR: my concern is as longer as the Chrome implementation is out the less likely the implementation will change<br>
<krit> krit: I share the concern and we already have this with clip-path and the outdated implementation in Blink.<br>
<krit> krit: I'd like to have a conclusion between the WG members.<br>
<krit> AmeliaBR: Tav, what do you do about CSS transforms?<br>
<krit> Tav: we don't implement it yet.<br>
<krit> krit: Can you live with just starting work on the path function for now AmeliaBR ?<br>
<krit> AmeliaBR: if that is the choice between deferring and only path yes.<br>
<krit> AmeliaBR: I'd be happier with a living long term plan to support all shape function.<br>
<krit> krit: I agree but the other shape functions are harder to specify because of the relative values they support.<br>
<krit> AmeliaBR: path() uses absolute units but the other shapes do support percentages and should be relative to boxes. I don't want to lock d on path() only.<br>
<krit> krit: I'd like us to focus on path() only for now and discuss boxes and other shapes later.<br>
<krit> RESOLUTION: d property only supports path() for now but potentially will support other CSS shape function<br>
<krit> AmeliaBR: 2nd resolution would be to decide if d attribute only supports string or will support shapes as well in the future.<br>
<krit> ericwilligers: I'd advocate to let d attribute only support path string and the property to support shape functions and no string<br>
<krit> krit: the decision to only support string on the attribute does not block us to add functions later<br>
<krit> proposed RESOLUTION: The d property will support the shape function path() only for now. The d attribute will only support SVG path string an no functional notation. d will be a presentation attribute and contributes into the CSS styling hierarchy as other presentation attributes.<br>
<krit> RESOLUTION: The d property will support the shape function path() only for now. The d attribute will only support SVG path string an no functional notation. d will be a presentation attribute and contributes into the CSS styling hierarchy as other presentation attributes.<br>
<krit> krit: last question from me: Can we align path() to the CSS Shape functions??<br>
<krit> AmeliaBR: we could have one data type path() function<br>
<AmeliaBR> <path-function> = path("..svg path code..")<br>
<AmeliaBR> <shape-function>=<path-function> | ellipse(..) | circle(..) | ...<br>
<krit> krit: IMO it is still confusing for content creators why we have patch() w/ fill rule and one path() w/o fill rule setting? We would just need to clarify how the fill rule interacts with the fill-rule/clip-rule properties?<br>
<krit> AmeliaBR: My suggestion was to have 3 options for fill-rule... default w/o fill rule would act as "auto" value... which would be fill-rule/clip-rule property on the d property. But with explicit fill rule to would overwrite the properties.<br>
<krit> AmeliaBR: default would be current behavior and with the explicit value the implementation would use this explicit value<br>
<krit> https://drafts.fxtf.org/motion-1/#offsetpath-pathfunc<br>
<krit> ericwilligers: it was removed as value since it is not needed for offset-path<br>
<krit> AmeliaBR: but it would be needed for clip-path and shape properties.<br>
<krit> AmeliaBR: currently the polygon() function has default values for missing winding rules. We would need to clarify with the CSS WG if we can make the default value dependent not he CSS property using the function notation...<br>
<krit> AmeliaBR: the same would apply to path()<br>
<krit> AmeliaBR: define that the missing value does not compute until used value time.<br>
<AmeliaBR> s/not he/on the/<br>
<krit> krit: could you bring this up to the CSS wG?<br>
<krit> AmeliaBR: I could<br>
<krit> ericwilligers: what is the motivation<br>
<AmeliaBR> > Computed Values of Basic Shapes https://drafts.csswg.org/css-shapes/#basic-shape-computed-values<br>
<AmeliaBR> Omitted values are included and compute to their defaults.<br>
<krit> krit: any resolutions we need to add still?<br>
<krit> RESOLUTION: Discuss winding rule issue of polygon() and path() with CSS WG. Especially with regards of use in different properties like offset-path, d and clip-path.<br>
<krit> RESOLUTION: Keep path() without fill rule on d property for now.<br>
<krit> trackbot, end telcon<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/320#issuecomment-414462645 using your GitHub account
Received on Monday, 20 August 2018 21:03:54 UTC