SVG Working Group Teleconference -- 18 Mar 2019

<scribe> ScribeNick: myles

krit: Any additional agenda topics?

krit: Let's start.

Radial gradients: "fully overlapping" vs "focal point on the edge" - which takes precedence?

github: https://github.com/w3c/svgwg/issues/648

Tavmjong: I just added a test file to the issue.
... Let's look at it.

<AmeliaBR> github: https://github.com/w3c/svgwg/issues/648

<krit> example: http://tavmjong.free.fr/SVG/SVG2_TESTS/gradient_animation.svg

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.
... On the right is repeat, and the left is the default
... The next row down is radial gradients. When you have the same values for focus and end, you get nothing.
... You can see an animation. When one gets bigger than the other, the gradient flips.
... 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.
... 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.

krit: I don't see a test for when the rings are the same?
... there was another test for it in the issue

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

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.

Tavmjong: That's partially true. Chrome also doesn't draw outside. 3rd one down, 3rd one across.
... 3rd one down, 3rd one across should be identical between Chrome and Firefox. The focal point is right on the edge.

krit: Chrome doesn't repeat after the edge.

Tavmjong: it's supposed to repeat very very close together.

krit: Firefox moves the focal point inside of the circle.
... SVG 1.1 says that the focal point should be slightly within the circle, not on the circle.

AmeliaBR: Maybe I'm seeing different results than you are? OS-dependent renderings?
... myles: on macOS, FF & Chrome agree on this one.

chris: They render similarly on Windows 10 too, but one puts the colors into sRGB and the other doesn't.

AmeliaBR: What is the most useful behavior? Is it reasonable for implementations to make it match?
... 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.

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.

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?

Tavmjong: "average" color.

AmeliaBR: okay.
... Depends on whether or not it's repeating or not.

Tavmjong: Exactly. The spec could be more clear here.
... On my screen on Chrome. It does do an average on linear repeating colors when X and Y are the same.

krit: On Chrome, that's true.

Tavmjong: that's what makes sense to me.

krit: Safari has blue there. Chrome has the average color. Firefox has green. Many choices!

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.

krit: Shouldn't the same apply to circle and focal radius being 0? And focal point is in the middle?

AmeliaBR: Yes. Any place where the logical geometry is infinite repeats of 0 lengths, then we should pick consistent results.

krit: That's inconsistent with other places where we use the last color. It seems we have to use the last color

<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

AmeliaBR: If it's a padded gradient, we use the last color. top left example with a zero-length vector

krit: What if we just don't specify it?

AmeliaBR: That's a cop out
... If we can't get interop, the spec should warn authors about it.

<chris> Avoids the numerical instability so not really a cop-out

AmeliaBR: Can we get an agreement that nothing should be transparent?
... And if you would do it, use the average color of the stops

krit: That won't work

<chris> agree average color makes the most sense as the repeats converge

Tavmjong: That won't work. If you look at the SVG 2 spec, there's an example

krit: At that point we have interoperability between Chrome and Safari and Canvas for all browsers.

<AmeliaBR> https://www.w3.org/TR/SVG2/pservers.html#RadialGradientNotes

Tavmjong: That's as if you take the circle, draw it, move it, draw it

krit: And firefox removes the restriction

Tavmjong: Everywhere but that case I would <missed>

chris: If we agree on that and put it in the spec, we could raise a bug on FF?

AmeliaBR: They're not the only one who's inconsistent
... There are 2 issues

krit: chris: Let's separate the two issues

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

Tavmjong: The first thing is a bug on Firefox for not supporting the focal point outside of the circle

AmeliaBR: Infinite repeats even with linear gradients. Tavmjong's example: top row 3rd over

krit: There we have inconsistency with all browsers.

chris: I did testing in Edge but there's no animation.

AmeliaBR: Edge shows solid blue instead of solid green or solid average

Tavmjong: That's wrong

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.

chris: We should clarify the spec, raise the issues, and if they're not fixed, change the spec back.

krit: ok
... Tavmjong and AmeliaBR and chris prefer average color
... Do we say how to compute the average color?

Tavmjong: Yes.

krit: Then we can resolve that way.

