SVG Working Group Teleconference -- 04 Aug 2016

Char: Nikos

<scribe> Scribe: Nikos

<scribe> scribenick: nikos

SVG 2 CR publication update

shepazu: I've mostly done my bit. Need to do some work to merge onto the correct branch. Will try to do it tonight.

nikos: I need to do disposition of comments and request review from i18n and a11y. I'm preparing a list of new features and breaking changes that is a bit more friendly than the changes appendix. I'll hopefully get that done today.

Once we have that we can request transition approval from the W3C

https://github.com/w3c/svgwg/wiki/SVG-2-new-features

https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes

shepazu: Nikos and I were talking earlier in the week about making a list of changes between SVG 1.1 and SVG 2 - so people can decide and evaluate what sort of review they are going to try to do

Self review - security and privacy questionnaire

https://www.w3.org/TR/security-privacy-questionnaire/

fill and stroke shorthand

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

<TabAtkins> Verifying as fantasai and I pull in SVG's fill and stroke stuff - fill-rule doesn't actually apply to text in any way, right? I'm not seeing it with any effect, and it seems silly for it to, as the segment directions are undefined.

<TabAtkins> Oh, hmm, should fantasai and I call in for this?

<TabAtkins> Because we are working on this *literally at this moment*.

most of us have only just seen the issue

if you want to jump in you're welcome

<AmeliaBR> TabAtkins: Re fill-rule, yes we explicitly state it doesn't apply here https://svgwg.org/svg2-draft/text.html#TextRenderingOrder

<TabAtkins> Okay, the 'fill-rule' property still states that it applies to text elements, so I was verifying.

<TabAtkins> We're in now

<shepazu> https://github.com/w3c/svgwg/issues/230

<fantasai> https://lists.w3.org/Archives/Public/www-style/2013Jun/0678.html

<fantasai> https://lists.w3.org/Archives/Public/www-style/2014Feb/0609.html

<fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0358.html

TabAtkins: Elika and I are writing this spec right now and our intention is to pull in everything svg needs so it can function as svg fill and stroke spec as well

fantasai: we talked about fill and stroke being short hands
... for svg attributes there's no issue because of the order in which they are processed.
... the unsuffixed properties are not a shorthand of these properties
... it breaks a little bit with how properties work in css.
... question is what resets? doe stroke-opacity and fill-opacity for example?

AmeliaBR: think we talked about this in the past and it would break way too much content
... it's an unfortunate naming situation where people maybe expect things to reset and we have to be very explicit with notes in the spec explaining this what is not part of the fill and stroke shorthand
... but there's no way we could have a backwards compatible way of making a short hand of any of these

fantasai: last time we had a meeting it was an open question

shepazu: I understand the desire but agree with AmeliaBR
... I could see another path - we could add a new property that is not 'stroke', but 'stroke-something'
... not elegant but could serve the same purpose
... don't mind aliasing stroke color for stroke

fantasai: not going to alias it, stroke is going to be a shorthand for stroke-color at the least
... if we can't make it work correctly we won't have a shorthand relationship here

shepazu: think whatever the shorthand is it should make the existing behaviour of svg

fantasai: we're doing that

AmeliaBR: the consequences are that the shorthand version of stroke and fill can't reset any existing properties
... does make sense for stroke geometry properties to have a new shorthand

TabAtkins: if we go with 'stroke-dash' that's very close to our naming scheme

Tav: stroke-color doesn't seem an appropriate name

fantasai: you can set a color or image as background. stroke-color actually only takes colours
... stroke-image would also exist
... we went over this in Sydney

AmeliaBR: all those new properties would only add up to describe the painting of the stroke. They wouldn't change the existing properties. It would just be a way of describing the layers of paint

fantasai: it would just be fill-opacity that would be a bit weird

<TabAtkins> https://drafts.fxtf.org/paint/ is what we're working on btw

AmeliaBR: my suggestion would be to have a note in the spec saying whether or not it is included in the shorthand

fantasai: we might do it by section

AmeliaBR: the other issue is that there is also a draft spec that svg put together for advanced stroke geometry

fantasai: we merged that in
... that was one of the action items we took in Sydney

AmeliaBR: we're glad you're working on this
... as I mentioned on Github is that layering has changed in SVG 2
... SVG 2 allows multiple paint server layers with fallback as the last parameter
... but we didn't add css images beacuse we didn't get into all the sizing and positioning issues

