- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Mar 2019 20:36:12 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `Radial gradients: "fully overlapping" vs "focal point on the edge" - which takes precedence?`, and agreed to the following: * `RESOLUTION: For spread-method="repeat" and "reflect", infinitesimal repeats use the average color of the stops` * `RESOLVED: For spread-method="repeat" and "reflect", infinitesimal repeats use the average color of the stops` * `RESOLVED: for spread-method="pad" we use the last color stop` * `RESOLVED: for spread-method="pad" we use the last color stop for infinitesimal repeats` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: Radial gradients: "fully overlapping" vs "focal point on the edge" - which takes precedence?<br> <myles> Tavmjong: I just added a test file to the issue.<br> <myles> Tavmjong: Let's look at it.<br> <AmeliaBR> github: https://github.com/w3c/svgwg/issues/648<br> <krit> example: http://tavmjong.free.fr/SVG/SVG2_TESTS/gradient_animation.svg<br> <myles> Tavmjong: The top one shows what happens for a linear gradient when x1=x2 and y1=y2. According to the spec, you're supposed to use the last stop color. FF & Chrome seem to do that. For some reason, on an earlier test, Chrome wasn't doing that. Maybe I screwed up. Then you see an animation where I animation x1, so you can see what happens at the limit.<br> <myles> Tavmjong: On the right is repeat, and the left is the default<br> <myles> Tavmjong: The next row down is radial gradients. When you have the same values for focus and end, you get nothing.<br> <myles> Tavmjong: You can see an animation. When one gets bigger than the other, the gradient flips.<br> <myles> Tavmjong: The next row down is from SVG 1.1. The focal point on the edge. You can see differences in behavior between Firefox and Chrome. Firefox doesn't allow you to move the focal point outside the outer circle. Chrome does. Firefox draws outside the left, but Chrome doesn't.<br> <myles> The bottom row is if you have a focal ring moving across from left to right. There is some difference in behavior with the browsers.<br> <myles> s/The bottom/Tavmjong: The bottom/<br> <myles> krit: I don't see a test for when the rings are the same?<br> <myles> krit: there was another test for it in the issue<br> <myles> AmeliaBR: We know there's an inconsistency there. It's useful to break it apart and find which parts are inconsistent. THe result: Lots of different parts are inconsistent<br> <myles> krit: I'm not so sure about that. The inconsistency between Firefox and Chrome, it's because Firefox doesn't allow you to have a focal radius that's outside of the circle. Firefox just didn't adapt to SVG 2 yet.<br> <myles> Tavmjong: That's partially true. Chrome also doesn't draw outside. 3rd one down, 3rd one across.<br> <myles> Tavmjong: 3rd one down, 3rd one across should be identical between Chrome and Firefox. The focal point is right on the edge.<br> <myles> krit: Chrome doesn't repeat after the edge.<br> <myles> Tavmjong: it's supposed to repeat very very close together.<br> <myles> krit: Firefox moves the focal point inside of the circle.<br> <myles> krit: SVG 1.1 says that the focal point should be slightly within the circle, not on the circle.<br> <myles> AmeliaBR: Maybe I'm seeing different results than you are? OS-dependent renderings?<br> <myles> AmeliaBR: myles: on macOS, FF & Chrome agree on this one.<br> <myles> chris: They render similarly on Windows 10 too, but one puts the colors into sRGB and the other doesn't.<br> <myles> AmeliaBR: What is the most useful behavior? Is it reasonable for implementations to make it match?<br> <myles> AmeliaBR: As far as my personal preference, I think that anything that results in transparent regions when all the stops are opaque is wrong and inconsistent with the rest of SVG gradients. But I understand it's consistent with canvas gradients.<br> <myles> krit: SVG 1.1 avoided that by not allowing the focal point outside of the focal radius. However, it was decided a long time ago that we would move closer to canvas.<br> <myles> AmeliaBR: The SVG spec does say "except that you pad with a solid color". That is a difference from canvas. Is making that one adjustment too difficult for implementors?<br> <myles> Tavmjong: "average" color.<br> <myles> AmeliaBR: okay.<br> <myles> AmeliaBR: Depends on whether or not it's repeating or not.<br> <myles> Tavmjong: Exactly. The spec could be more clear here.<br> <myles> Tavmjong: On my screen on Chrome. It does do an average on linear repeating colors when X and Y are the same.<br> <myles> krit: On Chrome, that's true.<br> <myles> Tavmjong: that's what makes sense to me.<br> <myles> krit: Safari has blue there. Chrome has the average color. Firefox has green. Many choices!<br> <myles> AmeliaBR: The average color is the logical limit of infinite repeats when the length of the repeat gets smaller and smaller. Animations make this clear.<br> <myles> krit: Shouldn't the same apply to circle and focal radius being 0? And focal point is in the middle?<br> <myles> AmeliaBR: Yes. Any place where the logical geometry is infinite repeats of 0 lengths, then we should pick consistent results.<br> <myles> krit: That's inconsistent with other places where we use the last color. It seems we have to use the last color<br> <chris> I guess, oce we have tightened the spec, whether the implementations are willing to converge on the correct rendering, or whether we should put "fr" at risk<br> <myles> AmeliaBR: If it's a padded gradient, we use the last color. top left example with a zero-length vector<br> <myles> krit: What if we just don't specify it?<br> <myles> AmeliaBR: That's a cop out<br> <myles> AmeliaBR: If we can't get interop, the spec should warn authors about it.<br> <chris> Avoids the numerical instability so not really a cop-out<br> <myles> AmeliaBR: Can we get an agreement that nothing should be transparent?<br> <myles> AmeliaBR: And if you would do it, use the average color of the stops<br> <myles> krit: That won't work<br> <chris> agree average color makes the most sense as the repeats converge<br> <myles> Tavmjong: That won't work. If you look at the SVG 2 spec, there's an example<br> <myles> krit: At that point we have interoperability between Chrome and Safari and Canvas for all browsers.<br> <AmeliaBR> https://www.w3.org/TR/SVG2/pservers.html#RadialGradientNotes<br> <myles> Tavmjong: That's as if you take the circle, draw it, move it, draw it<br> <myles> krit: And firefox removes the restriction<br> <myles> Tavmjong: Everywhere but that case I would <missed><br> <myles> chris: If we agree on that and put it in the spec, we could raise a bug on FF?<br> <myles> AmeliaBR: They're not the only one who's inconsistent<br> <myles> AmeliaBR: There are 2 issues<br> <myles> krit: chris: Let's separate the two issues<br> <myles> AmeliaBR: Issue 1) What to do with infinite repeats and using the average color, we'll keep the spec text there and make sure there's a bug on Firefox<br> <myles> Tavmjong: The first thing is a bug on Firefox for not supporting the focal point outside of the circle<br> <myles> AmeliaBR: Infinite repeats even with linear gradients. Tavmjong's example: top row 3rd over<br> <myles> krit: There we have inconsistency with all browsers.<br> <myles> chris: I did testing in Edge but there's no animation.<br> <myles> AmeliaBR: Edge shows solid blue instead of solid green or solid average<br> <myles> Tavmjong: That's wrong<br> <myles> krit: So should the color be blue, green, or average? Can we just open issues against any browsers that don't match the behavior? And assume that those would be fixed? Or keep it unspecified.<br> <myles> chris: We should clarify the spec, raise the issues, and if they're not fixed, change the spec back.<br> <myles> krit: ok<br> <myles> krit: Tavmjong and AmeliaBR and chris prefer average color<br> <myles> krit: Do we say how to compute the average color?<br> <myles> Tavmjong: Yes.<br> <myles> krit: Then we can resolve that way.<br> <myles> Tavmjong: The color space is the same in which the gradient is interpolated.<br> <myles> krit: Let's agree on average color for infinite repeating patterns<br> <chris> avg color is the correct result, if you assume infinite sub-pixel sampling<br> <myles> Tavmjong: spread-method="repeat". If there's no spread method, use the last color stop.<br> <myles> krit: So the average color is just for spread-method="repeat" and "reflect"?<br> <myles> Tavmjong: yes<br> <myles> RESOLUTION: For spread-method="repeat" and "reflect", infinitesimal repeats use the average color of the stops<br> <myles> RESOLVED: For spread-method="repeat" and "reflect", infinitesimal repeats use the average color of the stops<br> <myles> RESOLVED: for spread-method="pad" we use the last color stop<br> <myles> RESOLVED: for spread-method="pad" we use the last color stop for infinitesimal repeats<br> <myles> krit: So let's open an issue on Firefox about how they don't match the above resolutions.<br> <myles> Tavmjong: Okay.<br> <myles> AmeliaBR: The final issue is do we want to continue to push spec text that says always paint something even when the focal radius is doing weird things that in canvas would include transparent regions of the code?<br> <myles> s/code/cone/<br> <myles> Tavmjong: maybe<br> <myles> Tavmjong: If you look at the first figure under 14.2.3.2 it shows you the logical way of drawing outside the code with transparent black. That's what everyone does.<br> <myles> AmeliaBR: But then we have that second picture which shows it padded and the note that says we've got a difference to maintain compatibility with SVG 1.1. Do we want to stick with that spec text or match implementations, or ask implementations to match the spec text?<br> <myles> Tavmjong: Ask them to match the spec text<br> <myles> chris: Yes. Use the other one as a fallback position<br> <myles> AmeliaBR: Okay, let's make sure there are bugs.<br> <myles> krit: Any other things to discuss?<br> <myles> <silence><br> <myles> AmeliaBR: I suppose it's just make sure there are bugs filed and we collect the links to the bugs in the issue on GitHub and then at some point we'll come back and decide if we need to recognize that we won't have conforming implementations and make this undefined or match reality<br> <myles> AmeliaBR: The issue should stay open until we get matching implementations. Can we get some tests?<br> <myles> krit: Should we add text about implementation feedback needed.<br> <myles> Tavmjong: Back to AmeliaBR's question about transparent black: I think there is an inconsistency between the two images.<br> <myles> AmeliaBR: The two figures in the spec?<br> <myles> Tavmjong: yeah.<br> <myles> Tavmjong: Cause if you move the circle in, in the top figure, so the two right edges edges just touch, then that cone becomes a half-plane.<br> <myles> krit: correct.<br> <myles> krit: We see that in Chrome and Firefox<br> <myles> AmeliaBR: It goes invisible because it can't define the geometry<br> <myles> Tavmjong: We could say that outside that becomes the average.<br> <myles> AmeliaBR: Do you want to make some figures of that case and what it could look like?<br> <myles> krit: I feel we'll get inconsistent again with canvas. We want to be more compatible with canvas, that's the initial reason for this change.<br> <myles> Tavmjong: The bottom right figure needs to be changed, then.<br> <myles> Tavmjong: The argument when we made that decision was if you move the focal point just inside the circle, we do fill the whole plane with color.<br> <myles> Tavmjong: So we were trying to be consistent with thtat<br> <myles> s/thtat/that/<br> <myles> AmeliaBR: Well, if we make sure there are bugs filed with implementors, we'll get some more opinions coming in hopefully.<br> <myles> Tavmjong: mhm.<br> <myles> Tavmjong: But the spec itself should be consistent.<br> <myles> AmeliaBR: Yeah.<br> <myles> krit: If you go back to the animation, you see the transparent left side in any browser other than Firefox (not sure about Edge)<br> <myles> AmeliaBR: Edge hasn't implemented the "fr" so it's not relevant.<br> <myles> Tavmjong: Edge is switching, right?<br> <myles> AmeliaBR: It will eventually be Chrome.<br> <myles> krit: Can we close the topic?<br> <myles> chris: yes<br> <myles> Tavmjong: yes<br> <myles> GitHub: https://github.com/w3c/svgwg/issues/642<br> <AmeliaBR> github: https://github.com/w3c/svgwg/issues/648<br> <myles> GitHub: https://github.com/w3c/svgwg/issues/648<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/648#issuecomment-474090448 using your GitHub account
Received on Monday, 18 March 2019 20:36:13 UTC