SVG Working Group Teleconference -- 29 Jan 2018

Clarify patternTransform/linearTransform

<Chris__> https://github.com/w3c/svgwg/pull/378

<Chris__> scribenick: Chris__

krit: CS transform spec introduces transform property.
... has a presentation transform attribute
... problem is with pattern and gradients. did not clarify where these can be specified
... and order of application

<AmeliaBR> github: https://github.com/w3c/svgwg/pull/378

krit: blink allow on pattern element, onlt

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

krit: similarly on gradient, but not transform attribute. Much like svg 1.1
... so these are all for the same transform property

Chris__, so these are aliases to the same property

krit: so content model does not change wrt SVG 1.1

AmeliaBR, that is what we wanted for SVG2 anyway, this is an editoral clarification?

krit: no, currently they are all allowed everywhere. want to rever to 1.1 behaviour

AmeliaBR, ok

krit: if they are both on the same element then we need to establish order

AmeliaBR, we had a couple different places related to presentation attribues

krit: the PR specifies this

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

AmeliaBR, not as clear as it should be

krit: is the PR okay?

AmeliaBR, we need to update the changelog too

RESOLUTION: explanation from Dirk looks good, accept

<krit> scribenick: krit

Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript

<Chris__> github: https://github.com/w3c/svgwg/issues/291

AmeliaBR: we have interfaces that are defined as NoInterfaceObject but other object types which implement these infterfaces which have those properties on them
... so you could access those constants but not as a static item
... usually constants are property of a class
... need to recall. it is from 2016

krit: those are mixing and get implemented by those classes. So they actually are part of those classes implementing them.
... not sure where the issue is?

AmeliaBR: those are legacy features and not used on the web. Keep them close to SVG 1.1
... not sure what is required.

krit: are those interfaces implemented already?
... we were asked to re-add interfaces not because they are used but because they are implemented widely

<AmeliaBR> Here's the last update on implementation https://github.com/w3c/svgwg/issues/291#issuecomment-254204205

Chris__: so we have interfaces that are not used but implemented.
... seems like some ppl argue it shouldn't be exposed.

<AmeliaBR> SVGUnitTypes was implemented, and was re-introduced to the spec. SVGZoomAndPan wasn't well implemented cross-browser, and that's whay it wasn't changed at the time.

Chris__: Firefox seems to expose and implement it directly and does seem to have tests

AmeliaBR: there are 2 different causes.
... for SVGZoomAndPan, no decision has been made and issue was reopened. Not implemented browsers anyways.

krit: they are not implemented? because I think they are.

<Chris__> https://bugzilla.mozilla.org/show_bug.cgi?id=1241898

Chris__: original comment was about aligning implementations so we have 2 implementations, Blink and Firefox

ericwilligers: we could still remove those interfaces if they are not used

Chris__: yes we could
... not sure what is proposed is better

AmeliaBR: I don't think we are getting anywhere on this on the call. We should ping ppl if this is still an issue or if they are happy with changes that were made.

Chris__: agree. Will post on the issue and ask for comments.

<Chris__> github: https://github.com/w3c/svgwg/issues/269

establish SVG 2 test suite

GitHub: https://github.com/w3c/svgwg/issues/269

<Chris__> github: https://github.com/w3c/svgwg/issues/269

Chris__: very old issue. And we have a test suite

<Chris__> https://raw.githubusercontent.com/w3c/web-platform-tests/master/svg/shapes/rect-01.svg

krit: Liam wanted us to clarify that we indeed have a test suite and that we also have guidelines

Chris__: has examples and assets that can be used. All similar like for CSS WG test suite.
... also, Peter Lins test tools can create test results. Need to check if we can reuse.

liam: put it on the agenda... came up for Agenda+... ppl look for tests likely find this issue.

<Chris__> https://github.com/w3c/svgwg/wiki/Testing

AmeliaBR: we need to do more what we want the web platform tests look like and add requirements for review and approval
... we all agreed on WPT framework

Chris__: we should get come down to what we are actually using.

AmeliaBR: we need to look at secure vs interactive environment. Need to design how we structure the tests for that.

Chris__: we need a set of tests SVG referencing SVG tests and also HTML based reference tests

AmeliaBR: we have the core SVG markup tests but want to easily test on inlining the markup also.
... what happens if you reference SVG as object or as image and so on.
... we do have a few open PRs that need to get reviewed.
... should we keep the issue open until we are done or close it because we have the test suite.

