- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Nov 2018 21:38:21 +0000
- To: public-svg-issues@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <myles> TOPIC: vector-effect host coordinate space is not "screen"<br> <AmeliaBR> s/sane/the same/<br> <myles> Github: https://github.com/w3c/svgwg/issues/582<br> <krit> https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects<br> <myles> krit: if you look at the definition for host coordinate system, there are two specification texts: ☝️<br> <krit> https://svgwg.org/svg2-draft/coords.html#VectorEffects<br> <myles> 👆<br> <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<br> <myles> krit: the second link ist he definition of the vector-effect property: screen, viewport.<br> <myles> <inaudible><br> <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.<br> <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<br> <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<br> <myles> AmeliaBR: but at the same time, it would be more useful if it was based to the screen, like get screen ppm is...<br> <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<br> <myles> AmeliaBR: The definition of that would need to get updated<br> <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<br> <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<br> <myles> depends if all the browsers are interoperable among themselves.<br> <myles> krit: there's 1 case where they're not interoperable, blink is interoperable to webkit but not to firefox<br> <myles> krit: Firefox would go up to the SVG root element, but BLink would stop before the root<br> <myles> AmeliaBR: that's not a shadow root, it's a foreignObject content switch<br> <myles> krit: that's the only interop issue.<br> <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<br> <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<br> <myles> krit: Is it defined this way in SVG 2?<br> <myles> AmeliaBR: It's defined that way for children of foreignObject are supposed to behave as children of HTML elements.<br> <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<br> <myles> krit: it's always easier this way than the other way around<br> <myles> myles: we don't want to hold up standardization. It's a corner case, we won't push either wa<br> <myles> AmeliaBR: <svg> direclty inside <foreignObject> is rare<br> <myles> s/either wa/either way/<br> <myles> krit: let's keep this one out for now and resolve on the general idea<br> <myles> krit: proposed resolution: The host coordinate system is the furthest SVG viewport without switching namespace contexts?<br> <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 ....<br> <myles> AmeliaBR: You can just say in teh resolution "as defined in SVG 1.2 Tiny"<br> <myles> RESOLVED: The host coordinate system is the furthest SVG viewport as defined in SVG 1.2 Tiny<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/582#issuecomment-438037286 using your GitHub account
Received on Monday, 12 November 2018 21:38:22 UTC