See also: IRC log
<trackbot> Date: 09 August 2012
<scribe> ScribeNick: heycam
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
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
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
http://www.w3.org/mid/501CAE02.6020809@mcc.id.au
CM: since Andreas is organising the hotel please respond ASAP
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
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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Regions/Exclusions/ Succeeded: s/you/Cameron/ Found ScribeNick: heycam Inferring Scribes: heycam Default Present: +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] Present: +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] Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0092.html Found Date: 09 Aug 2012 Guessing minutes URL: http://www.w3.org/2012/08/09-svg-minutes.html People with action items: cameron kelvin WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]