- From: Dirk Schulze <dschulze@adobe.com>
- Date: Thu, 12 Dec 2013 21:45:56 +0000
- To: www-svg <www-svg@w3.org>, SVG WG <public-svg-wg@w3.org>
Hi,
Here are the meeting minutes of 12/12/2013 [1].
Greetings,
Dirk
[1] http://www.w3.org/2013/12/12-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
12 Dec 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0024.html
See also: [3]IRC log
[3] http://www.w3.org/2013/12/12-svg-irc
Attendees
Present
krit, [IPcaller], Doug_Schepers, birtles, ed, heycam,
stakagi, Tav, Rich_Schwerdtfeger
Regrets
Chair
ed
Scribe
krit, nikos
Contents
* [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
behaviour
<nikos_> ... so I propose we specify that in2 should behave the
same as in
<ed>
[12]http://lists.w3.org/Archives/Public/public-fx/2013OctDec/01
59.html
[12] 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>
[13]http://tavmjong.free.fr//INKSCAPE/MANUAL/html/Filters-Light
ing.html
[13] 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>
[14]http://lists.w3.org/Archives/Public/public-fx/2013OctDec/01
66.html
[14] 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> [15]http://www.w3.org/TR/SVG2/text.html#TextSelection
[15] http://www.w3.org/TR/SVG2/text.html#TextSelection
shepazu: we have a description what it means to select and copy
text in SV
G
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
[16]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
<[17]http://www.w3.org/2005/06/tracker/irc> for help.
[17] http://www.w3.org/2005/06/tracker/irc%3E
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
[18]http://www.w3.org/2013/12/12-svg-minutes.html#action01]
[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 $
__________________________________________________________
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
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]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/but it doesn't quite do it correctly/with operator source o
ver/
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
h_Schwerdtfeger
Agenda: [22]http://lists.w3.org/Archives/Public/www-svg/2013Dec/0024.htm
l
Found Date: 12 Dec 2013
Guessing minutes URL: [23]http://www.w3.org/2013/12/12-svg-minutes.html
People with action items: shepazu
[22] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0024.html
[23] http://www.w3.org/2013/12/12-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of [24]scribe.perl diagnostic output]
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 12 December 2013 21:46:29 UTC