- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Fri, 5 Aug 2016 00:06:44 +0000
- To: www-svg <www-svg@w3.org>
https://www.w3.org/2016/08/04-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
04 Aug 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2016Aug/0006.html
See also: [3]IRC log
[3] http://www.w3.org/2016/08/04-svg-irc
Attendees
Present
nikos, stakagi, Tav, shepazu_, AmeliaBR
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Nikos
Contents
* [4]Topics
1. [5]SVG 2 CR publication update
2. [6]Self review - security and privacy questionnaire
3. [7]fill and stroke shorthand
4. [8]SVG Animation and SVG Integration specs
* [9]Summary of Action Items
* [10]Summary of Resolutions
__________________________________________________________
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
[11]https://github.com/w3c/svgwg/wiki/SVG-2-new-features
[11] https://github.com/w3c/svgwg/wiki/SVG-2-new-features
[12]https://github.com/w3c/svgwg/wiki/SVG-2-breaking-changes
[12] 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
[13]https://www.w3.org/TR/security-privacy-questionnaire/
[13] https://www.w3.org/TR/security-privacy-questionnaire/
fill and stroke shorthand
[14]https://github.com/w3c/svgwg/issues/230
[14] 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
[15]https://svgwg.org/svg2-draft/text.html#TextRenderingOrder
[15] 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> [16]https://github.com/w3c/svgwg/issues/230
[16] https://github.com/w3c/svgwg/issues/230
<fantasai>
[17]https://lists.w3.org/Archives/Public/www-style/2013Jun/0678
.html
[17] https://lists.w3.org/Archives/Public/www-style/2013Jun/0678.html
<fantasai>
[18]https://lists.w3.org/Archives/Public/www-style/2014Feb/0609
.html
[18] https://lists.w3.org/Archives/Public/www-style/2014Feb/0609.html
<fantasai>
[19]https://lists.w3.org/Archives/Public/www-style/2016Mar/0358
.html
[19] 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> [20]https://drafts.fxtf.org/paint/ is what we're
working on btw
[20] https://drafts.fxtf.org/paint/
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>
[21]https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint
[21] 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
[22]https://github.com/w3c/fxtf-drafts/issues/
[22] 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
[23]http://www.w3.org/2016/08/04-svg-minutes.html#action01]
[23] 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
[24]http://www.w3.org/2016/08/04-svg-minutes.html#action02]
[24] 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>
[25]https://www.w3.org/TR/SVG2/render.html#RenderingOrder
[25] 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> [26]https://svgwg.org/svg2-draft/conform.html
[26] 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
[27]http://www.w3.org/2016/08/04-svg-minutes.html#action03]
[27] 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
[28]http://www.w3.org/2016/08/04-svg-minutes.html#action04]
[28] 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].
Summary of Action Items
[NEW] ACTION: Doug to edit SVG 2 to include processing modes
from SVG integration spec [recorded in
[29]http://www.w3.org/2016/08/04-svg-minutes.html#action03]
[NEW] ACTION: Nikos to make edits to SVG 2 to remove things
going to CSS fill and stroke [recorded in
[30]http://www.w3.org/2016/08/04-svg-minutes.html#action02]
[NEW] ACTION: Nikos to prepare a blurb for front page news
[recorded in
[31]http://www.w3.org/2016/08/04-svg-minutes.html#action04]
[NEW] ACTION: Tav to review CSS fill and stroke to ensure it
captures everything from SVG [recorded in
[32]http://www.w3.org/2016/08/04-svg-minutes.html#action01]
[29] http://www.w3.org/2016/08/04-svg-minutes.html#action03
[30] http://www.w3.org/2016/08/04-svg-minutes.html#action02
[31] http://www.w3.org/2016/08/04-svg-minutes.html#action04
[32] http://www.w3.org/2016/08/04-svg-minutes.html#action01
Summary of Resolutions
1. [33]we will roll back multi layered fill in SVG 2 and it
will be defined in an FXTF module
2. [34]Publish FPWD of SVG Animation pending Brian Birtles
agreement
[End of minutes]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Friday, 5 August 2016 00:07:31 UTC