SVG WG Meeting Minutes 12-12-2013


Here are the meeting minutes of 12/12/2013 [1].





                               - DRAFT -

                    SVG Working Group Teleconference

12 Dec 2013



   See also: [3]IRC log



          krit, [IPcaller], Doug_Schepers, birtles, ed, heycam,
          stakagi, Tav, Rich_Schwerdtfeger


          krit, nikos


     * [4]Topics
         1. [5]CR MAsking
         2. [6]Filter Effects: feBlend/feComposite should in2
            behave like in
         3. [7]Filter Effects : feBlend, supporting compositing
            modes or just no-composite
         4. [8]HTML working group has taken up DOM4
         5. [9]next telcons
         6. [10]selection, copy and paste and linking
     * [11]Summary of Action Items

   <trackbot> Date: 12 December 2013

   <krit> ScribeNick: krit

CR MAsking

   krit: There is nothing to discuss for today. I got comments
   yesterday and need to go through them.

   ed: ok

Filter Effects: feBlend/feComposite should in2 behave like in

   <nikos_> scribenick: nikos

   <nikos_> krit: We discussed this at the F2F

   <nikos_> ... there was a comment that it's unclear what in2
   means when it's not set

   <nikos_> ... does it mean the same input as the in attribute?

   <nikos_> ... I did some testing

   <nikos_> ... examples on the mailing list

   <nikos_> ... in2 is handled the same as in

   <nikos_> ... in if it's not set takes the last primitive

   <nikos_> ... I checked with feComposite and feBlend and looked
   at some source

   <nikos_> ... it really is handled the same

   <nikos_> ... tested on various browsers and they agree on

   <nikos_> ... so I propose we specify that in2 should behave the
   same as in



   <nikos_> ed: in your example on the mail, I'm not sure I follow

   <nikos_> ... you're saying that the feBlend in that example
   there takes in2 as what?

   <nikos_> ... in2 takes the value of the previous primitive,
   which is the output of the previous feFlood

   <nikos_> ... because no value is specified explicitly for in2

   <nikos_> Tav: this is how I originally intepreted the spec

   <nikos_> ed: that sounds reasonable

   <nikos_> nikos: +1

   <nikos_> ed: I didn't read the spec that way, but the behaviour
   is good

   <nikos_> ... it could be clarified

   <nikos_> RESOLUTION: The in2 attribute of feBlend will have the
   same behaviour as in

