W3C

- DRAFT -

SVG Working Group Teleconference

11 Mar 2019

Attendees

Present
AmeliaBR, Tavmjong, chris, krit, myles, plh
Regrets
Chair
krit
Scribe
AmeliaBR, myles

Contents


<AmeliaBR> Scribenick:AmeliaBR

<TabAtkins> krit: you sure there?

<chris_> see https://w3c.github.io/spec-dashboard/report.html#abandoned

<myles> ScribeNick: myles

Outdated SVG specs

<scribe> ScribeNick: AmeliaBR

PLH: We have old SVG specs published as TR on W3 website which aren't very helpful for redirecting people to correct place.
... Chris & I reviewed & found two categories
... First, there are abandoned spec proposals. They should stay for historical reasons, but shouldn't confuse people looking for current specs.

Dirk: For these four (Media Access Events, SVG Filter Requirements, and SVG Parameters), any objections to publishing as notes marking them abandoned.

Amelia: What are the Media Access Events?

Chris: It was an SVG-specific set of events that have been completely overtaken by other changes to UI Events.

PLH: The other set of specs are SVG things that have been replaced by CSS specs. We want to redirect them to the current spec.
... Filters 1.2 > CSS Filter Effects, SVG Transforms > CSS Transforms 1, SVG Color 1.2 > CSS Color 4

Dirk: Would there still be a way to access the historical versions?

PLH: Yes, the dated versions of the publications will still be there. It is only the undated version that will redirect.

Chris: And the old versions will get the Red Box that marks them as out of date?

PLH: Yes, our system would add that automatically.

<chris_> https://www.w3.org/TR/SVG2/conform.html#processing-modes

Chris: For SVG Integration, which doesn't have a single replacing spec, we'd like to publish a stub that redirects to the correct chapter of SVG 2.
... I can write that little stub to get the redirect.

Dirk: Does anyone have concerns?

Amelia: My one concern with the redirects is that some of these are very different from what they are being redirected to.

PLH: Other option is publish as a note, saying discontinued, and in status give a link to the current document.

Amelia: Also, what happens if one of these specs does get revived in future? Might happen with SVG Parameters.

PLH: That could happen. Not an issue to revive in the future.
... So, do people want redirects or publish as abandoned?

Chris: I think it sends wrong impression to say these are retired. They just evolved.

Dirk: Agreed.

