SVG Working Group Teleconference -- 03 Dec 2018

<chris> draft charter at https://w3c.github.io/charter-drafts/svg-2019.html

<scribe> scribe: AmeliaBR

New Charter

Chris: We have a new draft charter up. Only real question right now is whether to include an FXTF task force. It's not currently there & wasn't in the last one. Not sure if it should be.

PLH: One thing that we've been trying to avoid in the past few years is shared deliverables between working groups. E.g., the SVG-AAM used to be shared with ARIA. But if we wanted to make it that again, we'd need to have a discussion with AC reps.

Dirk: My main concern is for some of the FXTF specs where there is a lot of coordination required between updates in the spec. But others make sense to say as CSS WG.

PLH: There would need to be a strong argument to explain why these needs to be joint deliverables.

Dirk: One other issue is whether there are any people who would be working on the specs who aren't members of the CSS working group.

PLH: Then we would consider whether it is possible for that person to join the group.

Dirk: For example, Tav I think is not currently a member of CSS. Tav, would you be willing to join another group to keep working on some of those FXTF specs?

Tav: Sure, if I was invited. I want to keep working on the advanced Fill & Stroke.

PLH: We can definitely talk with the CSS chairs and make that happen.

Dirk: So, it sounds like we should keep the status quo, and CSS maintains full responsibility for the FXTF specs. Any other deliverables?

Chris: There's also the question of where to discuss new SVG features. Could be within Web Incubation, but there's a lot happening there, it could get lost. We could maybe have one SVG community group that discusses new proposals, and when they have traction bring them back to the main working group.

Dirk: Or would it be better to have distinct community groups for each new proposal? That way, it's clear how much support there is for that specific proposal.

Chris: Presence of a group is not a guarantee of active support or work. It's a lot of overhead.

Dirk: Myles, you'd talked about "SVG Native" as a stripped down spec. Would you want a community group for that?

Myles: Having a community group just for that might be too much. People who'd be working on that would overlap with other issues.

Chris: I've already mentioned the SVG Native (working title) spec in the charter.

Tav: What's this?

Myles: It's a stripped down profile of SVG that could be implemented in more limited, performant way.

Chris: E.g., the subset of SVG being used in OpenType

Tav: Like SVG Tiny?

Chris: Yes, but with a different focus.

Dirk: Back to the idea of a community group. Any opinions?

Amelia: I like the idea of a single community group. If logical sub-groups develop later, we can deal with that then.

Tav: I like one group, too.

<chris> ok, I will put one CG in the charter but allow contributions from other places (WICG, other CGs, etc)

Dirk: We're technically out-of-charter as of the end of November. Do we need to extend (again) the last one, or should we focus on the new one.

PLH: I'm focused on getting a new charter that we can get approved. Right now, you can't publish, but that's not a big issue so long as the charter gets approved soon.

December teleconference schedule

Dirk: Are there meetings that we need to skip because of Christmas holidays?
... we probably want to cancel Dec 24 and 31. But is everyone available the next two weeks.
... and then come back on Jan 7.

(general agreement)

Implementation interest for vector-effects

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

Dirk: Last month, we decided to remove the at-risk flag, but a question was raised about what counts as an implementation
... there is a test implementation in Firefox, but it has not landed in master and they're not currently going to review or land it until there is stated implementer interest in other browsers.
... Myles, Eric, any knowledge of whether there is interest in WebKit or Blink?

Eric: Is this something that's requested by authors?

Chris: It is something that is liked by authors & was originally proposed based on author feedback.
... Would be better to more document those use cases. What do you really need?

Eric: We don't have strong opinions. I discussed with Frederick, he asked whether there was author demand.

Amelia: I think there's not strong author feedback because there aren't any existing implementations for authors to play with. Getting the polyfill polished and out in the wild might help provoke interest.

Myles: I don't see any work in WebKit. We only get comments about non-scaling-stroke. But we would look at it if there were other implementations.

Dirk: So, it sounds like everyone is waiting on everyone else. But at least, no one objects to it.

Chris: Have people tested the Firefox implementation?

Dirk: Well, right now it's just a patch. You'd need to download and compile it yourself before testing.

Amelia: So, for the spec: don't remove anything, but also don't remove the at-risk flag yet?

Dirk: I think so. But also we should file issues on browsers.

Chris: Yes, and user voice polls and such so authors can mark support.

