See also: IRC log
<trackbot> Date: 19 March 2015
<scribe> scribenick: nikos
<scribe> Scribe: Nikos
ed: I was wondering if we had set
a date for when to publish SVG 2 ?
... and the associated modules
Rossen: are you talking about the modules or SVG 2?
ed: At the F2F we said we'd
publish the split out modules and chapters along with the svg 2
spec
... wondering how far along we are?
... is what we have now sufficient?
Rossen: if we're talking about
publishing a bunch of FPWD and a refreshed WD of SVG 2
... I don't see why we should hold off
heycam: we agreed to do that - I
was going to take care of it
... I think the date we set is coming up in the next week
... the only thing is I want to do the splitting of the
stroking features
... that's not so straight forward
ed: so do we have a set date for last edits?
heycam: If you really want them
in then the end of this week
... Not sure when I'll do the bundling but probably early next
week
ed: so expect to publish Thursday next week?
heycam: yes
... that will be the main spec, the marker module, and the
stroking module
bogdan: we did iniital pass
through of co-ord system and units chapter
... want to know if it's the right approach
... we put everything that does need discussing
separately
... does that make sense so far?
ed: yes I think so
Rossen: we can jump into
discussion and allow everyone to review the not an issue and
actionable bits and discuss later
... or we can spend some time walking through the 'not an issue
and actionable' first and then get into discussion
... imo the wg time will be spent jumping into the issues that
need discussion
... sound good?
heycam: yes - we've been doing
that for the last couple of weeks where people have put their
issues up for assessment
... many chapters now only have issues that need
discussion
... but require chapter manager to do work or investigation
before they can be discussed
Rossen: let's dive into open issues on co-ordinates and units then
bogdan: issue 5 - effect of transform matrix on sibling element
bogdan: proposal is to move this
to the attributes section
... doesn't look like this is specific to transforms
... are we missing something here?
heycam: I think the section was
removed illustrated how other elements on the element that the
attribute is specified on are affected by the transform
... same behaviour is going to occur for transform
property
... so not sure why that section would have been removed
bogdan: that's the question - is
there anything specific to do with transforms? if so we should
put it back
... otherwise we should move it to somewhere more general
heycam: think it would be good to have wording describing how transform affects other attributes on the element
bogdan: so bring back the removed part?
heycam: yes
bogdan: issue 6 - about the blue
box for attributes in general - a generic question
... doesn't look like we need it in this case
... proposal is to remove it
heycam: agree it should be
removed
... pattern i was using in the rest of the spec is for
properties defined completely in other specs - we wouldn't have
the blue box
... just point to the other spec - like in hte green box
bogdan: resolved that we don't need a resolution on minor editorial changes - just put it in the commit message so it's trackable
Tav: noticed css 3 transform spec
is in the green note - is that how we should do it?
... 'see other specs' should be in green?
heycam: I'll find an example
Tav: there's a mixture of styles
Rossen: bikeshed will usually link automatically and generate the reference table
heycam: think we'd like to switch to using bikeshed but there's some issues at the moment with features that aren't supported
<heycam> https://svgwg.org/svg2-draft/painting.html#VisibilityControl
heycam: the pattern I've been
using is this "See the blah specification for the definitions
of blah"
... and name the section 'The effect of the so and so
property'
... to distinguish that we're not defining the property
here
Tav: that's awfully wordy
Rossen: only makes it worse for the writers
AmeliaBR: so you'd have 'The
effect of the transform on svg layout properties'?
... so a kind of a note section?
heycam: it is a kind of a
note
... we usually have the property name, then colon, then a short
description of the property
... in this case the only difference is to include 'The effect
of'
Tav: personally I don't think
it's neccessary
... but don't care that much
heycam: I like seeing from the TOC here is something we define, and here is something we reference
Rossen: ok sounds good
bogdan: Issue 9
... more or less the same as issue 5
... suggest we follow the same resolution and update the link
if we bring the paragraph back
... it's also about the effect of the transform attribute
heycam: sounds fine
bogdan: Issue 10
... it appears we won't need this
... but would like to hear from the group
heycam: think someone put that issue there because I haven't seen anyone use defer
ed: my preference is to ignore it
AmeliaBR: the only place it's
useful is when embedding svg images using an svg image
element
... usually you use 'use' elements rather than images
Smailus: we have a use case at Boeing for putting svg documents in svg documents
AmeliaBR: would it be useful to use the defer setting ?
Smailus: yes, we're using it to overlay two images so we'd need to have each of those separate SVGs properly retain their look and feel
Rossen: not sure I follow how that correlates?
Smailus: what's the key question?
AmeliaBR: is defer useful on preserveAspectRatio
Smailus: can't speak to that - don't think we're using it that way
AmeliaBR: is it difficult to
support defer on preserveAspectRatio in implementations?
... in an html document this is used automatically
Rossen: I was thinking the
opposite - the aspect ratio preservation is assumed
... and I don't know when you'd want to have a non ratio
preserved image
... does that make sense?
... for implementation you're already doing that for
images
... don't see non aspect preserving scenario being a useful use
case
AmeliaBR: the idea you can
override the setting on the file you're embedding?
... one case might be alignment
... file embedding has cetner
... and you want it left aligned
Rossen: what does that have to do with aspect ratio?
AmeliaBR: preserveAspectRatio
does both
... whether you preserve and if you are how do you align within
the space
<heycam> xMinYMin vs xMidYMix for example
<heycam> *Mid
Rossen: can you explain what you
mean by alignment in here?
... even if you preserve the aspect ratio you always have an
origin where the image is going to be rendered
... not sure what alignment you are referring to exactly
AmeliaBR: in your main file you
have a certain area described for 'draw the image in this
space'
... but embedded image doesn't fit in that space
... if you're preserving aspect ratio you're not stretching to
fit that space
... so the question is how you align it ?
Rossen: there's no aligment here
. there's just an origin where the image goes
... assume you have a square and a 1x2 svg that has to go
inside
... when the svg is scaled with ratio preservation half the
square to the left where the origin is
... the other half will be empty
... there's no way to align the image that I know of
... are we trying to invent something different here?
AmeliaBR: think we have a
language mix up
... by align I'm talking about xMid yMax, etc
Rossen: these would be applied as they would, regardless of the aspect ratio
ed: so what do we do -
investigate further?
... can we decide something here?
bogdan: don't think we need an
action. if it's there it should work
... can discuss dropping later
ed: think we should maybe ask if
there's someone that has use cases
... put it to the list
... raise again in future
bogdan: i can do that
<scribe> ACTION: bogdan to create test case for preserveAspectRatio defer [recorded in http://www.w3.org/2015/03/19-svg-minutes.html#action01]
<trackbot> Created ACTION-3773 - Create test case for preserveaspectratio defer [on Bogdan Brinza - due 2015-03-26].
bogdan: issue 17
... need a line for mesh gradients?
... so mesh gradient owner needs to add this?
Tav: can give me an action. It's going to take some thought
<scribe> ACTION: Tav to come up with solution for issue 17 in co-ordinates and units [recorded in http://www.w3.org/2015/03/19-svg-minutes.html#action02]
<trackbot> Created ACTION-3774 - Come up with solution for issue 17 in co-ordinates and units [on Tavmjong Bah - due 2015-03-26].
bogdan: Issue 18
... it's not clear
AmeliaBR: is there going to be a way to set object bounding boxes to use the other types of bounding boxes?
heycam: similar to what we discussed last week relating to Paul's request on the list
AmeliaBR: it's not necessarily
either, or
... the issue itself seems to be just 'reference the definition
and how it's calcualted'
heycam: think we just need a
sentence saying 'the bounding box that this is talking about is
the one you get by invoking that algorithm'
... next is issue 20
bogdan: that should be a comment at the end
<ed> https://svgwg.org/svg2-draft/coords.html#InterfaceSVGTransformList
bogdan: is this something specific we need to add or can we just defer to CSS transforms?
heycam: dirk not here, but pretty
sure all this dom transform stuff got added to css
transforms
... so shouldn't need to define it
... but person doing the editing should check
... if it is then we don't want to duplicate the wording
<AmeliaBR> http://www.w3.org/TR/css3-transforms/#transform-attribute-dom
bogdan: will clarify with the editor about what is the best way to proceed - sounds like deferring to transforms is preferable
AmeliaBR: css transform spec
references svg
... doesn't have a full definition
heycam: perhaps person who added the issue thought incorrectly
<ed> http://dev.w3.org/fxtf/geometry/
ed: think it's the geometry spec
heycam: would suggest talking to Dirk about where these things should live
bogdan: I'll follow up
... Issue 21
<ed> "The DOMMatrix and DOMMatrixReadOnly interfaces replace the SVGMatrix interface from SVG [SVG11]."
bogdan: is there anything new with regards to svg 1.1 that we need to put here?
heycam: there is a question in
that issue 7 in the spec about whether the none value (added in
tiny 1.2) should be included here
... not sure of the answer
bogdan: sounds like answer is yes
- just needs to be done
... hard to imagine the case where it wouldn't be true
heycam: I'm not sure what the implementation status is
<pdr__> ed, DOMMatrix has faced resistance from implementations (Webkit and Blink) for performance concerns.
AmeliaBR: if you say viewbox none
I'm pretty sure every implementation would treat it as not
having a viewbox attribute
... which is the result you want
... might fail validation but as far as what is displayed on
screen the result is fine
heycam: that makes it an easy decision to include it
bogdan: sounds like we don't need the attribute table?
heycam: we should have the
attribute table
... that will define the lacuna value
<ed> pdr__, true, also in the issue we were discussing it wouldn't be sufficient to have DOMMatrix anyway, SVGTransformList is a list of "DOMMatrix"...
bogdan: issue 23
... want to clarify the intent here?
AmeliaBR: for shapes with width
or height is zero we have disable rednering
... not sure if that's true for negative values
Rossen: if I have a rectangle
that is 1,1,-1,-1
... make it -2,-2
... a 2x1 rectangle spanning the origin
... is that valid?
AmeliaBR: no - you can't use
negative height and width
... I think it would be a neat feature, but it's currently an
error
shepazu: we could allow that to happen because there's no content that is counting on it being otherwise
Rossen: not looking for things to
add - just looking to resolve the issue
... so are we saying this is an error?
ed: error processing rules is that we should render up to and including the element with the error
AmeliaBR: what if you had nested SVGs and one had an error? you wouldn't render that and anything after in the containing file
bogdan: issue 24
... looks like the same as issue 21
Rossen: why are we adding a table?
heycam: every attribute in the spec needs a table
ed: this chapter is particularly bad in defining attributes
Rossen: 2 more issues in this
chapter are waiting for further discussion
... one for chat with dirk, one for test case
... others are all actionable
... do you want to walk over the non-issues we've identified
?
bogdan: I suggest doing that offline
<ed> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Needing_discussion
nikos: Should we keep the non
normative text that jwatt wrote for the z-index feature?
... don't think it says anything that isn't said in the
normative text
... I guess it's a general q about the svg 2 spec - do we want
to have big blocks of non normative text?
Tav: think having a description is useful
nikos: what about the pattern of saying 'this is non-normative' and 'this is normative'
heycam: having in a green box
might be useful - but that would be a large block
... if you think the normative text + the examples explain
everythign
... then I'd be alright with removing it
nikos: that would be my feeling
Tav: you should probably have a few lines introducing the concept
nikos: 2.3 - rendering order introduces the concept
Tav: I didn't see 2.3 - if it's repetitive then it's probably not needed
resolution: remove non-normative text for z-index. keep examples and move to where appropriate
shepazu: in Sparta, they have some SVG animation stuff - thank you for putting that in
bogdan: we still haven't introduced smil
<shepazu> https://status.modern.ie/csstransitionsanimationsforsvgelements
shepazu: there has been a lot of
heat and not a lot of light regarding smil
... on the mailing list
... my understanding is that the element based animation syntax
will be supported by the animation model
birtles: right
shepazu: and all this gloom and doom about smil is not neccessary
birtles: I believe so
... think part of the concern is that google says they're not
interested in extending the feature set of element based
animation
shepazu: ok, but old stuff will work
birtles: though there was some indication there might be slight changes in the behaviour
ed: that's in the engine itself. doesn't have to affect content
shepazu: I'm going to make a wiki
page that spells this out
... think if we're going to have this element based syntax it
should be in a spec right?
birtles: yes. I started writing a
spec called 'Animation Elements'
... don't have much time to work on it at the moment
... main problem with the draft is that I started adding extra
features
<AmeliaBR> https://svgwg.org/specs/animation-elements/
<AmeliaBR> ScribeNick: AmeliaBR
Doug: ok, I'm going to set up a wiki page, to try to clarify our current strategy
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/need align for/need a line for/ Found ScribeNick: nikos Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: AmeliaBR ScribeNicks: nikos, AmeliaBR WARNING: No "Present: ... " found! Possibly Present: AmeliaBR Doug Doug_Schepers IPcaller Microsoft P1 P2 P3 P7 P9 Rossen Smailus Tav Thomas_Smailus birtles bogdan ed heycam https jcraig joined krit nikos pdr__ scribenick shepazu stakagi svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0081.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 19 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/19-svg-minutes.html People with action items: bogdan tav[End of scribe.perl diagnostic output]