20:29:07 <RRSAgent> RRSAgent has joined #svg
20:29:07 <RRSAgent> logging to http://www.w3.org/2013/09/19-svg-irc
20:29:09 <trackbot> RRSAgent, make logs public
20:29:09 <Zakim> Zakim has joined #svg
20:29:11 <trackbot> Zakim, this will be GA_SVGWG
20:29:11 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)4:30PM already started
20:29:12 <trackbot> Meeting: SVG Working Group Teleconference
20:29:12 <trackbot> Date: 19 September 2013
20:29:57 <Zakim> +[IPcaller]
20:30:11 <ed> Zakim, [IP is me
20:30:11 <Zakim> +ed; got it
20:30:29 <Zakim> + +61.2.980.5.aabb
20:30:33 <ed> Zakim, +1 is thomas
20:30:33 <Zakim> +thomas; got it
20:30:40 <nikos> Zakim, +61.2 is me
20:30:40 <Zakim> +nikos; got it
20:30:53 <birtles> birtles has joined #svg
20:31:00 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0100.html
20:31:06 <ed> Chair: Erik
20:31:29 <ed> Regrets: heycam, rich, chris
20:31:43 <Zakim> +??P8
20:31:57 <Zakim> +??P9
20:32:13 <Tav> zakim, +??P8 is me
20:32:13 <Zakim> sorry, Tav, I do not recognize a party named '+??P8'
20:32:15 <Zakim> +[IPcaller]
20:32:23 <birtles> Zakim, [ is me
20:32:23 <Zakim> +birtles; got it
20:32:44 <Tav> zakim, P8 is me
20:32:44 <Zakim> sorry, Tav, I do not recognize a party named 'P8'
20:32:51 <Zakim> + +49.341.263.2.aacc
20:33:06 <thorton> thorton has joined #svg
20:33:22 <ed> Zakim, pick a scribe
20:33:22 <Zakim> Not knowing who is chairing or who scribed recently, I propose nikos
20:33:31 <ed> Zakim, pick a scribe
20:33:31 <Zakim> Not knowing who is chairing or who scribed recently, I propose ??P8
20:33:35 <Zakim> + +33.6.48.38.aadd
20:33:45 <krit> krit has joined #svg
20:34:01 <ed> scribeNick: ed
20:34:22 <Luc> Luc has joined #SVG
20:34:42 <ed> Zakim, ??P8 is tav
20:34:42 <Zakim> +tav; got it
20:35:05 <ed> topic: Replace feImage's xlink:href with href
20:35:29 <Zakim> +cabanier
20:35:47 <Zakim> +Doug_Schepers
20:36:07 <ed> ed: heycam thought this was dealt with, did we have a conclusion?
20:36:09 <nikos> http://www.w3.org/2013/09/05-svg-minutes.html#action01
20:36:28 <ed> dirk: only the order wasn't decided, xlink:href or href first
20:36:50 <ed> nikos: correct, i think heycam took an action to figure it out
20:37:18 <nikos> scribe: nikos
20:37:25 <nikos> Topic: First F2F of 2013
20:37:34 <nikos> dirk: I'd like to get organisation started
20:37:41 <nikos> ... propose seattle after css meet
20:37:56 <nikos> nikos: Canon can host in Sydney if we want to come here so I can start organising that too
20:38:00 <nikos> ... depending on what the group want
20:38:56 <Tav> s/2013/2014/
20:39:45 <nikos> ed: seems like it would be a good idea to meet with css wg
20:40:41 <nikos> krit: it might be difficult to meet in last week of Jan and meet with CSS as poll shows many people unavailable
20:41:39 <nikos> https://www.w3.org/2002/09/wbs/19480/SVGF2FPlanning2014/results
20:41:54 <nikos> http://doodle.com/kzd7fuw48t6ds4fn
20:43:53 <nikos> krit: not sure if the css wg want a joint meeting
20:43:56 <nikos> ... we can discuss on the mailing list
20:44:58 <nikos> ... I'll ask the CSS wg if they would be willing/available to meet
20:45:37 <nikos> ACTION: Dirk to talk to CSS WG about whether they want to meet with SVG at first F2F of 2014
20:45:37 <trackbot> Created ACTION-3526 - Talk to css wg about whether they want to meet with svg at first f2f of 2014 [on Dirk Schulze - due 2013-09-26].
20:45:51 <nikos> Topic: Mailing lists
20:46:13 <nikos> shepazu: when we first became a public group, we decided to have 3 mailing lists
20:46:23 <nikos> ... original, www-svg, the public list that anyone can subscribe and post to
20:46:57 <nikos> ... we already had the member list only wg members can subscribe and read archives - member-svg-wg
20:47:17 <nikos> ...then we made the third list, public-svg. Anyone can read archives, only wg members can subscribe/post to
20:47:44 <nikos> ... sort of transparent but people might be posting to wrong list
20:48:09 <nikos> ed: I'd prefer we use www-svg for everything we do if possible
20:48:13 <nikos> shepazu: agree
20:48:26 <nikos> ... or we make public-svg open to anyone
20:48:56 <nikos> ... I think members post there without knowing that the public don't have full access
20:49:13 <nikos> ... to promote more discourse with the public I suggest we shut down public-svg and only have two lists
20:49:30 <nikos> ... better if we just do everything on www-svg
20:50:01 <nikos> all: agree
20:50:25 <nikos> shepazu: I'll send an email to the lists about this
20:50:38 <nikos> ACTION: Doug to email SVG mailing lists and propose shutting down public-svg
20:50:38 <trackbot> Created ACTION-3527 - Email svg mailing lists and propose shutting down public-svg [on Doug Schepers - due 2013-09-26].
20:51:12 <nikos> Topic: paint-order computed value
20:51:30 <nikos> ed: computed value or computed style?
20:51:40 <nikos> krit:  computed value or computed style?
20:51:50 <nikos> ed: just says specified value and I don't think that's the right thing to put there
20:51:58 <ed> https://svgwg.org/svg2-draft/painting.html#PaintOrder
20:52:25 <nikos> ed: definition of property says computed values are specified
20:52:33 <nikos> ... if you put paint-order normal you would get that as computed value
20:52:49 <nikos> ... I'm proposing normalise the list to three values which is the order that you draw things in
20:53:04 <nikos> krit: even if i agree this is useful to the user, it would be off from css
20:53:12 <nikos> ... in css wg we always use the specified value where possible
20:53:19 <nikos> ... because that's the computed value
20:53:26 <nikos> ... I think we shouldn't change that
20:53:34 <nikos> ... however the CSS WG is looking at a used value
20:53:40 <nikos> ... and I'd agree for 'used value'
20:53:50 <nikos> ed: the reason you want to keep the specified value?
20:53:57 <nikos> krit: consistency with other CSS properties
20:54:04 <nikos> ed: do we have any others that expand to a list like this?
20:54:11 <nikos> krit: we have some with special requirements
20:54:14 <nikos> ... eg url
20:54:27 <nikos> ... in general I'm not aware of other computed values that have special values
20:54:34 <nikos> ... the general rule is that we should return the specified value
20:55:05 <Zakim> +nikos.a
20:55:46 <Zakim> -nikos
20:56:07 <nikos> ed: the used value for the property is not exposed anywhere except to the UA
20:56:28 <nikos> ... I mean to the js DOM methods
20:57:13 <nikos> ... I guess I could live with keeping it like this for consistency
20:57:18 <nikos> ... but I don't think its efficient
20:57:23 <nikos> krit: computed value in general is not efficient
20:57:54 <nikos> RESOLUTION: keep paint-order computed value as is
20:58:11 <nikos> Topic: non-scaling-stroke in patterns and markers, how should it work
20:58:19 <nikos> http://jsfiddle.net/TfWqX/
20:58:26 <ed> http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0101.html
20:58:43 <nikos> krit: we had discussion at Adobe. Main issue is that it's very hard to implement in pattern
20:58:57 <nikos> ... I don't think further specification is needed
20:59:09 <nikos> ... but it's hard to map original viewport co-ordinate system to all elements you need to
20:59:23 <nikos> ed: Yes its tricky, which I imagine is why some browsers don't implement it
20:59:50 <nikos> thomas: does this cover the dashed line cases?
21:00:15 <nikos> ... I'll add a separate agenda item later for stroke and dashed lines
21:00:27 <nikos> ... what I've seen so far is that the dash line scales
21:00:43 <nikos> cabanier: with non-scaling stroke you'd get that
21:00:59 <shepazu> agenda+  hit-testing on SVG root
21:01:19 <nikos> ed: back to original question, I think the result is what you'd expect
21:01:50 <nikos> ... but I don't agree that it's not something that needs more specification
21:01:55 <nikos> ... because it's not defined in the spec at the moment
21:02:04 <nikos> ... think it needs to be pointed out, especially for those cases
21:02:20 <nikos> ... that's regardless of how we decide to deal with it
21:02:32 <nikos> ... in Presto, I implemented it to compensate for all scale factors
21:02:41 <nikos> ... don't think FireFox or Chrome do compensation in this case
21:03:05 <nikos> ... so easier to go with what implementations do, but I don't think it's the right choice
21:03:14 <nikos> krit: I agree but Adobe doesn't
21:03:20 <nikos> Tav: I agree with Erik
21:05:00 <nikos> ed: I could submit some test cases if that would help
21:05:42 <nikos> ... if we don't have consensus on one way or the other we'll have to come back to the topic or deal with it on the mailing list
21:06:03 <nikos> ACTION: Erik to submit test cases for non-scaling-stroke/markers in patterns and mail the list
21:06:03 <trackbot> Created ACTION-3528 - Submit test cases for non-scaling-stroke/markers in patterns and mail the list [on Erik Dahlström - due 2013-09-26].
21:06:17 <nikos> ed: I'd like more details on the objections from Adobe
21:06:45 <nikos> ACTION: Rik to query Adobe for concerns relating to non-scaling-stroke/markers in patterns and mail the list
21:06:46 <trackbot> Created ACTION-3529 - Query adobe for concerns relating to non-scaling-stroke/markers in patterns and mail the list [on Rik Cabanier - due 2013-09-26].
21:06:53 <nikos> Topic: treating U+000C as white space in attributes
21:07:12 <nikos> krit: I'm for it
21:07:15 <nikos> ed: sounds fine to me
21:07:24 <nikos> Tav: me too
21:07:44 <nikos> RESOLUTION: U+000C will be treated as white space in attributes
21:07:53 <nikos> Topic: variable-width stroke syntax
21:08:01 <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_proposal
21:08:13 <nikos> birtles: In June I proposed a syntax
21:08:19 <nikos> ... there was some feedback about that
21:08:27 <nikos> ... I've incorporated that into this updated proposal
21:08:38 <nikos> ... I think I'd like to get Tab in particular to have a look
21:08:47 <birtles> http://lists.w3.org/Archives/Public/www-svg/2013Sep/0022.html
21:08:49 <nikos> ... There was also a proposal on the list for an element based syntax
21:08:52 <birtles> ^ element-based syntax
21:09:20 <nikos> ... what do people think of the updated proposal?
21:09:30 <nikos> ... there was one suggestion to specify the type of smoothing per point
21:09:38 <nikos> ... I haven't incorporated that
21:09:49 <nikos> ... because I think we need to decide in general what options we want for smoothing
21:09:55 <nikos> ... hasn't been resolved yet
21:10:19 <nikos> ... if no one has specific suggestions right now we can continue on the list
21:10:25 <nikos> ... just wanted to bring it to your attention
21:10:42 <nikos> ... once we're happy with it then it's over to Rik or someone to work on details of the algorithm
21:10:51 <nikos> shepazu: do you have a sample page or script library that does this?
21:10:59 <nikos> birtles: no
21:11:08 <nikos> shepazu: can I propose that we make a script library to emulate this?
21:11:12 <nikos> ... I'd be happy to help
21:11:23 <nikos> birtles: if you have time to do that it would be helpful
21:11:33 <nikos> ... I don't need a formal resolution on the sytanx
21:11:43 <nikos> s/sytanx/syntax
21:11:49 <nikos> birtles: I just want to close the action
21:12:04 <nikos> shepazu: this doesn't seem to include different widths on different sides?
21:12:12 <nikos> birtles: see the asymmetric section
21:12:29 <nikos> shepazu: is that part of the initial proposal?
21:12:37 <nikos> birtles: my suggestion is to do it from the start
21:13:26 <nikos> shepazu: I have a feeling this is something that we are likely to get wrong (from the users perspective) so I'd like us to make a script library
21:13:49 <nikos> birtles: I agree, and more than syntax, that will help us decide on algorithms for smoothing and stuff
21:14:01 <nikos> shepazu: If I start a script, can anyone help?
21:14:04 <nikos> Tav: I could help
21:14:26 <nikos> ... I think it might be important to test handling of angles and line joins
21:14:37 <nikos> shepazu: I don't know if my implementation would be that sophisticated
21:14:58 <nikos> ... let's see what we can do
21:15:04 <nikos> birtles: that's a good next step
21:15:26 <nikos> ... if there's any feedback on my syntax or if anyone prefers the element based syntax that would be useful now
21:15:49 <nikos> shepazu: my initial reaction to the element based syntax was that we'd get bigger bang for buck if we had a less verbose syntax that is more like something you'd do with css
21:15:57 <nikos> ... was there anything you could do with element that you can't do with the other?
21:16:04 <nikos> birtles: easier to animate one point on the path
21:16:25 <nikos> nikos: were there a few problems with the element syntax?
21:16:33 <nikos> birtles: one is driving from CSS
21:17:31 <birtles> e.g. override just the repeat behavior, or use with @supports etc.
21:18:33 <nikos> ed: I agree it would be good to have a script library
21:18:41 <nikos> shepazu: failing that, even just images would be nice
21:18:53 <nikos> Topic: Parsing of URL, fetching undefined
21:19:13 <nikos> krit: I was talking with Anne about security model
21:19:29 <nikos> ... we seem to rely on IRI specification
21:19:37 <nikos> ... it's not very explicit on how to parse
21:19:48 <nikos> ... also not clear how data URLs are parsed or accepted
21:19:51 <nikos> ... lots of other issues
21:20:05 <nikos> ... it's not clear how the about scheme would work
21:20:07 <shepazu> q+
21:20:33 <nikos> krit: it would be great if we could specify it but I don't know if it's possible
21:20:44 <nikos> shepazu: my question is why would SVG behave any differently than HTML?
21:20:47 <nikos> krit: HTML defines it
21:20:54 <nikos> shepazu: so why don't we refer to HTML?
21:21:04 <nikos> krit: HTML is talking about attributes, etc
21:21:14 <nikos> ... we would do it in the integration spec
21:21:29 <nikos> shepazu: doesn't seem like that's in scope for SVG
21:21:34 <nikos> ... I think we should refer to something else
21:21:45 <Zakim> -tav
21:21:46 <nikos> shepazu: I don't think we do anything special
21:22:08 <nikos> shepazu: there was supposed to be a URI spec, why don't we refer to that?
21:22:20 <nikos> krit: URL just specifies URL, doesn't specify fetching model or security model
21:22:24 <Zakim> + +33.9.53.77.aaee
21:22:27 <nikos> ... we need to define that for SVG
21:22:34 <nikos> ... I hope we can reference another document too
21:22:48 <nikos> ... it's part of Anne's URL specification, still early draft and very much in flux
21:22:54 <nikos> ... we couldn't reference it
21:23:02 <nikos> shepazu: wouldn't we just refer to what HTML does?
21:23:13 <nikos> krit: still need to say that, at the moment we don't
21:23:22 <nikos> shepazu: defining says more to me than just referring
21:23:43 <nikos> ... if you just mean we say 'we treat our stuff the same way HTML treats their stuff'
21:23:46 <nikos> ... then that's fine
21:23:52 <nikos> krit: that's why I would do
21:24:18 <nikos> krit: I'm just saying we don't have anything at all in the spec right now
21:24:24 <nikos> shepazu: trivial to reference then
21:25:46 <nikos> shepazu: I suggest we resolve by defining that we will refer to HTML and only change if neccessary
21:26:18 <nikos> ... I don't think we should define security model or anything
21:26:24 <nikos> ... that seems way out of scope for SVG
21:26:51 <nikos> RESOLUTION: Add definition to SVG 2 for the model of URLs, referring to equivalent attribute values of HTML and only change where neccessary
21:28:25 <nikos> Topic: SVG hit testing
21:28:33 <nikos> shepazu: I was wondering how SVG roots do hit testing
21:28:59 <nikos> ... we'll discuss next week
21:30:54 <Zakim> -cabanier
21:30:56 <Zakim> -ed
21:30:57 <Zakim> - +33.6.48.38.aadd
21:30:58 <Zakim> -thomas
21:30:59 <Zakim> -Doug_Schepers
21:30:59 <Zakim> - +33.9.53.77.aaee
21:31:00 <Zakim> -nikos.a
21:31:00 <Zakim> -birtles
21:31:01 <Zakim> - +49.341.263.2.aacc
21:31:01 <Zakim> -??P9
21:31:02 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:31:02 <Zakim> Attendees were +1.425.373.aaaa, [IPcaller], ed, +61.2.980.5.aabb, thomas, nikos, birtles, +49.341.263.2.aacc, +33.6.48.38.aadd, tav, cabanier, Doug_Schepers, +33.9.53.77.aaee
21:31:04 <shepazu> shepazu, talking more about SVG accessibility
21:31:18 <nikos> RRSAgent, make minutes
21:31:18 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/19-svg-minutes.html nikos
21:31:41 <thorton> thorton has joined #svg