20:57:50 <RRSAgent> RRSAgent has joined #svg
20:57:50 <RRSAgent> logging to http://www.w3.org/2012/08/09-svg-irc
20:57:52 <trackbot> RRSAgent, make logs public
20:57:52 <Zakim> Zakim has joined #svg
20:57:54 <trackbot> Zakim, this will be GA_SVGWG
20:57:54 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)5:00PM scheduled to start in 3 minutes
20:57:55 <trackbot> Meeting: SVG Working Group Teleconference
20:57:55 <trackbot> Date: 09 August 2012
20:58:07 <Zakim> GA_SVGWG(SVG1)5:00PM has now started
20:58:13 <Zakim> + +1.415.832.aaaa
20:59:34 <Zakim> +??P7
20:59:36 <heycam> Zakim, ??P7 is me
20:59:36 <Zakim> +heycam; got it
20:59:53 <Zakim> +??P11
21:00:03 <birtles> Zakim, ??P11 is me
21:00:03 <krit> Zakim, is me
21:00:03 <Zakim> + +61.2.980.5.aabb
21:00:03 <Zakim> +birtles; got it
21:00:03 <Zakim> I don't understand 'is me', krit
21:00:16 <krit> zakim, aaaa is me
21:00:17 <Zakim> +krit; got it
21:00:22 <nikos> Zakim, +61.2 is me
21:00:22 <Zakim> +nikos; got it
21:00:40 <Zakim> +Kelvin
21:00:54 <hober> hober has joined #svg
21:01:31 <Zakim> +[Apple]
21:01:36 <hober> Zakim, Apple has me
21:01:36 <Zakim> +hober; got it
21:01:52 <cabanier> cabanier has joined #svg
21:02:02 <heycam> Chair: Cameron
21:02:08 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0092.html
21:03:36 <heycam> ScribeNick: heycam
21:03:41 <heycam> Topic: Publishing Filters
21:03:47 <heycam> http://www.w3.org/mid/92709D97-07E6-4031-90C3-A4B4F7AE3D2A@adobe.com
21:04:03 <heycam> Dirk: worked on Filters for quite some time
21:04:14 <heycam> … it's based on SVG filters + new effects, like drop shadow, and shorthand filters for CSS
21:04:16 <krit> file:///Users/dschulze/Documents/hg/FXTF/filters/index.html
21:04:17 <Tav> Tav has joined #svg
21:04:21 <heycam> … something also added was CSS Shaders
21:04:26 <Kelvin> Kelvin has joined #svg
21:04:35 <heycam> … we updated the CSS Shader security model according to comments on the list
21:04:40 <Zakim> +Doug_Schepers
21:04:40 <heycam> … we think we've covered the issues
21:04:45 <heycam> … it's in good shape to get published now
21:04:54 <krit> :(
21:04:57 <birtles> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html ?
21:05:02 <heycam> CM: it's the FPWD
21:05:03 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
21:05:07 <heycam> … although the document has been split out for a while
21:06:01 <heycam> Doug: when did Shaders get added to the Filters spec?
21:06:15 <heycam> Dirk: a few months
21:06:20 <heycam> RC: I think at least a year
21:06:52 <Zakim> + +1.612.789.aacc
21:07:02 <heycam> CM: do you think the shaders stuff is going to slow down the rest of the document?
21:07:06 <heycam> Doug: yes there's a risk
21:07:12 <heycam> Dirk: there's not two implementations
21:07:24 <heycam> … but this is just asking for a FPWD
21:07:31 <heycam> RC: we don't need two implementations yet?
21:07:32 <heycam> Doug: no
21:07:47 <heycam> {7}
21:09:08 <heycam> … my only concern, pro forma, filters is moving forward at a good pace, and I suspect we will have interop on filters, considering we have tests already
21:09:15 <heycam> RC: for the filter shorthands we haven't heard from other people yet either
21:09:34 <heycam> Doug: do you think time frame wise, we'll be able to accomplish all of this in the same time frame?
21:09:42 <Tav> zakim, +1.612 is me
21:09:42 <Zakim> +Tav; got it
21:09:46 <heycam> Dirk: I think they belong together and that's why they should be together
21:10:43 <heycam> Doug: I'm just wondering if it should be a separate spec
21:11:04 <heycam> … don't want to argue at this point, but down the track we might need to reevaluate
21:11:17 <heycam> … can we have a Test Facilitator?
21:11:32 <heycam> Dirk: I'm starting writing a test suite
21:11:54 <heycam> CM: I find the document a bit hard to read with its style
21:13:02 <heycam> Dirk: you can click the "default style" link at the top right
21:13:39 <heycam> Dirk: I agree we need some tests
21:14:14 <heycam> … I could volunteer to be the Test Facilitator for the document
21:15:44 <heycam> NA: why are you not listed in the editors?
21:15:48 <heycam> Dirk: I wanted to ask about that
21:15:55 <heycam> CM: it's fine from our side for you to be an editor of the document
21:16:19 <heycam> RESOLUTION: SVG WG is happy to publish Filter Effects FPWD
21:16:41 <heycam> Topic: Kelvin Lawrance introduction
21:16:48 <heycam> KL: I know a lot of you came on after I left
21:16:54 <heycam> … I was on the original SVG WG last century
21:17:02 <heycam> … and stayed with it mostly to the end, writing a viewer and test cases
21:17:09 <heycam> … I stopped being a member about the time just before 1.0 was published
21:17:27 <Zakim> -krit
21:17:35 <heycam> … the reason IBM has rejoined is that I and Rich Schwerdtfeger have been following SVG and hoping for it to become mainstream
21:17:46 <heycam> … Rich asked me to work with him on accessibility for SVG
21:18:10 <heycam> … we did a gap analysis here at IBM, and we wanted to engage with you guys on what it would take, we think, to add some more interesting accessbility features to it
21:18:17 <heycam> … we need our products to be more accessibility, so we're motivated
21:18:30 <heycam> … I'm in Austin, TX
21:18:37 <heycam> … I'm part of the emerging standards group
21:18:51 <heycam> … continued to follow SVG as it evolved
21:19:00 <Zakim> + +1.415.832.aadd
21:19:16 <krit> Zakim, aadd is me
21:19:16 <Zakim> +krit; got it
21:19:16 <cabanier1> cabanier1 has joined #svg
21:19:23 <heycam> Topic: Moving Masking to a FX specification
21:19:28 <heycam> http://www.w3.org/mid/4D5839DF-60ED-4EBF-88D8-FD6073DFEDC3@adobe.com
21:19:44 <heycam> Dirk: the CSS WG was already looking at specifying masking in CSS in general
21:19:52 <heycam> … we already have an implementation for masking in CSS
21:20:02 <heycam> … it looks like we can just move both specifications together, the CSS part of masking and our masking in SVG
21:20:08 <heycam> … and make it possible to apply both masks to both content
21:20:17 <heycam> … Ted already volunteered to look at that
21:20:34 <heycam> TO: nothing much to add, I think from a WebKit perspective we've had a good experience with people using masks
21:20:59 <heycam> … our existing syntax is straightforward, so I think the reason why it didn't move forward in CSS a few years ago is that SVG already had masks, and there was concerns with feature overlap
21:21:01 <heycam> … and incompatibility
21:21:11 <heycam> … if we can do this in FX with an eye towards harmonising I think that would be fantastic
21:21:28 <heycam> CM: I think it makes complete sense
21:21:40 <heycam> Dirk: do we want to move clip-path to the specification as well? or just mask?
21:21:58 <heycam> CM: good question, they're simliar things
21:22:14 <heycam> Dirk: I think it would make sense to allow clip-path applying to HTML content
21:22:19 <heycam> … and Mozilla already supports this
21:22:35 <heycam> RC: would the clipPath be SVG content?
21:23:56 <heycam> CM: I'm wondering if it makes sense to have a simpler syntax for clip-path than referencing an SVG fragment for the path
21:24:04 <heycam> Dirk: I think we can worry about it later
21:24:12 <heycam> TO: I think of clipPath as one of the reasons to use SVG
21:25:25 <heycam> CM: I think we could make clip-path apply to HTML elements
21:25:50 <heycam> Tav: I'd like that, but I don't want to see a path syntax in CSS
21:26:13 <heycam> KL: I view masking as more aligned with filter effects, for example I see gradients going over a picture, but clipPath is more of a geometrical thing
21:26:38 <heycam> CM: I think authors think of them similarly though
21:26:55 <heycam> Dirk: besides referencing an SVG clipPath, maybe you can have a shorthand with a point list
21:27:38 <heycam> CM: maybe we can just start with mask, and add it in later if people request?
21:27:48 <heycam> BB: I would say put it in, and drop it if people think it's misplaced
21:28:03 <heycam> RC: defining a path syntax in CSS would be more contentious
21:28:29 <heycam> … if Regions proceeds rapidly then we can reuse that syntax
21:28:40 <heycam> s/Regions/Exclusions/
21:28:55 <heycam> CM: who was planning on being the editor?
21:29:16 <heycam> TO: I just became one of the HTML editors so I'm not sure I'll be able to have time for it
21:29:33 <heycam> … but I'm happy to try to help if someone wants to run with it, I'll chip in
21:32:27 <heycam> RESOLUTION: We will split out Masking into an FX document and combine it with CSS masking (-webkit-mask)
21:32:58 <heycam> CM: Brian would you be interested in editing?
21:33:11 <heycam> BB: I could get the document started but won't have time to edit it
21:33:38 <heycam> Topic: Registration for F2F in Switzerland
21:33:44 <heycam> http://www.w3.org/mid/501CAE02.6020809@mcc.id.au
21:33:55 <Zakim> -[Apple]
21:34:23 <heycam> CM: since Andreas is organising the hotel please respond ASAP
21:35:10 <heycam> Topic: Transformable masks
21:35:15 <heycam> http://www.w3.org/mid/F3A628B4-3EDB-4B38-BE96-3FF4D3CF8F0A@adobe.com
21:35:29 <heycam> CM: this is why we don't have maskTransform on <mask>?
21:35:42 <heycam> Dirk: other resources are transformable, like clipPath. why is mask not transformable?
21:36:10 <heycam> CM: I can't think of a good reason why not
21:37:25 <heycam> CM: so gradients use gradientTransform
21:37:29 <heycam> Dirk: but clipPath uses transform
21:37:34 <heycam> … I think we should just use the name transform
21:37:40 <heycam> … (there's patternTransform too)
21:37:56 <heycam> CM: and in the Transforms spec these are just presentation attributes for the 'transform' property?
21:37:57 <heycam> Dirk: yes
21:38:28 <heycam> CM: I am not opposed to mask being transformable
21:38:51 <heycam> BB: sounds good
21:38:57 <heycam> NA: can't think of a reason why not
21:39:12 <heycam> KL: I can try to ask some of the guys back then who might remember
21:39:23 <heycam> … I can guess, but I could ask JonF
21:39:44 <heycam> Tav: this is why I've been pushing for annotations in the spec
21:39:59 <heycam> ACTION: Kelvin to ask JonF why mask doesn't have transform
21:39:59 <trackbot> Created ACTION-3338 - Ask JonF why mask doesn't have transform [on Kelvin Lawrence - due 2012-08-16].
21:40:51 <heycam> CM: with clipPath, do the transforms from ancestor elements contribute to the clipPath's transform?
21:40:56 <heycam> … but patternTransform wouldn't?
21:41:01 <heycam> Dirk: patternTransform transforms the content
21:41:59 <heycam> … for clipPath, I just know we apply that single transform attribute
21:42:29 <heycam> RC: for Adobe's imaging, our soft masks don't have matrices
21:42:35 <heycam> … which might be why <mask> doesn't have a transform
21:43:02 <heycam> Topic: getBBox() with zero width or height shapes
21:43:09 <heycam> http://www.w3.org/mid/CAJgFLLvPwPxviX+BfuK4e=Y9kk3zFz5zE56BakHgZnQqke0mzg@mail.gmail.com
21:43:51 <heycam> CM: long thread on www-svg about whether getBBox should return a correctly positioned zero sized bbox for a shape with zero width or height
21:44:03 <heycam> Dirk: from the WebKit side, for normal shapes this should not be a big deal
21:44:13 <heycam> … for ellipse, circle and rect
21:44:22 <heycam> … with path I'm not that sure, we might have problems with it, but it's definitely solvable
21:44:39 <heycam> … display:none is a separate topic
21:46:06 <heycam> CM: I tend to agree with Dirk that returning a correctly positioned bbox would be preferable
21:46:26 <heycam> RC: getting a tight bounding box is a bit more work than a loose one, for beziers
21:47:46 <Zakim> -heycam
21:49:04 <Kelvin> I checked with JonF and he confirmed what I suspected that back in 1998-2001 when we did the original SVG work, we felt that as Masks would be applied at the lowest level of the graphics rendering engine that it would be too much to ask the engine to be able to do vector transforms that late in the pipeline.
21:50:01 <Zakim> +[IPcaller]
21:50:04 <heycam> Zakim, [ is me
21:50:04 <Zakim> +heycam; got it
21:52:15 <heycam> BB: I think I agree with you
21:52:22 <heycam> s/you/Cameron/
21:53:05 <heycam> CM: I think it's just more useful for authors too
21:53:43 <heycam> … if it's difficult for the underlying library, then that's just some more work that needs to be done to get that working
21:53:56 <heycam> Dirk: for Gecko and WebKit, we do not make a rendering tree when display:none
21:54:10 <heycam> … we won't implement that do something like a shadow render tree just to make getBBox() on a display:none possible
21:54:32 <heycam> … if we really want to have a bounding box you can set visibility:hidden
21:54:51 <jet> jet has joined #svg
21:55:36 <heycam> … looks like IE does not do getBBox on display:none elements either
21:56:17 <heycam> CM: I'm wondering how difficult it really is
21:57:01 <heycam> … you could just resolve the style on the element, and look at the transforms up the tree, as a one off when you call getBBox
21:57:15 <heycam> Dirk: there's also the difficulty of a display:none child not contributing to its parent's bbox
21:57:52 <heycam> RC: you could say display:none elements don't have style
21:58:06 <heycam> Dirk: we won't be implementing it for WebKit
21:58:37 <heycam> CM: you agree in principle that it would be useful?
21:58:50 <heycam> Dirk: yes, but implementation feedback is that it won't be implementable in WebKit
21:59:31 <heycam> CM: if all implementations except one don't handle getBBox on display:none elements, then that's the point where we should question whether it's useful to have it in the spec
22:00:47 <heycam> … but it sounds like everyone here is in favour of returning a bounding box for a zero-sized shape?
22:01:27 <heycam> RESOLUTION: Zero-sized shapes will continue to return a properly positioned and sized bounding box
22:02:11 <heycam> Doug: touching on pointer events, we still don't have a hit testing model for the web
22:02:13 <Zakim> -birtles
22:02:24 <heycam> … we were going to have it in css3-ui, but it was put off
22:03:08 <heycam> … another place where we need to talk about pointer events is masking and shaders
22:03:23 <heycam> … and touch interfaces are also going to be relevant, and in the Web Events WG we're working on touch interface stuff
22:03:46 <heycam> … CSS has introduced the idea of there being a different granularity of the pointer
22:03:59 <heycam> … I'm wondering where pointer events should be specified
22:04:04 <heycam> … I don't think in SVG, it's more general
22:04:07 <heycam> Dirk: CSS?
22:04:10 <heycam> Doug: could be
22:04:23 <heycam> … but we're also talking about events
22:04:31 <heycam> … not sure why it's better there than anywhere else
22:04:43 <heycam> Dirk: just because it's set with a CSS property
22:04:52 <heycam> Doug: but it's also any kind of pointer/touch events
22:05:11 <heycam> … and I'm not sure the expertise is in that WG for this work
22:06:04 <heycam> CM: CSS is kind of a common ground between the different presentation languages like SVG and HTML
22:07:03 <heycam> Topic: Filter clipping region
22:07:09 <heycam> http://www.w3.org/mid/F8B16E4C-0C49-4ADB-B4D5-1AEDF84741A6@adobe.com
22:07:20 <heycam> Dirk: as an introduction, filters have different primitives
22:07:25 <heycam> … each primitive can have a so called subregion
22:07:31 <heycam> … SVG 1.1 says the subregion is a hard clipping region
22:07:40 <heycam> … a problem we always had was that 1.1 wasn't clear what it clips
22:07:43 <heycam> … output, input, both?
22:07:53 <heycam> … we had a resolution that it clips both input and output for a filter primtiive
22:07:58 <heycam> … this was also moved to SVG 1.1 SE
22:08:16 <heycam> … but the discussion in the mailing list was just that it should be doing output clipping
22:08:20 <heycam> … I did some tests of browsers
22:08:29 <heycam> … it looks like IE, Firefox and WebKit just do output clipping
22:08:34 <heycam> … and Opera just do input clipping
22:08:41 <heycam> … so nobody does what the spec says
22:08:53 <heycam> … should we move from input & ouptut clipping to something more common? or keep it as it is?
22:09:06 <heycam> CM: I don't have a good sense of what is more useful
22:09:11 <heycam> Dirk: you can emulate everything
22:09:23 <heycam> … if you only have output clipping, you can emulate input clipping anyway
22:09:26 <heycam> … and vice versa
22:09:31 <heycam> … so it doesn't really matter
22:09:37 <heycam> … but we should have the same default behaviour
22:09:44 <heycam> RC: emulate with an extra filter?
22:09:49 <heycam> Dirk: feOffset
22:09:57 <heycam> Tav: is the major purpose of this to avoid doing ltos of computations?
22:10:02 <heycam> Dirk: it's just an edge case
22:11:53 <heycam> Tav: if you have a blur with high values you have to look at quite some distance
22:12:01 <heycam> … so it's computationally significant
22:12:07 <heycam> RC: this is input clipping
22:12:18 <heycam> Dirk: well the limit for infinite stuff is the filter region
22:12:34 <heycam> … the reason why I'm asking is because IE 10 is shipping soon and is in feature freeze
22:12:44 <heycam> … and if the spec is inconsistent with IE it might be bad
22:12:54 <heycam> … I don't want to rely on one implementation, but following IE here might make sense
22:13:06 <heycam> RC: could they just treat it as a bug and fix it?
22:13:11 <heycam> Dirk: might take a while
22:13:32 <heycam> … my opinion is to change the spec just to do output clipping
22:13:41 <heycam> NA: I don't think the spec does imply that you should do input clipping
22:13:56 <heycam> Dirk: SVG 1.1 SE was clarified that subregions do clip inputs
22:14:11 <krit> http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion
22:14:22 <krit> "http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveXAttribute, http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveYAttribute, http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveWidthAttribute and http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveHeightAttribute act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result."
22:15:39 <heycam> CM: I lean towards clipping just output, but I want to hear what Erik says
22:15:48 <heycam> Dirk: for WebKit we could do either easily
22:15:56 <heycam> CM: us too
22:16:41 <heycam> ACTION: Cameron to email Erik to ask his opinion of filter clipping
22:16:41 <trackbot> Created ACTION-3339 - Email Erik to ask his opinion of filter clipping [on Cameron McCormack - due 2012-08-16].
22:18:24 <Zakim> -krit
22:18:25 <Zakim> -nikos
22:18:25 <Zakim> -heycam
22:18:26 <Zakim> -Kelvin
22:18:26 <Zakim> -Tav
22:19:50 <heycam> RRSAgent, end telcon
22:19:50 <RRSAgent> I'm logging. I don't understand 'end telcon', heycam.  Try /msg RRSAgent help
22:19:55 <heycam> trackbot, end telcon
22:19:55 <trackbot> Zakim, list attendees
22:19:55 <Zakim> As of this point the attendees have been +1.415.832.aaaa, heycam, +61.2.980.5.aabb, birtles, krit, nikos, Kelvin, hober, Doug_Schepers, +1.612.789.aacc, Tav, +1.415.832.aadd,
22:19:59 <Zakim> ... [IPcaller]
22:20:03 <trackbot> RRSAgent, please draft minutes
22:20:03 <RRSAgent> I have made the request to generate http://www.w3.org/2012/08/09-svg-minutes.html trackbot
22:20:04 <trackbot> RRSAgent, bye
22:20:04 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2012/08/09-svg-actions.rdf :
22:20:04 <RRSAgent> ACTION: Kelvin to ask JonF why mask doesn't have transform [1]
22:20:04 <RRSAgent>   recorded in http://www.w3.org/2012/08/09-svg-irc#T21-39-59
22:20:04 <RRSAgent> ACTION: Cameron to email Erik to ask his opinion of filter clipping [2]
22:20:04 <RRSAgent>   recorded in http://www.w3.org/2012/08/09-svg-irc#T22-16-41