– DRAFT –
SVG WG

<karlcow> eeting: SVG WG

'Segment-completing close path operation' command not implemented

w3c/svgwg#893

viralipurbey: Read about it and found that this is mainly used to close a polygon when we have a curve. For lines we have Z. But for curves it is difficult because it gets a straight line to end. This one creates a smooth close path. But it hasn't been implemented widely yet.

<karlcow> https://w3c.github.io/svgwg/specs/paths/#PathDataClosePathCommand

viralipurbey: According to the path grammar, e.g. L Z , we get an error. So we have to provide a point to get a valid path.

viralipurbey: So I wanted to see if any browser supports smooth close but none has.

viralipurbey: if it is not needed, should we remove it from the spec

nzimmermann: I wasn't aware that it existed. It doen't by you much. You need to provide the points and doesn't by you a lot.

viralipurbey: If we close a curve with q c, t c it is obscure

nzimmermann: Auto computing the control points would highly dependent on the implementation.

nzimmermann: the example only covers the most trivial case.

<karlcow> https://wpt.fyi/results/svg/path/closepath/segment-completing.svg?label=master&label=experimental&aligned&q=closepath

ydaniv: Z by iteself is implemented as closing line. And we are talking about an alternative to create a curved closing segment, right.

viralipurbey: right.

<karlcow> https://issues.chromium.org/issues/40558668

viralipurbey: If you have curves and close the path, it would be a straight line. This looks bad. The idea of smooth close would be to make it look better

ydaniv: I also don't see a point. Just create another curve.

nzimmermann: t c is valid? Spec says: segment smooth close not supported in current spec but a working item of the WG in the future.

viralipurbey: there was a spec update but WPT tests still exist

<karlcow> https://w3c.github.io/svgwg/specs/paths/#PathDataClosePathCommand

<karlcow> https://w3c.github.io/svgwg/svg2-draft/paths.html

nzimmermann: you are right Karl, it is gone from the past spec... SVG Path spec.

nzimmermann: it was only in an old draft

<viralipurbey> https://wpt.fyi/results/svg/path/closepath/segment-completing.svg

<nzimmermann> https://w3c.github.io/svgwg/svg2-draft/paths.html#Segment-CompletingClosePath

<viralipurbey> https://svgwg.org/svg2-draft/paths.html#Segment-CompletingClosePath

note in spec: Segment-completing close path operations are not currently supported as a command in the path data syntax. The working group has proposed such a syntax for future versions of the specification.

<karlcow> 9.3.4.1. Segment-completing close path operation

RESOLUTION: Remove section 9.3.4.1

refX/refY keyword forms unimplemented and no WPT tests

w3c/svgwg#1137

karlcow: We have the marker element with refX and refY and marker element

karlcow: refX, refY have length values

<nzimmermann> (I found a comment regarding the "syntax" for closePath: https://github.com/web-platform-tests/wpt/commit/71b0d4129db9cf569a924604905b93505490b689)

karlcow: the keywords center/bottom/right/left/top have been specified. For symbol they are missing and not implemented at all.

karlcow: maker: length values are supported in browsers, keywords are not

karlcow: symbol: not supported at all.

krit: this describes SVG 1.1 behavior.

karlcow: correct

krit: so no implementation changed

krit: I believe we added that because InkScape created good use cases for refX, refY on symbol.

nzimmermann: have refX and refY ever been length values?

<karlcow> https://w3c.github.io/svgwg/svg2-draft/single-page.html#painting-MarkerElementRefXAttribute

nzimmermann: then it would be easy to implement the keywords for browsers as they can use the percentage implementation.

karlcow: number + percentage

nzimmermann: according to IDL it is SVGLength?

<nzimmermann> https://w3c.github.io/svgwg/svg2-draft/single-page.html#painting-InterfaceSVGMarkerElement

karlcow: the IDL says length+percentage... another issue

<karlcow> refX <length-percentage> | <number> | left | center | right

krit: that is the new specification... what is implemented? Actual length or just numbers?

krit: IF percentage is implemented, the keywords are of limited use.

nzimmermann: in webkit it is implemented as SVGLength with percentage. And I agree.

nzimmermann: it is convenience of use and I am not opposed to the keywords in general

nzimmermann: it would not hard to implement for browsers that have refX and refY for keywords.

krit: On keywords it takes more time to discuss and implement than giving any value.

nzimmermann: agree

RSOLUTION: For marker we drop the convenience keywords as they do not provide unique value

karlcow: for symbols, the attributes are not implemented in any browser

krit: What does the spec say to symbols? What would percentage be releative too?

<karlcow> https://w3c.github.io/svgwg/svg2-draft/single-page.html#struct-SymbolAttributes

<nzimmermann> Here is the discussion why it was added: https://www.w3.org/2014/04/08-svg-minutes.html#item12

karlcow: On symbol, it is length only. No percentage

karlcow: so it is inconsistence as wlel

krit: oh, it is relative to the viewport

karlcow: In SVG, objects are defined by its left/top corner. So if you want to center something, it gets difficult.

krit: so position an element by its center of the object rather than top/left

nzimmermann: when combined by a keyword...

karlcow: correct

krit: and what about trasnform-origin + transform? Isn't that the same.

nzimmermann: only for infinite rotation which it doesn't have.

nzimmermann: mapping is the primary use case. Why limit yourself on symbol? That requires symbol on use. You want to have that on general shapes/groups. It seems a unique solution but actually you want to have that for anything and not use symbols everywhere.

<karlcow> There is a similar issue w3c/svgwg#1075

ydaniv: From an author point of view: I don't think we want to define it on the symbol but rather define it on the use element and leave the content as is.

ydaniv: I'd probably align the container...

nzimmermann: there is no generic solution if you have multiple objects and want to move them and can't define it on a container

nzimmermann: what if you want mutliple things to align? You can't align them by a container. Each needs an individual translation.

nzimmermann: I understand the use case but using the symbol is obscure. You'd wrap all the individual elements into symbols.

nzimmermann: up to some extend, you can use transforms and in the past the issue was the clipping region.

nzimmermann: but what if you want overflow clipping, you can't rely on overflow: visible

nzimmermann: Why container move is different? refX and refY are in the coordinate space established by the symbol. So that is not possible with simple x.,y on use element.

karlcow: why wasn't it discussed to have a solution for all shapes in the past?

nzimmermann: for simple use cases, you could use transform-origin

krit: With the new motion path specification we have offset-anchor and offset-path. Is that something that could be used in the future?

krit: it is getting implemented in browsers for HTML. So we could think about it.

nzimmermann: interesting. The difference still is that refX and refY are in the coordinate space of the symbol

<nzimmermann> https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/offset-anchor

nzimmermann: it could be repurposed for such kind of feature.

nzimmermann: we should ping path... it is not hard to implement. But thinking about tests for it is really hard in InkScape. Maybe Tav has tests to contribute.

ACTION: nzimmermann to ping Tav and asks for implementation status and tests

<karlcow> https://gitlab.com/inkscape/inkscape/-/blob/master/src/object/sp-symbol.h#L50