- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 Jul 2019 21:08:01 +0000
- To: public-svg-issues@w3.org
The SVG Working Group just discussed `[svg-native] Decide whether reusable graphical elements are needed`, and agreed to the following: * `RESOLUTION: Patterns are not part of SVG Native` * `RESOLUTION: Markers are not part of SVG Native` * `RESOLUTION: Symbol and nested SVG elements are not part of SVG Native` * `RESOLUTION: Allow use element in SVG Native` * `RESOLUTION: Support href on gradients referencing gradients` <details><summary>The full IRC log of that discussion</summary> <myles> Topic: [svg-native] Decide whether reusable graphical elements are needed<br> <myles> GitHub: https://github.com/w3c/svgwg/issues/689<br> <krit> ScribeNick: krit<br> <krit> sairus_: SVG OT spec does not support pattern, marker and symbol<br> <krit> sairus_: but not banned either<br> <krit> sairus_: The use element is specifically used as an example in the spec though<br> <krit> myles: We can probably support patterns<br> <krit> s/support/agree on/<br> <krit> myles: Apples implementation is the only implementation as far as I know that supports it and we didn't find any content that uses it. We can remove.<br> <krit> AmeliaBR: Depends on the use cases for SVG Native.<br> <krit> AmeliaBR: if the idea is that the files are individual icons or small things in general then Wouldn't expect anything of that to be in.<br> <krit> AmeliaBR: otherwise I would imagine that you want to reuse shapes to simulate shadows w/o rewriting the same shape.<br> <krit> AmeliaBR: for patterns there is even more<br> <krit> AmeliaBR: For patterns, every dot can add a lot of markup in comparison of using a pattern once.<br> <krit> AmeliaBR: making the SVG larger and less easy to work with it<br> <krit> myles: file size vs supported features is a trade of<br> <krit> myles: There is no content that does use patterns for fonts.<br> <krit> myles: and that makes sense since the files are so small<br> <krit> myles: there is a point for supporting it on the other hand: 1) there is no wide support for fonts and 2) there is a way to do visually the same w/o patterns<br> <krit> sairus_: There were discussions to add patterns to the OT table. IT would be a competitive advantage to support it in SVG Native.<br> <krit> myles: will all implementations update to do it?<br> <krit> sairus_: Patterns doesn't seem to be a minimal subset. Though SVG Native is not really "minimal".<br> <krit> AmeliaBR: Myles point is that it is easier to add features later.<br> <krit> myles: there is a CTPattern... an API to draw patterns in CT. The pattern space is different from the document coordinate space and it is tricky to match the 2 spaces and that part is not in the API<br> <myles> s/CTPattern/CGPattern/<br> <myles> s/CT./CG./<br> <krit> RESOLUTION: Patterns are not part of SVG Native<br> <krit> AmeliaBR: markers and symbols we were leaning to not support?<br> <krit> myles: A tool that generates SVG Native file would know the geometry for markers. So we can omit it. Not much markup anyway<br> <krit> myles: And as far as I know it does not have wide support in OT implementations<br> <krit> RESOLUTION: Markers are not part of SVG Native<br> <krit> myles: I think we have to support use. There is much content out it that uses it.<br> <krit> myles: Apple does not support symbol.<br> <krit> AmeliaBR: Symbol to me is very similar to nested SVG.<br> <krit> AmeliaBR: as it affects coordinate system and internal coordinate system. They should be treated the same. So I would say no symbol either. But there definitely are use cases for symbol.<br> <krit> myles: symbol doesn't let you do what you can't do otherwise.<br> <krit> AmeliaBR: It allows creating a new SVG viewport<br> <krit> AmeliaBR: that is why it is similar to nested SVG.<br> <krit> krit: I would be ok with removing.<br> <krit> AmeliaBR: use is still useful w/o symbol.<br> <krit> RESOLUTION: Symbol and nested SVG elements are not part of SVG Native<br> <krit> RESOLUTION: Allow use element in SVG Native<br> <krit> myles: gradients sharing color stops?<br> <krit> myles: we support it in our implementations.<br> <krit> AmeliaBR: used a lot in Adobes SVG export.<br> <krit> AmeliaBR: Ai ends up with using lot of gradients but all sharing the same color stops.<br> <krit> AmeliaBR: shouldn't be a large implementation addition.<br> <krit> krit: inheritance and currentColor might be the biggest issue but that applies to everything<br> <krit> myles: don't think anyone considered it<br> <krit> myles: IMO if SVG OT doesn't mention something it is supported since it is SVG 1.1 minus stuff<br> <krit> AmeliaBR: It would be useful for fonts to define stops once and use it at different glyphs<br> <krit> myles: does Adobe's OSS implementation support it?<br> <krit> krit: it does.<br> <AmeliaBR> s/at different/at different positions for different/<br> <krit> RESOLUTION: Support href on gradients referencing gradients<br> <krit> trackbot, end telcon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/svgwg/issues/689#issuecomment-511570536 using your GitHub account
Received on Monday, 15 July 2019 21:08:04 UTC