SVG Working Group Teleconference -- 09 Nov 2017

Introductions

<ericwilligers> Eric Willigers., Google Chrome style team, Sydney

<ericwilligers> ericwilligers@google.com

Chris Lilley, W3C, alternate staff contact for SVG WG, also CSS, WebAudio, WebFonts, W3C Core Strategy

<BogdanBrinza> Bogdan Brinza, Microsoft

<liam> Liam Quin, W3C, staff contact, also verifiable claims, Improving Web Advertising

<liam> liam@w3.org

<IanPouncey> Ian Pouncey, The Paciello Group. UK. APA, CSS a11y TF co-facilitator.

SVG AAM

RESOLUTION: Ian Pouncey to be SVG AAM editor

<BogdanBrinza> https://www.w3.org/TR/svg-aam-1.0/

https://w3c.github.io/aria/svg-aam/svg-aam.html

<BogdanBrinza> For reference the test results: https://w3c.github.io/test-results/core-aam/

bogdan: we found some issues in this document about the use element. rest looks in good shape and very implementable

<scribe> scribenick: Chris

<BogdanBrinza> Bogdan will reach out to Microsoft test team to see if they can help with testable statements

<BogdanBrinza> Good morning Amelia!

<BogdanBrinza> Give us a second we'll try to set the dial in

meanwhile could you drop a link to the github repo for svg-aam?

<BogdanBrinza> https://github.com/w3c/aria/tree/master/svg-aam?

<AmeliaBR> yes, that's it.

<BogdanBrinza> along with https://github.com/w3c/aria/tree/master/graphics-aam

<AmeliaBR> (I think, the ARIA folks were trying to split up the repo)

<AmeliaBR> The Graphics-AAM is the one that needs the most work, because that's where the actual mapping to OS accessibility APIs is defined. Republishing SVG-AAM is waiting on it.

Ian now has write access to the AAM repo

<liam> AmeliaBR: 2 versions of svg-aam; ED has additional changes

<liam> ... related to use elements & shadow dom, and a new graphic-specific role

<liam> svg aam refers to other specs for defs of actual roles

<liam> need graphics aam for def of where the aria roles map to

<liam> so need that before we can test

tink, we need to help get Graphics Accessibility API Mappings moving forward. Any ideas on who in ARIA WG could help with that? It is blocking SVG-AAM

bogdan; reach out to platform maintainers for HTML AAM

<tink> Chris my suggestion would be to wrap the Graphics module roles into the SVG AAM.

<tink> Chris but there is a dependancy on the Graphics module I think.

<tink> Chris I can talk to the ARIA WG tomorrow if helpful?

yes!

<tink> Wilco

<smfr> is there an agenda for today’s discussion?

<BogdanBrinza> smfr we don't have published agenda - we're covering topics discussed in the mail

SVG2

<AmeliaBR> smfr: approximate agenda here: https://lists.w3.org/Archives/Public/public-svg-wg/2017OctDec/0018.html

we need to assume svg 1.1 when testing. we can easily do tests for xlink:href vs bare href for example

<AmeliaBR> +1 to what Liam is saying. There are lots of little differences, separate from the big new features. The issue with testing SVG 2, is how thoroughly do you want to test. There are so many little details that weren't covered in the SVG 1.1 test suite, which only looked at "does this feature exist" and not "is it implemented interoperably in all edge cases".

https://svgwg.org/svg2-draft/changes.html

bogdan: this is a todo list for testing
... if impls pass, keep it else push to later version or another module

<AmeliaBR> How should we handle things that were in SVG 1.1, but don't have two interoperable implementations? Make them officially "undefined for now"? Make them SHOULD instead of MUST?

https://github.com/w3c/web-platform-tests/tree/master/svg/import

liam: porting that does not help with keep/drop of svg2 features

RESOLUTION: Things that were in SVG 1.1 but don't have two interoperable implementations should be specified as SHOULD instead of MUST

<AmeliaBR> https://svgwg.org/svg2-draft/Overview.html long list of editors, most of which should be made former editors

I suggest we take a chapter each and a) check the edits were not subsumed by later edits and b) make some basic reftests for that chapter

<scribe> ACTION: chris to make svg2 color tests

<trackbot> 'chris' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., chris, ChrisLittle).

<scribe> ACTION: chris lilley to make svg2 color tests

<trackbot> 'chris' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., chris, ChrisLittle).

<scribe> ACTION: clilley to make svg2 color tests

<trackbot> Error finding 'clilley'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: chrisl to make svg2 color tests

<trackbot> Error creating an ACTION: could not connect to Tracker. Please mail <sysreq@w3.org> with details about what happened.

<AmeliaBR> For new features, there are a few big items where we know that the browsers haven't started work, e.g. mesh gradients, hatches, z-index.

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

