<AmeliaBR> Scribenick:AmeliaBR
<TabAtkins> krit: you sure there?
<chris_> see https://w3c.github.io/spec-dashboard/report.html#abandoned
<myles> ScribeNick: myles
<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.
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
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
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.
<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
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
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]