- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 30 Aug 2013 08:42:32 +1000
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from this week's SVG WG telcon are below.
http://www.w3.org/2013/08/29-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
29 Aug 2013
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0071.html
See also: [3]IRC log
[3] http://www.w3.org/2013/08/29-svg-irc
Attendees
Present
[IPcaller], ed, heycam, +49.341.263.2.aaaa,
+33.6.48.38.aabb, krit, cyril, luc, +61.2.980.5.aacc,
nikos, +1.425.373.aadd
Regrets
Rik
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
1. [5]response to css-fonts-3 comments
2. [6]initial color for drop shadow
3. [7]adding edge mode to feGaussianBlur
4. [8]negative standard deviation on feGaussianBlur
5. [9]high dpi filters on convolution and lighting
6. [10]url() passed through on invalid reference
* [11]Summary of Action Items
__________________________________________________________
<trackbot> Date: 29 August 2013
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
response to css-fonts-3 comments
[12]http://lists.w3.org/Archives/Public/www-style/2013Aug/0477.
html
[12] http://lists.w3.org/Archives/Public/www-style/2013Aug/0477.html
CM: got this reponse tfrom John Daggett
... I will reply today asking for more detail on the test files
initial color for drop shadow
<krit>
[13]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#FilterProperty
[13]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterProperty
krit: we have a drop shadow filter function
… we have a default color value
… we don't have a fallback color
… I suggest using the same as box-shadow
… i.e. the current used value of the color property
heycam: is that the same for text-shadow and box-shadow?
krit: yes
heycam: sounds reasonable to me
ed: to me too
… this only applies if you don't specify the color in the
drop-shadow syntax right?
krit: yes
ed: fine with me then
RESOLUTION: drop-shadow will use the computed value of 'color'
property if no shadow color is specified
adding edge mode to feGaussianBlur
<krit>
[14]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#FilterCSSImageValue
[14]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterCSSImageValue
krit: for context, I implemented the CSS image function for
WebKit
<krit> background-image: filter(url(image.png), blur(10px));
krit: if you specify blur, then the image gets blurred
… but on the edges, it takes from transparent black
… you get a fading effect at the edges
… the problem is that the dimensions of the image must not
change
… so you clip right in the middle of the fading effect
… and it looks ugly
… my question is whether we can edgeMode that we have on
convolution matrix
… which specifies the edge behaviour you want
… it has three different values: you can take the same colour
at the edge
… another is that you walk to the opposite side's pixel (good
for repeating patterns)
… I'd suggest for the filter() function that we use the
edgeMode="duplicate", which takes the takes the colour at the
edge and repeats it
<ed>
[15]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#feConvolveMatrixElementEdgeModeAttribute
[15]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feConvolveMatrixElementEdgeModeAttribute
… this gives the most reasonable result
… there is an example where we apply different blurs and a
convolution matrix
… what do you think?
heycam: don't you just want to inflate the rectangle that clips
the background image?
krit: this would modify the origin of the background image
… if you increase the area, then the image would shift
heycam: maybe it's too much of a special case
krit: it wouldn't work if you had a repeated background image
... I'd like to add edgeMode="" to <feGaussianBlur>
… for the shorthand function I suggest it to be fixed
… fixed to be "duplicate", when used in a filter() image
… we could add an argument later if it's needed
ed: I'm wondering about the feGaussianBlur case
… you can have repeated tiles only when you use feTile, right?
krit: yes
ed: so that doesn't support edgeMode="" either
krit: with feGaussianBlur, you might not want the edge blurred
… but it also effects things like feTile
heycam: do this apply to 'blur'?
krit: just to blur
heycam: there aren't any other filter primitives that sample
outside the image?
krit: blur and drop-shadow can extend the image
… for blur the use case is that you don't want the edge fading
effect cut off
… the other filter primitives are just color manipulations
heycam: but drop-shadow doesn't sample pixels outside the
original image?
krit: right
ed: do we add this now, later, or just at feGaussianBlur?
krit: one option is to not care about it at all
… second option is to have special behaviour for filter
functions
… third option is have edgeMode="" on <feGaussianBlur>, and
still have special behaviour for filter functions
heycam: we don't have to special case 'blur', just say that if
any filter primitive sampled outside the original image, it
uses the edgeMode="duplicate" behaviour
ed: I'm wondering about the syntax, what would you put in the
shorthand syntax?
<scribe> … new parameter? new property?
krit: so far I'm still suggesting to fix it to "duplicate"
… but later we could add a new keyword next to 'blur'
ed: no objections to this right now
krit: we can review it later if we need to
<krit>
[16]http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlOb
jectApproved/filters-conv-01-f.html
[16]
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-conv-01-f.html
<scribe> ACTION: Dirk to edit FIlter spec to make
edgeMode="duplicate" behaviour the default for filter() image
functions [recorded in
[17]http://www.w3.org/2013/08/29-svg-minutes.html#action01]
<trackbot> Created ACTION-3521 - Edit filter spec to make
edgemode="duplicate" behaviour the default for filter() image
functions [on Dirk Schulze - due 2013-09-05].
RESOLUTION: filter() image functions use edgeMode="duplicate"
behaviour for sampling outside source image
negative standard deviation on feGaussianBlur
krit: I noticed that we have no special case for negative
values
… implementations agree that we don't support them
… I think that makes sense. for a negative value you either
take the absolute value, or define what else happens
… an error state or as zero
heycam: we could treat it as if you didn't specify it
krit: Lacuna value is actually zero
ed: the equations specify what happens for negative values, but
we decided not to allow it
… the stdDeviation values are squared anyway, so it would work
… so a minus value would be the same result as the positive
value
… I think the spec right now says it's in error
krit: it doesn't
… for squaring, it's true for real gaussian blur, but not for
the approximation
ed: I was sure we had negative value handling in the spec, but
maybe we don't
krit: I just added "A negative value or a value of zero
disables the effect of the given filter primitive (i.e., the
result is the filter input image)."
... so that's fine, keep it?
heycam: yep
ed: that's what implementations do?
krit: yes. though I think Firefox disables rendering of the
element.
heycam: file a bug!
RESOLUTION: Keep current negative stdDeviation value handling
that's in the spec.
high dpi filters on convolution and lighting
krit: gaussian blur and lighting are highly resolution
dependent
… you could simulate with your normal screen if you zoom in
… you can see the rendered result doesn't scale
<krit>
[18]http://www.w3.org/Graphics/SVG/Test/20110816/svg/filters-co
nv-01-f.svg
[18]
http://www.w3.org/Graphics/SVG/Test/20110816/svg/filters-conv-01-f.svg
… if you resize the window, you see the result looks different
… is this the desired effect?
… do we accept that the results are resolution dependent?
… we have filterRes="" to make things look the same on all
devices, but people don't use that
… (and kernelUnitLength="")
… filterRes="" affects the whole filter chain,
kernelUnitLength="" is just for the convolution primitive
… scaling the kernel unit length automatically could result in
different behaviour
… I think kernel scaling is not a possibility
heycam: I would be worried that authors are expecting
convolutions etc. to be acting on specific bitmap image
… and scaling could change the result
krit: this issue comes up with hidpi displays
… but it existed before, with zooming
… we already decided to remove filterRes=""
… but you can still use kernelUnitLength=""
… I checked various examples on the Web, didn't find uses of
these attributes with convolution matrices or lighting effects
… kernelUnitLength="" doesn't really help the author; it's
dependent on the object size
… to apply the filter to a specific object you need to know the
size of the object
… which reduces reusability of filters
… (the object could be text, shapes, etc.)
ed: how common did you find the use of convolution matrices?
krit: I found a lot of tutorials, examples
… where the kernel didn't really matter
… e.g. a 3x3 matrix that just did a blur
ed: my personal experience is that it's not very common
krit: so what do we want to do?
… we could say that these filters are highly dependent on the
resolution
… this might be fine for convolution matrices, but not great
for lighting filters
… they're used for bump maps
… we could scale the image ourselves, we know the local space
to screen coord space
… we could say how much 1 CSS px scales to the screen
… so we could have a convolution matrix / lighting that is
independent of the platform
… but since 1 CSS px doesn't match 1 device pixel, if you
scaling things you'll lose quality
… you could pixellate, or bilinear interpolate, ...
… might look reasonable, might look very bad
… but at least they would be the same across platforms
… my suggestion is that we preserve the current mode, device
dependent results, but allow the user to specify that it scales
so that it is platform independent (possibly with a loss of
quality)
ed: how about must at least match CSS pixels, but
implementations are allowed to match device pixels?
krit: how would the author control that? at all?
ed: we already have a quality hint
… maybe there's not one for filters?
krit: we could say that image-rendering could affect the result
of filters
ed: we should try to compute reasonable values on behalf of the
user
krit: I don't care how we do it -- a new attribute, or hints
from other properties -- but maybe not implement
kernelUnitLength at all
heycam: so convolution matrices always have to be a specific
size?
krit: it doen'st affect the convolution matrix
… it scales the input to the kernel
… but kernelUnitLength always makes things look bad, if device
independent
… so I'm suggesting using either CSS px or device px everywhere
… and not have kernelUnitLength
heycam: so Blink/WebKit doesn't implement kernelUnitLength
currently?
krit: right
… it's implemented in Firefox, Batik, possibly in ASV
ed: Presto had it too
heycam: what was the view on the mailing list?
krit: one implementer in a new UA agreed kernelUnitLength is
not useful
… ddailey suggested lack of usage could be due to lack of
implementation
… but I don't think that addresses the concerns with
kernelUnitLength
krit: so I propose to remove kernelUnitLength="", either add a
new attribute to select between matching to CSS px or device
px, or use one of the existing properties
… I'd prefer a new attribute
… I can work out a proposal
<scribe> ACTION: Dirk to propose an attribute to control
convolution/lighting kernel size working on CSS or device
pixels [recorded in
[19]http://www.w3.org/2013/08/29-svg-minutes.html#action02]
<trackbot> Created ACTION-3522 - Propose an attribute to
control convolution/lighting kernel size working on css or
device pixels [on Dirk Schulze - due 2013-09-05].
url() passed through on invalid reference
krit: right now you can use url() to reference an SVG filter
… if the filter doesn't exist, or is not loaded, the whole
filter chain is in an error state and we don't render the
element at all
… so if you specify a 'filter' property with an invalid url,
the whole element doesn't get rendered
… with filter functions, I don't think it's useful
… if we have an invalid url, we should treat it as a
passthrough filter
… it's easier for the author to see that something is not
working -- you also see it if it's not rendered at all, but I
think that's more confusing
… if you have two url() functions in a chain, the second would
get a null image input
… and applies its own filters to this null image
… either way it's not the desired result of the author
… but I think it's easier for the author to see what's
happening, and for the viewer
… this has no effect on the screen reader btw
ed: so you want it to be a pass through, rather than breaking
the entire chain, using no filter at all?
krit: that's another option
… not applying the filter at all
ed: if you have a chain of filter, presumably you want the
entire thing
… I can see sometimes you might want the pass through
… either of those options
krit: which would you prefer?
ed: I guess it depends on how it's used
heycam: I feel like there's more chance of the reader being
able to read the content if you don't apply the entire filter
chain
… because leaving out one filter primitive could leave you in a
state where the content is not readable
ed: it depends how you're constructing your examples
… might be cases where you're applying it to a duplicated part
of the page where you don't want it to show at all
… I could see it either way
heycam: maybe that case wouldn't come up that often, since
you'd do the duplication in the filter itself
ed: sounds like ignoring the whole chain has the most support
RESOLUTION: An invalid url() in a filter chain causes the
entire filter chain not to be applied.
Summary of Action Items
[NEW] ACTION: Dirk to edit FIlter spec to make
edgeMode="duplicate" behaviour the default for filter() image
functions [recorded in
[20]http://www.w3.org/2013/08/29-svg-minutes.html#action01]
[NEW] ACTION: Dirk to propose an attribute to control
convolution/lighting kernel size working on CSS or device
pixels [recorded in
[21]http://www.w3.org/2013/08/29-svg-minutes.html#action02]
[End of minutes]
Received on Thursday, 29 August 2013 22:43:07 UTC