<AmeliaBR> But then there are many features where implementers have started work, but they might not yet be stable and interoperable, e.g. use element changes, new marker rules.

<BogdanBrinza> thank you Amelia

<smfr> https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=is%3Aopen%20label%3Acss-transforms-1%20label%3Asvg

<smfr> https://github.com/w3c/csswg-drafts/issues/358

Transforms

<smfr> github: https://github.com/w3c/csswg-drafts/issues/358

<krit> Is there any implementation that supports transform on the listed elements?

<AmeliaBR> This isn't changing anything with respect to current implementations.

<krit> > The elements that must be included are:

<krit> If no implementation supports them then they don't

<AmeliaBR> Problem is current definition is based on whether or not an element has a particular attribute in SVG 1.1. In SVG 2, that attribute has been converted into the transform style property, which can theoretically be added to any element, but which won't necessarily have an effect.

prefer to avoid element whitelists

<krit> Ok, does SVG2 specify a list of "transformable elements" that the spec can link to?

<krit> Otherwise, we need to list all elements in CSS Transforms or element groups if possible.

<smfr> https://github.com/w3c/csswg-drafts/issues/919

krit, I don't want whitelists. they go out of date

<smfr> https://drafts.csswg.org/css-transforms/

<krit> Chris: understandable, but <tspan> currently is not transfomable and that needs to be specified. Same for many other elements.

<smfr> https://drafts.csswg.org/css-transforms/#svg-transform

<AmeliaBR> krit: SVG 2 defines "renderable elements", so you can link to that, and the text section will define the exceptions. SVG 2 should also define "paint server elements"; if there isn't a link-able definition, it should be added.

<AmeliaBR> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes

Any element in the SVG namespace; however, for historical reasons the ‘linearGradient’ and ‘radialGradient’ elements use the attribute name ‘gradientTransform’, and the ‘pattern’ element uses ‘patternTransform’.

AmeliaBR: it is a mapping to the style property. but impls do not do that

<krit> Actually, I am not sure about that. It might be that I implemented it in Safari

<krit> (not sure if I ever submitted the patch though)

smfr: we have overlap between transforms-1 and svg2, somaybe transforms should reference svg2 for details

<AmeliaBR> https://drafts.csswg.org/css-transforms/#svg-gradient-transform-pattern-transform

BogdanBrinza: should we be concerned with historical, legacy stuff? Unblock by linking to svg2, no additional work on transform side

<smfr> https://drafts.csswg.org/css-transforms/#svg-user-coordinate-space

AmeliaBR: patternUnits = "userSpaceOnUse | objectBoundingBox" patternContentUnits = "userSpaceOnUse | objectBoundingBox"

<smfr> https://github.com/w3c/csswg-drafts/issues/893

<AmeliaBR> The transform for pattern and mask should apply in the "content" coordinate system.

https://www.w3.org/TR/SVG/pservers.html#PatternElementPatternUnitsAttribute

<smfr> krit: do you remember what this para is supposed to mean: “In particular the patternUnits, gradientUnits and maskUnits attributes don’t affect the user coordinate system used for transformations [SVG11].”

<krit> hm

<krit> well, they are implicit transforms as the issue says

<krit> so wording probably should be updated

<smfr> to say what?

<krit> I need to check. You could give me an action

<smfr> no ACTIONs!

<smfr> please comment on the github

<krit> assign the issue to me :P

<smfr> https://github.com/w3c/csswg-drafts/issues/999

<smfr> https://drafts.csswg.org/css-transforms-1/#transform-box

<krit> transforms apply on coordinate origin in SVG

<krit> not the bounding box of the object.

<krit> Sorry, the origin is on the viewport origin

<AmeliaBR> Most of this issue was resolved previously, the only open question is whether/how to define `stroke-box`, I think.

<krit> Isn't stroke-xbox defined yb CSS Masking?

<krit> https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box

<krit> (Maybe should move to SVG2)

<smfr> https://github.com/w3c/csswg-drafts/issues/892

<krit> relative to the transform-box, no?

<smfr> AmeliaBR: can you hear the phone?

https://github.com/w3c/csswg-drafts/issues/892

<AmeliaBR> Using the scaling box as the transform-box for graphical effects makes sense, but it needs to be clearly specified which scaling box for patterns & masks.

<krit> +1

<AmeliaBR> I would recommend patternUnits and maskUnits, and then to transform the contents as if it was child elements of that layout box (this is consistent with how it works for patterns currently.)

<AmeliaBR> This would of course need to tie in with #893

<smfr> is “scaling box” defined?

<AmeliaBR> no, I don't think there's a consistent term in the SVG specs. objectBoundingBox or userSpaceOnUse

<AmeliaBR> More discussion of the current lack of interop here: https://github.com/w3c/svgwg/issues/293

<smfr> https://github.com/w3c/csswg-drafts/issues/894

