20:31:01 <RRSAgent> RRSAgent has joined #svg
20:31:01 <RRSAgent> logging to http://www.w3.org/2013/12/12-svg-irc
20:31:03 <trackbot> RRSAgent, make logs public
20:31:05 <trackbot> Zakim, this will be GA_SVGWG
20:31:05 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started
20:31:06 <trackbot> Meeting: SVG Working Group Teleconference
20:31:06 <trackbot> Date: 12 December 2013
20:31:20 <birtles> Zakim, who is on the call?
20:31:20 <Zakim> On the phone I see krit, [IPcaller], Doug_Schepers
20:31:26 <birtles> Zakim, [ is me
20:31:26 <Zakim> +birtles; got it
20:31:38 <ed> chair: ed
20:31:41 <ed> agenda: http://lists.w3.org/Archives/Public/www-svg/2013Dec/0024.html
20:32:05 <Zakim> +[IPcaller]
20:32:10 <ed> Zakim, [IP is me
20:32:10 <Zakim> +ed; got it
20:32:31 <Zakim> +??P6
20:32:36 <Zakim> +[IPcaller]
20:32:37 <heycam> Zakim, [ is me
20:32:37 <Zakim> +heycam; got it
20:32:46 <stakagi> zakim, ??P6 is me
20:32:46 <Zakim> +stakagi; got it
20:33:04 <Zakim> +??P8
20:33:20 <nikos_> nikos_ has joined #svg
20:33:50 <ed> Zakim, pick a scribe
20:33:50 <Zakim> Not knowing who is chairing or who scribed recently, I propose Doug_Schepers
20:34:48 <krit> ScribeNick: krit
20:35:15 <Zakim> +Tav
20:35:48 <krit> topic: CR MAsking
20:36:10 <krit> krit: There is nothing to discuss for today. I got comments yesterday and need to go through them.
20:36:12 <krit> ed: ok
20:36:31 <krit> topic: Filter Effects: feBlend/feComposite should in2 behave like in
20:36:46 <nikos_> scribenick: nikos
20:36:58 <nikos_> krit: We discussed this at the F2F
20:37:08 <nikos_> ... there was a comment that it's unclear what in2 means when it's not set
20:37:16 <nikos_> ... does it mean the same input as the in attribute?
20:37:27 <nikos_> ... I did some testing
20:37:46 <nikos_> ... examples on the mailing list
20:38:01 <nikos_> ... in2 is handled the same as in
20:38:13 <nikos_> ... in if it's not set takes the last primitive
20:38:35 <nikos_> ... I checked with feComposite and feBlend and looked at some source
20:38:40 <nikos_> ... it really is handled the same
20:38:52 <nikos_> ... tested on various browsers and they agree on behaviour
20:39:09 <nikos_> ... so I propose we specify that in2 should behave the same as in
20:39:32 <ed> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0159.html
20:39:44 <nikos_> ed: in your example on the mail, I'm not sure I follow
20:39:59 <nikos_> ... you're saying that the feBlend in that example there takes in2 as what?
20:40:52 <nikos_> ... in2 takes the value of the previous primitive, which is the output of the previous feFlood
20:41:05 <nikos_> ... because no value is specified explicitly for in2
20:41:43 <nikos_> Tav: this is how I originally intepreted the spec
20:41:59 <nikos_> ed: that sounds reasonable
20:42:09 <nikos_> nikos: +1
20:42:18 <nikos_> ed: I didn't read the spec that way, but the behaviour is good
20:42:42 <nikos_> ... it could be clarified
20:43:07 <nikos_> RESOLUTION: The in2 attribute of feBlend will have the same behaviour as in
20:44:31 <nikos_> Topic: Filter Effects : feBlend, supporting compositing modes or just no-composite
20:44:38 <nikos_> krit: We discussed this at the F2F
20:44:46 <nikos_> ... feBlend does a composite, but it doesn't quite do it correctly
20:44:52 <nikos_> ... it includes the backdrop twice in the result
20:45:09 <krit> s/but it doesn't quite do it correctly/with operator source over/
20:45:21 <nikos_> krit: instead it should not composite at all
20:45:52 <nikos_> ... there are cases, especially with backdrop, where you don't want to do the composite because you don't want the double backdrop contribution
20:46:01 <nikos_> ... we've discussed two options
20:46:08 <nikos_> ...1. an attribute to disable compositing
20:46:26 <nikos_> ...2. adding all compositing modes
20:46:43 <nikos_> nikos: do we need to preserve the double backdrop contribution on src-over?
20:46:45 <nikos_> krit: yes
20:46:55 <nikos_> ... in many cases you want compositing
20:47:13 <nikos_> ... but once the backdrop is involved, you want to disable compositing
20:47:29 <nikos_> heycam: will the mix-blend-mode ever give you the ability to grab the background
20:47:35 <nikos_> krit: yes
20:47:56 <nikos_> heycam: does that mean it's worth having the ability for turning off compositing for general CSS compositing as well?
20:51:29 <nikos_> Tav: in the original blending and compositing spec you specified a mix-blend-mode and a composite at the same time?
20:51:41 <nikos_> krit: yes in the second level
20:52:53 <nikos_> nikos: it's not normal to separate compositing and blending controls
20:54:12 <nikos_> krit: they're two separate things, one controls colour and one controls whether parts of the shapes are drawn
20:54:34 <nikos_> ed: is there a particular proposal we need to decide on?
20:54:46 <nikos_> krit: on the mailing list we decided not to add all compositing modes
20:55:01 <nikos_> ... instead just add a way to disable compositing
20:55:32 <nikos_> I'd suggest a 'composite' attribute that takes true/false
20:55:41 <nikos_> krit: even though I don't like true/false as attribute values
20:56:00 <nikos_> ... I'd rather do as in the HTML world where a boolean attribute can either be present or not
20:56:11 <nikos_> ... but I don't think XML allows that
20:56:23 <nikos_> ed: in XHTML you need to repeat the attribute name as the value to make it value
20:56:26 <nikos_> heycam: you can just leave it empty
20:56:57 <nikos_> shepazu: I don't think we'll solve the parsing problem today
20:57:04 <nikos_> ... it's an interesting issue in itself
20:57:22 <nikos_> ... maybe it's something we need to address before converging SVG into HTML
20:57:42 <nikos_> krit: it seems to be reasonable to do no-composite="no-composite"
20:57:52 <nikos_> ... and omit if you want existing behaviour
20:58:44 <nikos_> nikos: should we resolve on the no-composite flag?
20:59:02 <nikos_> krit: i would be in favour of that
20:59:07 <nikos_> heycam: what does it mean to not composite?
20:59:20 <nikos_> krit: [gives example]
21:02:37 <nikos_> ed: in the second level of blending and compositing
21:02:45 <nikos_> ... if you were to add a compositing property, would this affect feBlend?
21:02:55 <nikos_> krit: no it would have no effect
21:03:28 <nikos_> RESOLUTION: add a no-composite flag to feBlend to control whether src-over compositing happens within the feBlend filter
21:04:13 <nikos_> Filter Effects: feTurbulence - limit numOctaves to max value
21:04:42 <nikos_> krit: feTurbulence has a numOctaves attribute that controls the number of iterations of the turbulence code
21:04:53 <nikos_> ... the idea is that we limit the max value of this
21:05:06 <nikos_> ... because at some point, more iterations don't affect the result
21:05:12 <nikos_> ... what is the right number to stop at?
21:05:15 <nikos_> ... 10 has been proposed
21:05:35 <nikos_> ... this is not easily possible because the max that has an effect depends on a lot of things
21:05:40 <nikos_> ... bits in the colour channel
21:05:46 <nikos_> ... base frequency
21:05:58 <nikos_> Tav: there are two effects as you go from one octave to the next
21:06:04 <nikos_> ... 1. the spacing gets smaller
21:06:19 <nikos_> ... it gets smaller than a pixel size and no longer really matters
21:06:31 <nikos_> ... depends on the base frequency
21:06:37 <nikos_> ... and how zoomed you are
21:06:52 <nikos_> ... the other factor is the contribution of each octave is half of the previous octave to the overall colour and alpha value
21:07:09 <nikos_> ... so if you have 8 bit colour, after 8 octaves it's not contributing a noticeable difference
21:07:21 <nikos_> ... i played with InkScape and couldn't see the difference between 5 and 6
21:07:29 <nikos_> ... I could see the difference between 9 and 10 in one case with a complex filter
21:07:37 <nikos_> ... but the overall effect didn't change
21:07:42 <nikos_> ... just some pixel values changed
21:07:56 <nikos_> ... my conclusion is that after 5,6,7 octaves you're not getting a benefit
21:08:07 <nikos_> krit: but we cannot fix a max value because it depends on things we cannot influence
21:08:29 <nikos_> Tav: if you have 12 bit colour for example, you might want more octaves
21:08:36 <nikos_> ... although I'm not sure it would change the effect
21:08:53 <nikos_> ... what does the specification exactly state? it says you get a number [0..255]
21:08:55 <nikos_> ... is this an int?
21:09:02 <nikos_> ... in which case it's never useful to go past 8 octaves
21:09:13 <nikos_> krit: we discussed on www-style about the colour depth in CSS
21:09:18 <nikos_> ... it is up to the implementation to decide that
21:09:49 <nikos_> ... so it's not necessarily an integer
21:09:58 <nikos_> Tav: might be useful to have a note in the spec
21:10:21 <nikos_> krit: we sort of talked about this, values in the specification should be referred as values between [0..1]
21:12:47 <nikos_> Tav: so it would be good to note in the spec that it's possible to not use integer types in this case
21:12:59 <nikos_> ... InkScape has always assumed everything is integer
21:13:10 <nikos_> krit: I'm not sure if we should add a should in this case
21:13:20 <nikos_> ... rather, a may
21:13:32 <nikos_> ... browsers may have security concerns
21:13:37 <nikos_> ... e.g. timed attacks
21:13:44 <nikos_> s/timed/timing
21:13:52 <Tav> http://tavmjong.free.fr//INKSCAPE/MANUAL/html/Filters-Lighting.html
21:14:13 <nikos_> Tav: if you scroll down in that link you can see the quantisation in the bump map
21:14:31 <nikos_> krit: its unfortunate but I'm not sure that can be fixed
21:14:40 <nikos_> ... it can also depend on the hw support
21:15:18 <nikos_> ... if functions don't take variable time depending on colour input then it could be fixed in future
21:15:32 <nikos_> ... but specs should use values between [0..1] and implementations can choose what this maps to
21:15:35 <ed> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0166.html
21:15:40 <nikos_> ed: Tav you had some suggestions in your email
21:15:47 <nikos_> Tav: it was based on colour depth
21:16:04 <nikos_> ... but maybe that's not so useful because if you're taking the output from the turbulence filter and feeding it into another filter
21:16:12 <nikos_> ... then you're not talking about an output that is limited by the colour depth
21:16:34 <richardschwerdtfeger> richardschwerdtfeger has joined #svg
21:16:35 <nikos_> krit: we can note it is an optimisation that they can do
21:16:50 <nikos_> ... I think we should reject the request for a fixed value
21:16:56 <thorton> thorton has left #svg
21:17:25 <nikos_> Tav: I can't see us ever needing more than 10 octaves
21:17:45 <nikos_> ... you would need a massively high res image to see the difference
21:17:54 <nikos_> krit: I don't disagree but I think it should be up to the implementations
21:18:25 <nikos_> ... it's an optimisation the browser can choose to do or not
21:18:36 <nikos_> ... I'm happy to add a note but wouldn't go farther
21:18:39 <Zakim> +Rich_Schwerdtfeger
21:18:39 <nikos_> ed: sounds fine to me
21:20:21 <nikos_> RESOLUTION: Add a note to feTurbulence noting that user agents may choose to stop iterations early as an optimisation
21:20:22 <krit> ScribeNick: krit
21:21:10 <krit> topic: HTML working group has taken up DOM4
21:21:21 <krit> richardschwerdtfeger: most things over the dom with events
21:21:44 <krit> richardschwerdtfeger: there are is also UI spec with new events but not implemented
21:21:54 <krit> richardschwerdtfeger: shall we stay with DOM3 events for now?
21:22:00 <krit> shepazu:
21:22:02 <Zakim> -ed
21:22:10 <krit> shepazu: we should stay with what is implemented
21:22:16 <krit> richardschwerdtfeger: that would be DOM3
21:22:25 <krit> richardschwerdtfeger: UI events have key codes
21:22:36 <krit> richardschwerdtfeger: but no implementations for those
21:22:42 <krit> shepazu: I suggest, well..
21:22:54 <krit> shepazu: I don’t want use to take a winner
21:22:58 <krit> shepazu: it may change
21:23:06 <krit> richardschwerdtfeger: can we change the links later on
21:23:07 <krit> ?
21:23:30 <krit> shepazu: someone was saying to take the current version of the other spec
21:23:46 <krit> shepazu: so if we don’t know if it is defined by DOM3 or DOM4
21:23:47 <Zakim> +[IPcaller]
21:24:01 <krit> shepazu: we don’t reference the version of the DOM spec
21:24:18 <krit> shepazu: but instead build on top of implemented events
21:24:26 <krit> shepazu: what ever they are at the time
21:24:38 <krit> richardschwerdtfeger: we want to align our selveswith DOM events
21:24:51 <krit> richardschwerdtfeger: unfortunately the DOM4 spec did not update since 2011
21:24:51 <Zakim> -Tav
21:25:06 <krit> richardschwerdtfeger: now HTML WG takes over DOM4
21:25:13 <krit> richardschwerdtfeger: I just want to be consistent
21:25:22 <krit> richardschwerdtfeger: we may need blur, keyboard, mouse events
21:25:28 <krit> richardschwerdtfeger: we also removed events
21:25:31 <Zakim> +Tav
21:25:37 <krit> richardschwerdtfeger: and I want to point to the right place
21:26:03 <krit> shepazu: do we need to point to a certain spec, or can we just say for pointer events for example
21:26:16 <krit> richardschwerdtfeger: in the past we just had events and we are changing that
21:26:33 <krit> richardschwerdtfeger: now you have the old DOM events, then DOM3 and eventually DOM4 events
21:26:42 <krit> richardschwerdtfeger: I think we have to say which version
21:26:59 <krit> shepazu: I disagree that we need to ref another spec
21:27:11 <krit> shepazu: but think DOM3 will be finished soon
21:27:21 <krit> richardschwerdtfeger: are we going to LC this year?
21:27:32 <krit> shepazu: we decided against that to last F2F
21:27:35 <krit> richardschwerdtfeger:
21:27:57 <krit> richardschwerdtfeger: with HTML taking over DOM… do we need to plan for SVG2? What is the time frame for HTML WG?
21:28:06 <krit> shepazu: I don’t know but not within a yeat
21:28:08 <krit> year
21:28:15 <krit> shepazu: I vote for late-binding
21:28:27 <krit> shepazu: when we go to LC, we update all references
21:28:49 <krit> krit: don’t need a resolution for that, so yes we can do that
21:29:06 <krit> topic: next telcons
21:29:17 <krit> ed: we should cancel all telcos after next week
21:29:20 <krit> shepazu: agree
21:29:33 <krit> RESOLUTION: no telcos after next week
21:29:48 <krit> topic: selection, copy and paste and linking
21:30:04 <shepazu> http://www.w3.org/TR/SVG2/text.html#TextSelection
21:30:07 <krit> shepazu: we have a description what it means to select and copy text in SV
21:30:07 <krit> G
21:30:24 <krit> shepazu: however, we should do what other systems do
21:30:28 <ed> s/cancel all telcos after next week/cancel the telcos that on 26 December and 2 January
21:30:37 <krit> shepazu: we talk about focus but not selection in sVG
21:30:50 <krit> shepazu: can we select an element and copy and paste it?
21:30:59 <krit> shepazu: can you select one or more elements?
21:31:23 <krit> shepazu: to make editions on the element
21:31:34 <krit> shepazu: e.g bar charts and select a bar
21:31:56 <krit> shepazu: we do not have any concept of selection, group or copy and paste elements
21:32:12 <krit> shepazu: I would propose text for it if ppl agree
21:32:28 <krit> heycam: will it be exposed to script
21:32:55 <krit> shepazu: I would like to look what HTML5 does and take that
21:33:06 <krit> shepazu: and not depend just on the UA
21:33:16 <krit> heycam: I had that on my mind
21:33:38 <krit> heycam: you could make that work for non-textual elements
21:33:51 <krit> shepazu: right, ATM you can’t do that
21:34:02 <krit> ed: would it be limited to SVG or with HTML as well?
21:34:15 <krit> shepazu: SVG is the only markup for graphics… so yes.. limited to SVG
21:34:18 <krit> shepazu:
21:34:23 <Zakim> -ed
21:34:38 <krit> shepazu: explaining use case of copy paste
21:35:11 <krit> shepazu: once you copy… do you copy peace or whole document? What do you paste? SVG? text?
21:35:23 <krit> shepazu: …or a rasterized snapshot?
21:35:43 <krit> shepazu: or just copy text… what is the text you paste?
21:35:51 <krit> shepazu: probably the selected text
21:36:12 <krit> shepazu: and if you copy an object… then you paste the description of the element if provided
21:36:33 <krit> shepazu: what if you copy a rect with a gradient? do you copy the gradient? (I say yes)
21:36:47 <krit> Tav: that becomes really complicated
21:36:58 <krit> Tav: especially with gradients, filters and so on
21:37:12 <krit> shepazu: depends if you copy the text or the structure?
21:38:09 <krit> krit: I would really like to see the proposal and hope you are open for changing direction later on
21:38:24 <krit> shepazu: I can do the minimal part for selection… and then we go from there
21:38:31 <krit> shepazu: happy about thoughts from others
21:39:04 <krit> shepazu: but don’t want to waste time
21:39:40 <krit> krit: I like the idea of copying descriptions.
21:40:39 <krit> krit: want a resolution?
21:40:53 <krit> shepazu: sure… we already have annotations but think it should be extended
21:41:19 <krit> action: shepazu come up with a proposal for selecting, copy/pasting SVG fragments
21:41:19 <trackbot> Created ACTION-3554 - Come up with a proposal for selecting, copy/pasting svg fragments [on Doug Schepers - due 2013-12-19].
21:42:55 <krit> trackbot, make minutes
21:42:55 <trackbot> Sorry, krit, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
21:42:57 <Zakim> -heycam
21:43:01 <Zakim> -birtles
21:43:04 <krit> ed: ?
21:43:08 <ed> trackbot, end telcon
21:43:08 <trackbot> Zakim, list attendees
21:43:08 <Zakim> As of this point the attendees have been krit, [IPcaller], Doug_Schepers, birtles, ed, heycam, stakagi, Tav, Rich_Schwerdtfeger
21:43:11 <Zakim> -??P8
21:43:16 <trackbot> RRSAgent, please draft minutes
21:43:16 <RRSAgent> I have made the request to generate http://www.w3.org/2013/12/12-svg-minutes.html trackbot
21:43:17 <trackbot> RRSAgent, bye
21:43:17 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2013/12/12-svg-actions.rdf :
21:43:17 <RRSAgent> ACTION: shepazu come up with a proposal for selecting, copy/pasting SVG fragments [1]
21:43:17 <RRSAgent>   recorded in http://www.w3.org/2013/12/12-svg-irc#T21-41-19
21:43:21 <Zakim> -Tav