- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 10 Aug 2012 08:21:07 +1000
- To: SVG public list <www-svg@w3.org>
http://www.w3.org/2012/08/09-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
09 Aug 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0092.html
See also: [3]IRC log
[3] http://www.w3.org/2012/08/09-svg-irc
Attendees
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]
Regrets
Chair
Cameron
Scribe
heycam
Contents
* [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
[13]http://www.w3.org/mid/92709D97-07E6-4031-90C3-A4B4F7AE3D2A@
adobe.com
[13]
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>
[14]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
?
[14] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
CM: it's the FPWD
<krit>
[15]http://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
[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
{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
[16]http://www.w3.org/mid/4D5839DF-60ED-4EBF-88D8-FD6073DFEDC3@
adobe.com
[16]
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
[17]http://www.w3.org/mid/501CAE02.6020809@mcc.id.au
[17] http://www.w3.org/mid/501CAE02.6020809@mcc.id.au
CM: since Andreas is organising the hotel please respond ASAP
Transformable masks
[18]http://www.w3.org/mid/F3A628B4-3EDB-4B38-BE96-3FF4D3CF8F0A@
adobe.com
[18]
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
[19]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
[20]http://www.w3.org/mid/CAJgFLLvPwPxviX+BfuK4e=Y9kk3zFz5zE56B
akHgZnQqke0mzg@mail.gmail.com
[20]
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
[21]http://www.w3.org/mid/F8B16E4C-0C49-4ADB-B4D5-1AEDF84741A6@
adobe.com
[21]
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>
[22]http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubReg
ion
[22] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion
<krit>
"[23]http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveXAttr
ibute,
[24]http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveYAttri
bute,
[25]http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveWidthA
ttribute and
[26]http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveHeight
Attribute act as a hard clip clipping rectangle on both the
filter primitive's input image(s) and the filter primitive
result."
[23] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveXAttribute
[24] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveYAttribute
[25]
http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveWidthAttribute
[26]
http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveHeightAttribute
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
[27]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
Summary of Action Items
[NEW] ACTION: Cameron to email Erik to ask his opinion of
filter clipping [recorded in
[28]http://www.w3.org/2012/08/09-svg-minutes.html#action02]
[NEW] ACTION: Kelvin to ask JonF why mask doesn't have
transform [recorded in
[29]http://www.w3.org/2012/08/09-svg-minutes.html#action01]
[End of minutes]
Received on Thursday, 9 August 2012 22:21:41 UTC