vector-effect host coordinate space is not "screen"

[dirkschulze]

The spec text for rendering of vector-effect: non-scaling-stroke says:

With the non-scaling-stroke vector effect, stroke outline shall be calculated in the "host" coordinate space instead of user coordinate system. More precisely: a user agent establishes a host coordinate space which in SVG Tiny 1.2 is always the same as "screen coordinate space".

https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects

The definition of vector-effect in the spec has the following:

viewport
Specifies immediate viewport coordinate system as the host coordinate space. When that element belongs to nested viewport coordinate system, vector effects are applied toward viewport coordinate system to which that element belongs directly. That is, that vector effect is not effective for change of CTM on ancestral viewport coordinate system.

screen
It specifies the coordinate system of content which under the immediate control of user agent. So to speak, it is "scrren" which user agent has. ("screen coordinate space" in SVGT1.2) Even if that element belongs to nested viewport coordinate system, that vector effect is always effective for change of CTM of the any hierarchy.

viewport is the default:

An initial value in case it is not specified is viewport.

https://svgwg.org/svg2-draft/coords.html#VectorEffects

Nothing of that is what browsers implement. I tested the following scenarios <rect> with non-scaling-stroke:

1. in nested, inner SVG element with viewBox scaling.
   https://codepen.io/krit/pen/KrMgWd?editors=1100
2. in inline SVG with CSS Transform on root-<div> box:
   https://codepen.io/krit/pen/RqRRgZ?editors=1100
3. in inline SVG within <div>-box within <foreignObject> in SVG document.
   https://codepen.io/krit/pen/xQOOBg?editors=1100
4. in 3D rendering context with 2D transform on group element establishing 3D rendering context.
   https://codepen.io/krit/pen/ZmOpaL?editors=1100 (only Firefox)

All examples have an overlaying <rect> which is not in a scaled coordinate space as reference. If you see red, then non-scaling-stroke does not apply to the same context as the reference <rect>.

Findings:

• The "host" coordinate system is the one on context change (SVG embedded in HTML context). Even inside a <foreignObject> the context change would be on a boundary to HTML. TODO: Test SVG only contexts within <foreignObject>
• A 3D rendering context does (surprisingly) not force the use of the coordinate system on that boundary. (Maybe more tests are needed.)
• Not the nearest SVG viewport but the furthest SVG viewport is the host coordinate system.

This behavior is interoperable in Chrome, Firefox and WebKit.

Suggestion: Use the furthest SVG viewport to the element with vector-effect or a context boundary to HTML as the host coordinate system. What ever comes first is chosen.

[dirkschulze]

CC @AmeliaBR and @tanyeah

[dirkschulze]

Update: Here an example of <foreignObject> w/o HTML context boundaries. (Pure SVG)

https://codepen.io/krit/pen/eQzgwJ?editors=1100

non-scaling-stroke uses the root SVG on Firefox and WebKit. Chrome uses the viewport of the <svg> in the <foreignObject> as host.

[dirkschulze]

This definition in SVG 1.2 Tiny might be the closest (but with viewport instead of element):

rootmost 'svg' element
The rootmost 'svg' element is the furthest 'svg' ancestor element that does not exit an SVG context.

and

SVG context
An SVG context is a document fragment where all elements within the fragment must be subject to processing by an SVG user agent according to the rules in this specification.

https://www.w3.org/TR/SVGTiny12/intro.html#TermRootmostSVGElement

[dirkschulze]

Something that came into my mind: We have the getScreenCTM() interface on SVGGraphicElements:

The getScreenCTM method is used to get the matrix that transforms the current element's coordinate system to the coordinate system of the SVG viewport for the SVG document fragment.

https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getScreenCTM

Should the matrix reflect the same coordinate space transformation that vector-effect is going to use?

[css-meeting-bot]

The SVG Working Group just discussed vector-effect host coordinate space is not "screen", and agreed to the following:

