See also: IRC log
Char: Nikos
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
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
https://www.w3.org/TR/security-privacy-questionnaire/
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
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].
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/shane:/shepazu:/ Succeeded: s/contnt/content/ Succeeded: s/stroke-*/stroke-dash/ Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Present: nikos stakagi Tav shepazu_ AmeliaBR Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Aug/0006.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/04-svg-minutes.html People with action items: doug nikos tav[End of scribe.perl diagnostic output]