W3C

- DRAFT -

SVG Working Group Teleconference

14 May 2018

Attendees

Present
krit, BogdanBrinza, liam, Tavmjong, chris, dstorey, AmeliaBR
Regrets
Chair
BogdanBrinza
Scribe
AmeliaBR

Contents


<BogdanBrinza> We're giving everybody a bit more time to join the call

<scribe> Scribe: AmeliaBR

Responsibly accelerating our progress to move SVG 2.0 to REC

<chris> https://onedrive.live.com/view.aspx?cid=fd9e7123283f274c&page=view&resid=FD9E7123283F274C!594647&parId=FD9E7123283F274C!103&app=Excel

Bogdan: On previous calls we discussed the desire to make progress on moving to Rec.
... One of the big obstacles is tests, but also there a many things where we know there is no value in making tests yet, since we don't have implementations.
... But we also don't want to prevent future work on those features.
... So we landed on the idea of forking the spec. We have two branches.

One is dedicated to shipping SVG 2. The other is about preserving all the content we have in the spec.

scribe: The spreadsheet (link above) lists some of the new features, and whether they are supported in both browsers and non-browsers.
... You can see some features are not well implemented: Hatch, meshGradient, cursor element.
... I'd like to remove them from the shipping version.

Tav: I have two questions: 1) What is the future of the SVG Next spec? Is it sanctioned by W3C, charter?

Bogdan: There is no commitment. The charter is about shipping a stable SVG 2.

<BogdanBrinza> https://www.w3.org/2017/04/svg-2017.html

Liam: Our charter is about SVG 2, and that involves stripping features at risk. But once that's done, nothing prevents working on the other features.

Chris L: Exactly right.

Tav: 2) I understand that polyfills are acceptable as a browser implementation.

Bogdan: It's not the same.

Liam: They can be. Especially, as in the case we discussed, when there is a non-browser implementation.

Bogdan: I have been looking at the specs to see if there have been any changes to the spec from implementer feedback & I haven't seen that for these features.

Tav: But that's because they are stable.

Chris L: Most of the spec work was done years ago. But we're just waiting for implementations.

Bogdan: But in my experience, implementations tend to result in changes to the spec from experience. So it's not really stable until there are implementations.
... So this is why we want both browser and non-browser implementations.

<chris> Would be good to have links to the mesh polyfils

Tav: For the case of mesh gradients, I can say there is demand from authors. At least four polyfills being worked on.

Amelia: But are any of those stable & shipping & being used with content, or are they just proof of concept?

Tav: I don't know of use.

Bogdan: We're not seeing use in content we are counting usage of. But that's only open-web content.

Dirk: Speaking for Adobe, we wouldn't ship the markup unless we're confident there is at least one browser that can implement it.
... Polyfills aren't enough, because we're shipping SVGs for use in contexts that don't support dynamic scripting.

Tav: It becomes a chicken-and-egg problem, if authoring tools won't ship markup until browsers support it, but browsers won't support it until the content is out on the web.

Liam: It is clear that mesh gradient at least need to be marked at risk.

Dirk: They are already. But question is whether it's worth just removing them, and when.

Liam: They only *need* to be removed before Proposed Rec stage.

Dirk: But if we know they will be removed, don't want to waste time working on that section of the spec which could be spent on other parts.

Bogdan: To make the job easier to move the spec to Rec, for implementers and editors, I'd recommend focusing on a more lean spec.
... We're trying to balance removing features while also preserving the work that was done. I'd welcome any proposals on how to do that.

Chris L: I don't have a new proposal. I like the two specs. I also think we should do a FPWD of the new SVG 2.1, to formalize it.

Chris L: However, I think the Cursor element should just be removed, not deferred.

Amelia: Cursor is different from the others in the list. It's an old SVG 1 feature that is now deprecated, not a new feature that we hope will one day get implemented.

<liam> +1 to publish 2.1 FPWD with new CR

Bogdan: Yes, I think cursor can be just removed. Only Safari currently supports it, and HTML spec recommends against it in HTML docs.
... Can we make a decision on the overall strategy before we go through all the individual features?

Dirk: Does an SVG 2.1 draft satisfy your concerns, Tav?

Tav: I guess that is acceptable.

Bogdan: The SVG 2.1 is currently as svg-next branch in Github.
... with help from Cam, it's also available at https://svgwg.org/svg-next/

RESOLUTION: We'll focus on shipping SVG 2.0 by forking current master branch into two branches - master tracking SVG 2.0 and svg-next tracking next generation graphic technologies. SVG 2.0 will remove all features currently at risk and focus on testing and shipping inteoperable core of the specification as outlined in the charter

RESOLUTION: As we have an updated SVG 2.0 in master branch and publish an updated CR, we'll simultaneously publish FPWD of SVG 2.1 (tentative name) from svg-next branch to signal the group commitment to next generation graphical features

Amelia: To answer Chris's question about an updated CR for SVG 2, that might be premature. We haven't yet made the major edits we're talking about.

Chris L: OK, then maybe worth waiting.

Dirk: So is then SVG21 the short name?

Amelia: That's consistent with shortname for SVG11. And it'll be decades before anyone working on SVG Level 21 hates us.

Bogdan: If that covers all the publication details, lets talk about the specific features & what work is needed.

SVG Cursor element