Chris__: I think we should keep the issue open because we do not have a central place for how to write and run tests.

AmeliaBR: Think Nico wants this to be a meta-issue for references
... but we can take Agenda+ off

<Chris__> https://github.com/w3c/web-platform-tests/pull/4015

AmeliaBR: discussions about inconsistencies on writing tests on the linked PR.

<Chris__> https://reviewable.io/reviews/w3c/web-platform-tests/4015

krit: should those tests reference masking spec?

Chris__: how much of masking is still in SVG2?

krit: should all be part of CSS Masking

Chris__: we should also keep tests for SVG as well.

<BogdanBrinza> I'm late - just joined

AmeliaBR: we have a page with properties that are defined by other specs. We should have sVG specific tests for those properties.

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

krit: I would just like to add that a test can reference multiple specs. So those property tests should reference the spec defining them + SVG.

Chris__: we seem to make progress.

virtual f2f

liam: we should have a virtual f2f around March

Chris__: I think this is a good idea. Be online on IRC and call in as needed.
... we did this before. Nice to have one time where everyone is online.
... for some it is easier to set up a block of time. So I am in favour for that

AmeliaBR: it is probably useful once we write tests and look at problems.
... and come up with a good set of guidelines. Do we need more than a one-hour discussion?
... Liam already mentioned going over each chapter

Chris__: that would be more than an hour

liam: we have to republish our CR with things that are on risk. We have to identify those things. We should have this done soon.
... we need to move on

ericwilligers: should we check pre-releases as well or just stable releases?

Chris__: I am comfortable with running tests on nighties

AmeliaBR: we should not only look at current implementations. We should look at future plans as well before deciding if something is on risk.

BogdanBrinza: we should have a rule that at least one implementation should be a browser.
... and we agreed on this before

Chris__: we should still be able to look at future plans of browsers and not limit to stable versions

BogdanBrinza: agree. but not just focus on browsers or just authoring tools

ericwilligers: how can we tell if something is implemented in Illustrator or InkScape

Tav: I can tell you about InkScape

Chris__: there is a way for InkScape to run reference tests from the console. More work than on browsers but still possible.

krit: Illustrator does support ref-tests in the lab but not necessarily WPT directly.

AmeliaBR: depends if the tests are standalone tests. If they are someone can download the folder of tests and compare the rendered version.
... virtual f2f difficult with timezones. But early morning PDT and wraps up midnight CET should work.
... we need a clear idea what we want to accomplish in advance.

Chris__: agree.

ericwilligerswe could do one chapter per week in a 30min block

Chris__: Tav: having an agenda would help

ericwilligers: we could look at extensibility

<ericwilligers> extensibility and paths have tests

AmeliaBR: we could take one chapter next week and see how much time it takes to go thorough for better planning

<ericwilligers> tests for all changes

Chris__: which chapters did you do?

ericwilligers: ---^

Chris__: tests are where?

ericwilligers: WPT

<ericwilligers> https://wpt.fyi/svg/extensibility and https://wpt.fyi/svg/paths

<ericwilligers> https://wpt.fyi/svg/path

Chris__: we should start with the weekly once and see how it goes before setting up f2f

BogdanBrinza: should we set up a 30min block in general for spec review?

AmeliaBR: yes, and see how it goes

krit: to summarise: start with 30min blocks and setup virtual f2f only when needed

fxtf issues

[filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes

GitHub: https://github.com/w3c/fxtf-drafts/issues?utf8=✓&q=is%3Aopen+label%3A%22Needs+SVGWG+Input%2FDecision%22++label%3AAgenda%2B
... https://github.com/w3c/fxtf-drafts/issues/160

krit: I'd like to make an actual filter tree out of scope for filter effects 1 if we are even do it at all

Chris__: agree

Tav: I don't see how to reuse filter primiteves a couple of times.

Chris__: put a label filter-effects-2 and go on

krit: fine with me

RESOLUTION: Defer proposal for a future version of the spec put filters 2 as label on issue.

Chris__: reminder to put Agenda+ on issues that shall eb on the agenda

- DRAFT -

SVG Working Group Teleconference

29 Jan 2018

Attendees

Contents

Clarify patternTransform/linearTransform

Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript

establish SVG 2 test suite

virtual f2f

fxtf issues

[filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes

end of meeting :)

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output