Tavmjong: The color space is the same in which the gradient is interpolated.

krit: Let's agree on average color for infinite repeating patterns

<chris> avg color is the correct result, if you assume infinite sub-pixel sampling

Tavmjong: spread-method="repeat". If there's no spread method, use the last color stop.

krit: So the average color is just for spread-method="repeat" and "reflect"?

Tavmjong: yes

RESOLUTION: For spread-method="repeat" and "reflect", infinitesimal repeats use the average color of the stops

RESOLUTION: for spread-method="pad" we use the last color stop

RESOLUTION: for spread-method="pad" we use the last color stop for infinitesimal repeats

krit: So let's open an issue on Firefox about how they don't match the above resolutions.

Tavmjong: Okay.

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 cone?

Tavmjong: maybe
... 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.

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?

Tavmjong: Ask them to match the spec text

chris: Yes. Use the other one as a fallback position

AmeliaBR: Okay, let's make sure there are bugs.

krit: Any other things to discuss?

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
... The issue should stay open until we get matching implementations. Can we get some tests?

krit: Should we add text about implementation feedback needed.

Tavmjong: Back to AmeliaBR's question about transparent black: I think there is an inconsistency between the two images.

AmeliaBR: The two figures in the spec?

Tavmjong: yeah.
... 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.

krit: correct.
... We see that in Chrome and Firefox

AmeliaBR: It goes invisible because it can't define the geometry

Tavmjong: We could say that outside that becomes the average.

AmeliaBR: Do you want to make some figures of that case and what it could look like?

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.

Tavmjong: The bottom right figure needs to be changed, then.
... 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.
... So we were trying to be consistent with that

AmeliaBR: Well, if we make sure there are bugs filed with implementors, we'll get some more opinions coming in hopefully.

Tavmjong: mhm.
... But the spec itself should be consistent.

AmeliaBR: Yeah.

krit: If you go back to the animation, you see the transparent left side in any browser other than Firefox (not sure about Edge)

AmeliaBR: Edge hasn't implemented the "fr" so it's not relevant.

Tavmjong: Edge is switching, right?

AmeliaBR: It will eventually be Chrome.

krit: Can we close the topic?

chris: yes

Tavmjong: yes

GitHub: https://github.com/w3c/svgwg/issues/642

<AmeliaBR> github: https://github.com/w3c/svgwg/issues/648

GitHub: https://github.com/w3c/svgwg/issues/648

Potentially invalid value for dasharray

GitHub: https://github.com/w3c/svgwg/issues/642

AmeliaBR: About the syntax for stroke-array. As I commented yesterday, this is something we discussed before, and we changed a lot of other examples and this one somehow got missed in all those edits.
... So, I would recommend changing the grammar to be consistent with the other edits we made, which is to explicitly separate out the space-separated repeats and the comma separated repeats using square brackets
... The other issue that krit discovered is there are some weird things where you don't need space separating at all, and I'm not sure if that's consistent with CSS or not. I pinged TabAtkins to see his thoughts, but he didn't get back to me. All browsers are consistent, though, so CSS parsing should change.

krit: I know TabAtkins's opinion on that, so I would not count on a spec change. At least for the SVG attribute we can specify it how it's implemented. For CSS, it's up to the CSSWG.
... On the other hand, this part is not that important.

AmeliaBR: We can make an edit to the grammar ourselves, and follow-up on whether spaces are necessary between subsequent numbers if the numbers are obviously distinguishable otherwise. It's a separate issue.

<TabAtkins> There's a bunch of stuff in CSS where you don't *technically* need spaces, if you're careful in how you're butting things against each other.

AmeliaBR: The other comment I made at the end. We have a statement about how these things are serialized if we allow spaces or comments and I haven't looked to see whether we have that

krit: For computed style?

AmeliaBR: Yes, and for serialization too
... <reads TabAtkins's IRC comments>

krit: They don't technically need spaces.

chris: I remember TabAtkins trying to explain that to me. There's a grammar that defines it but <it says spaces are required then says they aren't in some cases>
... It sounded like handwaving magic to me but okay.

AmeliaBR: With that clarification from TabAtkins it covers that topic
... I'll see if the serialization issue is already covered, if it isn't, I'll make another issue

