SVG Working Group Teleconference -- 09 Aug 2012

<trackbot> Date: 09 August 2012

<scribe> ScribeNick: heycam

Publishing Filters

http://www.w3.org/mid/92709D97-07E6-4031-90C3-A4B4F7AE3D2A@adobe.com

Dirk: worked on Filters for quite some time

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

<krit> file:///Users/dschulze/Documents/hg/FXTF/filters/index.html

… 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> :(

<birtles> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html ?

CM: it's the FPWD

<krit> 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

{7}

… 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 document

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 published

… 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 motivated

… 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

http://www.w3.org/mid/4D5839DF-60ED-4EBF-88D8-FD6073DFEDC3@adobe.com

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 CSS

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 misplaced

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

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

CM: since Andreas is organising the hotel please respond ASAP

Transformable masks

http://www.w3.org/mid/F3A628B4-3EDB-4B38-BE96-3FF4D3CF8F0A@adobe.com

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 remember

… 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 http://www.w3.org/2012/08/09-svg-minutes.html#action01]

<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 attribute

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

http://www.w3.org/mid/CAJgFLLvPwPxviX+BfuK4e=Y9kk3zFz5zE56BakHgZnQqke0mzg@mail.gmail.com

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 pipeline.

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 visibility:hidden

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

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

http://www.w3.org/mid/F8B16E4C-0C49-4ADB-B4D5-1AEDF84741A6@adobe.com

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 clips

… 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 computations?

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 clipping

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

<krit> http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion

<krit> "http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveXAttribute, http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveYAttribute, http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveWidthAttribute and http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveHeightAttribute act as a hard clip clipping rectangle on both the filter primitive's input image(s) and the filter primitive result."

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 http://www.w3.org/2012/08/09-svg-minutes.html#action02]

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

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

09 Aug 2012

Attendees

Contents