RESOLUTION: Republish the following specs as retired: Media Access Events (http://www.w3.org/TR/MediaAccessEvents/), SVG Filter Requirements ( http://www.w3.org/TR/SVGFilterReqs12/), SVG Parameters 1.0, Part 1: Primer ( http://www.w3.org/TR/SVGParamPrimer/), SVG Parameters 1.0, Part 2: Language ( http://www.w3.org/TR/SVGParam/)

RESOLUTION: Redirect the following specs to CSS versions: SVG Filters 1.2, Part 2: Language:

http://www.w3.org/TR/SVGFilter12/

should instead go to https://www.w3.org/TR/filter-effects-1/

SVG Transforms 1.0, Part 2: Language:

https://www.w3.org/TR/SVG-Transforms/

should instead go to https://www.w3.org/TR/css-transforms-1/

SVG Color 1.2, Part 2: Language:

http://www.w3.org/TR/SVGColor12/

should instead go to https://www.w3.org/TR/css-color-4/

RESOLUTION: Republish SVG Integration ( http://www.w3.org/TR/svg-integration/) as a note with links to SVG 2 processing mode definitions

Dirk: Should the redirects go to un-numbered versions of the CSS specs?

Chris: They could, either way.

SVG WG at TPAC 2019

Dirk: Every chair has been asked to declare if they'll be meeting & need a meeting room.
... So: do we want to meet? If so, how many people & how long.

Myles: How will this interact with a CG meeting.

Chris: They shouldn't conflict. Maybe schedule so CG is a supergroup of the WG.
... I will be there, but will also be going to CSS & Audio &c so I might not be able to join

Myles: Yes, we definitely shouldn't conflict with CSS.

Tav: I can't see the costs for going in person. Could call in.

Amelia: I expect to be there.

Dirk: Okay, is one day enough?

Amelia: Or one day for the WG plus a half day for the CG?
... Or should we ask for a full 2 days for WG, just in case?

PLH: Please don't ask for meeting rooms you won't need!

Tav: Do we really expect a lot of extra participants for the CG?

Amelia: Don't really know yet.

RESOLUTION: SVG WG will meet at TPAC, probably Thursday, must not conflict with CSS

PLH: Any other conflicts people care about.

Chris: I'd prefer to also go to Web Audio

Amelia: I might also try to get to ARIA WG

SVG CG update

Dirk: Amelia posted a draft charter (https://w3c.github.io/charter-drafts/svgcg-2019.html)
... Any concerns/comments from the WG perspective?
... Or maybe read the charter on your own time & let us know if there are issues

Amelia: What's the status on the WG charter?

<chris_> https://www.w3.org/Graphics/SVG/svg-2019.html

Chris: All the comments have been integrated, Mozilla's formal objection has been withdrawn, now we are waiting for review of the changes

<chris_> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019-ac.html&doc2=https%3A%2F%2Fwww.w3.org%2FGraphics%2FSVG%2Fsvg-2019.html

Myles: So will the WG charter be finalized before the CG charter?

Chris: Yes.

Myles: Then there is no need to start the SVG Core spec in the CG for chartering issues.

Chris: Aside, this is last chance to change the name of the spec from SVG Core to SVG Native. Should I do that.

Myles: I've been using the name SVG Native to discuss it, e.g. in the OpenType group.

Amelia: Is the scope of the spec really restricted to SVG in native apps, or is the idea more general.

Myles: As we've been discussing it, the focus has been on native apps.
... but I don't care either way.

Amelia: I think Core is more general, but we already use the name Core (e.g., GitHub issue labels) for the main SVG 2+ spec.

Tav: And our charter talks about "restricting to core SVG 2".

Chris: Okay, changing the name to "SVG Native".

Dirk: Again, feedback needed on the SVG CG charter.

Myles: About the 2 charters, should I now focus on bringing SVG Native to the main WG.

Amelia: Sure, unless there are other reasons to want to do it in the CG.

Publish FPWD of SVG Animations

<myles> ScribeNick: myles

AmeliaBR: We got a question: Someone is confused about the statsu of the animation spec and the animation elements.
... This is the chapter of animations from SVG 1.1 plus minor edits from SVG 2. Was pulled out of SVG b/c of issues with implementor commitments
... It would be published as a separate module in parallel to SVG 2 but never got officially published as a WD
... So, can we get it as a PR that this is a separate thing that can be referenced so people don't have to reference SVG 1.1 animations chapter. They can reference SVG 2 and this parallel spec that adds in the stuff about animation elements
... We don't have anyone committed with time to work on cleaning it up and moving it through the publication process. bburtles is the editor on record, but it probably isn't a priority

chris_: Are we publishing this for posterity, or do we expect implementations?

AmeliaBR: It's mostly implemented in multiple implementations (b/c SVG 1.1). But if we're saying SVG 2 replaces 1.1, except for this 1 chapter where 1.1 is the spec of record, then that's confusing. So let's make this a separate module so we can mark 1.1 obsolete

krit: I chatted with bburtles, he said he doesn't have time to spare for this
... This is concerning. I'm not sure if he just wanted to publish FPWD just so we could save the split off to SVG 2
... Do we have concrete plans to move it to REQ?

AmeliaBR: That's dependent on people available to work on it
... As far as the things that are additions to 1.1, if there are implementor interest in doing that

krit: In the long term, we woul dneed to identify additions to 1.1, and see how to put that onto the standards track. We need editorship, too.
... I'll talk to bburtles
... Any volunteers to help?

AmeliaBR: I could, but I have other commitments too. It's low priority than cleaning up SVG 2.

krit: Fair.
... So can we add you as editor?

AmeliaBR: Sure!
... On the chartering status, we can't publish until we're in charter. This counts still in the statement of the charter that pieces that might be taken out of main SVG 2 still being in scope if we publish them as separate modules

chris_: Yes, it would

krit: We have broad implementation support.
... So, I do not expect pushback from browser vendors, as long as we cover what's in implementations

AmeliaBR: The majority of this spec already has 2 implementations. There are some other features that need more testing.

krit: I'm fine with leaving them in FPWD. It's good for visibility, esp. for implementors. No objection.
... we just eventually need an editor.
... Any objections to publish as FPWD once we are rechartered?

<silence>

RESOLUTION: Publish this animation spec as a separate module once we get rechartered.

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

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

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

krit: As AmeliaBR pointed out, we introduced "fr" attribute. It's a focal radius. If you don't know what that means, radial gradients consist of 2 circles. The starting circle and the end circle, and interpolate between. The focal radius is a generalization of the focal point (whcih is a focal radius of 0). What happens if we have an fr and a normal radius being 0, and cx, cy, fx, fy, are on top of the radius for focal and normal radius?
... There's an example in the issue.
... You see a yellow box and a blue box. Yellow uses SVG. You have a radial gradient. Both distances are 0. The focal distance is placed on top, which is 0. Which color should the rectangle with teh radius get filled with? Should it be yellow? Should it not have a color and the blue shines through from below?

AmeliaBR: There's no way in the spec that it should be transparent because radial gradient is always padded, no matter what other attributes, so it always should be padded with one of the stops. So Chrome / WebKit is treating the radial gradient as an error, in which case it should be orange, or they pad it with yellow. I haven't gone into the details ...
... That's the one weird thing of the focal radius, it doesn't necessarily draw whereever, even when spreadMethod is padded?

krit: Yeah...

<chris_> Edge does the same as Firefox, fwiw

AmeliaBR: We don't have an example, it would be different from other SVG gradients
... We don't have a spread method that is "Stop drawing the gradient outside of the circle." Instead, it's just pad, reflect, or repeat.
... So that would be problematic.

krit: I thought the right answer would be yellow.
... But if you compare the canvas, you get blue.
... We tried to work on the focal radius to maek the canvas gradient as compatible with SVG gradient

Tavmjong: They can't agree.
... The limiting case if they're not quite on top of each other, you would expect to stop drawing otuside as soon as they overlap

krit: right.
... I get what you mean.
... We should explicitly point that out in the spec.
... There's a difference between canvas and SVG. SVG might not be able to be fully compatible, but pointing it out would help, maybe as an example. Doesn't have to be normative. Normative text already covers this.

Tavmjong: We already have a note about another difference between canvas and SVG. When the focal point is distanced by the right side of the circle. If you look in the spec, you'll see it in 14.2.3.2, the second green box
... "Notes on radial gradients"
... That deals with a focal point being on the circle

AmeliaBR: That's separate from talking about the focal radius being overlapping.
... Whatever happens, if there is an error, that we have clear error behavior, or if we use one stop or the other, we have clear behavior. But turning the gradient transparent isn't consistent with anything.

krit: That is the annotation. Annotation 3, I see this comment. I don't see it anywhere else.

AmeliaBR: Maybe that note should be promoted?

krit: I thought annotations were going to be in the spec but not visible

Tavmjong: yeah

<general confusion>

<AmeliaBR> Scribenick: AmeliaBR

Amelia: There are two notes. One mentions a change vs SVG 1.1 to conform with Canvas, the other mentions that there is still a difference compared to canvas (padding with solid color vs padding with transparent black) to keep consistency with SVG 1.1. But the question is whether normative text backs up those notes.

Dirk: Ok, I think we need to review again & comment on the issue, maybe come back next week.

github-bot, end topic

<scribe> Chair: krit

trackbot, end telcon

Summary of Action Items

Summary of Resolutions

  1. Republish the following specs as retired: Media Access Events (http://www.w3.org/TR/MediaAccessEvents/), SVG Filter Requirements ( http://www.w3.org/TR/SVGFilterReqs12/), SVG Parameters 1.0, Part 1: Primer ( http://www.w3.org/TR/SVGParamPrimer/), SVG Parameters 1.0, Part 2: Language ( http://www.w3.org/TR/SVGParam/)
  2. Redirect the following specs to CSS versions: SVG Filters 1.2, Part 2: Language:
  3. Republish SVG Integration ( http://www.w3.org/TR/svg-integration/ ) as a note with links to SVG 2 processing mode definitions
  4. SVG WG will meet at TPAC, probably Thursday, must not conflict with CSS
  5. Publish this animation spec as a separate module once we get rechartered.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/03/11 21:17:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/exitor/editor/
Succeeded: s/objectiong/objection/
Succeeded: s/15.2.3.2/14.2.3.2/
Succeeded: s/krit: RESOLVED: Publish this animation spec as a separate module once we get rechartered./RESOLVED: Publish this animation spec as a separate module once we get rechartered./
Default Present: TabAtkins, plh, AmeliaBR, Tavmjong, krit, chris
Present: AmeliaBR Tavmjong chris krit myles plh
Found ScribeNick: AmeliaBR
WARNING: No scribe lines found matching ScribeNick pattern: <AmeliaBR> ...
Found ScribeNick: myles
Found ScribeNick: AmeliaBR
Found ScribeNick: myles
Found ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR, myles
Scribes: AmeliaBR, myles
ScribeNicks: AmeliaBR, myles
Found Date: 11 Mar 2019
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]