<AmeliaBR> https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint

AmeliaBR: this is where it is

fantasai: don't think it would be good to add anything on top of SVG 1 until we've worked through everything
... can we not do that in svg 2?
... we're introducing layering in css. Not sure how it will end up
... I know you're trying to go to CR right now, which means if we run into problems we can't fix them

shepazu: think our goal is to get this capability in asap
... seems if it's added to css rather than svg 2 it can be added in a timely way and it should meet the goal
... is that correct?

fantasai: yes, we could take co-editor from svg but we'd like to address this all at once in a nice coherent way
... not saying there will be issues, but can't say right now
... I would say take it out of SVG 2 and we'll work on it over the next 6 months
... we would be happy with cutting back our draft to move quickly
... but we need to lock down the interaction

shepazu: if the goal is to have the feature and we're not so set on the syntax
... if svg goes its own way I'd be concerned about conflicts
... so I'm very reluctant to introduce a feature in svg that may be overriden by css
... so as long as functionality is available in a timely way

AmeliaBR: There's two different much requested features here - layering is one, but css image types is a bigger one
... if there is a movement from Tab and Elika to work on the spec and a commitment from implementers to follow through
... I'm ok with reverting that section to SVG 1.1 syntax for now
... maybe with a note

shepazu: it's more likely to be implemented quickly if it's a css feautre
... and this reduces our testing load

<AmeliaBR> FXTF issues https://github.com/w3c/fxtf-drafts/issues/

RESOLUTION: we will roll back multi layered fill in SVG 2 and it will be defined in an FXTF module

shepazu: To clarify, context-fill and context-stroke will not be removed

AmeliaBR: the idea of using a child instead of a url id is important as well

<scribe> ACTION: Tav to review CSS fill and stroke to ensure it captures everything from SVG [recorded in http://www.w3.org/2016/08/04-svg-minutes.html#action01]

<trackbot> Created ACTION-3851 - Review css fill and stroke to ensure it captures everything from svg [on Tavmjong Bah - due 2016-08-11].

<scribe> ACTION: Nikos to make edits to SVG 2 to remove things going to CSS fill and stroke [recorded in http://www.w3.org/2016/08/04-svg-minutes.html#action02]

<trackbot> Created ACTION-3852 - Make edits to svg 2 to remove things going to css fill and stroke [on Nikos Andronikos - due 2016-08-11].

shepazu: Tab and Elika, have you reviewed z-index in SVG?

<shepazu> https://www.w3.org/TR/SVG2/render.html#RenderingOrder

AmeliaBR: The big difference is that 2d transform doesn't make a stacking context

TabAtkins: I'll review it

SVG Animation and SVG Integration specs

AmeliaBR: for SVG Animation I'd like to publish a FPWD of what we have - won't be any extra work on Brian
... for SVG Integration I'd like to bring the bits we depedn on into SVG 2

nikos: Agree on SVG integration, we and other specs reference the processing modes and they should just be in svg 2
... that would save us spending lots of time tidying up the svg integration spec
... svg in OT is looking for something solid to reference too as well so should hopefully make them happy

<AmeliaBR> https://svgwg.org/svg2-draft/conform.html

AmeliaBR: currently the conformance section is an appendix, so we need to make a normative chapter we can put processing modes in

<scribe> ACTION: Doug to edit SVG 2 to include processing modes from SVG integration spec [recorded in http://www.w3.org/2016/08/04-svg-minutes.html#action03]

<trackbot> Created ACTION-3853 - Edit svg 2 to include processing modes from svg integration spec [on Doug Schepers - due 2016-08-11].

AmeliaBR: why don't we make conform a proper chapter?

shepazu: Let's do that

RESOLUTION: Publish FPWD of SVG Animation pending Brian Birtles agreement

birtles: ping

<scribe> ACTION: Nikos to prepare a blurb for front page news [recorded in http://www.w3.org/2016/08/04-svg-minutes.html#action04]

<trackbot> Created ACTION-3854 - Prepare a blurb for front page news [on Nikos Andronikos - due 2016-08-11].

- DRAFT -

SVG Working Group Teleconference

04 Aug 2016

Attendees

Contents

SVG 2 CR publication update

Self review - security and privacy questionnaire

fill and stroke shorthand

SVG Animation and SVG Integration specs

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output