• RESOLVED: The host coordinate system is the furthest SVG viewport as defined in SVG 1.2 Tiny

The full IRC log of that discussion

<myles> TOPIC: vector-effect host coordinate space is not "screen"
<AmeliaBR> s/sane/the same/
<myles> Github: https://github.com//issues/582
<krit> https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects
<myles> krit: if you look at the definition for host coordinate system, there are two specification texts: ☝️
<krit> https://svgwg.org/svg2-draft/coords.html#VectorEffects
<myles> 👆
<myles> krit: the first is a defintion for how everything gets painted. Refers to a "screen" value. The screen coordinate system is the initial coordinate system. Doesn't need to be the device coordinate system. It's the coordinate system of the canvas
<myles> krit: the second link ist he definition of the vector-effect property: screen, viewport.
<myles> <inaudible>
<myles> krit: screen references the same thing as the painting section, but viewport says the nearest viewport is used as the host coordinate system. Neither are correct, but there is interop between firefox, webkit and blink to a degree.
<myles> krit: I would explain it as in the host coordinate system is the furthest viewport of the current SVG fragment which doesn't include any boudnaries of other namespaced elements
<myles> AmeliaBR: I liket he wording you found in SVG 1.1, clearly breaking out to other layout, then you're resetting the baseic transfomration
<myles> AmeliaBR: but at the same time, it would be more useful if it was based to the screen, like get screen ppm is...
<myles> krit: get screen ppm is defined to refer to the documetn root, which is something else. Ideally, both would be defined the same way
<myles> AmeliaBR: The definition of that would need to get updated
<myles> AmeliaBR: It might be what impelmentations do. I need to check whether it's implemented, and how. It might be good to align, but let's concentrate on vector-effect. Let's focus on what's imjplemented and interoperable, even if it isn't the device coordinate space or the init coordinate space
<myles> AmeliaBR: I prefer an implementation that didn't have separate rules for transformations on SVG vs transformations on parent CSS layout box. I prefer that we were able to approach those transformations and cumulative transformations, and the vector-effect dealt with that same cumulative effect. But I would also like to get this spec finalized, and if that means matching what everyone has implemented, then that's the sort of compromise I can make. But it
<myles> depends if all the browsers are interoperable among themselves.
<myles> krit: there's 1 case where they're not interoperable, blink is interoperable to webkit but not to firefox
<myles> krit: Firefox would go up to the SVG root element, but BLink would stop before the root
<myles> AmeliaBR: that's not a shadow root, it's a foreignObject content switch
<myles> krit: that's the only interop issue.
<myles> krit: I believe it used to be the same as WebKit and blink, but somehow behavior changed. But we still have 2 interoperable implementations, webkti and blink
<myles> AmeliaBR: a foreign object inside would switch to CSS layotu mode, but if there's SVG inside that, you switch to SVG layout mode. But there's a box that follows CSS rules
<myles> krit: Is it defined this way in SVG 2?
<myles> AmeliaBR: It's defined that way for children of foreignObject are supposed to behave as children of HTML elements.
<myles> krit: It should be easy for WebKit to also have this switch on the foreignObject. If it's easy, we can do that, and follow the blink implementation
<myles> krit: it's always easier this way than the other way around
<myles> myles: we don't want to hold up standardization. It's a corner case, we won't push either wa
<myles> AmeliaBR: <svg> direclty inside <foreignObject> is rare
<myles> s/either wa/either way/
<myles> krit: let's keep this one out for now and resolve on the general idea
<myles> krit: proposed resolution: The host coordinate system is the furthest SVG viewport without switching namespace contexts?
<myles> krit: I put up a pull request, which I think was an SVG fragment that can be .... any element in that fragment being in the SVG naemspace, but that's something that ....
<myles> AmeliaBR: You can just say in teh resolution "as defined in SVG 1.2 Tiny"
<myles> RESOLVED: The host coordinate system is the furthest SVG viewport as defined in SVG 1.2 Tiny