20:29:21 <RRSAgent> RRSAgent has joined #svg
20:29:21 <RRSAgent> logging to http://www.w3.org/2013/10/03-svg-irc
20:29:23 <trackbot> RRSAgent, make logs public
20:29:23 <Zakim> Zakim has joined #svg
20:29:25 <trackbot> Zakim, this will be GA_SVGWG
20:29:25 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:30PM already started
20:29:26 <trackbot> Meeting: SVG Working Group Teleconference
20:29:26 <trackbot> Date: 03 October 2013
20:29:41 <Zakim> + +49.341.263.2.aabb
20:29:45 <krit> krit has joined #svg
20:29:59 <Zakim> +[IPcaller]
20:30:09 <ed> Zakim, [IP is me
20:30:09 <Zakim> +ed; got it
20:30:32 <Zakim> +??P9
20:30:37 <Zakim> + +61.2.980.5.aacc
20:30:55 <stakagi> zakim, +??P9 is me
20:30:55 <Zakim> sorry, stakagi, I do not recognize a party named '+??P9'
20:31:07 <Zakim> +Doug_Schepers
20:31:08 <krit> Zakim, who is on the call?
20:31:08 <Zakim> On the phone I see +1.425.373.aaaa, +49.341.263.2.aabb, ed, ??P9, +61.2.980.5.aacc, Doug_Schepers
20:31:10 <nikos> Zakim, +61.2 is me
20:31:10 <Zakim> +nikos; got it
20:31:23 <krit> Zakim, aabb is me
20:31:23 <Zakim> +krit; got it
20:31:49 <ed> agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0003.html
20:31:50 <Zakim> +cabanier
20:32:10 <stakagi> zakim, ??P9 is me
20:32:10 <Zakim> +stakagi; got it
20:33:09 <ed> Zakim, +1.425 is thomas
20:33:09 <Zakim> +thomas; got it
20:34:05 <ed> chair: ed
20:34:20 <cabanier> scribenick: cabanier
20:34:32 <ed> regrets: CL, Luc, Cyril, heycam, brian, rich
20:34:48 <cabanier> topic: TPAC 2013 dial-in
20:35:09 <cabanier> ed: does anyone need to dial in to TPAC so we can ask for conference equipment
20:35:18 <cabanier> krit: who is not going?
20:35:22 <Zakim> +??P14
20:35:34 <Tav> zakim, 14 is me
20:35:34 <Zakim> sorry, Tav, I do not recognize a party named '14'
20:35:52 <Tav> zakim, ??P14 is me
20:35:52 <Zakim> +Tav; got it
20:35:54 <cabanier> ThomasSmailus: I'm not
20:36:05 <cabanier> ThomasSmailus: yes. I should dial in
20:36:34 <cabanier> ed: in that case, let us know what topics so we can schedule them
20:37:43 <nikos> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131114&p1=240&p2=1232&p3=234
20:38:16 <cabanier> ed: I'll take an action to arrange conference equipment
20:38:47 <cabanier> ed: me and heycam will prepare topic
20:39:01 <cabanier> ed: please let us know and we'll put them on the wiki page
20:39:09 <stakagi> hi
20:39:23 <stakagi> Yes
20:39:34 <ed> s/prepare topic/prepare an agenda/
20:39:41 <cabanier> shepazu: it would be good to talk about mapping
20:40:05 <cabanier> topic: Modes of SVG SVG integration
20:40:14 <cabanier> link: https://svgwg.org/specs/integration/
20:40:25 <krit> https://svgwg.org/specs/integration/
20:40:42 <cabanier> krit: we have this spec and shepazu mentioned the intent
20:40:53 <cabanier> krit: I wonder if we need all these categories
20:41:16 <cabanier> krit: the only really important ones are secure mode and insecure mode
20:42:02 <cabanier> krit: I'm not sure if these details should be specified. the focus should be on security modes
20:42:13 <cabanier> krit: I think that should be the main focus
20:42:19 <cabanier> krit: I wanted to check
20:42:26 <cabanier> shepazu: why do you think that?
20:42:53 <cabanier> krit: because browsers don't want to go into these categories
20:43:04 <cabanier> krit: maybe you just want to support static mode
20:43:14 <cabanier> krit: it could depend on the device
20:43:32 <cabanier> shepazu: this is contrary to the requests from people
20:43:45 <cabanier> shepazu: they want different categories.
20:44:34 <cabanier> shepazu: implementors like inkscape don't offer declaritive animation
20:44:46 <cabanier> krit: for clarification, I'm fine with that
20:45:02 <cabanier> krit: features can be disabled by browsers.
20:45:27 <cabanier> krit: but they might not want to implement a certain category
20:45:47 <cabanier> shepazu: but this is what this specification should do
20:46:25 <cabanier> krit: we should say that there are modules and browsers can choose which ones they implement
20:46:55 <cabanier> shepazu: what's the harm in having categories?
20:47:50 <cabanier> shepazu: it harms svg if we don't have these
20:48:11 <cabanier> shepazu: 1. implementations are the consumer of this spec
20:48:43 <cabanier> shepazu: 2. other specifications are referencing this spec. so they have a category of what subset they support
20:48:53 <cabanier> krit: for me, security is the main part
20:49:15 <cabanier> krit: we can have secure and insecure and then have subcategories
20:49:44 <cabanier> shepazu: I have no problem with security being the prime category. there is animated and secure animated
20:50:20 <cabanier> shepazu: not everyone follows the spec. for instance css animation is applied
20:50:38 <cabanier> shepazu: so, security is ok to be the main mode, but why is that the most important one
20:51:04 <cabanier> krit: because security is the most pressing feature today
20:51:43 <cabanier> shepazu: the author/developer comes first for a spec.
20:52:14 <cabanier> shepazu: it's ok to make security the prime thing but others are needed as well to help authors
20:52:30 <cabanier> shepazu: there should be a secure/insecure mode for each target
20:53:47 <cabanier> shepazu: what I care about is that publisher want to know what the capabilites of the devices are
20:53:58 <cabanier> shepazu: this seems obvious
20:54:12 <cabanier> shepazu: it would be nice if someone can agree with me
20:54:48 <cabanier> ThomasSmailus: I can see the value
20:55:15 <cabanier> shepazu: we should push implementations to these categories
20:55:25 <cabanier> shepazu: I'm ok with dropping unrealistic modes
20:55:45 <cabanier> ThomasSmailus: so, if you target a mode, you implement everything for that mode?
20:55:47 <cabanier> shepazu: yes
20:56:11 <cabanier> krit: SVG fonts for instance can be optional so browser can choose
20:56:20 <cabanier> shepazu: optional features are bad ideas
20:56:32 <cabanier> ThomasSmailus: they might weaken the status
20:56:58 <cabanier> krit: optional features can be a good idea
20:57:08 <cabanier> nikos: there are probably not that many optional features
20:57:23 <cabanier> nikos: so we'll probably only have a few modes
20:57:30 <cabanier> krit: right now, nothing is optional
20:58:03 <cabanier> shepazu: I think you associate scripting with a security mode
20:58:22 <cabanier> shepazu: the goal is to profile what the ua is trying to accomplish
20:58:54 <cabanier> krit: in the security mode you can't do scripting, but in insecure mode, you *could* do scripting
20:59:13 <cabanier> krit: for cors, it's different
20:59:43 <cabanier> krit: but in a security mode, you can load resources from external resources through script
21:00:03 <cabanier> shepazu: we should define that SVG needs to define CORs
21:00:11 <cabanier> krit: I agree and my main focus
21:00:41 <cabanier> shepazu: some people see a <use> reference external element as a security hole
21:00:46 <cabanier> krit: yes, it can be
21:01:13 <cabanier> krit: the intergration spec should say when you can use <use>
21:01:25 <cabanier> shepazu: I would decouple script and security
21:01:38 <cabanier> krit: yes, and we should specify what UA do
21:01:54 <cabanier> shepazu: yes, but we should also guide UA's if they do something silly
21:02:28 <cabanier> shepazu: I welcome that you fork the spec and do it from another angle so we can compare them
21:03:35 <cabanier> shepazu: if you can show that a mode is useless, we can remove them unless we can back them up with reality
21:03:59 <cabanier> topic: Hit testing SVG root
21:04:30 <cabanier> shepazu: if you have a <div> and you click on it
21:04:48 <ed> s/ed: please let us know and we'll put them on the wiki page/ed: please let us know what topics you'd like to discuss at TPAC (feel free to use the agenda request wikipage) and we'll put them on the agenda/
21:05:00 <cabanier> shepazu: and there 2 <p>'s and you click on the space between the <p>'s
21:05:05 <cabanier> shepazu: what happens?
21:05:28 <cabanier> ThomasSmailus: I've added invisible object to work around that
21:05:38 <cabanier> krit: what do you want to have hit?
21:05:43 <cabanier> krit: what is the problem?
21:06:19 <cabanier> shepazu: what if I'm writing an application, and there's an SVG on top of the document and I want to click on a paragraph and annotate it
21:06:34 <cabanier> krit: so you want the svg to be ignore?
21:06:38 <cabanier> shepazu: yes
21:07:16 <cabanier> shepazu: I can see what you want to hit the svg root or just want to pass through
21:07:24 <cabanier> shepazu: is that the default behavior
21:08:08 <cabanier> krit: we had the same issue in webkit. if the svg had click through, it went to the background. authors didn't like it
21:08:18 <cabanier> shepazu: we should have both
21:08:33 <cabanier> shepazu: maybe by default, the svg root takes pointer events
21:08:57 <cabanier> shepazu: is unpainted one? no, it's bounding box
21:09:05 <cabanier> ed: that wouldn't cover the viewport
21:09:19 <cabanier> ed: if the root was empty for instance
21:09:30 <cabanier> shepazu: should we resolve this?
21:09:50 <cabanier> ThomasSmailus: yes. I'm running into this problem
21:10:06 <cabanier> shepazu: right now, SVG has a strange relation with backgrounds
21:11:22 <cabanier> krit: for an svg svg element we could say 'all'
21:11:26 <krit> https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
21:12:06 <cabanier> krit: if you look at the syntax. intiial is 'auto'. and you could say for svgsvgelement this means 'all'
21:13:52 <cabanier> krit: auto is not specified yet so we can do whatever we want
21:14:09 <cabanier> krit: it just happens to be implemented across all browsers
21:14:16 <cabanier> shepazu: how about nested svg elements
21:15:08 <cabanier> shepazu: could you have nested svg that would have different behavior
21:15:20 <cabanier> shepazu: or would it be the same as 'auto' on the root?
21:15:27 <cabanier> krit: not sure if we can differ
21:16:01 <cabanier> krit: on inner SVG elements
21:16:14 <cabanier> shepazu: if people think this is reasonable behavior
21:16:34 <cabanier> ed: we need test cases. It seems useful that you can pick a mode
21:17:32 <cabanier> shepazu: what is the best default? according to Dirk , webkit changed it to ...
21:17:44 <cabanier> shepazu: erik, what do you think?
21:18:13 <cabanier> ed: it really depends on your use case. usually I wanted the click to go through  but that might not be the most common one
21:18:23 <cabanier> shepazu: I will write it up and do some testing
21:18:29 <cabanier> shepazu: and you can comment
21:18:51 <TabAtkins> Note as well that if you need to change the "initial value" for particular elements, you can just do that in the UA stylesheet.  No need to actually mess with the spec.
21:18:51 <cabanier> topic: feImage and new crossOrigin attribute
21:19:07 <cabanier> krit: filter effects has a new security section
21:19:16 <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#fedisplacementmap-restrictions
21:19:17 <cabanier> krit: and this defines new behavior
21:19:28 <cabanier> krit: which makes it more complicated
21:19:49 <cabanier> krit: firefix knows about some issues and other browsers probably have it as well.
21:20:10 <cabanier> krit: color should not change behavior of timing because you can mount attacks otherwise
21:20:44 <cabanier> krit: fedisplacement map can be used to harvest information
21:21:16 <cabanier> krit: the specification is trying to identify filters which expose this risk
21:21:37 <cabanier> krit: feimage can reference external images which can have private information
21:22:06 <cabanier> krit: my idea is to have a cors attribute just like in the html image so you can specify the cors mode
21:22:27 <cabanier> krit: if it's set, you can use an feImage in a displacement map
21:22:59 <cabanier> ed: this sounds reasonable
21:23:30 <cabanier> ed: I was wondering about fetransform.
21:23:37 <cabanier> krit: it can take currentcolor
21:23:39 <ed> s/fetransform/feFlood/
21:24:29 <cabanier> ed: same origin would continue to work?
21:25:22 <cabanier> krit: probably yes
21:25:58 <cabanier> krit: my problem with same origin is that the spec is not there yet
21:26:15 <cabanier> krit: we can limit the restriction later
21:26:38 <cabanier> cabanier: will this break current behavior?
21:26:40 <cabanier> krit: yes
21:26:58 <krit> s/yes/probably/
21:27:03 <cabanier> krit: depending on the specs that are in progress
21:27:42 <cabanier> ed: can we reference it?
21:27:56 <cabanier> krit: it's in html5 from w3c
21:29:02 <cabanier> ed: I'm concerned with backward compatibility
21:29:09 <cabanier> krit: I will make a note
21:29:11 <cabanier> resolution: krit to add a crossOrigin attribute to feImage
21:29:43 <cabanier> topic: fx tf meetig in Seattle
21:29:53 <cabanier> krit: I will take care of planning
21:30:11 <cabanier> krit: mon-tues will be css. wed fxg and thurs-fri SVG
21:30:28 <Zakim> -Tav
21:30:29 <cabanier> krit: let me know if you have suggestions, please reply
21:31:21 <Zakim> -thomas
21:31:23 <Zakim> -Doug_Schepers
21:31:24 <Zakim> -nikos
21:31:25 <Zakim> -ed
21:31:27 <Zakim> -stakagi
21:31:28 <Zakim> -krit
21:31:42 <cabanier> ed: can you send out meeting notes?
21:32:35 <cabanier> thanks!
21:32:37 <ed> trackbot, end telcon
21:32:37 <trackbot> Zakim, list attendees
21:32:37 <Zakim> As of this point the attendees have been +1.425.373.aaaa, +49.341.263.2.aabb, [IPcaller], ed, +61.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier, stakagi, thomas, Tav
21:32:43 <Zakim> -cabanier
21:32:45 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:32:45 <Zakim> Attendees were +1.425.373.aaaa, +49.341.263.2.aabb, [IPcaller], ed, +61.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier, stakagi, thomas, Tav
21:32:45 <trackbot> RRSAgent, please draft minutes
21:32:45 <RRSAgent> I have made the request to generate http://www.w3.org/2013/10/03-svg-minutes.html trackbot
21:32:46 <trackbot> RRSAgent, bye
21:32:46 <RRSAgent> I see no action items