Filter Effects : feBlend, supporting compositing modes or just

   <nikos_> krit: We discussed this at the F2F

   <nikos_> ... feBlend does a composite, with operator source

   <nikos_> ... it includes the backdrop twice in the result

   <nikos_> krit: instead it should not composite at all

   <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

   <nikos_> ... we've discussed two options

   <nikos_> ...1. an attribute to disable compositing

   <nikos_> ...2. adding all compositing modes

   <nikos_> nikos: do we need to preserve the double backdrop
   contribution on src-over?

   <nikos_> krit: yes

   <nikos_> ... in many cases you want compositing

   <nikos_> ... but once the backdrop is involved, you want to
   disable compositing

   <nikos_> heycam: will the mix-blend-mode ever give you the
   ability to grab the background

   <nikos_> krit: yes

   <nikos_> heycam: does that mean it's worth having the ability
   for turning off compositing for general CSS compositing as

   <nikos_> Tav: in the original blending and compositing spec you
   specified a mix-blend-mode and a composite at the same time?

   <nikos_> krit: yes in the second level

   <nikos_> nikos: it's not normal to separate compositing and
   blending controls

   <nikos_> krit: they're two separate things, one controls colour
   and one controls whether parts of the shapes are drawn

   <nikos_> ed: is there a particular proposal we need to decide

   <nikos_> krit: on the mailing list we decided not to add all
   compositing modes

   <nikos_> ... instead just add a way to disable compositing

   <nikos_> I'd suggest a 'composite' attribute that takes

   <nikos_> krit: even though I don't like true/false as attribute

   <nikos_> ... I'd rather do as in the HTML world where a boolean
   attribute can either be present or not

   <nikos_> ... but I don't think XML allows that

   <nikos_> ed: in XHTML you need to repeat the attribute name as
   the value to make it value

   <nikos_> heycam: you can just leave it empty

   <nikos_> shepazu: I don't think we'll solve the parsing problem

   <nikos_> ... it's an interesting issue in itself

   <nikos_> ... maybe it's something we need to address before
   converging SVG into HTML

   <nikos_> krit: it seems to be reasonable to do

   <nikos_> ... and omit if you want existing behaviour

   <nikos_> nikos: should we resolve on the no-composite flag?

   <nikos_> krit: i would be in favour of that

   <nikos_> heycam: what does it mean to not composite?

   <nikos_> krit: [gives example]

   <nikos_> ed: in the second level of blending and compositing

   <nikos_> ... if you were to add a compositing property, would
   this affect feBlend?

   <nikos_> krit: no it would have no effect

   <nikos_> RESOLUTION: add a no-composite flag to feBlend to
   control whether src-over compositing happens within the feBlend

   <nikos_> Filter Effects: feTurbulence - limit numOctaves to max

   <nikos_> krit: feTurbulence has a numOctaves attribute that
   controls the number of iterations of the turbulence code

   <nikos_> ... the idea is that we limit the max value of this

   <nikos_> ... because at some point, more iterations don't
   affect the result

   <nikos_> ... what is the right number to stop at?

   <nikos_> ... 10 has been proposed

   <nikos_> ... this is not easily possible because the max that
   has an effect depends on a lot of things

   <nikos_> ... bits in the colour channel

   <nikos_> ... base frequency

   <nikos_> Tav: there are two effects as you go from one octave
   to the next

   <nikos_> ... 1. the spacing gets smaller

   <nikos_> ... it gets smaller than a pixel size and no longer
   really matters

   <nikos_> ... depends on the base frequency

   <nikos_> ... and how zoomed you are

   <nikos_> ... the other factor is the contribution of each
   octave is half of the previous octave to the overall colour and
   alpha value

   <nikos_> ... so if you have 8 bit colour, after 8 octaves it's
   not contributing a noticeable difference

   <nikos_> ... i played with InkScape and couldn't see the
   difference between 5 and 6

   <nikos_> ... I could see the difference between 9 and 10 in one
   case with a complex filter

   <nikos_> ... but the overall effect didn't change

   <nikos_> ... just some pixel values changed

   <nikos_> ... my conclusion is that after 5,6,7 octaves you're
   not getting a benefit

   <nikos_> krit: but we cannot fix a max value because it depends
   on things we cannot influence

   <nikos_> Tav: if you have 12 bit colour for example, you might
   want more octaves

   <nikos_> ... although I'm not sure it would change the effect

   <nikos_> ... what does the specification exactly state? it says
   you get a number [0..255]

   <nikos_> ... is this an int?

   <nikos_> ... in which case it's never useful to go past 8

   <nikos_> krit: we discussed on www-style about the colour depth
   in CSS

   <nikos_> ... it is up to the implementation to decide that

   <nikos_> ... so it's not necessarily an integer

   <nikos_> Tav: might be useful to have a note in the spec

   <nikos_> krit: we sort of talked about this, values in the
   specification should be referred as values between [0..1]

   <nikos_> Tav: so it would be good to note in the spec that it's
   possible to not use integer types in this case

   <nikos_> ... InkScape has always assumed everything is integer

   <nikos_> krit: I'm not sure if we should add a should in this

   <nikos_> ... rather, a may

   <nikos_> ... browsers may have security concerns

   <nikos_> ... e.g. timing attacks



   <nikos_> Tav: if you scroll down in that link you can see the
   quantisation in the bump map

   <nikos_> krit: its unfortunate but I'm not sure that can be

   <nikos_> ... it can also depend on the hw support

   <nikos_> ... if functions don't take variable time depending on
   colour input then it could be fixed in future

   <nikos_> ... but specs should use values between [0..1] and
   implementations can choose what this maps to



   <nikos_> ed: Tav you had some suggestions in your email

   <nikos_> Tav: it was based on colour depth

   <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

   <nikos_> ... then you're not talking about an output that is
   limited by the colour depth

   <nikos_> krit: we can note it is an optimisation that they can

   <nikos_> ... I think we should reject the request for a fixed

   <nikos_> Tav: I can't see us ever needing more than 10 octaves

   <nikos_> ... you would need a massively high res image to see
   the difference

   <nikos_> krit: I don't disagree but I think it should be up to
   the implementations

   <nikos_> ... it's an optimisation the browser can choose to do
   or not

   <nikos_> ... I'm happy to add a note but wouldn't go farther

   <nikos_> ed: sounds fine to me

   <nikos_> RESOLUTION: Add a note to feTurbulence noting that
   user agents may choose to stop iterations early as an

   <krit> ScribeNick: krit

