20:58:37 <RRSAgent> RRSAgent has joined #svg
20:58:38 <RRSAgent> logging to http://www.w3.org/2013/04/11-svg-irc
20:58:39 <trackbot> RRSAgent, make logs public
20:58:39 <Zakim> Zakim has joined #svg
20:58:41 <trackbot> Zakim, this will be GA_SVGWG
20:58:41 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)5:00PM already started
20:58:42 <trackbot> Meeting: SVG Working Group Teleconference
20:58:42 <trackbot> Date: 11 April 2013
20:59:14 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0056.html
20:59:31 <heycam> Zakim, who is on the call?
20:59:31 <Zakim> On the phone I see no one
21:00:49 <ed> present+ ed, heycam
21:00:58 <heycam> present+ dirk, brian
21:01:50 <ed> regrets+ thomas, cyril
21:02:10 <ed> present+ rich
21:02:20 <heycam> Scribe: Cameron
21:02:22 <heycam> ScribeNick: heycam
21:03:10 <heycam> Topic: how to handle Document object
21:03:16 <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0015.html
21:03:55 <heycam> richardschwerdtfeger: it appears that Gecko really has a full Document object
21:04:06 <heycam> … they have a reduced one for SVGDocument but that has activeElement in it
21:04:13 <heycam> … their version of Document has activeElement
21:04:18 <heycam> … but the W3C standard does not
21:04:29 <heycam> … what's the right answer for SVG?
21:04:35 <nikos> present+ nikos
21:04:48 <heycam> heycam: when you say the spec doesn't have activeElement which are you talking about?
21:04:48 <ed> chair: ed
21:04:50 <heycam> richardschwerdtfeger: DOM4
21:05:03 <heycam> … we sent a note to Anne, and he suggested using the HTML5 Document
21:06:09 <heycam> heycam: the HTML5 Document interface augments the DOM one
21:07:59 <heycam> richardschwerdtfeger: so HTML should define what activeElement means for all documents?
21:08:01 <heycam> heycam: yes
21:08:53 <heycam> krit: the HTML5 editors said that we should define the behaviour for SVG
21:09:01 <heycam> … which I don't agree with
21:09:45 <heycam> richardschwerdtfeger: when we have SVG as a standalone document, do we still want to use the HTML5 Document object?
21:09:57 <heycam> … and still address activeElement etc.?
21:11:08 <heycam> krit: yes
21:11:20 <heycam> birtles: what about for standalone SVG viewers?
21:12:25 <heycam> heycam: it's a good question
21:12:26 <heycam> birtles: boris had two proposals
21:12:38 <heycam> … one was to have SVG say for these implementations that they just implement activeElement from HTML
21:12:44 <heycam> … the other was to move activeElement up to Document
21:13:05 <heycam> s/up to Document/to DOM4/
21:13:14 <heycam> richardschwerdtfeger: Anne wasn't in favour of moving activeElement
21:13:40 <heycam> richardschwerdtfeger: I'll work on it
21:13:46 <heycam> Topic: telcon time
21:13:49 <ed> http://doodle.com/wsru9ykt2u8nqbin
21:14:17 <heycam> ed: Chris wasn't super happy with any of these times, and I think Cyril didn't like the late times
21:14:34 <heycam> … but if you look at everyone reponding here, the time that best fits everyone is Thursday 11pm in GMT+1
21:14:40 <heycam> … the second column
21:15:25 <heycam> ed: the only other option is to split the telcon in two
21:15:29 <heycam> … have two separate times every other week
21:15:33 <shepazu> (I will abide by any times)
21:15:50 <heycam> heycam: would it do the same topics?
21:16:02 <ed> s/the only other/another/
21:16:03 <heycam> krit: I don't think that's helpful
21:16:09 <heycam> birtles: another possibility is half an hour earlier
21:16:13 <heycam> … 10:30pm in Europe
21:16:41 <heycam> heycam: so that would be 6:30am for me/Nikos, 5:30am for brian?
21:17:06 <heycam> heycam: I could do that
21:17:12 <heycam> ed: fine for me too
21:17:16 <heycam> birtles: it might help, would have to ask them
21:18:16 <richardschwerdtfeger> got to drop. I will look at the minutes
21:18:34 <heycam> heycam: how about we leave it at this current time, which is the one selected in the Doodle poll, and during the week ask Chris/Tav/Cyril to see if 30 mins earlier would help
21:18:46 <heycam> ACTION: Cameron to mail public-svg-wg with 30 min earlier telcon proposal
21:18:46 <trackbot> Created ACTION-3485 - Mail public-svg-wg with 30 min earlier telcon proposal [on Cameron McCormack - due 2013-04-18].
21:19:01 <krit> krit has joined #svg
21:19:23 <heycam> Topic: SVG Integration
21:19:26 <krit> zakim, who is on the phone?
21:19:26 <Zakim> On the phone I see no one
21:20:03 <heycam> Topic: Firefox unprefixing context-fill and context-stroke
21:20:27 <nikos> scribenick: nikos
21:20:39 <nikos> heycam: as part of the SVG in OpenType work
21:20:45 <nikos> ... we originally had different names for these values
21:21:18 <nikos> ... there was something like moz-object-fill and moz-object-stroke. We discussed in Switzerland and decided to go with ContextFill and ContextStroke
21:21:28 <nikos> ... As part of the renaming work, Edwin is wondering if we can drop the prefixes
21:21:40 <nikos> ... are people happy that the functionality of these won't change?
21:22:01 <nikos> ... Currently they don't have an effect on other elements - e.g. markers
21:22:05 <nikos> krit: can we have more time to review?
21:22:31 <nikos> heycam: that's fine. The other alternative is to keep those values behind a pref - there is already a pref for the font support, we could place them behind that.
21:22:34 <nikos> ... to avoid the problem
21:22:41 <nikos> krit: Is it specified in SVG 2 or in the OT spec?
21:22:47 <nikos> heycam: In SVG 2.
21:22:58 <nikos> krit: I'm not sure if it is part of SVG 2
21:23:05 <nikos> ... if you can use it in other places then maybe
21:23:06 <heycam> https://svgwg.org/svg2-draft/painting.html#SpecifyingPaint
21:23:19 <nikos> heycam: there was an SVG requirement talked about before the font stuff
21:23:46 <nikos> nikos: They'll be useful for use as well
21:23:54 <nikos> krit: is it supported in FireFox already?
21:24:01 <nikos> heycam: no
21:24:32 <nikos> ... The plan is for them to also apply to marker
21:24:48 <nikos> krit: I'm fine with it
21:26:43 <nikos> Resolution: SVG working group don't want ContextFill and ContextStroke unprefixed in Mozilla yet, but behind a pref is ok.
21:27:09 <heycam> Scribe: Cameron
21:27:13 <heycam> ScribeNick: heycam
21:27:28 <heycam> Topic: backpointing pointer-events:boundingBox from SVG 1.2T to SVG 2
21:27:29 <heycam> ed: do we want this functionality in SVG 2?
21:27:32 <heycam> … just adding this keyword
21:27:35 <shepazu> q+
21:27:51 <heycam> ed: the feature itself allows to more easily get pointer events on text
21:27:57 <heycam> … but also for other shapes
21:28:02 <heycam> ack
21:28:13 <heycam> krit: what's the difference for text?
21:28:36 <heycam> ed: I saw someone with lots of tspans, and the bbox of all those parts be clickable
21:28:43 <heycam> … to avoid computing the rect that covers the whole thing
21:28:54 <heycam> … and if the text changes, you have to recompute
21:29:09 <heycam> … so this is telling the UA to automatically generate that clickable region from the bbox
21:29:48 <heycam> krit: I think you've already got this behaviour with WebKit and Blink?
21:29:58 <heycam> shepazu: there's a couple of different scenarios
21:30:13 <heycam> … if the text is really large, and you want to click through the circle in the middle of the O
21:30:47 <heycam> … so there's the glyph cell
21:30:57 <heycam> … and then what if you have a really big line height
21:31:11 <heycam> … do you want the space between the lines to respond to pointer events?
21:31:28 <heycam> … those are two scenarios where you might want to control this
21:31:40 <heycam> … there's already behaviour for making it not hittable, pointer-events:none
21:31:46 <heycam> … there should be a way of getting these two different things
21:31:55 <heycam> … (a) are the hole in the glyphs hit tested?
21:32:08 <heycam> … (b) also with the line height
21:32:10 <ed> s/saw someone with/recently saw an example where someone had a <text> that contained/
21:32:19 <heycam> … I don't think we should do any of this in SVG 2, we should push this forward as a CSS module
21:32:32 <heycam> … it was removed from CSS UI 3, deferred to 4
21:32:39 <heycam> … UI 3 hasn't had much progress
21:32:52 <heycam> … I propose we find someone to do a hit testing for the web spec in CSS
21:32:56 <heycam> … I have some notes on that
21:33:16 <heycam> … and I propose that we do it in that spec, and not in SVG, although there might be SVG specific behaviour
21:33:33 <heycam> krit: I spoke with Tantek and he says it'll be in CSS UI 4
21:33:45 <heycam> shepazu: it was also going to be in 3
21:34:00 <heycam> krit: the CSS WG didn't know how to solve some of the problems with it applying to HTML content
21:34:58 <heycam> shepazu: so I'm proposing we defer this to some CSS spec
21:35:01 <heycam> krit: I agree with that
21:35:15 <heycam> shepazu: I think we should make this use case clear to the CSS WG so they can specify it similarly
21:35:30 <heycam> ed: not just similarly, but with the exact same keywords
21:35:38 <heycam> shepazu: I respect that
21:35:41 <heycam> krit: we can special case anything
21:35:47 <heycam> … but we should specify things in a general manner
21:36:40 <heycam> heycam: I'm wondering whether this new value should be dash separated rather than camel case
21:36:50 <heycam> ed: making this use case clear to CSS WG would be good
21:37:02 <heycam> ACTION: Erik to talk to CSS WG about the use cases for pointer-events in SVG
21:37:02 <trackbot> Created ACTION-3486 - Talk to CSS WG about the use cases for pointer-events in SVG [on Erik Dahlström - due 2013-04-18].
21:37:15 <heycam> ed: does this spec exist yet? CSS UI 4?
21:37:19 <heycam> krit: no, just talked about
21:38:58 <heycam> Topic: SVG Integration
21:39:14 <heycam> heycam: I moved the spec here https://svgwg.org/specs/integration/
21:40:46 <birtles> (see element table: https://svgwg.org/specs/integration/#svg-elements)
21:42:17 <heycam> shepazu: it looks tidier, but it requires JS to interact/read the table
21:43:09 <heycam> … we could have three different tables, one for each spec
21:43:13 <heycam> … or maybe different subrows
21:44:15 <heycam> … like you have with "For SVG 1.1", "For SVG 1.2T", ...
21:44:47 <heycam> shepazu: you could, on top of that, have a script that hides and shows this presentation
21:45:11 <heycam> … so why do we have this table in the first place?
21:45:14 <heycam> … it's sort of a master table
21:45:27 <heycam> … the motivation was that, at the time, Hixie wanted to white list certain SVG elements for the parser
21:46:30 <heycam> … has that motivation gone by the wayside?
21:47:52 <heycam> heycam: it might well have
21:48:04 <heycam> … we did discuss not coming up new camelcase names from now on
21:48:22 <heycam> shepazu: the Integration spec was intended for any other specs that reference SVG
21:48:32 <heycam> … one of the motivations for making the spec in the first place, was I was on the ODF TC
21:48:55 <heycam> … and there was a real sense at the time, that they'd be moving on to ODF.next any day now, and they wanted to fix the way they used SVG
21:49:19 <heycam> … but ODF has lost steam, and I'm not convinced at this point that there's going to come along a similar thing that wants to reference SVG like that
21:49:33 <heycam> … HTML has re-taken over, and I'm trying to think of other specs that want to reference SVG
21:49:39 <heycam> … another one at the time was Widgets
21:49:57 <heycam> … that spec wanted to reference SVG for icons, but not enable JS
21:50:16 <heycam> … and I can see wanting to have a set of features that might be considered part of those individual profiles
21:50:22 <heycam> s/profiles/referencing modes/
21:50:46 <heycam> … when thinking about the table, think about which of these features are enabled in which referencing mode
21:51:05 <heycam> … if people are trying to make SVG just for Inkscape, static, or maybe static and animated but not with JS ...
21:51:25 <heycam> … or if people are making a Filter that they upload to a website, should certain elements be restricted ...
21:51:34 <heycam> … SVG Integration could be useful for defining these things
21:51:58 <heycam> … that could make the use of SVG consistent
21:52:04 <heycam> … across different applications
21:53:11 <heycam> heycam: I think the spec needs to still exist
21:53:19 <heycam> … I want to reference it from the fonts stuff
21:53:28 <heycam> s/fonts/SVG OpenType Fonts/
21:53:35 <heycam> ed: I think it make sense to have a list of static elements, or elements that can reference things
21:53:43 <heycam> … not sure how easy it would be to generate these tables
21:54:13 <heycam> shepazu: if we decide upon a list of these things, we could simply have a <span class> or <a class>, and those classes could be colour coded
21:54:48 <heycam> … to identify which things are allowed in which referencing mode
21:56:40 <heycam> … as a way to not balloon out the table
21:56:52 <heycam> … but we could also have the referencing mode sections list the allowed elements/attributes too
21:58:53 <heycam> shepazu: we should go through the referencing modes to see if they're still accurate
21:59:08 <heycam> … implementations do allow animations even though the "in <img>" referencing mode doesn't allow it
21:59:25 <heycam> birtles: for the use case we talked about on public-fx, an SVG avatar
21:59:32 <heycam> … so you're including an SVG image from a third party site
21:59:45 <heycam> … is it enough to say in that context that you can't use these elements and you can't have interactivity?
21:59:51 <heycam> … you'd still need to do some content filtering
22:00:38 <heycam> krit: I think this should be specified, it should not rely on the server filtering these things
22:00:45 <heycam> … the browser implementations should enforce the modes
22:00:55 <heycam> shepazu: there might be some things that are easier and some harder
22:01:08 <heycam> … enforcing reasonable coordinate spaces is a harder one
22:01:29 <heycam> birtles: if the content uses some feature in a way that makes the browser run slowly, is that something that should be specced?
22:01:38 <heycam> shepazu: maybe it uses a whole bunch of clip paths for example
22:02:18 <heycam> … I don't know if it's the kind of thing we should specify
22:02:37 <heycam> ... I think at least for V1 we should worry just about the security problems
22:03:15 <heycam> birtles: it's almost a security problem; someone can post a message to your forum with an avatar that has <path>s with ridiculous values, and suddenly people can't read your page any more
22:04:25 <heycam> shepazu: I'm going to take a stab at revising Integration to address the things we talked about
22:04:42 <heycam> … and put in a section about element/attributes restrictions in different modes
22:05:18 <heycam> shepazu: what if there were an attribute that could restrict these features? refmode='secure animated'?
22:05:42 <heycam> heycam: sounds similar to iframe sandbox
22:05:47 <heycam> ed: I think WICD had something like that too
22:06:02 <heycam> … I think Opera implemented that at one point, but don't think it took off
22:07:21 <ed> s/it took off/the params part (for controlling interactivity/scripting etc) was much used/
22:10:40 <glenn> heycam: ping?
22:11:44 <heycam> RRSAgent, make minutes
22:11:44 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/11-svg-minutes.html heycam
22:11:44 <Zakim> GA_SVGWG(SVG1)5:00PM has ended
22:11:45 <Zakim> Attendees were
22:12:13 <heycam> present+ rik
22:12:18 <heycam> RRSAgent, make minutes
22:12:18 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/11-svg-minutes.html heycam
22:13:31 <heycam> glenn, pong
22:13:34 <krit> krit has joined #svg
22:14:10 <glenn> could you comment on https://bugs.webkit.org/show_bug.cgi?id=114465#c3
22:14:47 <glenn> there seems to be some misunderstanding about why a non-callback interface object is a Function object but a callback interface is not
22:15:08 <glenn> intuitively one would think the converse holds
22:16:12 <heycam> was there confusion between "callback interface" and "callable interface"?
22:16:34 <heycam> callback interfaces never get reflected with interface objects on window
22:16:45 <glenn> probably
22:17:01 <glenn> anyway, if you could add a brief comment to that bug it would be helpful
22:17:04 <heycam> sure
22:17:25 <glenn> i can't say i have internalized the difference between callback interface and callable interface for that matter
22:22:46 <heycam> I've commented, let me know if that makes sense
22:24:12 <glenn> thanks, yes, that helps me at least, we'll see about Erik
22:25:20 <heycam> cool
22:25:42 <glenn> what's it, about 8am there?
22:26:10 <cabanier> cabanier has joined #svg
22:27:10 <heycam> yeah coming up on 8:30
22:27:35 <glenn> have a good weekend... cheers mate
23:02:46 <birtles> birtles has joined #svg
23:08:47 <cabanier1> cabanier1 has joined #svg
23:38:18 <krit> krit has joined #svg