minutes, 10 August 2012 SVG WG telcon



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

                                - DRAFT -

                     SVG Working Group Teleconference

09 Aug 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/08/09-svg-irc


           +1.415.832.aaaa, heycam, +61.2.980.5.aabb, birtles,
           krit, nikos, Kelvin, hober, Doug_Schepers,
           +1.612.789.aacc, Tav, +1.415.832.aadd, [IPcaller]




      * [4]Topics
          1. [5]Publishing Filters
          2. [6]Kelvin Lawrance introduction
          3. [7]Moving Masking to a FX specification
          4. [8]Registration for F2F in Switzerland
          5. [9]Transformable masks
          6. [10]getBBox() with zero width or height shapes
          7. [11]Filter clipping region
      * [12]Summary of Action Items

    <trackbot> Date: 09 August 2012

    <scribe> ScribeNick: heycam

Publishing Filters



    Dirk: worked on Filters for quite some time

    … it's based on SVG filters + new effects, like drop shadow,
    and shorthand filters for CSS


    … something also added was CSS Shaders

    … we updated the CSS Shader security model according to
    comments on the list

    … we think we've covered the issues

    … it's in good shape to get published now

    <krit> :(


      [14] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

    CM: it's the FPWD


      [15] http://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

    … although the document has been split out for a while

    Doug: when did Shaders get added to the Filters spec?

    Dirk: a few months

    RC: I think at least a year

    CM: do you think the shaders stuff is going to slow down the
    rest of the document?

    Doug: yes there's a risk

    Dirk: there's not two implementations

    … but this is just asking for a FPWD

    RC: we don't need two implementations yet?

    Doug: no


    … my only concern, pro forma, filters is moving forward at a
    good pace, and I suspect we will have interop on filters,
    considering we have tests already

    RC: for the filter shorthands we haven't heard from other
    people yet either

    Doug: do you think time frame wise, we'll be able to accomplish
    all of this in the same time frame?

    Dirk: I think they belong together and that's why they should
    be together

    Doug: I'm just wondering if it should be a separate spec

    … don't want to argue at this point, but down the track we
    might need to reevaluate

    … can we have a Test Facilitator?

    Dirk: I'm starting writing a test suite

    CM: I find the document a bit hard to read with its style

    Dirk: you can click the "default style" link at the top right
    ... I agree we need some tests

    … I could volunteer to be the Test Facilitator for the document

    NA: why are you not listed in the editors?

    Dirk: I wanted to ask about that

    CM: it's fine from our side for you to be an editor of the

    RESOLUTION: SVG WG is happy to publish Filter Effects FPWD

Kelvin Lawrance introduction

    KL: I know a lot of you came on after I left

    … I was on the original SVG WG last century

    … and stayed with it mostly to the end, writing a viewer and
    test cases

    … I stopped being a member about the time just before 1.0 was

    … the reason IBM has rejoined is that I and Rich Schwerdtfeger
    have been following SVG and hoping for it to become mainstream

    … Rich asked me to work with him on accessibility for SVG

    … we did a gap analysis here at IBM, and we wanted to engage
    with you guys on what it would take, we think, to add some more
    interesting accessbility features to it

    … we need our products to be more accessibility, so we're

    … I'm in Austin, TX

    … I'm part of the emerging standards group

    <scribe> … continued to follow SVG as it evolved

Moving Masking to a FX specification



    Dirk: the CSS WG was already looking at specifying masking in
    CSS in general

    … we already have an implementation for masking in CSS

    … it looks like we can just move both specifications together,
    the CSS part of masking and our masking in SVG

    … and make it possible to apply both masks to both content

    … Ted already volunteered to look at that

    TO: nothing much to add, I think from a WebKit perspective
    we've had a good experience with people using masks

    … our existing syntax is straightforward, so I think the reason
    why it didn't move forward in CSS a few years ago is that SVG
    already had masks, and there was concerns with feature overlap

    … and incompatibility

    … if we can do this in FX with an eye towards harmonising I
    think that would be fantastic

    CM: I think it makes complete sense

    Dirk: do we want to move clip-path to the specification as
    well? or just mask?

    CM: good question, they're simliar things

    Dirk: I think it would make sense to allow clip-path applying
    to HTML content

    … and Mozilla already supports this

    RC: would the clipPath be SVG content?

    CM: I'm wondering if it makes sense to have a simpler syntax
    for clip-path than referencing an SVG fragment for the path

    Dirk: I think we can worry about it later

    TO: I think of clipPath as one of the reasons to use SVG

    CM: I think we could make clip-path apply to HTML elements

    Tav: I'd like that, but I don't want to see a path syntax in

    KL: I view masking as more aligned with filter effects, for
    example I see gradients going over a picture, but clipPath is
    more of a geometrical thing

    CM: I think authors think of them similarly though

    Dirk: besides referencing an SVG clipPath, maybe you can have a
    shorthand with a point list

    CM: maybe we can just start with mask, and add it in later if
    people request?

    BB: I would say put it in, and drop it if people think it's

    RC: defining a path syntax in CSS would be more contentious

    … if Exclusions proceeds rapidly then we can reuse that syntax

    CM: who was planning on being the editor?

    TO: I just became one of the HTML editors so I'm not sure I'll
    be able to have time for it

    … but I'm happy to try to help if someone wants to run with it,
    I'll chip in

    RESOLUTION: We will split out Masking into an FX document and
    combine it with CSS masking (-webkit-mask)

    CM: Brian would you be interested in editing?

    BB: I could get the document started but won't have time to
    edit it

Registration for F2F in Switzerland


      [17] http://www.w3.org/mid/501CAE02.6020809@mcc.id.au

    CM: since Andreas is organising the hotel please respond ASAP

Transformable masks



    CM: this is why we don't have maskTransform on <mask>?

    Dirk: other resources are transformable, like clipPath. why is
    mask not transformable?

    CM: I can't think of a good reason why not
    ... so gradients use gradientTransform

    Dirk: but clipPath uses transform

    … I think we should just use the name transform

    … (there's patternTransform too)

    CM: and in the Transforms spec these are just presentation
    attributes for the 'transform' property?

    Dirk: yes

    CM: I am not opposed to mask being transformable

    BB: sounds good

    NA: can't think of a reason why not

    KL: I can try to ask some of the guys back then who might

    … I can guess, but I could ask JonF

    Tav: this is why I've been pushing for annotations in the spec

    <scribe> ACTION: Kelvin to ask JonF why mask doesn't have
    transform [recorded in

    <trackbot> Created ACTION-3338 - Ask JonF why mask doesn't have
    transform [on Kelvin Lawrence - due 2012-08-16].

    CM: with clipPath, do the transforms from ancestor elements
    contribute to the clipPath's transform?

    … but patternTransform wouldn't?

    Dirk: patternTransform transforms the content

    … for clipPath, I just know we apply that single transform

    RC: for Adobe's imaging, our soft masks don't have matrices

    … which might be why <mask> doesn't have a transform

getBBox() with zero width or height shapes



    CM: long thread on www-svg about whether getBBox should return
    a correctly positioned zero sized bbox for a shape with zero
    width or height

    Dirk: from the WebKit side, for normal shapes this should not
    be a big deal

    … for ellipse, circle and rect

    … with path I'm not that sure, we might have problems with it,
    but it's definitely solvable

    … display:none is a separate topic

    CM: I tend to agree with Dirk that returning a correctly
    positioned bbox would be preferable

    RC: getting a tight bounding box is a bit more work than a
    loose one, for beziers

    <Kelvin> I checked with JonF and he confirmed what I suspected
    that back in 1998-2001 when we did the original SVG work, we
    felt that as Masks would be applied at the lowest level of the
    graphics rendering engine that it would be too much to ask the
    engine to be able to do vector transforms that late in the

    BB: I think I agree with Cameron

    CM: I think it's just more useful for authors too

    … if it's difficult for the underlying library, then that's
    just some more work that needs to be done to get that working

    Dirk: for Gecko and WebKit, we do not make a rendering tree
    when display:none

    … we won't implement that do something like a shadow render
    tree just to make getBBox() on a display:none possible

    … if we really want to have a bounding box you can set

    … looks like IE does not do getBBox on display:none elements

    CM: I'm wondering how difficult it really is

    … you could just resolve the style on the element, and look at
    the transforms up the tree, as a one off when you call getBBox

    Dirk: there's also the difficulty of a display:none child not
    contributing to its parent's bbox

    RC: you could say display:none elements don't have style

    Dirk: we won't be implementing it for WebKit

    CM: you agree in principle that it would be useful?

    Dirk: yes, but implementation feedback is that it won't be
    implementable in WebKit

    CM: if all implementations except one don't handle getBBox on
    display:none elements, then that's the point where we should
    question whether it's useful to have it in the spec

    … but it sounds like everyone here is in favour of returning a
    bounding box for a zero-sized shape?

    RESOLUTION: Zero-sized shapes will continue to return a
    properly positioned and sized bounding box

    Doug: touching on pointer events, we still don't have a hit
    testing model for the web

    … we were going to have it in css3-ui, but it was put off

    … another place where we need to talk about pointer events is
    masking and shaders

    … and touch interfaces are also going to be relevant, and in
    the Web Events WG we're working on touch interface stuff

    … CSS has introduced the idea of there being a different
    granularity of the pointer

    … I'm wondering where pointer events should be specified

    … I don't think in SVG, it's more general

    Dirk: CSS?

    Doug: could be

    … but we're also talking about events

    … not sure why it's better there than anywhere else

    Dirk: just because it's set with a CSS property

    Doug: but it's also any kind of pointer/touch events

    … and I'm not sure the expertise is in that WG for this work

    CM: CSS is kind of a common ground between the different
    presentation languages like SVG and HTML

Filter clipping region



    Dirk: as an introduction, filters have different primitives

    … each primitive can have a so called subregion

    … SVG 1.1 says the subregion is a hard clipping region

    … a problem we always had was that 1.1 wasn't clear what it

    … output, input, both?

    … we had a resolution that it clips both input and output for a
    filter primtiive

    … this was also moved to SVG 1.1 SE

    … but the discussion in the mailing list was just that it
    should be doing output clipping

    … I did some tests of browsers

    … it looks like IE, Firefox and WebKit just do output clipping

    … and Opera just do input clipping

    … so nobody does what the spec says

    … should we move from input & ouptut clipping to something more
    common? or keep it as it is?

    CM: I don't have a good sense of what is more useful

    Dirk: you can emulate everything

    … if you only have output clipping, you can emulate input
    clipping anyway

    … and vice versa

    … so it doesn't really matter

    … but we should have the same default behaviour

    RC: emulate with an extra filter?

    Dirk: feOffset

    Tav: is the major purpose of this to avoid doing ltos of

    Dirk: it's just an edge case

    Tav: if you have a blur with high values you have to look at
    quite some distance

    … so it's computationally significant

    RC: this is input clipping

    Dirk: well the limit for infinite stuff is the filter region

    … the reason why I'm asking is because IE 10 is shipping soon
    and is in feature freeze

    … and if the spec is inconsistent with IE it might be bad

    … I don't want to rely on one implementation, but following IE
    here might make sense

    RC: could they just treat it as a bug and fix it?

    Dirk: might take a while

    … my opinion is to change the spec just to do output clipping

    NA: I don't think the spec does imply that you should do input

    Dirk: SVG 1.1 SE was clarified that subregions do clip inputs


      [22] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion

    ttribute and
    Attribute act as a hard clip clipping rectangle on both the
    filter primitive's input image(s) and the filter primitive

      [23] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveXAttribute
      [24] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveYAttribute

    CM: I lean towards clipping just output, but I want to hear
    what Erik says

    Dirk: for WebKit we could do either easily

    CM: us too

    <scribe> ACTION: Cameron to email Erik to ask his opinion of
    filter clipping [recorded in

    <trackbot> Created ACTION-3339 - Email Erik to ask his opinion
    of filter clipping [on Cameron McCormack - due 2012-08-16].

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Cameron to email Erik to ask his opinion of
    filter clipping [recorded in
    [NEW] ACTION: Kelvin to ask JonF why mask doesn't have
    transform [recorded in

    [End of minutes]

Received on Thursday, 9 August 2012 22:21:41 UTC