<AmeliaBR> I think everything has been resolved. The root SVG is a CSS layout box, and behaves as such for transforms.

<krit> AmeliaBR: even on standalone SVG files?

<AmeliaBR> Yes.

<AmeliaBR> It's consistent with other aspects of browser implementations, e.g., you can have background, margins, borders, on a root svg in a standalone file.

<smfr> https://github.com/w3c/csswg-drafts/issues/932

<smfr> krit: you may want to comment here

<smfr> https://lists.w3.org/Archives/Public/www-svg/2012May/0088.html

<smfr> https://drafts.csswg.org/css-transforms-1/#neutral-element

<krit> Sorry, too long ago and can't get my head around it right now.

<krit> IIRC this text was added after a suggestion from the WebAnimation authors

https://github.com/w3c/csswg-drafts/issues/932

<AlexD> The example 6 seems to indicate these are synthesized elements, not neutral.

<AmeliaBR> I think the example in this section is new, and it definitely helps explain the purpose, but not entirely. If this section is specifically about SMIL animation, it should say that. Different from the identity transform for transitions.

<AlexD> The example describes a rectangle starting at 0 size, animating to scale(1) at 5s so these don't appear to be no-op elements in the animation.

<AmeliaBR> I'm still not sure *why* you'd want to start from scale(0) by default, but maybe this was to match existing implementations?

<krit> It is not just for SMIL IIRC. Again, the WebAnimation authors requested the definition of neutral elements

<AmeliaBR> Because, if I took an untransformed element, and told it to animate an increase in scale by 1, I would expect it to animate from the default scale to scale(2).

<krit> Brian Birtles is probably the best person to ask for the context

<AmeliaBR> +1 to defering to @birtles

<BogdanBrinza> we're back from the break

Testing

