minutes, 29 August 2013 SVG WG telcon

Minutes from this week's SVG WG telcon are below.



       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

29 Aug 2013



    See also: [3]IRC log

       [3] http://www.w3.org/2013/08/29-svg-irc


           [IPcaller], ed, heycam, +49.341.263.2.aaaa,
           +, krit, cyril, luc, +61.2.980.5.aacc,
           nikos, +1.425.373.aadd





      * [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

    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: 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: for context, I implemented the CSS image function for

    <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

    … 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



    … 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

    … 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



    <scribe> ACTION: Dirk to edit FIlter spec to make
    edgeMode="duplicate" behaviour the default for filter() image
    functions [recorded in

    <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

    … 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

    … 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

    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

    … you could simulate with your normal screen if you zoom in

    … you can see the rendered result doesn't scale



    … 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

    … 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

    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

    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

    krit: it doen'st affect the convolution matrix

    … it scales the input to the kernel

    … but kernelUnitLength always makes things look bad, if device

    … so I'm suggesting using either CSS px or device px everywhere

    … and not have kernelUnitLength

    heycam: so Blink/WebKit doesn't implement kernelUnitLength

    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

    … but I don't think that addresses the concerns with

    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

    <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

    … 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
    [NEW] ACTION: Dirk to propose an attribute to control
    convolution/lighting kernel size working on CSS or device
    pixels [recorded in

    [End of minutes]

Received on Thursday, 29 August 2013 22:43:08 UTC