Amelia: As discussed, this is a deprecated feature. Should we make it obsolete, so that implementations are not required.

Chris L: I agree. It's not desirable to continue to ask for implementations.

Dirk: I think it it was in Chrome before the fork. So Chrome must have removed it. Definitely in favour of removing.

Bogdan: I'm also in favour of removing.

Amelia: To slightly derail the conversation. This will be one of a number of obsolete elements from SVG 1. I think we may need to at least list them somewhere, for parsing purposes. E.g., HTML still recognizes these as valid SVG elements, even if they aren't implemented.

<chris> I agree with Amelia that this needs to be done

Amelia: Not against making it obsolete, just some clean-up work required.

Bogdan: Do we have a list of those elements?

Amelia: Not currently in the spec.

Bogdan: OK, so we'd need to compare with SVG 1 to see what has been removed.

Dirk: I wonder what Edge & other browsers currently do with these elements. Does the HTML parser already have special parsing rules for cursor element?

Amelia: That's a good question. Don't know the answer.

Bogdan: I know HTML spec says you shouldn't implement cursor, but I don't know beyond that.

Amelia: And there are other obsolete elements. Font-related elements, plus a few others.

https://oreillymedia.github.io/Using_SVG/guide/markup.html#obsolete

Dirk: Maybe best to discuss with the HTML editors, about what they think we should do.

Bogdan: I think we (Microsoft team) can take an action item to look into best ways forward.

Amelia: Can you make a GitHub issue to track it?

Bogdan: Will do.

Hatches & mesh gradients

Dirk: Should solid color also be included?

Chris L: Maybe not. It's less clear if it's still useful.

Amelia: For hatch & mesh gradient: Inkscape now implements both. Adobe has a compatible mesh gradient implementation, but doesn't yet support the markup, correct?

Dirk: Yes.

Chris L: And there are many other graphics libraries with compatible mesh gradient implementations in other graphic rendering libraries.

Tav: E.g., browser PDF rendering

Dirk: But that isn't necessarily running through the browser rendering engine.

Chris L: Both of these are very useful features. Hatches are very useful for technical graphics, mesh for artistic ones.

Amelia: So is it agreed these should be kept in 2.1, but removed from 2 because no browser implementations?

(various agreements, no objections)

Amelia: Who can make the edits?

David: I can.

Dirk: I would ask, for all of these, to try to be very isolated with your commits. Don't mix up removals with any changes. We want to be able to patch changes between the different branches later.

RESOLUTION: Remove mesh gradients and hatches from SVG 2.0, keep in 2.1

Solid Color element

Chris L: Historical context, this comes from the SVG 1.2 time. We noticed people making single-color gradients to reference one value many places & be able to reference it many places.

<krit> CSS properties can replace solidColor

<krit> CSS custom properties

scribe: Since then, we've clarified the single-color gradient behavior, and we've got CSS gradients, and CSS color image layers, and CSS variables. So I don't think that there's no need for it anymore.

Tav: I agree. We implemented it because of the single-color gradient usage. Fully implementing the CSS approach is more difficult, but that is something we're working on.

Amelia: Were there any other implementation, beyond Inkscape?

Tav: Batik.

<chris> list of supported elements and attributes in batik https://xmlgraphics.apache.org/batik/status.html

Amelia: Well, no harm if they continue to support an obsolete element. But less sure if they're going to implement CSS custom properties.

Dirk: I'm in favour of removing the element.

<chris> I don't see solid color in the batik list tw

Amelia: I'm also in favour of removing it, but maybe track it in the issue about obsolete elements.

<Tavmjong> That's a SVG 1.1 list. It's supported in their SVG 1.2 profile.

RESOLUTION: Remove <solidcolor> element and its solid-color / solid-opacity style properties from SVG 2 and 2.1

ElementInstance interface properties (as a mixin for SVGElement)

Amelia: This was the result of trying to maintain backwards compatibility while switching to the modern Shadow DOM model. But as every rendering engine has implemented things in slightly different ways, these properties aren't really supported anywhere currently.

Bogdan: We're over time. Can we continue this discussion next week?

trackbot, end telcon

Summary of Action Items

Summary of Resolutions

  1. We'll focus on shipping SVG 2.0 by forking current master branch into two branches - master tracking SVG 2.0 and svg-next tracking next generation graphic technologies. SVG 2.0 will remove all features currently at risk and focus on testing and shipping inteoperable core of the specification as outlined in the charter
  2. As we have an updated SVG 2.0 in master branch and publish an updated CR, we'll simultaneously publish FPWD of SVG 2.1 (tentative name) from svg-next branch to signal the group commitment to next generation graphical features
  3. Remove mesh gradients and hatches from SVG 2.0, keep in 2.1
  4. Remove <solidcolor> element and its solid-color / solid-opacity style properties from SVG 2 and 2.1
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/05/14 19:38:59 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/to have/to ask for/
Succeeded: s/was never even in Chrome/it was in Chrome before the fork. So Chrome must have removed it/
Default Present: krit, BogdanBrinza, liam, Tavmjong, chris, dstorey, AmeliaBR
Present: krit BogdanBrinza liam Tavmjong chris dstorey AmeliaBR
Found Scribe: AmeliaBR
Inferring ScribeNick: AmeliaBR
Found Date: 14 May 2018
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]