HTML working group has taken up DOM4

   richardschwerdtfeger: most things over the dom with events
   ... there are is also UI spec with new events but not
   ... shall we stay with DOM3 events for now?

   shepazu: ... we should stay with what is implemented

   richardschwerdtfeger: that would be DOM3
   ... UI events have key codes
   ... but no implementations for those

   shepazu: I suggest, well..
   ... I don’t want use to take a winner
   ... it may change

   richardschwerdtfeger: can we change the links later on


   shepazu: someone was saying to take the current version of the
   other spec
   ... so if we don’t know if it is defined by DOM3 or DOM4
   ... we don’t reference the version of the DOM spec
   ... but instead build on top of implemented events
   ... what ever they are at the time

   richardschwerdtfeger: we want to align our selveswith DOM
   ... unfortunately the DOM4 spec did not update since 2011
   ... now HTML WG takes over DOM4
   ... I just want to be consistent
   ... we may need blur, keyboard, mouse events
   ... we also removed events
   ... and I want to point to the right place

   shepazu: do we need to point to a certain spec, or can we just
   say for pointer events for example

   richardschwerdtfeger: in the past we just had events and we are
   changing that
   ... now you have the old DOM events, then DOM3 and eventually
   DOM4 events
   ... I think we have to say which version

   shepazu: I disagree that we need to ref another spec
   ... but think DOM3 will be finished soon

   richardschwerdtfeger: are we going to LC this year?

   shepazu: we decided against that to last F2F

   richardschwerdtfeger: ... with HTML taking over DOM… do we need
   to plan for SVG2? What is the time frame for HTML WG?

   shepazu: I don’t know but not within a yeat


   shepazu: I vote for late-binding
   ... when we go to LC, we update all references

   krit: don’t need a resolution for that, so yes we can do that

next telcons

   ed: we should cancel the telcos that on 26 December and 2

   shepazu: agree

   RESOLUTION: no telcos after next week

selection, copy and paste and linking

   <shepazu> [15]


   shepazu: we have a description what it means to select and copy
   text in SV


   shepazu: however, we should do what other systems do
   ... we talk about focus but not selection in sVG
   ... can we select an element and copy and paste it?
   ... can you select one or more elements?
   ... to make editions on the element
   ... e.g bar charts and select a bar
   ... we do not have any concept of selection, group or copy and
   paste elements
   ... I would propose text for it if ppl agree

   heycam: will it be exposed to script

   shepazu: I would like to look what HTML5 does and take that
   ... and not depend just on the UA

   heycam: I had that on my mind
   ... you could make that work for non-textual elements

   shepazu: right, ATM you can’t do that

   ed: would it be limited to SVG or with HTML as well?

   shepazu: SVG is the only markup for graphics… so yes.. limited
   to SVG
   ... explaining use case of copy paste
   ... once you copy… do you copy peace or whole document? What do
   you paste? SVG? text?
   ... …or a rasterized snapshot?
   ... or just copy text… what is the text you paste?
   ... probably the selected text
   ... and if you copy an object… then you paste the description
   of the element if provided
   ... what if you copy a rect with a gradient? do you copy the
   gradient? (I say yes)

   Tav: that becomes really complicated
   ... especially with gradients, filters and so on

   shepazu: depends if you copy the text or the structure?

   krit: I would really like to see the proposal and hope you are
   open for changing direction later on

   shepazu: I can do the minimal part for selection… and then we
   go from there
   ... happy about thoughts from others
   ... but don’t want to waste time

   krit: I like the idea of copying descriptions.
   ... want a resolution?

   shepazu: sure… we already have annotations but think it should
   be extended

   <scribe> ACTION: shepazu come up with a proposal for selecting,
   copy/pasting SVG fragments [recorded in

   <trackbot> Created ACTION-3554 - Come up with a proposal for
   selecting, copy/pasting svg fragments [on Doug Schepers - due

   trackbot, make minutes

   <trackbot> Sorry, krit, I don't understand 'trackbot, make
   minutes'. Please refer to
   <[17]> for help.


   ed: ?

   <ed> trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: shepazu come up with a proposal for selecting,
   copy/pasting SVG fragments [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [19]scribe.perl version
    1.138 ([20]CVS log)
    $Date: 2013-12-12 21:43:21 $


Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [21]


Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/but it doesn't quite do it correctly/with operator source o
Succeeded: s/timed/timing/
Succeeded: s/cancel all telcos after next week/cancel the telcos that on
 26 December and 2 January/
Found ScribeNick: krit
Found ScribeNick: nikos
WARNING: No scribe lines found matching ScribeNick pattern: <nikos> ...
Found ScribeNick: krit
Inferring Scribes: krit, nikos
Scribes: krit, nikos
ScribeNicks: krit, nikos
Default Present: krit, [IPcaller], Doug_Schepers, birtles, ed, heycam, s
takagi, Tav, Rich_Schwerdtfeger
Present: krit [IPcaller] Doug_Schepers birtles ed heycam stakagi Tav Ric
Agenda: [22]
Found Date: 12 Dec 2013
Guessing minutes URL: [23]
People with action items: shepazu


WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

   [End of [24]scribe.perl diagnostic output]


Received on Thursday, 12 December 2013 21:46:29 UTC