W3C home > Mailing lists > Public > public-svg-issues@w3.org > November 2018

[svgwg] vector-effect host coordinate space is not "screen"

From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
Date: Fri, 09 Nov 2018 15:34:00 +0000
To: public-svg-issues@w3.org
Message-ID: <issues.opened-379208605-1541777639-sysbot+gh@w3.org>
dirkschulze has just created a new issue for https://github.com/w3c/svgwg:

== vector-effect host coordinate space is not "screen" ==
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 `<foreignContext>` the context change would be on a boundary to HTML. TODO: Test SVG only contexts within `<foreignContext>`
* 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.

Please view or discuss this issue at https://github.com/w3c/svgwg/issues/582 using your GitHub account
Received on Friday, 9 November 2018 15:34:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 9 November 2018 15:34:02 UTC