<liam> [projects https://github.com/w3c/web-platform-tests/]

<krit> For reference testing I'd like to suggest that reference files should be SVG files as often as possible. Only if there is no other way than falling back to HTML should the reference file not be SVG. How do companies contribute tests?

<krit> (In a folder with company?)

<liam> snedders: we have some DOM interfaces and manual 1.1 tests.

<krit> Reason for a SHOULD on SVG reference files are SVG content creation tools that might not support HTML but want to run the official test suite as well.

<BogdanBrinza> https://svgwg.org/svg2-draft/changes.html#typeshttps://svgwg.org/svg2-draft/changes.html#typeshttps://svgwg.org/svg2-draft/changes.html#types

<BogdanBrinza> https://svgwg.org/svg2-draft/changes.html#types

<liam> snedders: yes, can use SVG.

yes, making html equivalents is a non-starter in general

<Tav> html doesn't work for us (Inkscape)

the reference in a reftest should be the (interoperable subset of) svg 1.1

not raster images though, preferable

<krit> yeah, if any possible only reference tests w/o raster graphics until the feature is getting tested and JS tests

<liam> so, use SVG, ref use interop subset of svg 1.1 for ref as much as possible

RESOLUTION: use interoperable subset of svg 1.1 for test references

<liam> 2 types of test...

<liam> one kind that uses JS and asserts things

<liam> other kind is ref tests

<liam> (some other kinds don't get run automatically)

<gsnedders> http://web-platform-tests.org/

<Tav> How do we merge tests? Who can do it?

<krit> The link doesn't say how companies/persons can contribute tests without name collisions on submitting? That would be interesting for automatically uploading latest revisions of internal tests.

you send a PR and get someone to review it

unless there is upstream review

<krit> Any rules on subfolders?

try to use sensible filenames with numbers, like feature-0001.svg

avoid folders with hundreds of tests. use folders with chapter *names*

<Tav> There is a README in the svg folder.

<liam> [Chris proposes using rel="help" links to the SVG draft]

<krit> you mean https://github.com/w3c/web-platform-tests/blob/master/svg/README.md?

<Tav> yes

<liam> snedders: that relies on the CSS build system, which adds lots of other requirements

<liam> ... wpt-report tool is widely used to make implementation reports, but it doesn't do so much to help show test coverage of the spec

<Tav> We decided on a format with rel="help" a long, long time ago...

<liam> The css build system moves lots of files around

<krit> We use the test schema suggested by Cameron at Adobe. See example here: https://raw.githubusercontent.com/w3c/web-platform-tests/master/svg/shapes/rect-01.svg

yes, I am arguing in favour of that scheme, especially the rel=help part

<Tav> That is close to what we decided...

<Tav> +1 for using that.

bogdan: we can use the changes section for what to link to

<liam> snedders: note also, rel="author" not needed in that example, but OK.

agreed, rel=author not needed in a version control system

<krit> Will there be a meeting tomorrow? Getting late for me too for today.

<krit> Chris: tests can be exported

<liam> [we don't have a room allocated tomorrow]

RESOLUTION: (continue) use the proposed schema, specifically rel=help

<AmeliaBR> Is there a way to accept tests but label them as "needs metadata"? Or to go back to an earlier discussion, "needs standalone SVG version"?

ericwilligers: author useful for statistic analysis of contributors

amelia, yes we can do that

<krit> and copyright purposes... evethough the W3C license must be used

<gsnedders> what I said before about authors is that we already have it in git in the author field

<gsnedders> https://github.com/w3c/wptreport is the tool I mentioned for IRs before

liam: propose weekly meetings with agenda 2 working days in advance, starting after US thanksgiving

<krit> gsnedders: not sure if I follow, but an author might be different from the submitter

<gsnedders> krit: git has both author and committer fields

<liam> so, next/first telecon would be 30th nov

RESOLUTION: first telcon Thursday 30 Nov

<gsnedders> krit: and they don't need to be the same person; you can set a author using `git commit --author='Foo Bar <foo@example.com>'

<krit> I'll take a look at the tool

<krit> gsnedders: even when submitting multiple tests at once from multiple authors?

<liam> krit - how often does that happen?

<liam> if very rare, could split into multiple commits?

<krit> liam: I am thinking about automated submits once in a while

suggest using Agenda+ label like CSS does

making some tests

<gsnedders> krit: from where?

<krit> company internal test suites/bots

<liam> with continuous integration & two-way sync?

<krit> liam: Speaking for Adobe, we are currently in the process of reviewing test submissions. The current thinking about contributions is in an unidirectional way. Automated by bots. Haven't thought about bi-directional

OK so chapter is https://svgwg.org/svg2-draft/embedded.html

<liam> ok. there was a presentation about two-way sync here yesterday in the plenary day, the slides are probably linked from the tpac page

https://svgwg.org/svg2-draft/linking.html#linkRefAttrs

<gsnedders> krit: so what Mozilla and Chrome do is one commit in wpt for each commit in their own VCS system, which makes it easy to preserve authorship. regardless, I think one person from Adobe submitting all of them should be fine from an IP POV given they are likely all authored from an IP POV by Adobe and not the individuals

<krit> probably

(discussion on relative vs absolute urls for images and suchlike)

<krit> absolute? With http or absolute from a certain root folder?

<AlexD> krit: discussion was with http

<krit> hm, at least for Adobe we would like to run tests locally w/o internet access

<AlexD> Yes, Liam pointed that out

<AlexD> Relative is preferred due to that use case

https://github.com/w3c/svgwg

Huh, I see https://github.com/w3c/web-platform-tests/blob/master/svg/linking/reftests/href-image-element.html

<gsnedders> https://wpt.fyi/svg/linking/reftests/href-image-element.html

myles: dean is working on the bare href bug. (safari only does that on the a element)

<BogdanBrinza> taking a break for lunch

<AlexD> Lunch break

<BogdanBrinza> we're restarting after the break

<liam> [agenda for this afternoon is people going through changes since last CR doc & creating tests]

<Rossen> I'll be joining you in 15mins as well.

<Rossen> For now on irc only

<gsnedders> ericwilligers: dom/nodes/Element-lastElementChild-svg.svg

<gsnedders> https://svgwg.org/svg2-draft/struct.html#UnknownElement

<gsnedders> "Unknown elements are all elements that are in the SVG namespace that are not defined by this specification or any SVG module. The SVGUnknownElement interface must be used for unknown elements."

<gsnedders> see http://web-platform-tests.org/writing-tests/testharness-api.html#list-of-assertions for asserts

<gsnedders> (or /resources/testharness.js directly)

<ericwilligers> pull request: https://github.com/w3c/web-platform-tests/pull/8135

<gsnedders> as an aside, can people who are likely to want to review tests add themselves to https://github.com/w3c/web-platform-tests/blob/master/svg/OWNERS?

<BogdanBrinza> https://github.com/w3c/svgwg/commit/371089affee27a18a30d6a00a9226316fb784683

<BogdanBrinza> that added links to the tests and results for the Linking chapter, individual tests and an issue to convert existing html tests to svg

<BogdanBrinza> gsnedders: https://github.com/w3c/web-platform-tests/pull/8136

<liam> [ svg wiki - https://www.w3.org/Graphics/SVG/WG/wiki/Main_Page]

<gsnedders> can someone from SVG look at https://github.com/w3c/web-platform-tests/pull/8137 and make sure I'm not going crazy?

<BogdanBrinza> a bit of history - this is why I'd rather not do a separate wiki: https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

<liam> i was thinking of a list of the lines from the change history and people would put their name next to it, but equally happy with change.html in the svg spec

RESOLUTION: use changes.html file to track people working on chapters and/or line items

<gsnedders> ericwilligers: I just added one more comment, FYI