SV_MEETING_TITLE -- 15 Nov 2013
- DRAFT -
SV_MEETING_TITLE
15 Nov 2013
See also:
IRC
log
Attendees
Present
Cameron, Doug, Brian, Satoru, Jun, Nikos, Chris, Cyril,
Erik, Dirk, Rik, Tab
Regrets
Chair
Cameron
Scribe
nikos, nikos1, Cameron
Contents
Topics
Path rotation and new
circluar/elliptical arc commands
SuperPath commands
Filter effects
More filter issues
use and shadow dom
Promotion of attributes to
properties
load events in SVG
zooming and panning
SVG Fonts still in SVG2?
F2F schedule for 2014
SVG Logo
paint-order naming
pointer-events:boundingBox
Summary of Action Items
TabAtkins
> kk
TabAtkins
> It's a good thing
we just switched to unlimited minutes, from 600.
nikos1
> scribe: nikos
nikos1
> scribe: nikos1
TabAtkins
> My cell plan.
scribe
> scribenick:
nikos
Path rotation and new circluar/elliptical arc
commands
nikos1
> heycam: one of the
requirements we had for svg 2 was for a path command to set
current rotation
nikos1
> ... subsequent
commands are then relative to that rotation
nikos1
> ... the reason for
allowing was to avoid having to do trig
nikos1
> ... if you want to
animate the path - e.g. rotate one section
nikos1
> ... I wanted that in
conjunction with a simpler arc command
nikos1
> ... so you could do
circular or elliptical arc from current position by a certain
number of degrees
nikos1
> ... I've given that
letter 'b' for bearing
nikos1
> ... the capital 'B'
takes the angle in degrees
heycam
nikos1
> ... the idea is that
when you have a bearing that is not zero, that effects only
relative path commands after that
nikos1
> ... so 'h' would go
that distance in the direction of the bearing
nikos1
> heycam: initial
rotation is zero
nikos1
> TabAtkins: tradition
for angles is to make them zero degrees pointing upwards -
especially with bearing
nikos1
> TabAtkins: you need
a capital B, but typically the way angles are done is that zero
degrees points upwards
nikos1
> ... it doesn't
matter a lot, not sure it makes a difference here
nikos1
> heycam: it makes a
difference which path commands you use to go straight
forward
nikos1
> TabAtkins: the
notion of straight forward doesn't have a meaning here
nikos1
> heycam: if we want
'h' to mean head forward
nikos1
> ... then it makes
sense for zero degrees to mean in the positive x axis
nikos1
> krit: we use always
x axis for rotation
nikos1
> ... but bearing is
usually looking north
nikos1
> ... e.g. negative y
axis
nikos1
> heycam: unless we
want the initial bearing value to be non zero
birtles
> \me 'v' is Veer
left, or Venestre ?
nikos1
> ... then we couldn't
have zero degrees meaning upwards
nikos1
> ... and lower case
'h' to mean go to the right
nikos1
> krit: can this be
combined with cubic and quadratic curves?
nikos1
> heycam: I've defined
it so that it does
nikos1
> ... all points are
rotated around the origin
nikos1
> ... for straight
line segments and quadratics and cubics
nikos1
> ... the point gets
rotated
nikos1
> krit: it's changing
the co-ordinate space
nikos1
> heycam: you can't
build up a path in Direct2D and apply a transform half way
through
nikos1
> ... I've described
in the respective sections what it means to have the transform
applied
nikos1
> heycam: if you look
at the cubic bezier command section for example, I added a
paragraph detailing how the control points are transformed
nikos1
> cyril: what are the
consequences on animate motion?
nikos1
> heycam: it's the
same as if you have two line segments
nikos1
> ... where we might
have to think about it is with the methods that give a path
segment that is a particular length
nikos1
> heycam: I think it
makes sense for the default to be zero, and that to be in the
positive x axis
nikos1
> cyril: do you think
it should be normalised?
nikos1
> heycam: good
question, I guess it should
nikos1
> cyril: what about
path morphing? Should have no effect right?
nikos1
> ... you normalise
first then you apply
nikos1
> ... by morphing I
mean path animation
nikos1
> ... so do you
require a 'b' to match up with a 'b'?
nikos1
> heycam: I think
so
nikos1
> ... you want to
animate the 'b'
nikos1
> heycam: the other
part of the discussion I wanted is
nikos1
> ... the best way to
get a bearing relative elliptical arc
nikos1
> ... haven't added
this to the spec yet
nikos1
> ... the last thing
we came up with in Switzerland was to add the two arc commands
that canvas has
nikos1
> ... maybe with long
names since we're running out of letters
nikos1
> ... we can still do
that
nikos1
> ... but I don't
think the canvas arcs are good for doing an arc from the
current position in a given direction
nikos1
> ... I wrote up a
couple of options for doing that in a text file
nikos1
> TabAtkins: we also
wanted to add in one of the arc commands from paper.js
nikos1
> ... where you give
two points that are on the arc
nikos1
> ... three points in
total
heycam
nikos1
> ... the 'i' command
does a circular arc in the given direction for a certain number
of degrees
heycam
> i
heycam
> = circular arc with
the given radius, beginning in the current bearing
heycam
> direction, drawing
clockwise
heycam
> e
heycam
> = elliptical arc
with the given radii, beginning in the current bearing
direction,
heycam
> as if you were
heycam
> defaults to going
clockwise
nikos1
> heycam: I was
thinking of having two commands. One for circular, one for
elliptical
nikos1
> ... the circular arc
(i) goes fowards from the current position in the current
direction with a radius and a certain number of degrees
nikos1
> ... the elliptical
version takes the x and y radius
nikos1
> ... you also have to
specify the start angle
nikos1
> ... might not be so
useful but included for completeness
nikos1
> TabAtkins: the i
command makes it easier to do corners for example
nikos1
> ... h, i 90 degrees
4 times
nikos1
> heycam: the current
bearing never changes unless you give a 'b' command
nikos1
> ... so you'd do "h i
90 degrees b 0 (zero degrees off previous arc command) h " and
so on
nikos1
> cyril: with 'e', why
do you need a start angle?
nikos1
> heycam: you need to
know where around the elliptical arc you are
nikos1
> cam draws on
whitebaord
nikos1
> TabAtkins: basically
because ellipses aren't radially symmetric
nikos1
> heycam: the angle is
the angle around the arc, not the initial bearing
nikos1
> shepazu: if you're
making a pie chart, is the initial angle always going to be 90
degrees?
nikos1
> TabAtkins: this
command isn't great for making a pie chart
nikos1
> heycam: it's good
for pie charts
nikos1
> ... maybe not as
good as the canvas one with the center point
nikos1
> ... you can move the
the center point, then bear in whatever direction
nikos1
> ... "m 100,100 b -90
h 40 b 90 i 20 0 b 90 h 40 "
nikos1
> ... then some
more
nikos1
> cyril: why do you
need the 'b 90' ?
nikos1
> heycam: you turn 90
degrees at the end of the upwards line
nikos1
> shepazu: I like the
idea of being able to do angles in svg finally
TabAtkins
> Hmm, bearings
help a little bit with pie charts, but only if you're drawing
all the segments in one go.
nikos1
> heycam: one thing
with these two circular elliptical and bearing path commands is
that there is no natural absolute version of these commands
nikos1
> ... you could make
it so that with the abs version you don't do the rotation of
the bearing
nikos1
> ... but it's
unlikely you would use it
TabAtkins
> You need the
Canvas arc command to do pie segments separately in an easy
way.
TabAtkins
> SO MANY ARCS
NECESSARY
nikos1
> shepazu: this
introduces angles into SVG
nikos1
> ... I'm wondering is
this a pattern we are going to duplicate?
nikos1
> ... are there other
places we could use angles?
nikos1
> ... is this a
suitable precedent to follow?
nikos1
> TabAtkins: does the
star element use angles?
nikos1
> shepazu: it
doesn't
nikos1
> heycam: I was
wondering whether zero degrees should be positive x?
nikos1
> TabAtkins: I can't
find a decent way to make proper bearing angles easy to use
nikos1
> ... so I think we go
with the current proposal
nikos1
> heycam: I like how
'h' can be thought of as move ahead
nikos1
> ... if anyone have
any better ideas for bearing relative arc commands let me
know
nikos1
> ... otherwise I'll
add lower case 'i's and 'e's
nikos1
> TabAtkins: not
bothered about absolute commands
nikos1
> heycam: 'b' and
lowercase 'i' and 'e' break pattern of last value of command is
the ending co-ordinate
nikos1
> ... don't think
that's a problem
TabAtkins
> I honestly didn't
even realize that was a pattern.
nikos1
> heycam: question of
what to do with the SVG dom?
nikos1
> ... new path seg
interface derivatives?
nikos1
> ... probably no
nikos1
> birtles: would you
even add this feature to the old svg ?
nikos1
> heycam: ideally
not
nikos1
> heycam: just like
with transforms we do have to define what happens if you use
them
nikos1
> ... can do the same
thing as transforms
nikos1
> ... should markers
be painted at the b?
nikos1
> heycam: I think
no
nikos1
> TabAtkins: agree
nikos1
> cyril: no, they
don't introduce a segment
nikos1
> cyril: a colleague
of mine edited some path commands, where should I put it?
nikos1
> heycam: mail it?
SuperPath commands
nikos1
> cyril: a colleague
of mine edited some path commands, where should I put it?
nikos1
> heycam: mail it?
nikos1
> cyril: the idea is
to have 'p' for referring to a path
nikos1
nikos1
> cyril: we are
proposing two commands, with absolute and relative
nikos1
> ... the piece
command takes a url fragment
nikos1
> ... draws a sub path
from the current point using the commands from the referenced
fragment
nikos1
> ... r draws the
referenced path backwards
nikos1
> krit: so the path
needs to be in the same document
nikos1
> ... the syntax is
not clear about that
nikos1
> cyril: iri is
defined
nikos1
> krit: iri is defined
to be url and then iri
nikos1
> cyril: but if the
url is not there then it is a fragment to the current
document
nikos1
> ... don't think we
want to allow the url
nikos1
> heycam: I would like
to use ids for reference in current document, not iri
nikos1
> cyril: so in the
syntax the '#' would be removed
nikos1
> cyril: can you have
spaces in ids?
nikos1
> birtles: I don't
like ids, but we can come back to that
nikos1
> krit: how do you
differ between the different command without '#'
nikos1
> ... could be the pr
command for example
nikos1
> ... having # would
be a delimiter you could detect
nikos1
> krit: we aren't
strict about spaces or comments
nikos1
> ... I think you want
to make it clear that it's a reference
nikos1
> heycam: I think it's
only a problem if we have the repeated parameter thing
nikos1
> cyril: the
difficulty here is how you draw a reverse path
nikos1
> ... usually you have
the ending point and then the following points
nikos1
> ... if you reverse a
quadratic bezier the first point isn't given in the command
nikos1
> ... have added some
notes in the text
nikos1
> ... see annotation
nikos1
> cyril draws on the
board
nikos1
> shepazu: someone
told me (maybe David Dailey) that he heard feedback that the
super path thing turns out not to be the solution for mapping
that they thought it would be
nikos1
> ... because when you
normalise paths the differences aren't significant
nikos1
> ... could you
communicate with David Dailey about this?
nikos1
> krit: the proposal
doesn't say how to deal with dash-array especially with shared
paths
nikos1
> cyril: I know
nikos1
> krit: many
implementations can't do it at the moment
nikos1
> krit: I'd like it
added as 'at risk' from the beginning
nikos1
> ... I don't think it
will be implemented in the next version of browsers
nikos1
> heycam: I think all
features will be assessed when going to CR
nikos1
> shepazu: it gives a
lack of confidence marking as at risk initially
nikos1
> ... implementers
won't even look at it if it's marked as 'at risk'
nikos1
> ... we can always
mark it at last call
nikos1
> heycam: especially
since it's in the list of requirements
nikos1
> cabanier: Flash was
never able to fix stroking on edge lists
nikos1
> ... it always looked
bad
nikos1
> ... what happens
with end caps, etc?
nikos1
> cyril: the model we
had in mind was to copy all the paths as if they were specified
there
nikos1
> heycam: this doesn't
address shared edges
nikos1
> cyril: this isn't
trying to address the problem of having touching objects
nikos1
> ... it's for
maps
nikos1
> ... you just say you
have a common path between two objects
nikos1
> shepazu: if I have
two states on a map that are adjacent
nikos1
> ... in that case,
this proposal says they have a shared line
nikos1
> ... and it's
referenced in the syntax
nikos1
> heycam: this does
give you information about which pixels are completely
covered
nikos1
> ... the underlying
graphics libraries aren't going to give us the facility to make
use of that
nikos1
> shepazu: That might
be the essence of what David Dailey was alluding to
nikos1
> cyril: we're not
changing how the rendering is working
nikos1
> ... it's just for
syntax
nikos1
> krit: the idea of
super paths was to have shared edges
nikos1
> cyril: that's not
what I was thinking
nikos1
> ... it's adding
semantics to the document so that path data can be re-used
nikos1
> .. with animations
applied, etc
nikos1
> krit: I don't think
this is the real requirement of super paths
nikos1
> shepazu: I'd like to
point out another thing that troubles me
nikos1
> ... that is, for me
it's common when I'm using a map that I
nikos1
> ... might pull out a
particular shape
nikos1
> ... e.g. pull out
Germany from a map of Europe
nikos1
> ... if I do that now
it's got it's own shape
nikos1
> ... with this I have
to follow the reference
nikos1
> ... we already have
an API for that
nikos1
> cyril: I was
thinking we could import the points into the normalised
version
nikos1
> shepazu: the
authoring experience is made more complicated with
references
nikos1
> heycam: in your
example you are referencing p1
nikos1
> ... if case of
commands was different what would be the effect?
nikos1
> cyril: if the path
you are referencing uses relative commands then those commands
are relative to the last point before the referenced path
nikos1
> ... and if the path
uses absolute commands then they're absolute
nikos1
> heycam: does that
mean, if you had a mix of absolute and relative, that segment
sizes would be different for the same re-used path?
nikos1
> cyril: yes
nikos1
> cyril gives
example
nikos1
> cyril: we kept small
'p' and small 'r' because all existing commands had two
versions
nikos1
> ... but they're
useless
nikos1
> krit: 'r' is
reserved
nikos1
> cyril: call it
'x'
nikos1
> heycam: could you
enumerate the problems?
nikos1
> cyril: I heard it's
not solving all the problems
nikos1
> cyril: I'd like to
add it to the spec for further discussion
nikos1
> heycam: I'm ok with
that
nikos1
ACTION:
cyril to add piece commands to SVG 2
specification [recorded in
trackbot
> Created
ACTION-3546 - Add piece commands to svg 2 specification [on
Cyril Concolato - due 2013-11-22].
scribe
> scribenick: someone
else
TabAtkins
> >_<
heycam
> Scribe: Cameron
heycam
> ScribeNick:
heycam
Filter effects
krit
krit
TabAtkins
> I lied, I can't
hear anything but an occasional burst of voice.
krit:
first issue is xlink
attributes
... we have it on most elements
... which did we decide to remove
TabAtkins
> Note that that
#issues-index section is auto-generated by Bikeshed. Yet
another reason to switch!
heycam:
we should remove all
except xlink:href
... then do the thing we planned to do with introducing
href
krit:
can we agree on removing
those other attributes?
cabanier:
yes
RESOLUTION: Remove
all xlink attributes apart from xlink:href from
Filters.
krit:
next issue is something I'd
like to discuss at the next F2F
... then, issue 3
... the text is saying that xlink:href="" is an IRI to
something within the current SVG document fragment
... this limits filters to only the current document
... I think Filter is the only thing restricted like this
ed:
gradients does this too
... only for inheriting definitions of gradients
cyril
> isn't it the 10th
time we resolve on removing xlink:href ?
krit:
does Firefox implement
this?
birtles:
I think it may
krit:
for WebKit and Blink I'm
pretty sure we don't
... do we want to deprecate it?
ed:
cleaner just to remove
it?
heycam:
I don't see it as very
useful for
ed:
it's of very limited use
heycam:
I've never liked this
inheriting pattern
krit:
Inkscape uses it for
gradients
... it doesn't for filters
ed:
I wanted to lift the
restriction at some point, but the feature isn't that
useful
... and we decided to keep it limited, since we want to remove
it
krit:
I won't implement it in
WebKit and Blink
heycam:
it's probably all right
for us to remove it then
RESOLUTION: Remove
krit:
issue 4, discuss at next
F2F
... issue 5 is difficult to discuss without Chris
it's about this in the spec:
Unless otherwise stated, all image filters
operate on premultiplied RGBA samples. Some filters like
non-premultiplied data. For the time of the filter operation,
all color values must temporarily be transformed to the
required color multiplication of the current filter unless
stated differently on the particular filter primitive.
krit:
I think the last part
doesn't matter, since none of the primitives have special
handling
... they all require one of the colour spaces
... the input must be in premultipled or
non-premultiplied
... I think the last sentence is confusing
... I just want to remove the "unless ..."
... the issue is incorrect, it's nothing to do with color
space
cabanier:
[asking about
sepia]
krit:
that would be a separate
issue
... next issue 6
... "Why is SourceGraphic drawn into a fixed linear RGB?"
... SourceGraphic takes the parent object, why do you need to
draw it into a temporary buffer in linearRGB?
... why can't you change it to something different?
... would like to get some input from Chris
... Issue 7
... the FillPaint and StrokePaint allow you to reference the
fill/stroke of the element you're filtering
... and use these fill or paint servers as generated input
images
... the question is, it's not really defined how you actually
use them
... you can have FillPaint referencing a paint server, like a
pattern, and that can be userSpaceOnUse or
objectBoundingBOx
... the objectBoundingBox of what? the element that is
filtered?
heycam:
I'd say the bounding box
of the thing it's targeting
krit:
that would make sense
... but the spec doesn't say
... if the paint server is drawn using objectBoundingBox, then
it should use the boundign box of the element being
filtered
ed:
the alternative would be the
filter region
RESOLUTION:
FillPaint/StrokePaint objectBoundingBox should be relative to
the bbox of the filtered element.
krit:
issue 8
... which coordinate space for userSpaceOnUse?
... if you have a paint server with userSpaceOnUse, which user
space to use?
... the filter can be in an SVG element that has a different
viewport from the filtered element
heycam:
I think again it only
makes sense to use the filtered element's user space
ed:
I agree
RESOLUTION:
FillPaint/StrokePaint userSpaceOnUse should use the coordinate
space of the the filtered element.
krit:
skip issue 9
... issue 10, we discussed this multiple times before
... we have different subregions
... should the input of the filter prmitive be clipped, the
output clipped, both? or not at all?
... the spec really says you should clip the output
... implementations are inconsistent
... you can't test what they implement, since it's hard to
figure it out; it doesn't matter in most cases
... would be good if we define which we use
... just pick one
ed:
if it doesn't make a big
difference, why do we need to define it?
krit:
it does make a difference,
but it's hard to test -- it depends on the particular filter
operator
heycam:
what was the outcome of
the previous discussion?
krit:
we talked about clipping
both
... but that is the most limiting
... do we want to change this? or keep it as it is?
heycam:
I say just keep our
previous decision
ed:
alternative is to add some
control over it
krit:
don't think that's
necessary
RESOLUTION: Filter
primitives will clip both input and output.
krit:
issue 11
... should we add all remaining blend modes from
Compositing?
... feBlend has certain blend modes
... Compositing has more
... do we backport them?
heycam:
I think so
ed:
yes
krit:
I'd like to have a wiki
page with all features that aren't in Filters but we might want
to deal with in the next level
... I'd like to defer these to the next level
... there was also a request to backport all the Compositing
modes from that spec to feComposite
... but we removed compositing from CSS
nikos:
the extended porter-duff
isn't in level 1, deferred to level 2
cabanier:
but it is in there for
canvas
... you can do all the porter duff with the current
keywords
... so I think you should just close this issue
shepazu:
whenever I talk to
developers/designers, who really want compositing
... what was the rationale for deferring this?
krit:
they really want blending,
rather than porter duff
shepazu:
what was the rationale
for not putting it into this level?
cabanier:
it was impossible to
implement in the way that you expect it
... we're working on it
... I think the browsers are all upgrading their
compositors
... we still get pushback because it's much more complex than
it first seems
... but we're slowly moving towards getting it working
nikos:
and the blend modes have
been implemented
shepazu:
what's the timeframe for
porter duff?
cabanier:
we'll start working on
the level 2 spec as soon as this one goes out
... for blink, it'll probably be 1 year out
... it's not technical issues, but it's convincing people
shepazu:
a matter of resources,
ok
RESOLUTION: We will
defer the addition of the Compositing spec's blend modes to
feBlend.
krit:
issue 12, this is one
together with issue 14 from Tav
... he is saying at the moment if you don't specify anything
for in2="", in Firefox/WebKit the filter operation doesn't
work
... but he expects in2="" to use the same as in=""
... looks like some implementations do so
... I think the spec text meant just that the syntax is the
same, though
heycam:
should the whole filter
fail if you leave off in2?
nikos:
or should the input 2 be
transparent?
... I think it makes sense for it not to be optional
krit:
so Firefox and Blink make
the whole filter invalid when you leave off in2
ed:
the whole filter?
... or just that primitive?
krit:
actually not sure
ed:
maybe one thing Opera did
that the others didn't was to come up with lacuna values, so
use something in most cases
... that might be the reason why it's rendering something
... that was never defined for Filters, since they weren't in
1.2T
krit:
sounds like most people
think the filter primitive should be invalid in this case?
krit:
we'll delay this for a week
to see if IE people have an opinion, since they don't treat it
as invalid
... issue 13. some time ago we decided feBlend just to do
blending, at the moment is does blending and compositing
... if you want to have that, we'd need to decide on a
keyword
... I don't think is important
... though we resolved in Tokyo to have it, we didn't resolve
on a name
cabanier:
how long will the spec
be before CR?
... two years out?
... we could put it in
krit:
then we should choose a
name
... XML doesn't allow attributes without values
heycam:
you do abc="" or
abc="abc"
krit:
this attribute would switch
between blending with or without compositing
TabAtkins
> Boolean
attributes in HTML just give the attribute the empty string as
value.
TabAtkins
> Please no boolean
words.
krit
heycam:
we could also stick
another keyword in the mode="" attribute
... to disable the compositing
krit:
mode="darken
no-composite"?
... or mode="darken src-over" vs mode="darken src"?
nikos:
saying "src" still implies
there's a compositing operation
... if you used Compositing & Blending 'src' for the
composite operation, and a blend operation, you'd get a
different result
... for the two overlapping circles, you'd have a bit of the
circle showing up
... if you want to blend without compositing, you kind of want
to draw both
cabanier:
no
... you want to avoid contributing the backdrop twice
nikos:
I think it might be
confusing in the future when you have the other method of
compositing
... I think you should be clear there's no compositing at
all
... since we're going to add compositing, I think it would be
confusing
cabanier:
the intent is for
canvas compositing and css compositing that you can specify
blending & compositing, combining the 2 keywords
... if we do it in this filter, it would be consistent with
that
... though today it would be a bit odd, having only "src" and
"src-over"
nikos:
discuss on the ML?
krit:
ok
... issue 15, feConvolveMatrix and fe lighting are device pixel
dependent
... you kind of make it independent using
kernelUnitLength
... but unless you create a filter primitive only for a single
element, you can't really do that
... you can't generalise it
... my question is, if you want to specify that instead of
kernelUnitLength that it always works on device pixels, you
always have clear results, but is highlight device
dependent
... depends on the pixel density
... otherwise you could do it in the user space of the
element
heycam:
where one unit = one
pixel?
krit:
yes
... pixellated results, but it's consistent
... I'm fine with having kernelUnitLength in the spec for now,
with a note saying it may change in the future
... but without a solution yet
ed:
fine with me
RESOLUTION: We will
keep kernelUnitLength but add a note explaining why it's not
great, and that we may have something different in the
future.
krit:
issue 16 & 17 are
related
... issue 16 the whole para is differing between high res and
low quality implementations
... we discussed yesterday about that
... I don't think we should differ between them
... in general, we should allow implementations to scale the
whole filter operation if it couldn't be computed
otherwise
... if it would run out of memory etc.
... I would like to discuss about image-rendering in
general
... about whether certain kinds of interpolations are required
or not for "high quality" or not implementations
heycam:
do you want to require a
particular kind of scaling here for filters?
krit:
no
heycam:
how about remove the last
two sentences there altogether?
krit:
ok
TabAtkins
> image-rendering
puts only the barest of requirements on what is required.
TabAtkins
> At the lowest
level, you can do linear-interpolation for "auto" and
nearest-neighbor for the other two.
krit
> When the image must be
resampled, it is recommended that high quality viewers make use
of appropriate interpolation techniques, for example bilinear
or bicubic. Depending on the speed of the available
interpolents, this choice may be affected by the
‘image-rendering‘ property setting.
TabAtkins
> (Actually, you
can do nearest neighbor for "auto" if you need to.)
krit
> sentence from current
spec
ed:
so you're saying
image-rendering should not affect the scaling?
krit:
for us it doesn't
ed:
so it shouldn't be allowed
to
krit:
it's a MAY
ed:
I don't have a strong
preference
... it is a hint anyway
krit:
what do you think about the
first sentence?
ed:
the first sentence can go
krit:
because image-rendering
also specifies bilinear
... I'd also like to put that whole sentence and put it at the
start of the para
... I'll come up with a proposal for changing the wording
here
... issue 18 is a result of a previous resolution of
input/output clipping
... don't need to discuss that now
... issue 19 is also related to that, I need to look into
it
... issue 20. it's about feImage and images that don't exist or
are blocked. what should happen?
... I think the whole filter chain should fail
heycam:
what happens if the 404
response is an image?
... should the feImage still work on the 404 image
response?
... if a normal element displays a 404 image
response then it should work here
krit:
the 404 image is trying to
say there is something that should be displayed here, but
couldn't
... I don't want to indicate that the image doesn't exist
... it might be a computation map for the filter
heycam:
so the broken image image
that the browser renders shouldn't be the feImage output, I
agree
... but what about if the 404 response from the server had type
image/png?
... *that* behaviour should be the same as
TabAtkins
> Images defines
the concept of an "invalid image" and uses that in a few
different ways, depending on th econtext.
nikos
krit:
can you agree that if you
don't get an image back from the server that the whole filter
chain fails?
heycam:
not sure if the whole
chain should fail, or just the primitive
... or what happens if an individual primitive fails
ed:
the question is when do you
detect the 404? you could have an feImage inside a filter,
that's not used in the filtering
... just sitting on the side
... should you still cancel the entire chain?
krit:
we generally still proceed
with the filter chain if a failing primtiive isn't used in the
chain
... I suppose it would be the same here for feImage
... I will look into it further and propose something
... continue the remaining issues after lunch; most don't
require discussion
cyril
> RRSAgent pointer
we haven't really started
just an off topic discussion about color
TabAtkins
> kk
scribe
> Scribe: Cameron
scribe
> ScribeNick:
heycam
More filter issues
krit:
... issue 18 and 21 are related
... both are solved by the previous resolutions
... issue 22, we talked about gaussian blur before
... if it has a negative value, we say it's like a null
filter
... erik on the ML asked if we could do the same for
feMorphology
... a year ago
... might be a good time to decide that
... even if you have a negative value, it's treated as if it
were zero
ChrisL:
clamped to zero
krit:
we also need to define what
zero does
... which i've done -- null filter if negative or zero is
used
... so, identity filter
RESOLUTION: If
radius on feMorphology is zero or negative, the filter operates
like an null filter (output = input).
krit:
issue 23
... "This filter primitive produces an image which contains the
specular reflection part of the lighting calculation. Such a
map is intended to be combined with a texture using the add
term of the arithmetic
Tav wanted to replace "map" with "image"
s/Tav/krit: /Tav/
krit:
I don't agree though, since
it is a bump map
cabanier:
but a bump map is an
image
see
cabanier:
does it make a
difference if it's required?
... is the result intended to be used, or is required to be
used? does it make a difference?
heycam:
you need to combine it
explicitly
... so it's "intended", because you should feMerge the output
of the lighting fliter with the thing you are lighting
... to get the intended effect
... but you are not required to put that additional feMerge, of
course
... I'm surprised if browsers differ in how they handled the
lighting filter output if it's not merged with the original
input, as Tav says
scribe
ACTION:
Dirk to investigate how lighting
filter outputs work when not composited on top of the original
thing being lit [recorded in
trackbot
> Created
ACTION-3547 - Investigate how lighting filter outputs work when
not composited on top of the original thing being lit [on Dirk
Schulze - due 2013-11-22].
krit:
issue 24. clamping the
feTurbulence numOctaves. firefox clamps it to 10.
ChrisL:
so it's diminishing
returns with higher octave values?
ed:
yes
heycam:
is it fine to choose 10,
really?
ChrisL:
it would be nice to see
in non-clamping implementations what the visual effect is
ed:
Presto clamped, can't
remember what number
... I have some examples written up to show this
TabAtkins
> Assuming there's
example code, it would be easy to demonstrate in canvas.
TabAtkins, there's pseudocode in the
spec...
scribe
ACTION:
Erik to find his numOctaves examples
to find out what a good number to clamp to is [recorded in
trackbot
> Created
ACTION-3548 - Find his numoctaves examples to find out what a
good number to clamp to is [on Erik Dahlström - due
2013-11-22].
TabAtkins
> Ah, yeah, the
spec has C code.
krit:
issue 25. this and the next
issue is determining "distance" between filters, for additive
animation
... for paced animation
krit
heycam:
I agree with my previous
proposal
krit:
some of these filter
primtiives aren't really linear when you combine them
heycam:
I think it's similar to
transforms, just concatenate the lists
krit:
that's mostly fine
... some functions are not linear
... what if you have "grayscale blur" on one and "blur
grayscale" on the other
heycam:
doesn't matter, you just
concatenate the lists
ChrisL:
sounds like the right
thing to do
RESOLUTION:
Additive animation of filter property works by concatenating
the lists.
krit:
let's discuss the issue of
distance calculations for paced animation of filter on the
list
krit
file:///Users/dschulze/Documents/hg/FXTF/filters/index.html#FloodColorProperty
krit:
there is one more issue
with flood-color and lighting-color
krit
krit:
currently you have
'
... should we refer to css-color-4, which includes icccolor in
ChrisL:
I'm reluctant to remove
it from SVG until it's definitely in CSS
... when it's in a WD
... it's better if it's in CSS as well, but there is still
pushback and discussion about the syntax
... however, I talked also with you about needing two types
"
... one is everything that can be a color
... the other is something used for the fallback sRGB
color
... doesn't allow HSL, etc.
... so we need to be careful which one we're using
... for flood-color at the end of the day we have
that means "all possible color syntaxes"
... css-color-3 defines
colors, etc.", but not ICC colors
... SVG defines
the functional form)
... we need to be careful about which one we're meaning
TabAtkins:
why do we need a
difference between those two?
ChrisL:
because in the definition
of the larger one you use the smaller one as the
"fallback"
... as it's used in SVG for sRGB fallback
... we should add an issue in the spec to say we how we'll
update when point to css-color-4
krit:
I'll do that
TabAtkins
> Is it for when
ICC specifies something outside the srgb gamut?
heycam:
it's for when you don't
understand ICC colors
... but also when you use device colors, and you e.g. apply a
filter to that element, which needs rgb colours
use and shadow dom
krit:
we decided to use the
shadom dom for the use element, in Hamburg
... the spec hasn't changed yet
... not sure who has the action yet
... the biggest problem is the instance tree
... the Blink people wanted to remove it, and Firefox did not
implement it
... the only other engine that supports it is Presto
... not sure about IE
... it might be possible to implement the instance tree on top
of shadow dom
... we're exploring it in Blink
... I'd like to try to specify use on top of shadow dom, and
instance tree on top of shadow dom
heycam:
so the instance tree is
for navigating over the original nodes really, since there's no
cloning going on
... but for shadow tree, they're cloned nodes
ChrisL:
you can modify the shadow
dom, but you can also modify the thing that created the shadow
dom
... reflecting both changes in to the tree?
... or does instantiating losing the link to the original
elements?
TabAtkins:
that's not true
... using mutation events we could make it live update
ChrisL:
but that's something you
need to do manually?
TabAtkins:
no
... we can make that part of how use works
ChrisL:
that's kind of how you
wanted it
... changing the original, and it will affect all of them
heycam:
so while with Web
Components, the author has to do the mutation observers and
propagate changes manually, here we should do it automatically
in the spec?
TabAtkins:
yes
krit:
I won't have time to work
on that before Jan
... if we want it to be in SVG2, we'll need to delay
shepazu:
we already decided
because of the DOM discussions, to delay LC of SVG2
heycam:
but we didn't decide to
delay our end of year cutoff
... ok, so we've decided to move our cutoff date to the end of
the January F2F, but any other items brought up in that F2F we
decide to add at that point, we'll give it a couple of
months
Promotion of attributes to properties
krit:
who had the action to do
this?
heycam:
nobody really
krit:
can you do it?
heycam:
not sure I really want
to
krit:
it's a big effort, since we
need to decide e.g. how 'auto' applies to
heycam:
also I'm still not 100%
sure I want to do it
ed:
not sure how much it ties in
to the SVG sizing discussion
... width/height on the root element is special
... I think Firefox already made width/height on the root
special
... they're presentation attributes more or less
krit:
I don't think so?
ed:
I think they're separate from
the properties
... it's kind of both
ChrisL:
for many years we pushed
that these things were different
... not the same as width/height properties
... it was the canonical examples for attributeType="XML/CSS"
in SMIL
ed
describes the issue
ChrisL:
then, when MS said they'd
only do animation of properties, and we discussed promotion of
a whole lot of properties, they got merged
... there were unresolved issues there though
... especially around percentages
... we ended up with something saying you either make a fixed
width/height to make it nonscalable, or give me an area to draw
in and I'll draw as much as I can
... 100% in CSS means something different though
... if we want to make these width/height attributes be the
same as the properties, we'd need to redefine them
... and worry about old content
krit:
the only thing that needs
to be clear is that width attribute and property are the
same
... for 'auto' you could say that it defaults to 100%
ChrisL:
auto-magic
... and what does 100% mean explicitly?
krit:
same as on a div
ChrisL:
of the containing
block?
... if I say
Succeeded: s/it's for maths/it's for maps/
Succeeded: s/remo e/remove/
Succeeded: s/RESOLUTION: Filter primitives that take in2="" are invalid if in2 is not specified.//
WARNING: Bad s/// command: s/Tav/krit: /Tav/
Succeeded: s/do to/to do/
Succeeded: s/ed/heycam/
Succeeded: s/buffered-rendering?/buffered-rendering work here/
Succeeded: s/display/overflow/
Succeeded: s/Lepzig/Leipzig/
Found Scribe: nikos
WARNING: "Scribe: nikos" command found,
but no lines found matching "
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname.
Found Scribe: nikos1
Inferring ScribeNick: nikos1
Found ScribeNick: nikos
Found ScribeNick: someone else
Found Scribe: Cameron
WARNING: No scribe lines found matching ScribeNick pattern:
Found ScribeNick: heycam
Found Scribe: Cameron
Found ScribeNick: heycam
Scribes: nikos, nikos1, Cameron
ScribeNicks: nikos1, nikos, someone else, heycam
WARNING: Replacing list of attendees.
Old list: Huangshan TabAtkins
New list: Huangshan
Default Present: Huangshan
Present: Cameron Doug Brian Satoru Jun Nikos Chris Cyril Erik Dirk Rik Tab
WARNING: No meeting title found!
You should specify the meeting title like this:
Got date from IRC log name: 15 Nov 2013
Guessing minutes URL:
People with action items: cameron cyril dirk erik
[End of
scribe.perl
diagnostic output]