See also: IRC log
<trackbot> Date: 12 June 2014
<scribe> scribenick: birtles
<scribe> scribe: birtles
<ed> 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
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
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
<krit> 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
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?
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?
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: 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
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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 Tav krit Regrets: nikos Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html Found Date: 12 Jun 2014 Guessing minutes URL: http://www.w3.org/2014/06/12-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]