<TabAtkins> ? No grammar weirdness, you just follow the parsing algorithm. `.9.9` is NUMBER(.9) NUMBER(.9), because the number-token parsing stops at the second `.`, emitting the NUMBER, then starts a new NUMBER.

krit: We should have another issue to see if implementations actually align.
... Let's open another issue

<chris> we agree, TabAtkins

krit: If you read the syntax, the prose doesn't require spaces.

AmeliaBR: It just says "repeated tokens" without commas that usually means spaces separation but it doesn't necessarily mean that

<TabAtkins> Note that serialization *should* always emit spaces, regardless of what the author input.

RESOLUTION: Change the syntax as AmeliaBR wrote it out in AmeliaBR's comment yesterday

AmeliaBR: I can make the edit. I'll also look into the other issue I brought up.

Officially SVGWG approved schema files for SVG 1.1 and SVG 2

AmeliaBR: krit and I have had some conversations with a group who are involved in IEC standards where they want to integrate vector graphic standards by reference. They weren't sure which SVG standard was stable and supported enough to incorporate by reference.
... One of the things for their standards is they'd like explicit machine-readable schemas. They were asking if such a thing existed for SVG or was likely to be created.

chris: I can give some history. SVG 1.0 1.1 were defined due to the DTD. There were things the grammar allowed that the DTD didn't. In the SVG 1.2 timeframe, we were moving toward RelaxNG, that was in Complex Document Frameworks days when we were trying to mix many languages. Also efficient XML spec, which needs their own grammar too.
... The most efficient grammars are the most constrained grammars, but SVG isn't constrained at all (e.g. "data-" anywhere) so they gave up. Someone else was interested in working toward RelaxNG schema, but it ran out because the group wasn't willing to put the time into reviewing the results.
... I thought for SVG 2 we did it the same as HTML does, which is to say, not "machine gobble-able"
... But maybe it is worth doing? But I would question whether or not it should be our top priority

AmeliaBR: They might do it for us if we ask them to. But they want to do it with our blessing

chris: That's good. We've had problems in the past

AmeliaBR: They were looking for a XSD. It's a W3C XML schema.

<chris> they wanted an XSD = W3C XML Schema

chris: If we accept their offer ... it would be nasty not to. But in good faith, if we accept, we should put some effort into reviewing it and checking it and putting it in our spec. That's the whole point.

AmeliaBR: I could maybe ask if there were interested in using the CG structure as a way of working on this with a connection to W3C. So they have their own structures.
... I'm not sure whether that would be welcomed or not.

krit: IEC group also did some research on an XML schema. They found one that was written by chris

<krit> https://www.w3.org/TR/2002/WD-SVG11-20020108/SVG.xsd

chris: I definitely didn't write it. I don't know enough to write an XML schema. Maybe I checked it in? I know someone did a bad job by converting the DTD to XML using an automated converter... it was not a good thing.

krit: edited by chris

chris: I know nothing!!!
... I disclaim all responsibility

krit: I think it's a good question to ask whether they would like to participate in the Community Group.

AmeliaBR: Okay, I'll follow up.

krit: Do we need to agree in the WG if we will review?

chris: I did write it. It was me throwing stuff together. This is handwritten, it's not a DTD conversion. It's as a reasonable start as any

krit: not complete

chris: Certainly not complete and not up to date.
... It even has a few comments!

krit: Are we going to re-use this? I don't see why not.

<AmeliaBR> Here's the project/team asking for this: https://www.iec.ch/dyn/www/f?p=103:38:4544547617021::::FSP_ORG_ID,FSP_APEX_PAGE,FSP_PROJECT_ID:1273,23,23766

chris: We should

AmeliaBR: If someone is willing to do the work, we should encourage it, and liaise with that, even if it's not our priority.

krit: Let's make clear this isn't our priority, but we are willing to help. A good start is the SVG CG.

none

<krit> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

18 Mar 2019

Attendees

Contents

Radial gradients: "fully overlapping" vs "focal point on the edge" - which takes precedence?

Potentially invalid value for dasharray

Officially SVGWG approved schema files for SVG 1.1 and SVG 2

none

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output