RESOLUTION: Hold off on removing "at-risk" note re vector-effects

Dirk: I'll also follow up with the issues.

Amelia: I'd suggest that if anyone want to take another look at Satoru's polyfill, to see if there's anything that's needed to get it ready for real-world use. That would help get author interest.

Tav: I've implemented for Inkscape, although it is less useful for us.

At-risk status of new stroke-linejoin keywords

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

Chris: These really do have to be at-risk. They are new features, and we have no browser implementations.

Tav: There are implementations in Inkscape, using a modified version of Cairo. They are also recreated with our live path effects.

Dirk: You said you implemented with Cairo?

Tav: In a modified version. Not in the public library.
... we also have a similar thing in the path effects, which uses custom attributes that are then exported as standard SVG path. It's very popular among artists.

Dirk: Any objections to marking at-risk?

RESOLUTION: Mark new stroke-linejoin keywords as at risk.

Eric: Do we have any feedback from implementers? Is there any interest of implementing?

Myles: Same issue as before. Not a lot of feedback from authors yet. I don't think there are technical obstacles.

Chris: Again, I think we need more worked examples and education to get people excited about them.

Percentages for alpha values

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

Eric: This was added, but no one has implemented it. Only numbers are accepted.

Chris: The complication is that it isn't SVG-only. Also want to keep coordinated with the rest of CSS.

Dirk: We used to define the value in our own data type; now we reference the CSS type, but that includes the unimplemented value.

Eric: Can we follow up with implementers and see if they're interested in adding this?

Myles: I think we could implement it, but not a high priority.

Amelia: We're currently referencing a CSS-defined data type, correct? Can we do it in a way that defers to CSS to update the allowed values when the implementations are there?

Dirk: I don't think so. CSS Level 3 didn't have a single name for that.

Eric: It shouldn't be hard to implement.

Dirk: Then please do so in Blink, and we won't have to have as much discussion!
... Tav, what about Inkscape?

Tav: I'm currently looking up how hard it would be.

Amelia: My only opinion is that the allowed values should stay consistent with CSS for the opacity property. Whatever we need to do to make that happen.

Dirk: Could we make normative text that just refers to whatever is valid for the opacity property?

<ericwilligers> See https://drafts.fxtf.org/fill-stroke/#fill-opacity

Eric: Yes, that syntax exists. I think it's just `<opacity>` meaning, use the syntax for the opacity property.
... (pastes link above) that's what fill-opacity is defined as in Fill and Stroke module.

RESOLUTION: Define syntax of SVG `*-opacity` properties by reference to the `opacity` property

Tav: What's the status of the opacity spec?

Chris: It's in CSS Color. Parts of Color 4 are supported, but it's not expected to go to PR this year.

Amelia: But important detail is that `opacity` already exists, with the more limited syntax (number only).

Chris: Yes, so percentage support would hold up CSS Color advancing to rec, but not SVG.

Text content area at-risk status

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

Dirk: I think Inkscape is the only implementation. I thought there was some work in Firefox, but Cameron said there was no support for text within a shape.

<chris> Good to have content that uses it.

Amelia: Firefox supports hard line breaks and whitespace control, but not automatic wrapping in a shape.

Tav: Inkscape's next stable release will have this, so authors will be creating content with it. It's definitely very popular in demonstrations.

Dirk: I think everyone agrees it's a nice feature, but we need another implementation.

RESOLUTION: Mark at-risk all aspects of text layout with automatic wrapping (inline-size and text in a shape)

should textPath elements parented to tspans or other textPaths render?

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

Dirk: This issue discussion is bigger than the title, but let's focus on that specific question.
... based on browser testing, textPath that is a child of tspan is not rendered.
... so we'd need to change the content model of tspan to not include textPath. Also textPath could not have a textPath as a child.
... textPath would only be valid as a child of text

Amelia: Well, there are also link elements, which confuse up the content models.

Chris: Yes, that sort of pass-through content model is difficult to define.

Dirk: With that complication, do we agree on the change? Then we can figure out how to specify it.

Amelia: I agree that we should change the spec to match reality, even if that's not the most logical model.

RESOLUTION: textPath is invalid as a child of tspan or textPath

Amelia: And then we need some testing for the `a` element to see if it correctly behaves as a transparent content model.

<krit> Thanks AmeliaBR for scribing!

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

03 Dec 2018

Attendees

Contents