-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vector-effect host coordinate space is not "screen" #582
Comments
Update: Here an example of https://codepen.io/krit/pen/eQzgwJ?editors=1100
|
This definition in SVG 1.2 Tiny might be the closest (but with viewport instead of element):
and
https://www.w3.org/TR/SVGTiny12/intro.html#TermRootmostSVGElement |
Something that came into my mind: We have the
https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__getScreenCTM Should the matrix reflect the same coordinate space transformation that |
The SVG Working Group just discussed
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 |
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1903546 gecko-commit: a11e8418e383e89972a8546e6400f424b84a2ac5 gecko-reviewers: emilio
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1903546 gecko-commit: a11e8418e383e89972a8546e6400f424b84a2ac5 gecko-reviewers: emilio
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303
This implements w3c/svgwg#582 and therefore mostly reverts bug 1904891 Differential Revision: https://phabricator.services.mozilla.com/D216303 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1903546 gecko-commit: a11e8418e383e89972a8546e6400f424b84a2ac5 gecko-reviewers: emilio
The spec text for rendering of
vector-effect: non-scaling-stroke
says:https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects
The definition of
vector-effect
in the spec has the following:viewport
is the default:https://svgwg.org/svg2-draft/coords.html#VectorEffects
Nothing of that is what browsers implement. I tested the following scenarios
<rect>
withnon-scaling-stroke
:viewBox
scaling.https://codepen.io/krit/pen/KrMgWd?editors=1100
<div>
box:https://codepen.io/krit/pen/RqRRgZ?editors=1100
<div>
-box within<foreignObject>
in SVG document.https://codepen.io/krit/pen/xQOOBg?editors=1100
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, thennon-scaling-stroke
does not apply to the same context as the reference<rect>
.Findings:
<foreignObject>
the context change would be on a boundary to HTML. TODO: Test SVG only contexts within<foreignObject>
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.The text was updated successfully, but these errors were encountered: