SVG Working Group Teleconference -- 12 Jun 2014

<trackbot> Date: 12 June 2014

<scribe> scribenick: birtles

<scribe> scribe: birtles

Missing 'turn' unit in SVGAngle

<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

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> 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

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> 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: 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

- DRAFT -

SVG Working Group Teleconference

12 Jun 2014

Attendees

Contents