W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2011

Re: Minutes, 26 July FX taskforce face to face meeting, Seattle

From: Linss, Peter <peter.linss@hp.com>
Date: Thu, 28 Jul 2011 17:06:46 +0100
To: Chris Lilley <chris@w3.org>
CC: FX <public-fx@w3.org>
Message-ID: <3396F066-373C-4FC2-8D85-44E3690BCD65@hp.com>
Also present:
Tantek «elik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter Linss (HP)

On Jul 27, 2011, at 11:27 AM, Chris Lilley wrote:

> On Wednesday, July 27, 2011, 8:16:53 PM, Chris wrote:
>
> CL> Minutes of the Seattle meeting are at
>
> (ignore those ones, the irc bot started a new log at midnight so they are truncated).
>
> For real this time:
> http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0024/26-fx-minutes.html
>
>                             FX Task Force
>
> 26 Jul 2011
>
>   [2]Agenda
>
>      [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
>
>   See also: [3]IRC log
>
>      [3] http://www.w3.org/2011/07/26-fx-irc
>
> Attendees
>
>   Present
>          Daniel_Glazman_(Disruptive_Innovations),
>          Sylvain_Galineau_(Microsoft), Arron_Eicholz_(Microsoft),
>          Jennifer_Yu_(Microsoft), Koji_Ishii, Elika_Etemad,
>          Steve_Zilles_(Adobe), Rik_Cabanier_(Adobe),
>          Alan_Stearns_(Adobe), Tab_Atkins_(Google),
>          David_Baron_(Mozilla), Anne_van_Kesteren_(Opera),
>          Divya_Manian_(Opera), Florian_Rivoal_(Opera),
>          Shane_Stevens_(Google), Patrick_Dengler_(Microsoft),
>          Simon_Fraser_(Apple), Dean_Jackson_(Apple),
>          Alex_Mogilevsky_(Microsoft)
>
>   Regrets
>
>   Chair
>          Erik
>
>   Scribe
>          dino
>
> Contents
>
>     * [4]Topics
>         1. [5]SVG Paint and CSS Images
>         2. [6]Pointer events an alpha-level hit testing
>         3. [7]filter effects
>         4. [8]filter effects (continued)
>         5. [9]CSS / SVG animations
>         6. [10]color correction
>         7. [11]SVG parameters in CSS in relation to CSS Variables
>         8. [12]FX transforms
>         9. [13]publishing schedule
>        10. [14]testing harness overview
>     * [15]Summary of Action Items
>     _________________________________________________________
>
>   [16]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
>
>     [16] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
>
>   <scribe> Scribe: dino
>
>   <scribe> Scribenick: dino
>
>   <tpod> Hello dino
>
>   is that all I have to do?
>
>   <tpod> Is this channel archived?
>
>   <anne> I am here
>
>   <fantasai> yes
>
>   <tpod> Publicly?
>
>   <fantasai> yes
>
> SVG Paint and CSS Images
>
>   <Ms2ger> Pain? :)
>
>   <smfr>
>   [17]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0111.ht
>   ml
>
>     [17] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0111.html
>
>   <hober> sylvaing: could you skype bradk & me in?
>
>   TabAtkins: There was a proposal a while ago about using SVG paint as
>   CSS images.
>
>   <smfr>
>   [18]http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_se
>   rve.html
>
>     [18] http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
>
>   TabAtkins: That's one proposal. I plan to add it into CSS Image
>   Values 4
>   ... The other way around is CSS into SVG paint servers
>   ... e.g. <rect fill="linear-gradient(top blue)">
>   ... but there are other useful things like the element() function
>   ... question is where to specify using CSS images as paint servers?
>
>   <dbaron> tek √elik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera),
>   Peter Linss (HP)
>
>   dino: what's the status of SVG specs
>
>   heycam: SVG 2e was just published. We are starting on new specs now.
>
>   <tpod> This is Tantek's iPod
>
>   heycam: it would be ok to specify this in image values spec
>
>   ed: many SVG implementations already support things like CSS3
>   colours anywhere you can use a <color> in svg even though that isn't
>   supported in the SVG spec(s)
>
>   dino: it seems weird for a CSS specification to define SVG behaviour
>
>   heycam: we could do it in the SVG spec, it would take time
>
>   szilles: It would be ok for the SVG spec to do this, by specifically
>   calling out the CSS image values spec as the normative behaviour.
>
>   tantek: The problem then is that the CSS image values spec now
>   requires an SVG implementation to exit CR
>
>   dbaron: it's ok if there are two browser engines that implement it
>
>   TabAtkins: Mozilla already have an implementation
>
>   <TabAtkins_>
>   [19]http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_se
>   rve.html
>
>     [19] http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
>
>   tantek: i am not formally opposing, but I think it is a potential
>   serious issue.
>
>   TabAtkins: all the CSS image values would be SVG paint servers in
>   userSpaceOnUse
>
>   heycam: uSoU percentages are relative to the viewport, not to the
>   bounding box of the shape
>
>   <tantek> <aside> Ms2ger - I created #fx-chat for off-topic
>   conversations. :) </aside>
>
>   TabAtkins: then the problem is that absolute lengths are not the
>   same. You don't have a middle ground where percentages are relative
>   to the bounding box and keeping units.
>   ... I don't want to create a new unit space just for this.
>
>   heycam: are there other issues?
>
>   TabAtkins: I think coordinate spaces are the only issues.
>
>   <dbaron> Brian Birtles (Mozilla), Cameron McCormack (Mozilla),
>   Tantek √elik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter
>   Linss (HP)
>
>   dino: what CSS image values have percentages?
>
>   TabAtkins: only gradients
>
>   vhardy: How about the keywords like top left etc? Would that be to
>   the SVG bounding box?
>
>   TabAtkins: we're dropping those temporarily. We'll have to deal with
>   that when it comes back in. I might have to think about coordinate
>   systems a little bit.
>
>   TabAtkins recaps yesterday's CSS discussion on gradients
>
>   <bradk> I thought we were unresolved on whether or not to do away
>   with corner-to-corner gradients for now. No concensus.
>
>   bradk, i believe they were officially deferred from CSS IM 3
>
>   ed: SVG 1.1 doesn't include the stoke and markers in the bounding
>   box. That might be important for gradients also.
>
>   TabAtkins: we may have to do some mode switching as you go from CSS
>   to SVG.
>
>   <bradk> dino, Are you sure? I don't recall seeing a resolution for
>   that. I thought it was "no consensus, back to the list".
>
>   TabAtkins: My plan will be to define how to use SVG paint servers in
>   CSS, and draft something for the other way around. We can decide
>   where to put the other way around.
>
>   bradk, no, I'm not sure.
>
>   <fantasai> There was no consensus on removing anything from
>   Gradients
>
>   bradk, but Tab is speaking now as if it was a resolution :)
>
>   <fantasai> Well, Tab's wrong then. :)
>
>   <bradk> wouldn't be the first time. ;)
>
>   heycam: CSS may have the same issue with calculating bounding boxes
>
>   TabAtkins: yes, it's fairly well defined there. It defines the
>   region of the canvas, such as content-box, border-box, etc.
>
>   RESOLUTION: Tab to add wording to CSS Image Values 4 about how SVG
>   Paint Servers apply to CSS
>   ... Tab to draft something about how CSS image values apply to SVG.
>   This will live in the CSS Image values 4 spec for now (it may move
>   later).
>
>   <stearns> bradk - you're right, it's not in the minutes. But I
>   believe it should have been
>
>   <fantasai> Dino: We had a mailing list discussion about new image
>   generators, kinda like your example of ppl using solid color with a
>   slight noise
>
>   <fantasai> Dino: We're sending out massive images right now when we
>   don't need to
>
>   <tantek> dino, TabAtkins, re: 2nd Resolution - suggest making that a
>   non-normative section.
>
>   <fantasai> Dino: Add things for noise, checkboard, halo, etc. Not
>   suggesting we add all those
>
>   <smfr>
>   [20]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.ht
>   ml
>
>     [20] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
>
>   <fantasai> Cam: How does Compositing work?
>
>   <fantasai> Dino; Becomes difficult in filters spec, bc sometimes you
>   want the generated below, and other times above.
>
>   <fantasai> Dino: e.g. ppl do a halo effect where a flash moves
>   across the text.
>
>   <fantasai> Dino: In that case you want it above.
>
>   <fantasai> Dino: Tab said it would be better to allow an image
>   anywhere in CSS
>
>   <fantasai> Dino: e.g. say your background is blue with a faint noise
>   texture above it
>
>   <cabanier> discussion:
>   [21]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.ht
>   ml
>
>     [21] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
>
>   <fantasai> Cam: With bg now you can specify multiple things?
>
>   <fantasai> smfr: multiple images, yes
>
>   <bradk> sterns, dino, I'm not really opposed, if we are just talking
>   about corner-to-corner, and not about removing keywords version
>   altogether. But I'd rather just resolve remaining issues first.
>   Anyhoo... not topic for now...
>
>   <fantasai> Dino: So, Tab and I came to an informal agreement that
>   would be a good thing to do, but maybe we should have a resolution
>
>   <fantasai> Tab: Thing sin CSS spec that would move to being image
>   values are :
>
>   <fantasai> Tab: flood ...
>
>   <fantasai> Tab: Unfortunately colors are not image types in CSS. Bg
>   has special case of bg-color
>
>   TabAtkins: flood would map to image() (eg. image(blue))
>
>   <fantasai> Tab: But you can't have list-style-image: blue;
>
>   <fantasai> Tab: If we don't get that otherwise, the image() function
>   lets you smuggle that in
>
>   TabAtkins: because image() has a fallback for a color
>
>   <fantasai> Tab: Because it allows a fallback color
>
>   TabAtkins: without an intrinsic size
>   ... turbulence could be an image value
>   ... the rest are filters so should stay as filters
>
>   dino: I propose asking for examples on the list of generated images.
>
>   RESOLUTION: The new image generator methods (eg. turbulence) to be
>   added to CSS Image Values 4
>
>   smfr: I am concerned about the syntax overhead of specifying some
>   complex filters. eg. a checkerboard has colour, repeat, offset.
>
>   TabAtkins: I agree. We'll have to balance that.
>
>   fantasai: Once SVG Paint Servers are allowed, it may be better to
>   reference an library of SVG images as a CSS paint.
>
>   ed: The noise function in SVG is defined in C, but it doesn't scale
>   to GPUs very well. I'd like to replace it with simplex noise.
>
>   vhardy: are you suggesting changing the algorithm as is?
>
>   ed: we can't remove what is there
>
>   vhardy: it was hard to get the algorithm right, we shouldn't change
>   it.
>   ... so which SVG filter primitives will become paint server?
>
>   TabAtkins: It won't be the full set.
>
>   dino: turbulence/noise is the only new one
>
> Pointer events an alpha-level hit testing
>
>   tantek: We have some degree of interop with the pointer-events
>   property. Mozilla + IE support it. WebKit supports "none" and "auto"
>   for HTML.
>   ... so it has been added to CSS 3 UI
>
>   <tantek> [22]https://developer.mozilla.org/en/css/pointer-events
>
>     [22] https://developer.mozilla.org/en/css/pointer-events
>
>   dbaron: I believe Mozilla support is similar to WebKit - none and
>   auto
>
>   (for HTML content)
>
>   <smfr> [23]http://dev.w3.org/csswg/css3-ui/#pointer-events
>
>     [23] http://dev.w3.org/csswg/css3-ui/#pointer-events
>
>   tantek: I've added all the values to CSS (eg. visiblePainted). We
>   need to make sure they are compatible with the way SVG defines it.
>
>   smfr: We've had requests to support visiblePainted in HTML for image
>   content.
>
>   ed: SVG does ignore hit tests on fully alpha pixels in an image
>
>   <ed>
>   [24]http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
>   (last paragraph, scroll down a bit)
>
>     [24] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
>
>   <ed> "The value visiblePainted means that the raster image can
>   receive events anywhere within the bounds of the image if any pixel
>   from the raster image which is under the pointer is not fully
>   transparent, with the additional requirement that the ‚visibility‚
>   property is set to visible."
>
>   dbaron: we need translations of the purely SVG names. define what
>   "stroke" means in HTML.
>
>   tantek: I suppose reducing the values now to "auto" and "none", then
>   put wording pointing people at a future spec for the other values
>   (eg. the SVG ones)
>
>   heycam: would the CSS spec define what shapes, etc are for the SVG
>   case? or should that be in the SVG spec?
>
>   tantek: I'll redefine "auto" slightly. It currently references
>   visiblePainted, but we're moving that out.
>   ... I'll normatively reference the SVG spec for SVG content.
>
>   <bradk> shouldn't there be a value for 'pointer-events' to determine
>   clickability based on an opacity value?
>
>   heycam: we should define a term in the SVG spec like "hit testable
>   area" and have that as a reference target
>
>   tantek: we can do that for a future spec, but we should move forward
>   with this now - ie. not wait for a future SVG spec
>
>   vhardy: what do you do for a stylesheet targeting both languages?
>   SVG will allow more values.
>
>   tantek: this is an old problem. some specifications allow different
>   values.
>
>   dbaron: i suspect that the current implementations accept all the
>   values that SVG supports, and treats the common value the same
>   across both languages.
>
>   tantek: then maybe the specification should define "auto" and
>   "none", then say that everything else is defined in the host
>   language.
>   ... this does mean that any new functionality will need new values
>
>   TabAtkins: hopefully people are not using visiblePainted and
>   expecting it to behave as "auto".
>   ... so we might be able to redefine visiblePainted
>   ... put the values in the spec and say that people should not use
>   them outside of SVG.
>
>   TabAtkins gave an example that the scribe missed
>
>   tantek: that example is deprecated values. this is different.
>
>   <vhardy> Example of precedent where SVG only uses a subset of the
>   existing value set:
>   [25]http://www.w3.org/TR/SVG/painting.html#DisplayProperty
>
>     [25] http://www.w3.org/TR/SVG/painting.html#DisplayProperty
>
>   szilles: the wording should be "these values only have defined
>   meaning in SVG"
>
>   RESOLUTION: List all the current values for pointer events,
>   everything other than "none" is treated as "auto" unless applied to
>   SVG content
>   ... Add an author conformance criteria saying that they should not
>   use the other values outside of SVG
>
>   <tantek> [26]http://wiki.csswg.org/spec/css3-ui#issue-4
>
>     [26] http://wiki.csswg.org/spec/css3-ui#issue-4
>
>   tantek: Issue 4 is related to the computed value
>
>   <tantek> @namespace svg "[27]http://www.w3.org/2000/svg";
>
>     [27] http://www.w3.org/2000/svg
>
>   <tantek> svg|svg { pointer-events: none }
>
>   <tantek> svg|svg>* { pointer-events: visiblePainted }
>
>   heycam: i don't think any content will be relying on seeing a
>   computedStyle of 'visiblePainted'.
>   ... so it would be ok to return 'auto' for SVG content
>
>   tantek: the style rule was an attempt to address the difference in
>   implementations.
>
>   ed: I think it would be ok to make SVG content have 'auto' as the
>   initial value
>
>   <tantek> [28]http://wiki.csswg.org/spec/css3-ui#issue-5
>
>     [28] http://wiki.csswg.org/spec/css3-ui#issue-5
>
>   vhardy: If 'auto' is added to CSS3 UI, we'll need to update/add the
>   SVG specification.
>
>   heycam: yes
>
>   <scribe> ACTION: Cameron to update the SVG specification, adding
>   'auto' the pointer-events specification. [recorded in
>   [29]http://www.w3.org/2011/07/26-fx-irc]
>
>     [29] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-35 - Update the SVG specification, adding
>   'auto' the pointer-events specification. [on Cameron McCormack - due
>   2011-08-02].
>
>   <ChrisL> which svg specification is that,Cameron?
>
>   tantek: moving on to issue 5
>
>   <heycam> ChrisL, that'd be SVG 2
>
>   <heycam> ACTION-35: To SVG 2
>
>   <trackbot> ACTION-35 Update the SVG specification, adding 'auto' the
>   pointer-events specification. notes added
>
>   tantek: I believe the style rule I gave above gives the SVG
>   behaviour to non-graphical elements.
>
>   discussion about what elements in SVG should get pointer events
>
>   <tantek> svg|svg { pointer-events: visiblePainted }
>
>   dbaron: the SVG element doesn't paint anything, then it should be ok
>   to have pointer-events applying to everything
>
>   heycam: also <g>
>   ... I think it should be auto everywhere
>
>   tantek: SVG doesn't specify 'auto'. we're trying to ship an
>   interoperable spec today.
>
>   vhardy: the property value is saying what is generating events, not
>   where you can place a listener.
>
>   tantek: are SVG ok with accepting this change?
>
>   Some discussion missed by scribe
>
>   <ChrisL> wasn't it mentioned earlier thatsome html browsers accept
>   visiblePainted?
>
>   <ChrisL> if the goal is interop now, that it the most interoperable
>   value
>
>   heycam: SVG2 will be a while coming. We'll change the value there.
>
>   RESOLUTION: Drop the SVG UA stylesheet rules. Add a note saying that
>   SVG will be adding 'auto' as the default value in a future spec.
>
>   <smfr> [30]http://wiki.csswg.org/spec/css3-ui#issue-6
>
>     [30] http://wiki.csswg.org/spec/css3-ui#issue-6
>
>   tantek: this makes Issue 6 a non-issue now
>
>   sylvaing: Question - is there a restriction on what elements the
>   pointer-events apply to?
>
>   tantek: do you have an example in markup?
>
>   sylvaing: we're worried about click hijacking
>
>   heycam: using elementFromPoint
>
>   smfr: This is a valid point to bring up.
>
>   sylvaing: MS is likely to add some restrictions on passing events
>   down to iframes, or whatever.
>
>   tantek: doesn't SVG define this with <foreignObject> ?
>
>   shepazu: spec doesn't say anything
>
>   tantek: what about implementations?
>
>   No one responds to suggest that SVG implementations are doing
>   anything to avoid click jacking at the moment
>
>   sylvaing: It's likely that we will not propagate an event into an
>   iframe
>
>   tantek: There are two problems: what should implementations do? and
>   now what should the specs say?
>
>   <tantek> [31]http://dev.w3.org/csswg/css3-ui/#pointer-events0
>
>     [31] http://dev.w3.org/csswg/css3-ui/#pointer-events0
>
>   tantek: I think the specification does have enough room to allow
>   implementations to not propagate events across origin if necessary.
>
>   tantek reads current CSS 3 UI spec language
>
>   (can someone paste it in or link?)
>
>   dbaron: i think that's more likely a bug in the spec rather than a
>   loose reading. It should be defined.
>
>   anne: agree. elementFromPoint only returns the iframe.
>
>   ----- break -----
>
>   <vhardy> ScribeNick: vhardy
>
>   ed: Let's continue on the CSS UI issues.
>
>   <tantek> [32]http://dev.w3.org/csswg/css3-ui/#pointer-events0
>
>     [32] http://dev.w3.org/csswg/css3-ui/#pointer-events0
>
>   tantek: we were discussing the click jacking scenario with
>   pointer-events: none.
>   ... sylvaing has a demo
>   ... the strawman proposal is to say that the UA must keep track of
>   the fact that the event fell through something that had
>   'pointer-events: none' and then check for cross-origin.
>
>   dbaron: you have the same issue with opacity.
>   ... the better protection is for web site to not allow being framed.
>
>   sylvaing shows a demo where a frame hides Amazon.com and a 'play'
>   button passes through and activates an 'add to cart button' without
>   the user's knownledge.
>
>   sylvaing: this is not a new issue, but it should be addressed.
>
>   tantek: the spec. as is, nothing says nothing about where the event
>   goes if the element does not handle it. It does not require anything
>   specific about z-order or children lower in the rendering stack.
>
>   shepazu: I think the spec. should be more specific.
>
>   dbaron: pointer-event's intent is to filter the targets of events
>   and to let the evet target something lower in z order.
>
>   shepazu illustrates the purpose of pointer-events: none.
>
>   anne: even if we want to be vague for cross origin, we need to be
>   specific for same origin.
>
>   tantek: there is a missing reference here to the definition of hit
>   testing.
>
>   anne: it should be in the pointer-events specification.
>
>   tantek: I do not agree.
>
>   <dbaron> [33]http://www.webkit.org/specs/PointerEventsProperty.html
>
>     [33] http://www.webkit.org/specs/PointerEventsProperty.html
>
>   tantek: does HTML5 define hit testing?
>
>   anne: no
>
>   <anne>
>   [34]http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
>
>     [34] http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
>
>   smfr: I thought it was defined.
>
>   <shepazu> [35]http://www.w3.org/TR/SVG/intro.html#TermHitTesting
>
>     [35] http://www.w3.org/TR/SVG/intro.html#TermHitTesting
>
>   anne: I think we had agreed that the definition of hit testing would
>   be in CSS 3 UI.
>
>   <anne>
>   [36]http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-ev
>   ents-20100820.html
>
>     [36] http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
>
>   tantek: this is just about the property.
>   ... there is nothign about geometry, z-index, etc...
>
>   <anne>
>   [37]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>
>     [37] http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>
>   anne: the first reference I pasted has a portion that needs to be
>   part of the spec.
>
>   <anne> hixie's notes on hit testing ^^
>
>   <tantek>
>   [38]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>
>     [38] http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>
>   shepazu: The SVG 1.1 2nd edition has a definition of hit testing,
>   which is new to SVG (was not in previous version).
>
>   <bradk> No skype... is Sylvain out??
>
>   anne: this was never in HTML5.
>   ... this should be in CSS.
>
>   tantek: or DOM Events?
>
>   several: CSS.
>
>   shepazu: should be in CSS.
>
>   tantek: should be split in CSS (geometry and opacity aspects) and
>   then the definition of events should be in DOM Events.
>
>   anne: sure.
>
>   tantek: this is essentially what Hixie's note is doing.
>
>   smfr: hit testing is the reverse of painting (order-wise). Where we
>   talk about painting order, we could talk about hit testing.
>
>   tantek: Hixie's note talks about painting order too.
>
>   <bradk> standing by...
>
>   tantek: are you saying that Hixie's note should be integrated in the
>   spec.?
>
>   anne: yes.
>
>   tantek: hit testing should be defined in CSS, in CSS UI.
>
>   anne: pointer-events is just about hit testing.
>
>   (discussion about Hixie's proposal and comments that were made).
>
>   shepazu: also needs to take into account SVG for hit-testing, so
>   that the definition is not just HTML.
>
>   dbaron: it is the opposite of z-order, so it should be fairly easy.
>
>   tantek: there are only a few exception cases with elements like
>   body, but the rest should apply for SVG.
>
>   shepazu: we should coordinate on this.
>
>   tantek: z-index and z-order should be in one place and hit testing
>   should reference that.
>
>   heycam: there are some SVG specificities that are different from
>   HTML.
>
>   <ChrisL> svg has a painting order, which is also relevant (as
>   z-index is for html/css)
>
>   anne: it would be nice if the hit testing algorithm was generic,
>   with possible arguments (like 'stop at the iframe')
>
>   shepazu: I think we need to do some more work and re-coordinate on
>   this later.
>
>   <smfr>
>   [39]http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
>
>     [39] http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
>
>   <scribe> ACTION: Tantek to integrate Hixie's proposal on hit testing
>   and define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG. [recorded in
>   [40]http://www.w3.org/2011/07/26-fx-irc]
>
>     [40] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - Tantek
>
>   <tantek> hello
>
>   <scribe> ACTION: tantek to integrate Hixie's proposal on hit testing
>   and define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG. [recorded in
>   [41]http://www.w3.org/2011/07/26-fx-irc]
>
>     [41] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - tantek
>
>   <ChrisL> trackbot, status
>
>   RESOLUTION: tantek to integrate Hixie's proposal on hit testing and
>   define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG.
>
>   <scribe> ACTION: shepazu to integrate Hixie's proposal on hit
>   testing and define hit-testing in CSS 3 UI and coordinate with Doug
>   for harmonizing with SVG. [recorded in
>   [42]http://www.w3.org/2011/07/26-fx-irc]
>
>     [42] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-36 - Integrate Hixie's proposal on hit
>   testing and define hit-testing in CSS 3 UI and coordinate with Doug
>   for harmonizing with SVG. [on Doug Schepers - due 2011-08-02].
>
>   tantek: this was the issue of security, partially. What do we need
>   to say about the scenario sylvaing presented.
>
>   shepazu: I liked the proposal with a dirty flag for something that
>   passed through because of pointer-events: none and then not
>   propagate to cross-origin.
>
>   tantek: the alternate proposal is to make a note that sites that do
>   not want to have this happen should not allow being framed.
>
>   dbaron: we should also talk to some people in the web security
>   field.
>   ... some people at Mozilla would know about this.
>
>   <scribe> ACTION: shepazu and dbaron to reach out to web security
>   experts and get an opinion on whether or not we should address
>   security concerns on the hit testing algorithm. Coordinate with
>   Tantek for the CSS 3 UI spec. [recorded in
>   [43]http://www.w3.org/2011/07/26-fx-irc]
>
>     [43] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-37 - And dbaron to reach out to web
>   security experts and get an opinion on whether or not we should
>   address security concerns on the hit testing algorithm. Coordinate
>   with Tantek for the CSS 3 UI spec. [on Doug Schepers - due
>   2011-08-02].
>
>   <shepazu> ACTION: dbaron to reach out to web security experts and
>   get an opinion on whether or not we should address security concerns
>   on the hit testing algorithm. Coordinate with Tantek for the CSS 3
>   UI spec. recorded in [44]http://www.w3.org/2011/07/26-fx-irc]
>
>     [44] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - dbaron
>
>   ed: is there anything more that we need to discuss here?
>
>   shepazu: want to talk about transparency.
>   ... proposal for alpha-levels.
>   ... this came up from Zynga.
>
>   <dbaron> trackbot, is user david David Baron or some other David?
>
>   <trackbot> Sorry, dbaron, I don't understand 'trackbot, is user
>   david David Baron or some other David?'. Please refer to
>   [45]http://www.w3.org/2005/06/tracker/irc for help
>
>     [45] http://www.w3.org/2005/06/tracker/irc
>
>   <ChrisL> action-1?
>
>   <trackbot> ACTION-1 -- Doug Schepers to create an FX repository --
>   due 2010-03-18 -- CLOSED
>
>   <trackbot> [46]http://www.w3.org/Graphics/fx/track/actions/1
>
>     [46] http://www.w3.org/Graphics/fx/track/actions/1
>
>   shepazu: they do most of their HTML5 games with PNGs that have
>   transparency and they need to do their own hit testing on the PNGs.
>
>   <ChrisL> users list at [47]http://www.w3.org/Graphics/fx/track/users
>
>     [47] http://www.w3.org/Graphics/fx/track/users
>
>   <ChrisL> david id david singer
>
>   shepazu: they would like to say that if a pixel has a certain level
>   of transparency, then the hist testing is not positive.
>   ... if opacity is less than x, then pass the even through
>
>   tantek: do they want the hit testing mask?
>
>   shepazu: they do not want to do their own hit testing.
>
>   tantek: there are cases where there is a hole and you still want to
>   hit positive for the hole.
>
>   smfr: I have not heard Zynga asking for a separate image.
>
>   tantek: where the opacity may address some of the use cases, it
>   seems that a separate mask would cover more use cases.
>
>   vhardy: and the image's opacity could be the default mask.
>
>   tantek: yes.
>
>   shepazu: this also solves some issues for SVG.
>   ... this is an issue we need to look into.
>
>   smfr: it is not obvious that this needs to go into pointer-events.
>
>   shepazu: right.
>   ... Paul Bakaus for Zynga mentioned he would rather not maitain two
>   images.
>
>   smfr: I think the threshold for pointer-events is simple enough that
>   we could put it into pointer-events.
>   ... a separate image is more complex and should be separate.
>
>   heycam: with filters, we started to talk about pointer-events
>   issues. It would be nice if we could resolve all these problems with
>   a single solution.
>
>   <tantek> Hixie's notes
>   [48]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>   refer to full transparency as allowing events to pass through
>
>     [48] http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
>
>   tantek: currently, in Hixie's proposal, onlyt 100% translucent
>   pixels let the event go through.
>
>   We are talking about adding a threshold instead.
>
>   <tantek> so we're talking about increasing that threshold from
>   opacity:0 to opacity:x where 0‚§x‚§1
>
>   dino: sometimes, you want the hit testing area to be larger than the
>   element itself.
>
>   tab: sometimes, you want the letters to be selected to have a larger
>   selection area. It would be easier if there were hit testing
>   controls.
>
>   shepazu: Alex Danilo said this is too difficult to implement because
>   you might have to get the graphics back from the GPU.
>
>   szilles: so you may have to precompute things.
>
>   tantek: the mask solves that problem.
>
>   <heycam> vhardy: having a mask, isn't that equivalent to just having
>   the texture around?
>
>   <heycam> vhardy: if you're keeping some data for hit testing, that's
>   the same as keeping on the gpu and in memory
>
>   <heycam> smfr: i think it might be expensive at run time
>
>   <heycam> smfr: doable, but it may be slow
>
>   tantek: if you go back to Paul's usecase, he is keeping his own mask
>   in JS.
>   ... that means the shapes are their masks.
>
>   <shepazu> Alex's critique:
>   [49]http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html
>
>     [49] http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html
>
>   tantek: so they have implemented masks as a work around. We could
>   provide masks to resolve their issue.
>
>   <shepazu> Paul,'s email
>   [50]http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html
>
>     [50] http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html
>
>   heycam: the email does not hint at their implementation method.
>
>   shepazu: quoting the email..
>
>   heycam: it seems to be a good shorthand.
>
>   tantek: if doing things in canvas and JS works, then shouldn't it be
>   feasible in implementations?
>
>   tab/shepazu: the point Alex Danillo made is valid.
>
>   <ChrisL> there are some video codecs on gpu like for mpeg etc. those
>   might be usablefor jpeg decoding
>
>   <ChrisL> but in general the bandwidth of he back channel from gpu to
>   cpu is not very good
>
>   smfr: if you have filters that are implemented on the GPU, then you
>   need to do read-back from the GPU and that is expensive.
>
>   tab: box shadows do not impact hit testing.
>   ... round-borders affect hit testing.
>   ... border-image does not affect hit testing.
>
>   <ChrisL> bordser is a classic case for needing more values like
>   visibleBorder for hit testing
>
>   tab: I would be ok to say that things may slow down if you do hit
>   testing on a filtered image, for example.
>
>   discussion on various filter effects that may affect hit testing.
>
>   dino: we all realize that a threshold is not enough because we need
>   a mask image in many cases. Can it be integrated with the
>   pointer-events property.
>
>   tantek: we are talking about CSS UI 4 right?
>
>   several: yes.
>
>   shepazu: I think the threshold is enough for most cases.
>
>   smfr: the GPU efficiency is an issue to consider.
>
>   tantek: I would like to add this to CSS UI 4.
>
>   <dino> ACTION: Dean to draft a proposal for specifying hit testing
>   regions or masks for CSS 4 UI [recorded in
>   [51]http://www.w3.org/2011/07/26-fx-irc]
>
>     [51] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-38 - Draft a proposal for specifying hit
>   testing regions or masks for CSS 4 UI [on Dean Jackson - due
>   2011-08-02].
>
>   <scribe> ACTION: tantek to specify how opacity:0 impact hit testing.
>   recorded in [52]http://www.w3.org/2011/07/26-fx-irc]
>
>     [52] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - tantek
>
>   <bradk> opacity:0.001 should not be different from opacity:0 WRT hit
>   testing
>
>   <tantek> Issue 9: [53]http://wiki.csswg.org/spec/css3-ui#issue-9
>
>     [53] http://wiki.csswg.org/spec/css3-ui#issue-9
>
>   <smfr> bradk: opacity already has discontinuitues: 0.9999 creates
>   stacking context, 1 does not
>
>   <ChrisL> bradk, hit testing is like pregnancy. it is on/off not a
>   sliding scale
>
>   <scribe> ACTION: Doug to propose that opacity of a pixel does not
>   affect its pointer-event behavior for CSS 3 UI. [recorded in
>   [54]http://www.w3.org/2011/07/26-fx-irc]
>
>     [54] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-39 - Propose that opacity of a pixel does
>   not affect its pointer-event behavior for CSS 3 UI. [on Doug
>   Schepers - due 2011-08-02].
>
>   ACTION-39: [55]http://wiki.csswg.org/spec/css3-ui#issue-9
>
>     [55] http://wiki.csswg.org/spec/css3-ui#issue-9
>
>   <trackbot> ACTION-39 Propose that opacity of a pixel does not affect
>   its pointer-event behavior for CSS 3 UI. notes added
>
>   <shepazu> ACTION: shepazu to write up proposal for opacity threshold
>   for pointer-events for CSS 4 UI [recorded in
>   [56]http://www.w3.org/2011/07/26-fx-irc]
>
>     [56] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-40 - Write up proposal for opacity
>   threshold for pointer-events for CSS 4 UI [on Doug Schepers - due
>   2011-08-02].
>
>   tantek: [57]http://wiki.csswg.org/spec/css3-ui#issue-10
>   ... I think we are ducking this.
>
>     [57] http://wiki.csswg.org/spec/css3-ui#issue-10
>
>   ed: the issue was mostly for SVG.
>
>   (discussion on filter effects and masks applying to HTML in SVG,
>   through foreignObject)
>
>   heycam: we would need to say that the mask actually impact hit
>   testing.
>   ... and clip-path as well.
>
>   vhardy: this should go into the hit testing section.
>
>   <tantek> [58]https://developer.mozilla.org/en/CSS/clip-path
>
>     [58] https://developer.mozilla.org/en/CSS/clip-path
>
>   <tantek> [59]https://developer.mozilla.org/en/CSS/mask
>
>     [59] https://developer.mozilla.org/en/CSS/mask
>
>   <scribe> ACTION: Doug to propose wording for CSS 3 UI about how
>   masks and clip-paths impact hit-testing. [recorded in
>   [60]http://www.w3.org/2011/07/26-fx-irc]
>
>     [60] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-41 - Propose wording for CSS 3 UI about
>   how masks and clip-paths impact hit-testing. [on Doug Schepers - due
>   2011-08-02].
>
>   <tantek>
>   [61]https://developer.mozilla.org/en/CSS/-webkit-mask-box-image
>
>     [61] https://developer.mozilla.org/en/CSS/-webkit-mask-box-image
>
>   <shepazu>
>   [62]http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg
>   _ef.html
>
>     [62] http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
>
>   <birtles>
>   [63]https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_co
>   ntent
>
>     [63] https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_content
>
>   tantek: we need a definition of these properties in a CSS spec.
>
>   ed; we could put clipping and masking in the FXTF filter spec.
>
>   <ed>
>   [64]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters
>   .html
>
>     [64] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
>
>   <scribe> ACTION: ed to move clip-path and masks to the FX Filter
>   specification draft. [recorded in
>   [65]http://www.w3.org/2011/07/26-fx-irc]
>
>     [65] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-42 - Move clip-path and masks to the FX
>   Filter specification draft. [on Erik Dahlström - due 2011-08-02].
>
>   tantek: I have no more issue on CSS 3 UI that requires CSS/SVG
>   coordination. I have gone through the issues I had.
>
>   ed: Next topic: filter effects.
>
>   <dino>
>   [66]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/F
>   ilterEffects
>
>     [66] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
>
>   dino: we have a lot of issues.
>   ... first issue is to come up with a name other than SVG filters.
>   ... there are pure css filters and then markup filters.
>
> filter effects
>
>   chris: advanced filers? markup filters?
>
>   dino: the whole spec. is CSS, there is a part that uses markup for
>   advanced filters.
>
>   (discussion on 'advanced filters' v.s. 'markup filters')
>
>   shepazu: I think markup filters is better
>
>   smfr: declarative filters?
>
>   <ChrisL> the filters previously known as SVG
>
>   <ChrisL> custom filters
>
>   dino: shorthand syntax and long-hand syntax?
>
>   tantek: is this a CSS module?
>
>   <ChrisL> its a jointly developed module
>
>   dino: not currently. But it should be?
>   ... it should just be "Filters"
>
>   tantek: I think we should call them 'CSS 3 Filters'
>
>   fantasai: "CSS Filters"
>
>   <ChrisL> can we please drop the 'levels' stuff
>
>   shepazu: the spec. defines markup for filters.
>
>   fantasai: we should call them "W3C filters"
>
>   chrisL: agreed.
>
>   <Ms2ger> HTML5 Filters?
>
>   shepazu: markup filters is the most descriptive.
>
>   <fantasai> XFilters :)
>
>   <ChrisL> people are gradually being used to pointing to other media
>   from css. images, svg, etc
>
>   dino: the options we have heard:
>   ... element based filters
>   ... shorhand/longhand filters
>   ... markup filters
>   ... XML Filters
>
>   <ChrisL> w3c filters
>
>   dino: W3C Filters
>   ... XFilters
>
>   <ChrisL> shorthand has an existing meaning in css,be careful to
>   avoid confusion there
>
>   <ChrisL> extesible filters
>
>   <ChrisL> custom filters
>
>   <ed> canned filters
>
>   <scribe> ACTION: Dino to make a naming proposal to distinguish
>   between CSS and markup filters. [recorded in
>   [67]http://www.w3.org/2011/07/26-fx-irc]
>
>     [67] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - Dino
>
>   <scribe> ACTION: dean to make a naming proposal to distinguish
>   between CSS and markup filters. [recorded in
>   [68]http://www.w3.org/2011/07/26-fx-irc]
>
>     [68] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-43 - Make a naming proposal to distinguish
>   between CSS and markup filters. [on Dean Jackson - due 2011-08-02].
>
>   <tantek> ACTION: RRSAgent - learn how to reference people by URL not
>   just alias. recorded in [69]http://www.w3.org/2011/07/26-fx-irc]
>
>     [69] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - RRSAgent
>
>   <ChrisL> I actually asked on sysreq about adding people to fx
>   tracker , but no response
>
>   <tantek> ACTION: trackbot - learn how to reference people by URL not
>   just alias. recorded in [70]http://www.w3.org/2011/07/26-fx-irc]
>
>     [70] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - trackbot
>
>   dino: next issue is to have a custom filter using a particular
>   language.
>
>   <smfr>
>   [71]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.ht
>   ml
>
>     [71] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
>
>   <ed>
>   [72]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters
>   .html#feCustomElement
>
>     [72] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#feCustomElement
>
>   patrickdengler: there are lots of issues with custom filters
>   (security). In IE, we did not see any use of the custom filters we
>   provided.
>
>   dino: what are the pros and cons?
>   ... cons: security, not used often.
>   ... Adobe has a public repository of pixel bender filters and there
>   are 20+ filters there.
>   ... pros: it is great for us as spec. developers because we do not
>   have to define every effect.
>   ... cons: we need to define a filter.
>
>   <tantek> ed - is there a URL for today's agenda? I added the CSS3-UI
>   coordination to here:
>   [73]http://wiki.csswg.org/planning/seattle-2011#tuesday but don't
>   see any other items (nor links to agendas in other locations)
>
>     [73] http://wiki.csswg.org/planning/seattle-2011#tuesday
>
>   dino: sometimes, people also want to protect their shader code.
>
>   <ed> patrick: inkscape has hundreds of defined filter effects that
>   only use the existing svg filter functionality
>
>   <tantek> ed - nm. thanks to smfr for
>   [74]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
>
>     [74] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
>
>   <ChrisL> orcuda
>
>   dino: on the language approach, if we accept WebGL, there is a
>   shading language specified there. GLSL is not always the right
>   solution. HLSL is not either. Sometimes, solutions like pixel bender
>   or Core Image filters are better. I think Silverlight has something
>   similar to HLSL.
>   ... seems like there is a lot of cons.
>
>   <smfr> ChrisL: or CUDA?
>
>   vhardy: i think there are very nice effects that would could have
>   with custom fitlers. We can come back later with more arguments.
>
>   chrisl: if there was a DOM interface for custom filters, that may be
>   easier.
>
>   dino: one use case where Apple uses a custom filter is for video
>   output to TV, or custom color correction.
>
>   heycam: if we had custom filters, what if you do not have hardware
>   accel.
>
>   vhardy: then there is a sw path.
>
>   <scribe> ACTION: vhardy to come back with more arguments on custom
>   filters and make a proposal. [recorded in
>   [75]http://www.w3.org/2011/07/26-fx-irc]
>
>     [75] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - vhardy
>
>   <heycam> trackbot, status?
>
>   <scribe> ACTION: vincent to come back with more arguments on custom
>   filters and make a proposal. [recorded in
>   [76]http://www.w3.org/2011/07/26-fx-irc]
>
>     [76] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - vincent
>
>   dino: next is pointer-events on filter regions.
>
>   <ed>
>   [77]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.ht
>   ml
>
>     [77] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
>
>   ed: we found that having filters impact hit testing is costly.
>
>   smfr: and there are cases like blur where the hit becomes an area.
>
>   dino: is that like shadows? Or should we deal with it with masking
>   as well?
>
>   <heycam> vhardy: in svg if oyu have text on a path, with hit testing
>   and text selection, that kind of "distortion" works
>
>   <heycam> vhardy: it doesn't if you go through a filter pipeline,
>   pixels gets shifted around
>
>   <heycam> ... you're still operating on the original geometry you had
>
>   <heycam> dino: you want 2 things. one is controlling whether hit
>   testing happens on the output, and possibly something about whether
>   you should map back to the input pixel from the output pixel
>
>   <heycam> fantasai: how would you determine that for a blur?
>
>   <heycam> dino: there are multiple pixels
>
>   <heycam> vhardy: it's not a 1-to-1 mapping
>
>   <heycam> ChrisL: if you have a filter that displaces things, or if
>   the visual result is quite different from the original, ...
>
>   <heycam> fantasai: why not use transforms for shifting content?
>
>   <heycam> vhardy: with filters you could use your source multiple
>   times
>
>   <heycam> dino: I think there's a difference between hit testing,
>   have I clicked on this element, and text selection, which is where
>   you need to select a character
>
>   <heycam> dino: the text might be in a different spot
>
>   <heycam> vhardy: if you use SourceGraphic and feOffset, you could
>   have a rectangle and make it a grid of four rectangles
>
>   <heycam> ... and that's the visual rendering
>
>   <heycam> ... in that case, it would be most natural to say if you
>   click anything in there it hits positive
>
>   <heycam> fantasai: if you want to multiply images, then that 's
>   different from just mirroring
>
>   <heycam> ... nobody expects to click on a reflection of an icon and
>   have that hit test
>
>   <ChrisL> trackbot, status
>
>   <heycam> ... if you want something that's actually solid, there
>   should be some other way of doing it that affects layout
>
>   <heycam> shepazu: you should use a mask in this case
>
>   <heycam> ... nobody's asked for this either
>
>   <heycam> fantasai: I think we haven't seen convincing use cases
>
>   <ChrisL> trackbot, init
>
>   <heycam> dino: if we have the mask image proposal, you would point
>   to the filter image as the mask
>
>   <heycam> vhardy: I think that covers most of what we need
>
>   <heycam> ... but I think still conceptually this is an important
>   issue
>
>   <heycam> ed: raise an issue for this?
>
>   <ChrisL> trackbot, status
>
>   dino: next one is enable-background.
>
>   <ChrisL> tracker, init
>
>   <ChrisL> trackbot, status
>
>   dino: there is a general proposal to deprecate it.
>
>   <ChrisL> trackbot, reload
>
>   proposal at:
>   [78]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/F
>   ilterEffects
>
>     [78] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
>
>   <ed> I raised ISSUE-5 for the hit-testing
>
>   <ChrisL> tracker, init
>
>   <ed> [79]http://www.w3.org/Graphics/fx/track/issues/5
>
>     [79] http://www.w3.org/Graphics/fx/track/issues/5
>
>   <ChrisL> tracker, init
>
>   <Ms2ger> trackbot, init
>
>   <ChrisL> trackbot, status
>
>   cabanier: enable-background is defined for SVG and not for HTML. We
>   need to define what that does for CSS/HTML.
>
>   <ChrisL> adobe used to implement it
>
>   dino: who implements enable-background.
>
>   <ChrisL> but it seems under-implemented in current svg
>   implementations
>
>   Opera, Batik, Illustrator, Inkscape?
>
>   <ChrisL> it would be good if adobe illustrator stopped writing it
>   needlessly on svg exports
>
>   ed: lunch break.
>
>   <dbaron> lunch-break-after: always
>
>   <ChrisL> trackbot, status
>
>   <ChrisL> yay
>
>   <dbaron> ScribeNick: nimbupani
>
>   <dbaron> ScribeNick: nimbu
>
>   ed: we can do svg composting first and continue with filters
>
>   <ed> [80]http://www.w3.org/TR/SVGCompositing/
>
>     [80] http://www.w3.org/TR/SVGCompositing/
>
>   cabanier: there is a need for adobe to specify the blending into the
>   css.
>   ... it can be done through filters and not easy as specifying
>   keywords. should we adopt what svg is doing in css or having a more
>   limited versin
>   ... the enable-backgrounds is necessary for compositing.
>
>   heycam: are we asking first if people are in favour of compositing
>   for css at all?
>
>   cabanier: there was a discussing in mailing list where people did
>   not see the point of it. smfr
>   ... since we need it for filters anyway maybe its not a big deal
>
>   smfr: webkit has a webkit property which lets you set compositing
>   mode for an image
>
>   heycam: can u do all compositing modes with existing svg filter
>   primitives
>
>   cabanier: i believe you can.
>   ... difficult as u need to do compositing urself.
>
>   vhardy: svg compositing spec is more complete.
>   ... if we are going to go about defining how things should render it
>   would be a general issue. it would be applicable to anything you
>   render. Do ywe want to do smthing that works for css in general?
>
>   heycam: if you have already implemented for svg it wont be much work
>   to extend it
>
>   cabanier: do u mean spec or implementation?
>
>   heycam: implementation
>
>   dbaron: how good is enable background is for authors to understand
>   whats going on
>   ... whats the deal with x, y params in that?
>
>   cabanier: those will go away. it is more confusing
>
>   dbaron: with filters, the defaults meant things were meant to be
>   clipped out.
>
>   smfr: enable-bg is like opacity.
>
>   cabanier: enable bg just generates stacking context.
>   ... the 1st elm with enable bg new will create a new stacking
>   context, the first descendant that has a blend mode will create a
>   second one and those two will be put together
>   ... i agree the keyword is pretty confusing
>
>   TabAtkins: i only understand it coz i have looked at it enough times
>   ... the svg compositing def
>
>   szilles is your point editorial improvements will be appreciated
>   dbaron
>
>   dbaron: in compositing it sez new buffers are established for both
>   of them. which seems wrong
>
>   cabanier: that confusion comes from Porter-Duff ‚¶
>   ... lets stick with regular blending modes
>
>   dbaron: i am not sure i follow but i dont know if it's worth
>   explaining to me
>
>   ed: do we want to have this for css or html?
>
>   vhardy: in the rendering model perspective, i dont see any harm done
>   by making this generic
>
>   anne: shouldnt all these things be generic
>
>   cabanier: maybe we can get a better name if we put this in css
>
>   anne: has anyone looked at how similar it is to canvas composite
>   feature
>
>   cabanier: canvas has porter-duff this is slightly different
>   ... we had a discussion on splitting it into porter-duff & blending
>   modes. porter-duff is hard to specify.
>
>   heycam: blend modes dont need u to keep it off on a separate buffer
>   like enable bg?
>
>   cabanier: they do.
>
>   <ChrisL> why is porter-duff hard to specify?
>
>   heycam: what ist he complexity for porter-duff
>
>   anne: why is it "easy" for canvas but not for svg?
>
>   vhardy: in svg or html u have multiple nodes and u need to define
>   which to accumulate and what level.
>
>   anne: and i guess u have to constantly run it if you change the
>   underlying mode
>
>   cabanier: canvas does not know about stacking context.
>
>   vhardy: its also one drawing operation at a time
>   ... in tree model you can have whole trees or groups.
>
>   cabanier: thats what enable bg does
>
>   dbaron: is porter-duff trying to do smthing in cases other than
>   where u have stacking context?
>
>   <smfr> url?
>
>   dbaron: there are elements that are outside subtree and interleave
>   with htem
>
>   <ChrisL> dbaron,svg tries to avoid that interleave so we don't use
>   the stacking conext
>
>   shepazu: i dont understand what you mean by interleaving
>
>   <ChrisL> shepazu, interleaved in z-order. in other words, not the
>   painters algorithm used in svg
>
>   dbaron: if there is A in subtree, B is outside, C is in subtree. and
>   if B is on top of A and C. a sub tree is not a single atomic thing
>   ... css does not even define things in terms of drawing operations
>
>   heycam: isnt there an appendix that sez paint the bg paint the
>   border?
>
>   <ChrisL> css defines the order of drawing border, background, and
>   text
>
>   dbaron: i am not sure if it was going to be interpreted that way.
>
>   cabanier: u create two buffers the top one with dest atop(?)
>
>   dbaron: in css that sort of thing only makes sense in stacking
>   context
>
>   cabanier: enable background adds another stacking context.
>
>   dbaron: if the stuff in here needs to apply to css it needs to say
>   more about stacking contexts
>   ... the comp-op property has initial value that sorts over.
>
>   <heycam> s/desta top(?)/dest-atop/
>
>   <dino> is this the latest spec?
>   [81]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
>   html
>
>     [81] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
>
>   <anne> [82]http://www.w3.org/TR/SVGCompositing/
>
>     [82] http://www.w3.org/TR/SVGCompositing/
>
>   <anne> oh
>
>   ChrisL: u would still need stacking context in css and html. there
>   is opacity or smthing that generates new stacking context
>
>   vhardy: are u saying comp-op wont trigger new stacking context?
>
>   <ed> dino: yes, that's the editor's draft version,
>   [83]http://dev.w3.org/SVG/modules/compositing/publish/SVGCompositing
>   .html
>
>     [83] http://dev.w3.org/SVG/modules/compositing/publish/SVGCompositing.html
>
>   ChrisL: it wont, even if it did the initial value would be smthing
>   different.
>
>   vhardy: should we make this work for html, css?
>
>   <anne> ed, that's a 404
>
>   <ed> [84]http://dev.w3.org/SVG/modules/compositing/publish/
>
>     [84] http://dev.w3.org/SVG/modules/compositing/publish/
>
>   <ed> that one works
>
>   cabanier: thebig drawback was we didnt want to blend two images
>   together, but if we are doing with filters anyway the drawback goes
>   away.
>
>   <anne> ed, should update that to say editor's draft...
>
>   ChrisL: it would be helpful if we have one for each host language,
>   and say more clearly what happens.
>
>   <scribe> ACTION: cabanier produce a new draft of compositing which
>   should probably called CSS Compositing with appendices on how
>   compositing works in css, html box model and svg model. [recorded in
>   [85]http://www.w3.org/2011/07/26-fx-irc]
>
>     [85] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Sorry, couldn't find user - cabanier
>
>   shepazu: add cabanier to this list :P
>
>   dino: so u dont want to remove enable background.
>
>   cabanier: no only the x, y.
>
>   <ChrisL> trackbot, status
>
>   <dbaron> [86]https://www.w3.org/2005/06/tracker/users/my
>
>     [86] https://www.w3.org/2005/06/tracker/users/my
>
>   ChrisL: pls add cabanier too :P
>
>   <scribe> ACTION: vhardy produce a new draft of compositing which
>   should probably called CSS Compositing with appendices on how
>   compositing works in css, html box model and svg model. [recorded in
>   [87]http://www.w3.org/2011/07/26-fx-irc]
>
>     [87] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-44 - Produce a new draft of compositing
>   which should probably called CSS Compositing with appendices on how
>   compositing works in css, html box model and svg model. [on Vincent
>   Hardy - due 2011-08-02].
>
>   dino: proposal from tab for a new image generator
>
> filter effects (continued)
>
>   dino: any image generator, stream of filter property
>   ... does anyone disagree?
>   ... TabAtkins and i agree its a good idea
>
>   dbaron: is this an extension to image vals
>
>   TabAtkins: will just be in there but will be a new image type
>
>   ChrisL: we need to find a separate way to bring it in.
>
>   dino: this is the separate way. if u want to just filter the border.
>
>   smfr: if u use border-image you will get sharp edges
>   ... Chris suggests we get blur after we slice and stretch
>
>   TabAtkins: @ santaclara tpac brad was talking about pulling sections
>   of elements instead of entire element as filter input.
>
>   dbaron: i think we need new filter input primitives for css stuff
>
>   <ChrisL> you need both. one to filter random images and one to
>   filter the border stuff (which may have been made from images or may
>   not)
>
>   smfr: the border-image should be solved this other way.
>
>   dino: other places can use this.
>
>   dbaron: i can see using multi bg and wanting to filter one of em
>
>   <scribe> ACTION: dino update the filter spec to produce the new
>   image type. recorded in [88]http://www.w3.org/2011/07/26-fx-irc]
>
>     [88] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-45 - Update the filter spec to produce the
>   new image type. [on Dean Jackson - due 2011-08-02].
>
>   <bradk> fitering borders should also filter border-images (since
>   border-images are substitutes for borders)
>
>   dino: the next topic there is a dropshadow effect. if there is smway
>   to do it at a higher level than within a filter
>
>   cabanier: svg images is an example, so u want shadow around the
>   shapes. it seems an overkill to apply filters to that
>
>   patrickdengler: does it not apply to blur and all that stuff. there
>   would be a cross over.
>
>   heycam: we do want it for svg content
>   ... if there was some short hand work in svg and not in css‚¶
>
>   dino: webkit has an extension -webkit-svg-shadow that will apply the
>   shadow to the svg content
>   ... the reason this was added was canvas has it
>   ... the req was basically to draw a shape and give it a shadow.
>
>   ChrisL: is the req to be a simple syntax?
>
>   dino: whats the req for current one
>
>   ChrisL: u have to do a lot of work to produce it.
>
>   dino: another q to ask is, you can assume shadow is a popular thing,
>   now if we add filters would they expect filters to apply to shadow?
>
>   ChrisL: if u want to apply two filters on svg, you need to put
>   second filter on group.
>
>   pdengler: i was thinking in terms of text-shadow, box-shadow,
>   drop-shadow
>   ... i think css authors dont think of them as filters
>   ... there are categories of effects that have nothing to do with
>   filters.
>
>   smfr: the issue is the order of ops
>
>   pdengler: it goes with input types.
>
>   smfr: if we have filter and box-shadow which do u do first
>
>   dino: people consider shadow as part of object drawn
>   ... if you set opacity of text to 0 would you expect shadow to fade
>   as well.
>
>   smfr: i think we still render the shadow.
>
>   dino: the shadow is really part of the object
>
>   smfr: transforms and shadow.
>   ... does the shadow move around, or stay same
>   ... it depends on scenarios
>
>   plinss: if i rotate smthing the shadow should stay and rotate.
>
>   <tantek> ed: I'd like to spend 5 minutes discussing
>   "color-correction" as mentioned/discussed here
>   [89]http://www.w3.org/2009/11/03-CSS-minutes.html (I don't think
>   it's been discussed since) - I think this is the right set of people
>   to discuss it.
>
>     [89] http://www.w3.org/2009/11/03-CSS-minutes.html
>
>   <ChrisL> tha is why we added the 'ref' transform for svg so yo can
>   use the local coordinate system of a higher element
>
>   Bradk: the shadow should be the last thing that comes after it is
>   transformed
>
>   <bradk> :)
>
>   dino: should we expose short hand for it?
>
>   <scribe> ACTION: dino add shorthand property for shadow. [recorded
>   in [90]http://www.w3.org/2011/07/26-fx-irc]
>
>     [90] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-46 - Add shorthand property for shadow.
>   [on Dean Jackson - due 2011-08-02].
>
>   <tantek> ed: I have to depart by 4pm.
>
>   dino: adding dropshadow keyword would become a long f()
>
>   <bradk> I imagine an objectg rotating, but still acting as if the
>   light source is from the same direction. But scaling the object
>   should scale the shadow.
>
>   dbaron: is it a property or fn
>
>   <smfr> like filter: dropshadow(10px, 10px, 20px, blue)
>
>   <bradk> not sure if the ofset should scale.
>
>   dbaron: what mechanism is it coming from, when the author is not
>   specifying the order
>   ... when author lists in order then no problme
>
>   smfr: issue when interacting with other css properties.
>
>   dbaron: i see box-shadow as part of border drawing stuff. and it
>   would happen before filters.
>
>   dino: that was my point
>   ... not an effect like blur or warp
>
>   bradk: can box-shadow be simulated with css?
>   ... can box-shaow be simulated with filters?
>
>   smfr: u could, but you have to generate mask the rounded border box
>   which the shadow is applied to
>
>   dino: u can do with markup filters by filter chain that floods black
>   region, offsets it, composits
>
>   <ChrisL> yes i assumed the question related to doing it with markup
>   filters
>
>   dino: not in short hand
>   ... proposal for a wave effect
>   ... ms has implemented
>   ... ed commented it might be interesting.
>
>   <bradk> I've never personally had any need for a wave effect.
>
>   <tantek> how about a new wave effect?
>
>   dino: it seems like there is not much support
>   ... discussion about custom element to add any effect
>   ... some implementations have effects to add that are useful
>
>   <ChrisL> as i mentioned earlier, a dom interface allws room for
>   experimentation
>
>   dino: some way it could be done as an extension and not how to
>   prefix a fn name
>   ... the webGl community all agreed on same prefix
>   ... u get interoperability between browsers but no guarantee it
>   would work forever
>   ... some effects that might be common the implementations would
>   agree enough, it could possibly done in that manner
>
>   heycam: we would need a reasonably complete desc of what that filter
>   would be.
>
>   dino: it is worthwhile getting feature pushed thro trackers as
>   quickly as possible
>   ... there are some effects tht would be useful to authors. there
>   cant be much debate on how it can be implemented. e.g motion blue
>   ... how should they do it? prefix fn names or if its standard
>   enough, send proposal, wait for agreement and use an experimental
>   prefix
>
>   heycam: prefixing sounds like a good idea
>
>   smfr: we have prefixed fn names for gradients so its not new
>
>   dino: idea of shared prefx name has not been proposed before
>   ... it seems to work pretty well in webGL community
>
>   szilles classic problem webkit community have webkit prefix
>
>   szilles getting agreement doing the same thing or it breaks
>
>   szilles: if it breaks come up with the new prefix.
>   ... that was concern in csswg seemed safer for each implementation
>   to have own prefix so it tried to be consistent to itself
>
>   dino: its not like its a big issue anyway. if and when people want
>   to use these new effects we will see what happens
>
>   cabanier: it would be nice to have one prefix.
>
>   heycam: its diff from property names
>
>   dino: i guess u can still.
>
>   smfr: people do that with bg image
>
>   heycam: its an invalid value.
>
>   dino: filter property in css om
>
>   ed: thats come up before whether or not if it should be exposed to
>   cssom
>
>   anne: exposed or rename attr on interface to css filter
>   ... i dont think there is a middle ground
>   ... ecmascript guys hate the document.all as it is hidden
>   ... that is the pattern we dont want to follow
>   ... i dont know why we didnt go with that.
>   ... it is for attr exposed on css style decl
>   ... and style decl values
>
>   smfr: is it coz ie claimed filter
>
>   anne: yes
>
>   dbaron: we have been shipping element.style.filter
>
>   ed: also opera
>   ... its not a big problem
>   ... not many sites are broken
>
>   dino: we should also ask ms
>
>   pdengler: we see this coming anyway. i dont know what our avenues
>   are to change.
>   ... i think we have some mitigations
>
>   heycam: u can still support if the syntax is right
>
>   pdengler: we are okay on this one if you want to keep style.filter
>   ... sylvaing?
>
>   ed: see if we can publish smthing so people know where we are
>
>   dino: we are happy to publish it
>
>   ChrisL: there are sm people who are not rep here.
>
>   dbaron: this is pretty much a full css meeting hre.
>
>   <dbaron> We've been shipping element.style.filter since Firefox 4...
>   so not all that long, but we have shipped it.
>
>   RESOLUTION: publish the FXTF Filter Effects draft as soon as the
>   edits discussed in this meeting are done.
>
>   <scribe> ACTION: ChrisL to check whether or not filters spec sounds
>   as a new draft or not [recorded in
>   [91]http://www.w3.org/2011/07/26-fx-irc]
>
>     [91] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-47 - Check whether or not filters spec
>   counts as a new draft or not [on Chris Lilley - due 2011-08-02].
>
>   dino: moving to css / svg animations.
>
>   ed: we have half an hour before break.
>
> CSS / SVG animations
>
>   <birtles>
>   [92]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/A
>   nimations/Harmonisation
>
>     [92] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Animations/Harmonisation
>
>   birtles: seems like there are diff ideas on where we are heading.
>   ... check if we are on same page where we want to end up with
>   animations in the long run
>   ... see how feasible it is to merge them
>
>   <tantek> [93]http://www.downforeveryoneorjustme.com/w3.org
>
>     [93] http://www.downforeveryoneorjustme.com/w3.org
>
>   <tantek> [94]http://www.downforeveryoneorjustme.com/web5.w3.org
>
>     [94] http://www.downforeveryoneorjustme.com/web5.w3.org
>
>   <birtles> [95]http://dl.dropbox.com/u/11894343/Harmonisation.htm
>
>     [95] http://dl.dropbox.com/u/11894343/Harmonisation.htm
>
>   birtles: the target of animation is diff svg is 1 attr on an elm,
>   css is more flex
>   ... its smthing we need to fix in svg
>   ... bigger diff is the values, in svg you can have independent anims
>   targetting one attr and control how they combine together. and have
>   anims build on themselves
>   ... more significant diff its been proposed to css anims be added to
>   underlying styles. i dont think there is anything to add anims
>   together.
>
>   smfr: we would like to be able to do
>
>   <ChrisL> its a common use case to apply multiple animations
>
>   smfr: we ahve talked about adding it to css for a while
>
>   vhardy: having same sandwich model as SMIL would help.
>
>   <ChrisL> yes, i think its needed and the sandwich model works well
>
>   birtles: one complication is there are rules, and its a grey area
>   ... animation types how to do interpolation.
>   ... interval timing is quite diff
>
>   <ChrisL> lets get rid of wallclock, please
>
>   birtles: css does not have complexity of svg
>   ... SMIL has all sorts of rules which is a big area of difference.
>   which might be difficult to merge and be impossible to merge.
>   ... multiple intervals, and syncbase
>
>   ChrisL: do we find that syncbase stuff is getting used well?
>
>   birtles: my guess is it is. i have already proposed that we drop it
>   and introduce timing groups instead which gives 80% of fn with
>   fraction of complexity
>   ... i am concerned people are using it
>
>   vhardy: what do you mean by you dont want syncbase?
>
>   birtles: SMIL has 2 diff features for kicking off anims
>   ... when an animation ends/starts, when I get an event
>   ... basically maintain network of times and work out how to break
>   that network
>   ... u can hv -ve offsets
>   ... event based is easier
>
>   shepazu: to implement?
>
>   birtles: yes for authors syncbase is better it is more predictable.
>
>   ed: in most cases u dont want two sync anims to start slightly off,
>   want it to start at same time
>
>   heycam: u can fudge it.
>
>   birtles: SMIL sez put event timestamp and use that.
>
>   vhardy: syncbase can give u a way to get perfect sync
>
>   birtles: time containers can give u that for most of use cases.
>
>   dino: whats an e.g of time container?
>
>   vhardy: difficulty is in spec hard to wrap head around, impl. is not
>   that much code.
>   ... once u know what to do, its not that bad.
>
>   birtles: i have test cases which werent working on other browsers.
>   cyclic dependencies SMIL has rules to break them but not impl.
>   consistently.
>
>   vhardy: it takes a couple of iterations to get right
>
>   heycam: it is complex to understand as well.
>
>   <birtles>
>   [96]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
>   on_improvements#Wanted_feature:_re-use_animations
>
>     [96] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_re-use_animations
>
>   birtles: svg lacks some things for timing fns
>   ... has timing mode mostly for motion on a path.
>   ... svg does not hve reversing, smthing we should add.
>
>   <ChrisL> adding reversing would be very helpful
>
>   birtles: its not too different.
>   ... its unfortunate the names are diff between css anims and svg.
>   ... css takes a snapshot, svg everything is live
>
>   shepazu: i dont understand what you mean
>
>   <ChrisL> you mean for the actual animation atributes themselves via
>   dom, right
>
>   dino: if you change duration, transition during animation it does
>   not change the animation itself
>   ... SMIL allows you to manipulate prop of animations while you
>   animate.
>
>   birtles: if you do try to merge these two, this needs to be
>   resolved.
>   ... svg makes everything declarative. css assumes you can use script
>   to cancel anims
>   ... we want to maintain decl. approach in svg
>
>   vhardy: it is not obv what timing model is for css animations.
>
>   birtles: svg has a notion of outermost element is a time container.
>
>   <ChrisL> in svgt 1.2 we made all svg elements be time containers,
>   also the media elements. that wasa a request from the accessibility
>   folks
>
>   <bradk> speak up!
>
>   birtles: do u want to be able to schedule multiple intervals.
>   ... i suppose if we add time containers anyway we dont need to do
>   that.
>
>   smfr: time 0 is where load event fired?
>   ... you might want to start animations when page is loading.
>
>   ed: in tiny 1.2 there is timelineBegin=onStart which solves that
>   problem
>
>   pdengler: there is more usage of css than svg
>   ... SMIL is more sophisticated and complex and causes problems in
>   syntax and merging
>   ... given css syntax is being more quickly adopted by webdevs,
>   shouldnt that be‚¶
>   ... anecdotal, i have seen more css anims than svg. the css syntax
>   is better absorbed. coz there is complexity merging seems scary to
>   me
>
>   birtles: thats exact q i wanted to talk about
>
>   pdengler: i think css anims is picking up.
>
>   <ChrisL> questio for pat, if we end up still with two separate specs
>   will IEnext implement only the css one?
>
>   birtles: have listed 3 possibilities. 1. drop svg anims and use css
>   2. merge them 3. try to align and play together but comprable enough
>   so web devs can switch if they need to.
>   ... #2 seems difficult, and I am nots o sure its impossible.
>   ... looking at 1 and 3. if we were to drop svg animations, we would
>   need to add some features to achieve feature-parity.
>
>   anne: are the missing features in wide use?
>
>   florian: probably got a bunch of uis written in svg
>
>   anne: at some point it will die out
>
>   <anne> I so support Microsoft for once
>
>   shepazu: we all agree we want one model
>
>   vhardy: i agree with what ChrisL is saying. i dont have strong
>   feelings for syntax. anims is like text so as you get deeper you
>   realise how complex it is.
>   ... i would focus on what features we need. timing model. recommend
>   we use SMIL as resource
>   ... i am okay with a new syntax.
>
>   pdengler: i dont disagree with we need feature parity.
>
>   shepazu: i prefer the element syntax to css syntax, but i dont
>   remember my rationale.
>
>   <anne> (With saying no to SVG Animation / SMIL)
>
>   heycam: the syntax is the sticking point here.
>
>   <ChrisL> doug is saying the stae chart stuff is one example where an
>   element based syntax helps
>
>   dino: is there a way to get to option 2 by changing the way SMIL
>   currently is.
>
>   smfr: when we talk about css animations we need css anims plus js.
>   ... we cant put all of svg into decl. css
>
>   dino: hope to come up with api that can be shared
>   ... can we map that api to SMIL
>
>   vhardy: u need a decl way of animations.
>
>   shepazu: wiling to see how far we can go with css syntax
>   ... just dont develop it further
>
>   smfr: here is an issue that is specific to css: css applies
>   properties at style resol. time and we dont define when style resol.
>   is. the timing thing is ill-defined.
>
>   vhardy: we tried to work on exporting timings to animations, it is
>   hacky stuff.
>
>   <ChrisL> so we could end up paiting ourselves into a corner that
>   can't for example animate things before the document completely
>   loaded
>
>   pdengler: css animations does not have the right stuff, then how is
>   smil going to apply to html.
>
>   <bradk> break time?
>
>   <bradk> afternoon snacks must have arrived
>
>   <bradk> :)
>
>   <ed> break 15min yes
>
>   ed: should we go thro the options, do we have strong objections to
>   #1?
>
>   birtles: i am uncomfortable pushing all complexity to css
>   ... okay dropping SMIL
>
>   anne: why do u want angle bracket syntax
>
>   birtles: u can already manipulate angle bracket stuff easily. it
>   would be out of place to chuck in a style block to animate while
>   everything else is in XML
>   ... it can get complicated
>
>   dino: if u think about a complex animations, you may have to put an
>   id on every element and might have overhead on performance.
>
>   tantek: would be great to see illustrative e.g.
>
>   birtles: if its xml you can already manipulate elm with DOM API. if
>   its new css u would need to invent a new DOM API
>
>   anne: with xml u only get string manipulation by default which is
>   not really right.
>
>   birtles: how to change this attr, all apis already exist for that.
>
>   ed: if we decide to drop svg animations, then css should cover svg
>   use cases and i am not sure that problem is small either.
>
>   heycam: it seems odd to me to have CSS anims affecting dom attr and
>   not property values
>
>   dino: i am not comfortable having css anims affect dom
>
>   anne: what u mean by dom attr
>
>   heycam: like x, y, attr on rect
>   ... its not a big deal in html as u dont animate things that are not
>   properties.
>   ... many geometry things are attr and not properties
>   ... i had a proposal to make attr properties, but it did not get
>   traction.
>
>   <birtles>
>   [97]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
>   S_Animation#Promoting_attributes_to_properties
>
>     [97] http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Promoting_attributes_to_properties
>
>   dino: pollution of property, potential clashes, were arguments
>   against
>
>   heycam: if we used shape-left instead of x, would lose the fact that
>   attr and property would have same name.
>
>   <dholbert> (side point: <animateMotion path="whatever"> is pretty
>   useful & isn't easy to convert to CSS, even with attr-property
>   mappings) (as I think birtles mentions in his document)
>
>   vhardy: we stopped short of that we did not bring it to csswg.
>
>   heycam: i thought TabAtkins mailed www-style with diff options
>
>   <dino> dholbert, he does mention it
>
>   TabAtkins: i dont recall getting much of a response.
>
>   <dbaron> Why not 'left' <=> @x, etc.
>
>   vhardy: we should have prioritized list of req of what we need to
>   put in.
>   ... set of animation feature sets that can work on svg, css, html
>
>   <heycam> dbaron, there are a few properties that map ok like that,
>   not all
>
>   vhardy: and then see if we can push css animations to that or not.
>
>   <heycam> dbaron, also suffers from the fact that it's a different
>   name
>
>   <scribe> ACTION: dino to write up use-cases and priority list of
>   features to be added to css animations [recorded in
>   [98]http://www.w3.org/2011/07/26-fx-irc]
>
>     [98] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-48 - Write up use-cases and priority list
>   of features to be added to css animations [on Dean Jackson - due
>   2011-08-02].
>
>   dino: we can make a wikipage
>
>   <tantek> "color-correction" as mentioned/discussed here
>   [99]http://www.w3.org/2009/11/03-CSS-minutes.html (I don't think
>   it's been discussed since)
>
>     [99] http://www.w3.org/2009/11/03-CSS-minutes.html
>
> color correction
>
>   <dbaron> [100]http://dev.w3.org/csswg/css-color-correction/
>
>    [100] http://dev.w3.org/csswg/css-color-correction/
>
>   tantek: has there been any update on this front?
>
>   ChrisL: one of the versions of mac os x changed from gamma of 1.8 to
>   1.2 it means throwing stuff at the screen on current macs should be
>   same as current PCs.
>   ... it used to be that macs had diff gamma correction.
>
>   smfr: its not just about gamma correction but finding ways to
>   authors to map css colors to images
>
>   ChrisL: the way we can do that, is to treat untagged images as sRGB
>
>   dbaron: is there any browser where untagged images and css colors
>   mismatch?
>   ... there are bunch of browsers that do good color matches for
>   tagged images, but dont for untagged and we want authors to optin to
>   color correction
>
>   <krijnh> (Should I publicly log this channel as well?)
>
>   smfr: webkit has a property for color correction.
>
>   <krijnh> anne: ^^
>
>   dbaron: i did put the stuff we discussed in a draft on dev.w3.org
>   didnt do anything in that draft.
>   ... it needs more work
>
>   <ChrisL> this is already logged btw
>
>   <scribe> ACTION: smfr to look at dbaron's draft and see if it
>   matches what they have implemented and determine if its an issue or
>   not. recorded in [101]http://www.w3.org/2011/07/26-fx-irc]
>
>    [101] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-49 - Look at dbaron's draft and see if it
>   matches what they have implemented and determine if its an issue or
>   not. [on Simon Fraser - due 2011-08-02].
>
>   <ChrisL> it would be good to knw if those pages are safari specific
>
>   <smfr> ok
>
>   <anne> krijnh, yeah
>
>   <ChrisL> the problem with this is that it removes sRGB as a baseline
>   and replaces 'dio what you want' as the baseline
>
>   <krijnh> And offline once in a while :)
>
>   tantek: do u have doc of support somewhere?
>
>   smfr: will check.
>
>   <anne> krijnh, if you can handle that :)
>
>   tantek: post url to doc if it exists.
>
>   <krijnh> anne: fixing the auto cache refresh thing right now
>
> SVG parameters in CSS in relation to CSS Variables
>
>   <shepazu>
>   [102]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/
>   SVGParamsUrlSyntax
>
>    [102] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/SVGParamsUrlSyntax
>
>   shepazu: we would like to consider csswg want to do smthing like
>   this.
>
>   TabAtkins: in ref to combining efforts, csswg is interested in
>   pursuing vars.
>
>   <krijnh> anne: done, every night around 00:10
>
>   TabAtkins: params can work in with concept of vars such that you
>   would put params and they would create vars.
>
>   <krijnh> Windows Task Scheduler ftw :')
>
>   shepazu: i thought you would decl. canonical what is the var, and
>   explicitly say this would be the param for that var
>
>   TabAtkins: yours is probably a better idea.
>
>   <krijnh> anne, hober: logging this channel as well, will add them to
>   my site somewhere this week
>
>   shepazu: # syntax has been overloaded by media fragments.
>   ... 3rd syntax is x-pointer style function that enclose vars in
>   would be best way forward.
>   ... imagine those are .css files. you are passing in a list of
>   parameters within paranthesis
>
>   <smfr>
>   [103]http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html
>
>    [103] http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html
>
>   <shepazu> fill="param(color) blue"
>
>   shepazu: if param is not passed in, use this keyword
>
>   <shepazu> x="calc(param(coordx)+10%)"
>
>   <tpod> Thanks everyone. I'll keel lurking as long as this connection
>   holds.
>
>   shepazu: is there any problem with this?
>
>   <tpod> *keep
>
>   heycam: for vars you know ahead of time.
>
>   florian: csswg did not express interest in variables but only allow
>   tab to work on his draft.
>   ... vars were global to the page, but params are stylesheet local
>   and would make people who hate variables hate them more
>
>   shepazu: my q is given this is smthing we are interested in adding
>   in svg. if you want to add this in the future in css, is this
>   acceptable in broad terms
>
>   TabAtkins: some of the qs raised against my proposal are valid here.
>   are they changable by script?
>
>   shepazu: yes
>   ... the HTML WG is not interested in changing the params thing
>
>   TabAtkins: presumably there would some script based api to easily
>   handle them rather than parse them urself
>
>   shepazu: smone proposed a url parsing api.
>
>   anne: adam barth is working on that.
>
>   shepazu: maybe we just plug this into abarth's thing
>
>   anne: is this not like param elms?
>
>   shepazu: at one point it was, but they didnt like that.
>
>   heycam: as in specify value of params in the url.
>
>   shepazu: there are param elements. if only thing we can do is url
>   syntax that is okay with me
>   ... this is a diff kind of param passing
>
>   heycam: adam barth proposed to get query string, this is stuff
>   embedded in frame.
>   ... its going to hit the network every time.
>
>   TabAtkins: i dont like the way u are defining right now to use a
>   param with default val.
>   ... u cannot use the syntax if you use fill property in css.
>   ... if u want default values on params pre decl them
>
>   shepazu: that was in org version of spec, but dropped as people
>   didnt like
>   ... what would be better for css
>
>   TabAtkins: anything where u have space separated value becomes
>   ambiguous with what is there right now. this is problem in css and
>   maybe for future svg things
>
>   <ChrisL> %20 is your freind
>
>   <ChrisL> url escaped space
>
>   <scribe> ACTION: shepazu propose a couple of diff syntax and submit
>   them for wider review and see what people think about them and ping
>   csswg recorded in [104]http://www.w3.org/2011/07/26-fx-irc]
>
>    [104] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-50 - Propose a couple of diff syntax and
>   submit them for wider review and see what people think about them
>   and ping csswg [on Doug Schepers - due 2011-08-02].
>
>   TabAtkins: nothing to do with spaces in param decl but in param use
>   ... param blue foo is ambiguous if you are specifying fallback or
>   another value
>
>   <ChrisL> syntactic spaces considered harmful. syntactic spaces as
>   ancestor selectors, doubly so
>
>   TabAtkins: if u use param in a path, it would be THE example.
>
>   <plinss_> param(name, default)
>
> FX transforms
>
>   <ed>
>   [105]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/
>   FXTransforms
>
>    [105] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FXTransforms
>
>   vhardy: agree on how we can go about doing this. I can help with
>   editing the doc.
>
>   heycam: who are editors of current doc?
>
>   vhardy: dean chris simon and we also had anthony
>   ... what we want here is to understand what we need as next step.
>   ... i just want to know how we go about producing a new document.
>
>   dino: you run into issue of how to combine with svg if u call it css
>   transforms
>
>   vhardy: soln is to say its css transform. there are only 2 ways to
>   combine them.
>
>   heycam: i seem to be the only one in fav of turning into a property
>   ... the fact that transform dom attr does not translate to property
>   names‚¶
>   ... arg against turn into property is what svg dom access to
>   transform stuff means. i dont think its impossible to design smthing
>
>   vhardy: if we agree on putting together a doc. we agree on intent to
>   combine them.
>
>   smfr: want a time frame as we already have implementations of css
>   transforms
>
>   vhardy: is it okay if we try to advance 2d first and then 3d
>
>   smfr: it is simple to have 1 doc, but we have multiple impl. of 2d
>   transforms.
>
>   dbaron: we are getting a few pieces of 3d transforms in
>
>   shepazu: by the time we finish this spec would we not have 2 impl.
>
>   vhardy: is that not likely?
>
>   <dbaron> [106]https://bugzilla.mozilla.org/show_bug.cgi?id=505115
>
>    [106] https://bugzilla.mozilla.org/show_bug.cgi?id=505115
>
>   smfr: for 3d transforms the impl would be more widely varied.
>   ... there are no obv conflicts in om.
>
>   sylvaing: i wouldnt want to take risk of doing 3d if smthing changes
>   in 2d.
>
>   dino: that relies on css om. we removed that css values have still
>   been deprecated.
>
>   sylvaing: we need a better def for 3D anyway.
>
>   vhardy: goes into direction of might as well have one spec.
>
>   shepazu: is anyone not using 2d transforms coz its not standardized?
>
>   dbaron: it is a pain for the authors coz of prefixes
>
>   shepazu: bigger pain if we get it wrong
>
>   sylvaing: do i prefix only 3d?
>
>   smfr: fair point as you can mix 2d & 3d functions
>
>   heycam: are there no more open issues on 2d?
>
>   smfr: there are def issues w.r.t svg and css
>   ... the issue with dropping prefix on 2d and not on 3d might have a
>   workaround.
>   ... it is possible to pass 3d transform functions, and throw away
>   the z parts.
>
>   dino: if they wanted to do 3d they can use prefix and the prefixed
>   one beats the unprefixed one.
>
>   smfr: you wouldnt want to do that.
>
>   vhardy: my pref is to make it one doc and work out the issues we
>   have and move forward.
>
>   smfr: ideally that would be mine too, but i think it would take 2
>   years
>
>   vhardy: it does not hurt to have one spec if its the hold up.
>
>   dino: we say we want to know what it should be.
>
>   anne: the thing with om you cant really pull transforms in front of
>   designing the value api.
>
>   smfr: transforms are a good test case for value api
>
>   sylvaing: try to drop prefixes on the property but the om can have
>   the prefixes.
>
>   smfr: probably apply the same for gradients
>
>   anne: webkit still has the old value api. all the new apis are
>   designed around premise of keeping around that api.
>   ... that seems bad as we abandonded it around 2003 or 4
>
>   shepazu: this does not resolve question of svg and css
>
>   smfr: does resolve prefix droppping on 2d and not on 3d
>
>   anne: why cant we drop for 3d.
>
>   smfr: we dont have more than 1 impl and there will be lots of issues
>   when there are more.
>
>   dbaron: i would be interested in figuring out what you do wrong.
>
>   dino: would property change even if impl is undefined.
>
>   smfr: the values and property are fairly stable. svg might add a few
>   things.
>   ... there is an issue with units in matrix
>
>   dbaron: issue of whether we want px as base unit, or get unit right
>   in "some sense"
>   ... i am less confident in the stability of other properties in 3d
>   transforms.
>
>   smfr: we should start filing issues somewhere
>
>   shepazu: it seems like people think this is priority. is that right?
>
>   smfr: i think so.
>
>   shepazu: we can make lot of progress if we start pushing this.
>
>   dino: the progress is all being in stuff thats stable and existing,
>   the work to be done to merge the two specs is how does svg become
>   transform properties
>
>   ChrisL: it is better that way to style if we multiply together
>
>   dino: it becomes harder if you want to make all svg attr properties
>   then you would have two properties
>
>   heycam: convert to property and use css one.
>
>   <ChrisL> "we dont need to keeparound SVG transforms" uh huh, make
>   every single piece of svg non conformant at a stroke ....
>
>   heycam: what do others think about turning svg transform attr into a
>   property
>
>   <ChrisL> turning it into a property makes it apply to all elements
>
>   shepazu: deal with legacy transform attr deal with it as we did,
>   going forward use css transforms
>
>   heycam: i dont want to put transform inside style.
>
>   shepazu: whats the downside
>
>   heycam: we need to make sure the syntax is compat and make sure
>   existing one would work
>   ... needto define what access to SVG transform means
>   ... i think we can come up with smthing reasonable.
>   ... i was hoping we would resolve syntax comat problems anyway.
>
>   Jennifer: would 3d apply to svg.
>
>   heycam: there are plans to.
>
>   vhardy: smfr u were talking about applying 3d transforms to svg
>   right?
>
>   smfr: yep
>
>   <smfr> ChrisL: you're rustling
>
>   ed: look at TraitAccess in svg tiny 1.2, it allows fetching both
>   baseVal and animVal for properties as well as for normal attributes
>
>   RESOLUTION: Turn transform attribute into a CSS property and heycam
>   to investigate and write a proposal to what SVG DOM does in this
>   situation
>
>   <scribe> ACTION: heycam to investigate and write a proposal to what
>   SVG DOM does when svg transform attribute becomes a css property
>   recorded in [107]http://www.w3.org/2011/07/26-fx-irc]
>
>    [107] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-51 - Investigate and write a proposal to
>   what SVG DOM does when svg transform attribute becomes a css
>   property [on Cameron McCormack - due 2011-08-02].
>
>   dino: we still got the question on merging the spec.
>   ... the transforms spec requires units in translations.
>
>   smfr: transform-origin changes
>
>   heycam: u still worried about slight differences in svg and css.
>
>   <ChrisL> yeah lets kill the units requirement
>
>   dino: making one unified spec isnt just adding 3d stuff but also
>   combining unitless and united transform fns and maybe differences in
>   transform origin
>
>   heycam: we should try to resolve any diff we can and put the restl
>   as slight differences between presentation and property
>
>   ed: some of the issues have been resolved in fx transforms draft
>   e.g. transform-origin has been resolved.
>
>   dino: the most dangerous difference is smthing like transform
>   scale(2) and expect it to apply to a bunch of elms some of which are
>   svg and html.
>
>   heycam: hows origin resolved?
>
>   ed: i think svg elements it was moved to smthing else.
>
>   anne: svg elms can have different origin specified
>
>   heycam: are u saying it could be confusing?
>
>   dino: yeah
>
>   anne: svg has diff co-ordinate model than css anyway
>
>   ed: you can specify transform-origin:50%,50% explicitly for svg to
>   get the same origin as for other elements
>
>   dino: next step is to find someone who wants to do it.
>
>   heycam: i have to look at transforms stuff and look at impact to svg
>
>   vhardy: i am willing to help.
>
>   <dbaron> Sounds like there are at least some :hover editors :-)
>
>   dino: i am oaky if you(vhardy) took it over
>
>   vhardy: heycam has a bunch of items that anthony had.
>
>   smfr: i am willing to edit some of the 3d parts
>
>   vhardy: i am not ready to do it just by myself.
>
>   dino: the stuff that needs to be done is the difficult part.
>
>   vhardy: i like someone to work with me on editing an wording the svg
>   stuff
>
>   smfr: i would like other implementors to start filing issues
>
>   dbaron: whats the tracking mechanism?
>
>   vhardy: we have a wiki page.
>
>   <ed>
>   [108]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/
>   FXTransforms
>
>    [108] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FXTransforms
>
>   smfr: wiki is fine.
>
>   <ed>
>   [109]http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransform
>   sToDoList
>
>    [109] http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsToDoList
>
>   vhardy: we agree to do one spec and call it 'css transforms'?
>
>   smfr: there is confusion with xslt transform
>   ... so we need a prefix
>
>   RESOLUTION: The CSS 2d, 3d, SVG 2d and 3d, FX transforms spec are
>   going to be combined into one CSS Transforms spec.
>
>   <scribe> ACTION: vhardy to work with heycam dino smfr to work on the
>   new spec for CSS Transforms. [recorded in
>   [110]http://www.w3.org/2011/07/26-fx-irc]
>
>    [110] http://www.w3.org/2011/07/26-fx-irc
>
>   <trackbot> Created ACTION-52 - Work with heycam dino smfr to work on
>   the new spec for CSS Transforms. [on Vincent Hardy - due
>   2011-08-03].
>
>   dbaron: i have mixed feelings, as 2d is more stable than 3d.
>   ... last TPAC we had a resolution to get css 2d get to CR more
>   quickly
>
>   dino: boris, dbaron and sylvaing had comments on css 2d
>
>   vhardy: i will work with you smfr dino to figure out what would be
>   the best base to start from.
>
>   dbaron: we can still advance the current specification
>
>   florian: so combined spec becomes css 4
>
>   <dbaron> dbaron: I think we should keep the option open to advance
>   2-D, but I'm ok with going ahead with this approach.
>
>   dino: it is just interesting that we have a spec that could possibly
>   enter cr and we are not progressing it.
>
>   shepazu: do we have tests for it?
>
>   smfr: we have some test cases that are being worked on
>
>   shepazu: if people want to push css2d before css2d and 3d go for it.
>
>   heycam: i dont think its a problem
>   ... its only a problem if we need to make changes to css2d spec.
>   ... i dont see how spec organization impacts 3d.
>
>   smfr: how do u ship a browser that supports prefixed or unprefixed.
>
>   heycam: thats a q regardless of whether they are in same spec or not
>
>   smfr: if in same spec u can drop prefixes at once.
>
>   heycam: is that the convention?
>
>   smfr: yeah one module yeah.
>
>   shepazu: having a 2d spec does not resolve the issue
>
>   smfr: thats true.
>
>   heycam: is the convention to drop prefix once we get to CR?
>
>   dbaron: convention is to drop prefix once u go to CR and get the
>   test suite
>
>   shepazu: we have no problems with anyone pushing 2D stuff, even
>   putting it into CR.
>
>   smfr: i think thats fine. we will figure out how to deal with prefix
>   issue when it comes up.
>   ... the combined spec is a good thing in long term, if we decide we
>   want to we can accelerate the 2d spec separately and we will figure
>   out internally issues related to dropping the prefix smhow.
>
>   vhardy: we could have a draft by TPAC for transforms
>
>   ed: for filters how long it would take?
>
>   dino: i can have it done by the week.
>
> publishing schedule
>
>   dino: everyone has agreed we can publish it as first WD
>
>   vhardy: discuss on friday how much progress we can make w.r.t
>   compositing
>
>   cabanier: how 3d transforms work with compositing and filters. as
>   compositing assumes 2D.
>
>   dino: we do specify some form of flattening in the 3D spec. it is a
>   bit of mlack magic at this moment.
>
>   vhardy: can u discuss this smtime tomorrow?
>
>   ed: thats all on the agenda i could squeeze a bit about the testing
>   ... plinss currently the svg test suite is not using the test
>   harness, it could be useful.
>
>   <plinss_> test.csswg.org/harness
>
> testing harness overview
>
>   <bradk> I have to take off. I wish all travelers a bon voyage.
>
>   plinss: it presents all the test in a test suite
>
>   <bradk> bye!
>
>   plinss: it computes what order ‚¶
>   ... there are metadata embedded in the test which links back to the
>   url.
>   ... presents your test in an iframe,. test can be multiple formats
>   in a tabbed interface.
>   ... upper right hand corner you have current results known by
>   rendering engine
>   ... it is doing manual testing visual.
>   ... it has a bunch of reporting system.
>   ... shows detailed results gathered thro that particular tests, user
>   agent.
>   ... full flushed out test file.
>
>   you can also see results by portions of the spec.
>
>   <plinss_> [111]http://test.csswg.org/annotations/css21/
>
>    [111] http://test.csswg.org/annotations/css21/
>
>   plinss: there is a spec annotation system
>   ... tests show up for each section
>   ... it injects that annotation mark.
>   ... annotations link back to the harness
>   ... the title for each annotation takes u to the test itself.
>
>   shepazu: how do u put this into the spec?
>
>   plinss: 1 line of script
>
>   alan: how does it display if a section does not have tests? maybe it
>   should display red.
>
>   plinss: not every section needs tests
>   ... there are some features that are exposed in the ui, you can
>   enter another UA string.
>   ... I run a cron that takes all the results and figures out where
>   tests are needed most to get to CR
>   ... there is an instance of this running on 23c server
>   ... its all open source.
>
>   shepazu: so in svg i can't tell can u do side by side comparisons?
>
>   <plInss_>
>   [112]http://test.csswg.org/harness/test/CSS21_DEV/flag/reftest/
>
>    [112] http://test.csswg.org/harness/test/CSS21_DEV/flag/reftest/
>
>   plinss: yoyou can do back and forth side by side.
>   ... can specify it must look like this page, AND this page and NOT
>   like this page.
>   ... the reference can be plain reference file or another test.
>
>   shepazu: can we resolve to move to this in SVG 2?
>
>   ed: i am most interested is the ability to see the test+results in
>   each spec sections
>
>   shepazu: even if u dont do tests in this harness you can post
>   reports.
>
>   plinss: i believe mozilla and webkit have their own systems to run
>   automated tests and they can export it to the harness.
>
>   <plinss_> [113]http://w3c-test.org/framework/
>
>    [113] http://w3c-test.org/framework/
>
>   TabAtkins: mainly for csswg, could people respond to thread of
>   background-print property
>
>   <TabAtkins_> >
>
>   <TabAtkins_> > --
>
>   <TabAtkins_> > Joshua Ganderson | Front End Software Engineer |
>   jganderson@google.com | 512.627.1539
>
>   <plinss_>
>   [114]http://test.csswg.org/suites/css2.1/nightly-unstable/report/
>
>    [114] http://test.csswg.org/suites/css2.1/nightly-unstable/report/
>
>   <TabAtkins_> >
>
>   <TabAtkins_> > --
>
>   <TabAtkins_> > Joshua Ganderson | Front End Software Engineer |
>   jganderson@google.com | 512.627.1539
>
>   <TabAtkins_>
>   [115]http://lists.w3.org/Archives/Public/www-style/2011Jul/0341.html
>
>    [115] http://lists.w3.org/Archives/Public/www-style/2011Jul/0341.html
>
>   TabAtkins: soln suggested by glazou to have authors override default
>   UA stylesheets is not feasible as browsers do not want authors to
>   override UA styles
>
>   plinss: i have no problem to override it, the default needs to be
>   auto. we need smthing in css when user pref is auto.
>
>   glazou: in your opinion auto is do not print bg until the author
>   says print background
>
>   plinss: there is no way to change default.
>
>   TabAtkins: background-print is just an element property.
>
>   ed: adjourned.
>
>   <tantek> safe travels everyone
>
> Summary of Action Items
>
>   [NEW] ACTION: cabanier produce a new draft of compositing which
>   should probably called CSS Compositing with appendices on how
>   compositing works in css, html box model and svg model. [recorded in
>   [116]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Cameron to update the SVG specification, adding 'auto'
>   the pointer-events specification. [recorded in
>   [117]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: ChrisL to check whether or not filters spec sounds as
>   a new draft or not [recorded in
>   [118]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: dbaron to reach out to web security experts and get an
>   opinion on whether or not we should address security concerns on the
>   hit testing algorithm. Coordinate with Tantek for the CSS 3 UI spec.
>   recorded in [119]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Dean to draft a proposal for specifying hit testing
>   regions or masks for CSS 4 UI [recorded in
>   [120]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: dean to make a naming proposal to distinguish between
>   CSS and markup filters. [recorded in
>   [121]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: dino add shorthand property for shadow. [recorded in
>   [122]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Dino to make a naming proposal to distinguish between
>   CSS and markup filters. [recorded in
>   [123]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: dino to write up use-cases and priority list of
>   features to be added to css animations [recorded in
>   [124]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: dino update the filter spec to produce the new image
>   type. recorded in [125]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Doug to propose that opacity of a pixel does not
>   affect its pointer-event behavior for CSS 3 UI. [recorded in
>   [126]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Doug to propose wording for CSS 3 UI about how masks
>   and clip-paths impact hit-testing. [recorded in
>   [127]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: ed to move clip-path and masks to the FX Filter
>   specification draft. [recorded in
>   [128]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: heycam to investigate and write a proposal to what SVG
>   DOM does when svg transform attribute becomes a css property
>   recorded in [129]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: RRSAgent - learn how to reference people by URL not
>   just alias. recorded in [130]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: shepazu and dbaron to reach out to web security
>   experts and get an opinion on whether or not we should address
>   security concerns on the hit testing algorithm. Coordinate with
>   Tantek for the CSS 3 UI spec. [recorded in
>   [131]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: shepazu propose a couple of diff syntax and submit
>   them for wider review and see what people think about them and ping
>   csswg recorded in [132]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: shepazu to integrate Hixie's proposal on hit testing
>   and define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG. [recorded in
>   [133]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: shepazu to write up proposal for opacity threshold for
>   pointer-events for CSS 4 UI [recorded in
>   [134]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: smfr to look at dbaron's draft and see if it matches
>   what they have implemented and determine if its an issue or not.
>   recorded in [135]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: tantek to integrate Hixie's proposal on hit testing
>   and define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG. [recorded in
>   [136]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: Tantek to integrate Hixie's proposal on hit testing
>   and define hit-testing in CSS 3 UI and coordinate with Doug for
>   harmonizing with SVG. [recorded in
>   [137]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: tantek to specify how opacity:0 impact hit testing.
>   recorded in [138]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: trackbot - learn how to reference people by URL not
>   just alias. recorded in [139]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: vhardy produce a new draft of compositing which should
>   probably called CSS Compositing with appendices on how compositing
>   works in css, html box model and svg model. [recorded in
>   [140]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: vhardy to come back with more arguments on custom
>   filters and make a proposal. [recorded in
>   [141]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: vhardy to work with heycam dino smfr to work on the
>   new spec for CSS Transforms. [recorded in
>   [142]http://www.w3.org/2011/07/26-fx-irc]
>   [NEW] ACTION: vincent to come back with more arguments on custom
>   filters and make a proposal. [recorded in
>   [143]http://www.w3.org/2011/07/26-fx-irc]
>
>    [116] http://www.w3.org/2011/07/26-fx-irc
>    [117] http://www.w3.org/2011/07/26-fx-irc
>    [118] http://www.w3.org/2011/07/26-fx-irc
>    [119] http://www.w3.org/2011/07/26-fx-irc
>    [120] http://www.w3.org/2011/07/26-fx-irc
>    [121] http://www.w3.org/2011/07/26-fx-irc
>    [122] http://www.w3.org/2011/07/26-fx-irc
>    [123] http://www.w3.org/2011/07/26-fx-irc
>    [124] http://www.w3.org/2011/07/26-fx-irc
>    [125] http://www.w3.org/2011/07/26-fx-irc
>    [126] http://www.w3.org/2011/07/26-fx-irc
>    [127] http://www.w3.org/2011/07/26-fx-irc
>    [128] http://www.w3.org/2011/07/26-fx-irc
>    [129] http://www.w3.org/2011/07/26-fx-irc
>    [130] http://www.w3.org/2011/07/26-fx-irc
>    [131] http://www.w3.org/2011/07/26-fx-irc
>    [132] http://www.w3.org/2011/07/26-fx-irc
>    [133] http://www.w3.org/2011/07/26-fx-irc
>    [134] http://www.w3.org/2011/07/26-fx-irc
>    [135] http://www.w3.org/2011/07/26-fx-irc
>    [136] http://www.w3.org/2011/07/26-fx-irc
>    [137] http://www.w3.org/2011/07/26-fx-irc
>    [138] http://www.w3.org/2011/07/26-fx-irc
>    [139] http://www.w3.org/2011/07/26-fx-irc
>    [140] http://www.w3.org/2011/07/26-fx-irc
>    [141] http://www.w3.org/2011/07/26-fx-irc
>    [142] http://www.w3.org/2011/07/26-fx-irc
>    [143] http://www.w3.org/2011/07/26-fx-irc
>
>   [End of minutes]
>     ___________________________________
>
>
>
> --
> Chris Lilley   Technical Director, Interaction Domain
> W3C Graphics Activity Lead, Fonts Activity Lead
> Co-Chair, W3C Hypertext CG
> Member, CSS, WebFonts, SVG Working Groups
>
>
Received on Thursday, 28 July 2011 16:07:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 July 2011 16:07:51 GMT