- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 12 Jun 2014 07:08:40 -0700 (PDT)
- To: www-svg@w3.org
Minutes:
http://www.w3.org/2014/06/12-svg-minutes.html
as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 Jun 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html
See also: [3]IRC log
[3] http://www.w3.org/2014/06/12-svg-irc
Attendees
Present
birtles, heycam, ed, stakagi, cabanier, [IPcaller],
+1.415.832.aaaa, Tav, krit
Regrets
nikos
Chair
Cameron
Scribe
birtles
Contents
* [4]Topics
1. [5]Missing 'turn' unit in SVGAngle
2. [6]Aiming for SVG Integration Last Call by April 2015
3. [7]Moving definition of getSVGDocument to HTML
4. [8]Geometry interfaces: Replace isIdentity?
5. [9]Geometry interfaces: various issues
6. [10]Geometry interfaces: replacee translateBy by
translateSelf for better expressiveness?
7. [11]F2F in London
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 12 June 2014
<scribe> scribenick: birtles
<scribe> scribe: birtles
Missing 'turn' unit in SVGAngle
<ed> [13]http://www.w3.org/2013/07/11-svg-minutes.html#item05
[13] http://www.w3.org/2013/07/11-svg-minutes.html#item05
ed: I spoke with Dirk about this and we already had a
resolution for this
... we decided not to add new IDL constants for the old SVG DOM
... so the previous resolution wasn't exactly clear what we
should do with new units for example
... for parts of the DOM that expect a unit
... I take this to mean we don't want to change any of the
behaviour
... i.e. act as if those new units weren't supported when you
inspect the SVG DOM
heycam: so you'd get the unknown value when you look up the
unit?
ed: and if you use valueAsString you'd get the default value as
if the unit wasn't supported
... since the new resolution only concerned not adding new IDL
constants
... I wanted to make sure the rest was covered
heycam: we've had a few instances of this kind of thing of not
having a new constant in the IDL
... but these issues that you bring up now show that it's kind
of awkward
... it makes those interfaces completely useless
... I wonder what we should do if in the future we don't go
ahead with the new SVG DOM proposal
... in that case perhaps we should extend these old interfaces
... or should we say you can only use get/setAttribute for
these new unit types
krit: most of these libraries just use get/setAttribute
... most of attributes get presentation properties and then
they can use 'style' for examples to set the value
... and get the string
<heycam> element.style.someAngledProperty = '2turn'
krit: with, of course, the units
... I don't want to shut the door on the SVG DOM but maybe we
should wait until we decide what we want to do with the SVG DOM
... but keep it as it is for now
heycam: so keep things exactly as they are for now until we
finally decide what we're doing with the DOM
... then we can add the constants or not depending on which
course we take
... it would be great to have that behavior defined in the spec
(re: when you use one of the new units)
ed: I think it is defined already
... it's just the angle interface is not so useful
... it basically just behaves as if the unit was not supported
heycam: ok, I guess the existing spec text is sufficient
ed: yes, I think it is, but I just wanted to confirm that's
what we wanted
... SVGAngle is not so useful but the same issue applies to
SVGLength and SVGTransform
heycam: I'm ok with that
ed: I think the existing resolution and spec text is enough but
just wanted to confirm
Aiming for SVG Integration Last Call by April 2015
heycam: I was speaking with Vlad who works on the OpenType font
format spec which is the spec with the SVG table now
... we've been discussing what to do about the reference to the
SVG Integration spec
... April 2015 is basically the last point where they can
update references in the spec
... so if the SVG Integration spec can be in last call by then,
then it's fine to leave it in as a normative reference
... I need to check if that would mean the LC URL would be
baked in, or if we could use the more general URL
... but that's the timeline
... so I wanted to see if we can have something usefully at LC
by then?
krit: I think we should try to do it before then
heycam: there is a period for final comments for the MPEG group
which finishes in about 1.5 days
... I'll send in a few suggested wording tweaks including
suggestions about the SVG reference
Moving definition of getSVGDocument to HTML
ed: I think I got this from Simon Pieters and I think we should
go ahead and let HTML define getSVGDocument
... basically removing it from the SVG spec
heycam: so getSVGDocument was a function the Adobe player
exposed on the <object> and <embed> elements when they
referenced an SVG document
... as a way of getting to the SVG document DOM
... since then contentDocument has been added
... and people should use that, so getSVGDocument is a bit
useless
... getSVGDocument is defined to be the same thing as
contentDocument but it isn't precise
... it's probably easier to define in HTML where definitions
about browsing contexts etc. are available
ed: I think contentDocument doesn't work for <embed> elements
heycam: does getSVGDocument work?
ed: yes, I believe so
heycam: somebody asked me again recently what was the status of
this and whether it was ok for the HTML spec to add it and us
to remove it
... any objections?
??: no
RESOLUTION: SVG2 will remove the definition of getSVGDocument
and it will move to the HTML spec
Geometry interfaces: Replace isIdentity?
<krit> [14]http://dev.w3.org/fxtf/geometry/
[14] http://dev.w3.org/fxtf/geometry/
krit: we had some discussions about isIdentity and to have
something more reliable like hasTransform which basically
returns false if there are no transforms on the matrix
... so it's more reliable because something that has not been
transformed is definitely not identity
... but at the end I think people thought it was more useful to
have isIdentity even if might return false sometimes where it
could return true
... I think at the end we agreed on the behavior but I just
wanted to tell the group about it
... in the end isIdentity is used for optimizations so it just
means the code might not run as optimally as it could
... there are cases where you transform something and transform
it back and you might end up returning false in that case
... but hasTransform would also return false then
... isIdentity would return true more often than hasTransform
heycam: so how is this different from what is currently
defined?
krit: it's not
cabanier: hasTransform never made it into the spec
heycam: so it just checks for 0s and 1s?
krit: yes, the simple-minded way
Geometry interfaces: various issues
[15]http://lists.w3.org/Archives/Public/public-fx/2014AprJun/01
64.html
[15] http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0164.html
krit: is2D is the next issue
... after discussion we decided to make this track
transformations
... if you have transforms that are 3D it will return false
... if all transforms are 2D it will return true
heycam: so it's a flag that once it becomes false it stays that
way?
krit: right
... this is something that Benoit preferred and I'm fine with
it too
heycam: so it requires you to store extra state in the object
cabanier: but usually you just allocate a 2D matrix until a 3D
transformation is made and then you swap it out
heycam: so you'd have some state there already
krit: I think that was the only open issue there
... the use case came from when you have rotation points around
the x-axis
... if you swap to 3D and back for one frame that would be odd
heycam: in what cases do you expect authors to use it?
krit: it might be the result of some calculation that you need
to check if you need to switch to 3D calculations or not
... I definitely want people to view the spec and send
objections to the list
... Geometry interfaces: replacee translateBy by translateSelf
for better expressiveness?
Geometry interfaces: replacee translateBy by translateSelf for better
expressiveness?
krit: people found translateBy confusing, we think
translateSelf is easier to understand
heycam: I agree
krit: the other suggestion was 'this' instead of 'self'
heycam: I'm not sure which I prefer
krit: another topic which may need agreement of WG was whether
we should have 'invert' or 'invertSelf'
... SVG has 'inverse'
... but 'invertSelf' is more consistent with the other methods
heycam: what's the plan for aligning SVGMatrix and DOMMatrix?
... does SVGMatrix inherit from DOMMatrix or alias it?
krit: alias it
heycam: in that case, will there still be an Inverse method for
compatibility
ed: SVG's Inverse returns a new matrix I think
krit: yes
... so any objections to adding 'invertSelf'
heycam: it seems bad to have 'invert' and 'inverse'
cabanier: it would be 'inverse' and 'invertSelf'
heycam: I though Dirk was suggesting we have 'invert' for
consistency
krit: no, the question was do we want to rename 'invert' to
'invertSelf'
heycam: yes, definitely
... do you think it's a silly idea to have 'invert' as well?
krit: why?
heycam: for completeness and matching the pattern
<heycam> 'inverse', 'invert', 'invertSelf'
<heycam> where inverse means the same as invert
heycam: I would probably shy away from having all 3 but it's
also tempting to have for completeness
krit: we keep inverse, that's for sure
... would invert modify itself?
... I'm not a fan of adding things for completeness
heycam: ok, we can add it later
cabanier: we can always add it later
heycam: the other matrix interfaces you want to have
compatibility with, MSMatrix, WebkitMatrix etc., what do they
have on them?
<cabanier>
[16]https://developer.apple.com/library/safari/documentation/Au
dioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatri
x/WebKitCSSMatrix.html
[16] https://developer.apple.com/library/safari/documentation/AudioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatrix/WebKitCSSMatrix.html
heycam: is it a goal to be compatible with them or just to have
the same features
krit: it would be good to be compatible. Both have inverse,
just like SVGMatrix
heycam: do they have the other methods that modify the same
object?
krit: no, they only have the methods that return a new object
cabanier: WebKitCSSMatrix has setMatrixValue
krit: I didn't add it because it seems to be redundant
... with the constructor that also takes a string
heycam: so you couldn't modify an existing object by giving it
a value using a string
krit: yes, that's correct
... if there's a need for that, we'll add it then
cabanier: you don't have any plans to alias WebKitCSSMatrix to
DOMMatrix right?
krit: actually, yes I'd like to do that
... but I'd still like to make setMatrixValue not part of
DOMMatrix
... not sure yet how I will do that, but somehow
cabanier: (checking github to see if anyone uses
setMatrixValue)
krit: Rik mentioned that he would like to make isIdentity and
is2D readonly attributes
... it's just a cosmetic issue
... I'd like to make them the same (i.e. both attributes or
both methods)
... I'm leaning towards methods
... attributes seem to suggest something is stored whereas
methods suggest checking something
... it's not a hard-and-fast rule but that's how I understand
it
... what does the group think?
heycam: from my intuition I think attributes are right
... I think it's fine to have attributes that reflect some
state of the object
ed: I think I agree with Cameron
krit: ok, we'll change it to attributes
cabanier: I found some places where setMatrixValue are used
krit: should we add it then, or try to avoid it?
heycam: I think it would be handy to be able to assign with a
string value
... is it also on MSCSSMatrix
krit: yes
heycam: then I'd say go with that
krit: the last question, should the in-place transformations
return the same object?
<cabanier> for instance:
[17]https://github.com/yui/yui3-gallery/blob/5b0e2d507be5916560
aebae04f8a74d4211af402/src/gallery-node-transform2d/js/node-tra
nsform2d.js#L20
[17] https://github.com/yui/yui3-gallery/blob/5b0e2d507be5916560aebae04f8a74d4211af402/src/gallery-node-transform2d/js/node-transform2d.js#L20
krit: for example translateSelf, changes it in place
... should it return the same object?
<cabanier> should the xxxSelf function return the object?
<krit> everything is void atm
<cabanier> so m.translateSelf(...).scaleSelf(...)
<krit> matrix.translateSelf()
<krit> matrix.scaleSelf()
<krit> matrix.translateSelf()
krit: the current return value of these is void
<krit> change this to
<krit> m.translateSelf(...).scaleSelf(…).translateSelf(...)
krit: I would like to change it so it returns the object and
you can chain like this ^
birtles: why would you not do that?
heycam: I'm not sure I'm a fan of that kind of chaining style
approach in general but I think it makes sense in this case
... since I think you often want to do these operations in a
row
birtles: promises use a lot of chaining
<ed> why would one not do m.stringSetter = "translate...scale
... translate"
ed: repeating "self" a lot is a bit redundant
krit: that's because we're dealing with the legacy of SVGMatrix
which took the short names
heycam: you could change 'self' to 'me' :)
... translateMe
krit: the benefit of 'me' is it's shorter (same as 'by')
heycam: I think 'self' is better
krit: I will make all these changes
... I would like to have people review the spec
... I'd like people to have a look after I've made the changes
too
... I will have it done today or so
... I would like to ask for last call in the next week or the
week after
... it depends if working group members want more time for
review
... just let me know me next week if you need more time or not
... I'll send a mail to the WG and to www-style as well
F2F in London
heycam: I've booked a room for the F2F
... I need to tell the office person a few weeks beforehand
about numbers/dietary requirements so plenty of time still
... Chris sent up a registration form for it
... I'll look into hotels too
<heycam> /me birtles do you wear a headset?
<krit> my
apologies: Nikos
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [18]scribe.perl version
1.138 ([19]CVS log)
$Date: 2014-06-12 14:04:24 $
__________________________________________________________
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[19] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/by/me/
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: birtles, heycam, ed, stakagi, cabanier, [IPcaller], +1.
415.832.aaaa, Tav, krit
Present: birtles heycam ed stakagi cabanier [IPcaller] +1.415.832.aaaa T
av krit
Agenda: [21]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.htm
l
Found Date: 12 Jun 2014
Guessing minutes URL: [22]http://www.w3.org/2014/06/12-svg-minutes.html
People with action items:
[21] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html
[22] http://www.w3.org/2014/06/12-svg-minutes.html
[End of [23]scribe.perl diagnostic output]
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 12 June 2014 14:09:09 UTC