20:29:34 <RRSAgent> RRSAgent has joined #svg
20:29:34 <RRSAgent> logging to http://www.w3.org/2013/10/17-svg-irc
20:29:36 <trackbot> RRSAgent, make logs public
20:29:36 <Zakim> Zakim has joined #svg
20:29:38 <trackbot> Zakim, this will be GA_SVGWG
20:29:38 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:30PM already started
20:29:39 <trackbot> Meeting: SVG Working Group Teleconference
20:29:39 <trackbot> Date: 17 October 2013
20:29:44 <Zakim> -??P4
20:29:59 <heycam> Zakim, who is on the call?
20:29:59 <Zakim> On the phone I see krit
20:30:03 <Zakim> +??P4
20:30:10 <nikos> Zakim, +??P4 is me
20:30:10 <Zakim> sorry, nikos, I do not recognize a party named '+??P4'
20:30:13 <nikos> Zakim, ??P4 is me
20:30:13 <Zakim> +nikos; got it
20:30:26 <Zakim> +[IPcaller]
20:30:28 <heycam> Zakim, [ is me
20:30:28 <Zakim> +heycam; got it
20:30:50 <heycam> Chair: Cameron
20:31:00 <heycam> Regrets: Erik, Luc, Tav, Rich
20:31:09 <Zakim> +??P6
20:31:17 <Thomas_Smailus> Thomas_Smailus has joined #svg
20:31:18 <birtles> birtles has joined #svg
20:31:24 <stakagi> zakim ??P6 is me
20:31:25 <thorton> thorton has joined #svg
20:31:25 <Zakim> +[IPcaller]
20:31:34 <birtles> Zakim, [ is me
20:31:34 <Zakim> +birtles; got it
20:31:39 <heycam> Zakim, ??P6 is stagaki
20:31:39 <Zakim> +stagaki; got it
20:31:40 <Zakim> +??P8
20:31:53 <Zakim> +Thomas_Smailus
20:31:56 <cyril> zakim, ??P8 is me
20:31:56 <Zakim> +cyril; got it
20:32:07 <cyril> zakim, mute me
20:32:07 <Zakim> cyril should now be muted
20:32:50 <cyril> zakim, unmute me
20:32:50 <Zakim> cyril should no longer be muted
20:35:06 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0016.html
20:35:24 <nikos> scribenick: nikos
20:35:42 <nikos> Topic: Publish CSS Masking as LCWD
20:35:51 <nikos> krit1: Can we publish?
20:35:51 <krit1> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
20:36:16 <nikos> krit1: short summary about changes
20:36:30 <nikos> krit1: syntax hasn't changed except one exception
20:36:39 <nikos> krit1: initial draft supported multiple layers of mask
20:36:55 <nikos> ... question was if it's possible to combine different masks or if it would be mask on mask
20:37:05 <nikos> ... so we delayed layers to next level until this is workedo ut
20:37:18 <nikos> heycam: so you can only specify one layer
20:37:20 <nikos> krit1: yes
20:37:40 <nikos> krit1: having multiple mask layers can be useful but how do you combine the mask?
20:37:46 <nikos> krit1: in webkit, you mask with each in turn
20:37:57 <nikos> ... but you might want to combine masks and then apply
20:38:02 <nikos> ... needs to be discussed more
20:38:08 <nikos> ... not worth waiting
20:38:21 <nikos> heycam: should be possible to define the first process you said? applying masks in turn
20:38:30 <nikos> ... should be possible to compute a single mask that does that?
20:38:46 <nikos> krit1: the problem is you always lose something
20:39:04 <nikos> krit1: imagine having a composite operator between the masks and then apply the result
20:39:14 <nikos> heycam: I think it's fine to leave that to later
20:39:26 <nikos> cyril: what is the difference compared to what svg had in the past?
20:39:34 <nikos> ... are features different or just css integration?
20:39:41 <nikos> krit1: the idea was to have a spec for html and svg world
20:40:08 <nikos> krit1: yes when combined with mask-box
20:40:33 <nikos> ... no because you could do a lot of things with svg mask element that you can now do with masking using an image
20:40:45 <nikos> ... it gets easier, but not necessarily more powerful
20:41:07 <nikos> birtles: we do have alpha and luminance masking
20:41:46 <nikos> krit1: both are implemented in webkit as of a couple of weeks ago
20:42:08 <birtles> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0056.html
20:42:13 <nikos> birtles: did you see the discussion on public-fx ahow how the properties are animated?
20:42:18 <nikos> s/ahow/on how
20:42:29 <nikos> krit1: all properties define if animatable or not
20:42:59 <nikos> ... what will work on mask properties will also apply to background properties
20:43:20 <nikos> ... mask-box-image-slice is not animatable at the moment
20:43:38 <nikos> heycam: is the background version of image-slice property animatable?
20:43:44 <nikos> krit1: yes it's called border-image-slice
20:43:51 <nikos> heycam: why is the mask one not animatable?
20:43:58 <nikos> krit1: I think it's the auto value cannot be animated
20:44:04 <nikos> ... but I think maybe it could be
20:45:24 <nikos> RESOLUTION: publish LCWD of CSS Masking.
20:45:37 <nikos> heycam: which group will handle publication?
20:45:50 <nikos> krit1: I asked ChrisL to handle it
20:46:03 <nikos> Topic: Should perspective affect object bounding box of SVG elements?
20:46:30 <nikos> krit1: object bounding box is a construct we have in svg for a long time
20:46:40 <nikos> ... it's the union of all bounding boxes of it's children including transforms
20:47:23 <nikos> ... as an example. You have group element with child rect. Child rect has scale of 2 then bounding box of the rect will be twice as big for the group element
20:47:38 <nikos> ... CSS transforms we have a lot more properties
20:47:48 <nikos> ... importantly, persepective and perspective-origin
20:48:26 <cyril> zakim, mute me
20:48:26 <Zakim> cyril should now be muted
20:48:35 <nikos> ... the persepective has percentage values
20:48:53 <nikos> ... the spec currently says for all properties, percentage values are resolved against object bounding box
20:49:27 <nikos> ... if the object bounding box includes perspective there is a circular dependency
20:49:37 <nikos> ... one option is to stick to definition of svg 1.1
20:50:04 <nikos> heycam: that means ignoring the transform property and all of the other perspective
20:50:17 <nikos> ... can you remind me what is the plan for transform presentation attribute and property?
20:50:21 <nikos> ... are they meant to be the same thing?
20:51:14 <nikos> krit1: transform attribute will be presentation attribute
20:51:30 <nikos> ... that means for transform property we have cascade
20:51:43 <nikos> ... so you could just look at the presentation attribute not the whole cascade
20:51:50 <nikos> ... I don't think we should go that way though
20:51:52 <nikos> heycam: I agree
20:52:02 <nikos> krit1: other solution is object bounding box does not included perspective
20:52:28 <nikos> ... so that we do not have the problem resolving
20:52:45 <nikos> krit1: third solution - all percentage values are resolved against the viewport
20:53:06 <nikos> heycam: do we have to consider the transform properties because we might have the individual perspective properties in that list?
20:53:17 <nikos> krit1: I don't think that's a problem. They apply as a transform function
20:53:23 <nikos> ... no dependency on parent or child
20:53:49 <nikos> heycam: if you have transform-origin with percentage values and transform property with list and one is a perspective
20:53:55 <nikos> ... would there be a cyclic dependency?
20:53:58 <nikos> ... what's different?
20:54:08 <nikos> krit1: transform just takes transform functions that are multiplied together
20:54:12 <nikos> ... persepective is not an exception
20:54:16 <nikos> ... it's just another function
20:54:26 <nikos> ... I would suggest we look at the 3d part
20:54:31 <nikos> ... for getting the bounding box
20:54:44 <nikos> ... perspective property on other hand is devised from the parent
20:54:52 <nikos> ... parent perspective multiplied by transform of current element
20:54:55 <nikos> ... that's the difference
20:55:02 <nikos> ... between perspective function and property
20:55:21 <nikos> ... I don't think it's actually that useful
20:55:46 <nikos> heycam: option 2 was to ignore perspective property when calculating the bounding box
20:56:04 <nikos> ... is that all situations (getBBox as well as bounding box for gradients for example)
20:56:15 <nikos> krit1: it should be all situations
20:56:28 <glenn> glenn has joined #svg
20:56:55 <nikos> krit1: the problem with option 3 is it's not intuitive
20:57:01 <nikos> ... and doesn't fit well with html world
20:57:08 <nikos> ... would also be different to transform and transform-origin
20:57:26 <nikos> heycam: if you add a small amount of perspective and transform-origin is in a different position, that would be bad
20:57:44 <nikos> krit1: in general perspective and 3d transforms are complex
20:57:52 <nikos> ... can wait on a resolution if people need time to digest
20:58:19 <nikos> heycam: my feeling is that number 2 sounds like the best
20:58:32 <nikos> krit1: I'd be in favour of 2
20:59:10 <Zakim> +Doug_Schepers
20:59:21 <nikos> heycam: in html if you have perspective and call getClientRect
20:59:31 <nikos> ... how does that work with perspective, etc
20:59:50 <nikos> krit1: main difference is that getClientRect does not included transforms
21:00:05 <nikos> heycam: is there no function for getting actual bounding box with transforms in html?
21:00:24 <shepazu> q+
21:01:07 <nikos> krit1: transform doesn't modify the layout
21:01:21 <krit1> shepazu: speak!
21:02:04 <nikos> shepazu: you're talking about whether perspective should change getBBox()?
21:02:12 <nikos> ... Dirk you were saying no?
21:02:14 <nikos> krit1: correct
21:03:20 <nikos> krit1: perspective on child element comes from the parent. Problem is that perspective can have percentage values that need to be resolved against object bounding box. But object bounding box needs the percentage values to be calculated
21:04:03 <nikos> krit1: bounding box inclueds the size of transformed children, but not the transform on the actual element
21:04:26 <nikos> s/is modiefied by/inclueds/
21:04:32 <nikos> s/modiefied/modified
21:04:42 <nikos> shepazu: I'd like to see it written up
21:05:05 <nikos> krit1: we need a solution for resolving the dependencies
21:06:03 <nikos> heycam: the issue is when you use percentage values in transform-origin and the percentages are relative to the shape you are transforming. But the perspective can change the bounding box of the shape being transformed
21:06:07 <nikos> ... so there's a cyclic dependency
21:06:30 <nikos> shepazu: there's an internal way of getting the bounding box right?
21:06:35 <nikos> ... but that's not what we're exposing to the user
21:06:49 <nikos> ... we are exposing a convenience function
21:07:12 <nikos> heycam: the issue isn't calculating the bounding box. The issue is having the percentage values influence the bounding box
21:07:20 <nikos> ... this isn't the case for regular transforms or html content
21:07:37 <nikos> shepazu: I'd like to see a diagram of this to clarify
21:07:46 <nikos> krit1: the browser has this problem internally
21:08:12 <nikos> ... we could move discussion to the mailing list? I tried to explain on public-fx
21:08:24 <nikos> shepazu: there's the bounding box - the internal calcualtion of this
21:08:31 <nikos> ... and the return value of the get bounding box function exposed to users
21:08:36 <nikos> ... they don't have to return the same result
21:08:46 <nikos> ... we could introduce a change to affect this
21:09:12 <nikos> ... I'll try to explain
21:09:58 <nikos> ... let's say we have a new bounding box function getBBox2
21:10:08 <nikos> ... it can return whatever we want because there's no dependency chain
21:10:19 <nikos> krit1: it can't be calculated internally
21:10:26 <nikos> ... we expose exactly what we calculate internally
21:11:17 <nikos> heycam: implementations at the moment. If they supported 3d transforms on SVG. There is no way to mathematically resolve the percentage values
21:13:16 <nikos> shepazu: I think we're talking about two different issues
21:14:10 <krit1> Zakim, who is on the call?
21:14:10 <Zakim> On the phone I see krit, nikos, heycam, stagaki, birtles, cyril (muted), Thomas_Smailus, Doug_Schepers
21:14:42 <nikos> [heycam summarises]
21:15:02 <nikos> krit1: let's continue on the mailing list
21:15:15 <nikos> Topic: Confirm location and dates for 1st F2F of 2014
21:15:35 <nikos> heycam: Dirk you've been co-ordinating with CSS?
21:16:11 <nikos> krit1: CSS group is happy to meet for half day as I said previously
21:16:18 <nikos> ... fx on second half of 29th Jan
21:16:24 <nikos> ... SVG on 30-31 Jan
21:16:30 <nikos> ... in Seattle
21:16:56 <nikos> ... I've booked the rooms
21:17:25 <nikos> RESOLUTION: SVG WG will meet in Seattle 30-31 January 2014 with FX half day on 29th January
21:18:08 <nikos> Topic: SVG Glyphs in OpenType specification
21:18:24 <cyril> zakim, unmute me
21:18:24 <Zakim> cyril should no longer be muted
21:18:48 <nikos> heycam: There was a second coloured fonts meeting which Chris was at
21:18:52 <nikos> ... he sent a summary to the list
21:19:16 <nikos> ... that was one of the reasons Sairus wanted the spec completed
21:19:26 <nikos> s/completed/stabilised
21:19:51 <nikos> ... the spec will serve as introduction to the discussion for ISO in January
21:20:04 <nikos> ... so that was the point of moving the community group draft to spec text
21:20:26 <nikos> cyril: Chris is saying there are 4 proposals
21:20:35 <nikos> ... Microsoft's, Apple's, etc
21:20:45 <nikos> heycam: Google and Apple are bitmap formats
21:20:56 <nikos> ... Google is something like embedding PNGs
21:21:06 <nikos> ... Microsoft has solid coloured filled vectors
21:21:42 <nikos> cyril: in terms of process. There's a call for proposals in ISO
21:21:43 <jdaggett> jdaggett has joined #svg
21:21:48 <nikos> ... how does the community group satisfy the requirements?
21:22:16 <nikos> heycam: someone needs to write up a document addressing how the specification matches each requirement
21:22:52 <nikos> ... there are requirements around lower power devices
21:23:00 <nikos> ... it seems the list of requirements covers all the bases
21:23:22 <nikos> http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0020.html
21:23:46 <Zakim> -cyril
21:23:47 <nikos> cyril: I think normally one is picked to continue and the interesting parts of others are merged in
21:24:22 <Zakim> +Cyril
21:24:39 <nikos> nikos: there's already been some merging - Microsoft palettes into SVG in OT
21:25:27 <nikos> heycam: one font could have the palette table plus Microsoft's multi coloured glyph table and SVG and use the palette in both
21:25:44 <nikos> krit1: benefits of the other proposals are that they are easy to implement in the font system
21:25:53 <nikos> ... but they do not have animations or things like that
21:26:56 <nikos> nikos: but there's no way to specify a colour that wasn't already defined in the font?
21:28:24 <nikos> shepazu: Does Adobe have a position?
21:28:49 <nikos> krit1: I'm not sure. Sairus is obviously working on SVG in OT but I don't know if it's personally motivated or on behalf of the company
21:29:03 <nikos> cyril: who will be representing SVG in OT at the MPEG meeting?
21:29:13 <nikos> heycam: I'm not sure
21:29:23 <nikos> ... in San Jose so convenient for Sairus
21:29:39 <nikos> cyril: meeting is 13th-17th
21:29:43 <Zakim> -Thomas_Smailus
21:29:48 <nikos> ... I will be there
21:30:24 <Zakim> -heycam
21:30:25 <Zakim> -Doug_Schepers
21:30:27 <Zakim> -krit
21:30:33 <Zakim> -Cyril
21:30:35 <Zakim> -stagaki
21:30:38 <Zakim> -nikos
21:30:44 <nikos> RRSAgent, make minutes
21:30:44 <RRSAgent> I have made the request to generate http://www.w3.org/2013/10/17-svg-minutes.html nikos
21:30:54 <Zakim> -birtles
21:30:56 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:30:56 <Zakim> Attendees were krit, nikos, [IPcaller], heycam, birtles, stagaki, Thomas_Smailus, cyril, Doug_Schepers
22:05:57 <glenn> glenn has joined #svg
22:41:37 <birtles> birtles has joined #svg
23:19:13 <thorton> thorton has joined #svg
23:42:39 <jdaggett> jdaggett has joined #svg