SVG Working Group Teleconference -- 12 Dec 2013

<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 behaviour

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

<ed> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0159.html

<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 no-composite

<nikos_> krit: We discussed this at the F2F

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

<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 well?

<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 on?

<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 true/false

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

<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 today

<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 no-composite="no-composite"

<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 filter

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

<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 octaves

<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 case

<nikos_> ... rather, a may

<nikos_> ... browsers may have security concerns

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

<Tav> http://tavmjong.free.fr//INKSCAPE/MANUAL/html/Filters-Lighting.html

<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 fixed

<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

<ed> http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0166.html

<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 do

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

<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 optimisation

<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 implemented
... 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 events
... 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

year

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 January

shepazu: agree

RESOLUTION: no telcos after next week

selection, copy and paste and linking

<shepazu> http://www.w3.org/TR/SVG2/text.html#TextSelection

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 http://www.w3.org/2013/12/12-svg-minutes.html#action01]

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

trackbot, make minutes

<trackbot> Sorry, krit, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

ed: ?

<ed> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

12 Dec 2013

Attendees

Contents