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

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

From: Chris Lilley <chris@w3.org>
Date: Wed, 27 Jul 2011 20:16:53 +0200
Message-ID: <914961909.20110727201653@w3.org>
To: FX <public-fx@w3.org>
Hello FX,

Minutes of the Seattle meeting are at
http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0023/26-fx-minutes.html

and below as text for trackbot

                             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
     * [13]Summary of Action Items
     _________________________________________________________

   [14]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda

     [14] 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>
   [15]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0111.ht
   ml

     [15] 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>
   [16]http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_se
   rve.html

     [16] 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_>
   [17]http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_se
   rve.html

     [17] 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>
   [18]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.ht
   ml

     [18] 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:
   [19]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.ht
   ml

     [19] 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> [20]https://developer.mozilla.org/en/css/pointer-events

     [20] https://developer.mozilla.org/en/css/pointer-events

   dbaron: I believe Mozilla support is similar to WebKit - none and
   auto

   (for HTML content)

   <smfr> [21]http://dev.w3.org/csswg/css3-ui/#pointer-events

     [21] 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>
   [22]http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
   (last paragraph, scroll down a bit)

     [22] 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:
   [23]http://www.w3.org/TR/SVG/painting.html#DisplayProperty

     [23] 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> [24]http://wiki.csswg.org/spec/css3-ui#issue-4

     [24] http://wiki.csswg.org/spec/css3-ui#issue-4

   tantek: Issue 4 is related to the computed value

   <tantek> @namespace svg "[25]http://www.w3.org/2000/svg";

     [25] 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> [26]http://wiki.csswg.org/spec/css3-ui#issue-5

     [26] 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
   [27]http://www.w3.org/2011/07/26-fx-irc]

     [27] 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> [28]http://wiki.csswg.org/spec/css3-ui#issue-6

     [28] 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> [29]http://dev.w3.org/csswg/css3-ui/#pointer-events0

     [29] 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> [30]http://dev.w3.org/csswg/css3-ui/#pointer-events0

     [30] 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> [31]http://www.webkit.org/specs/PointerEventsProperty.html

     [31] http://www.webkit.org/specs/PointerEventsProperty.html

   tantek: does HTML5 define hit testing?

   anne: no

   <anne>
   [32]http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html

     [32] http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html

   smfr: I thought it was defined.

   <shepazu> [33]http://www.w3.org/TR/SVG/intro.html#TermHitTesting

     [33] 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>
   [34]http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-ev
   ents-20100820.html

     [34] 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>
   [35]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html

     [35] 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>
   [36]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html

     [36] 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>
   [37]http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html

     [37] 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
   [38]http://www.w3.org/2011/07/26-fx-irc]

     [38] 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
   [39]http://www.w3.org/2011/07/26-fx-irc]

     [39] 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
   [40]http://www.w3.org/2011/07/26-fx-irc]

     [40] 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
   [41]http://www.w3.org/2011/07/26-fx-irc]

     [41] 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 [42]http://www.w3.org/2011/07/26-fx-irc]

     [42] 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
   [43]http://www.w3.org/2005/06/tracker/irc for help

     [43] 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> [44]http://www.w3.org/Graphics/fx/track/actions/1

     [44] 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 [45]http://www.w3.org/Graphics/fx/track/users

     [45] 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
   [46]http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
   refer to full transparency as allowing events to pass through

     [46] 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:
   [47]http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html

     [47] 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
   [48]http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html

     [48] 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
   [49]http://www.w3.org/2011/07/26-fx-irc]

     [49] 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 [50]http://www.w3.org/2011/07/26-fx-irc]

     [50] 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: [51]http://wiki.csswg.org/spec/css3-ui#issue-9

     [51] 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
   [52]http://www.w3.org/2011/07/26-fx-irc]

     [52] 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: [53]http://wiki.csswg.org/spec/css3-ui#issue-9

     [53] 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
   [54]http://www.w3.org/2011/07/26-fx-irc]

     [54] 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: [55]http://wiki.csswg.org/spec/css3-ui#issue-10
   ... I think we are ducking this.

     [55] 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> [56]https://developer.mozilla.org/en/CSS/clip-path

     [56] https://developer.mozilla.org/en/CSS/clip-path

   <tantek> [57]https://developer.mozilla.org/en/CSS/mask

     [57] 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
   [58]http://www.w3.org/2011/07/26-fx-irc]

     [58] 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>
   [59]https://developer.mozilla.org/en/CSS/-webkit-mask-box-image

     [59] https://developer.mozilla.org/en/CSS/-webkit-mask-box-image

   <shepazu>
   [60]http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg
   _ef.html

     [60] http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html

   <birtles>
   [61]https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_co
   ntent

     [61] 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>
   [62]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters
   .html

     [62] 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
   [63]http://www.w3.org/2011/07/26-fx-irc]

     [63] 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>
   [64]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/F
   ilterEffects

     [64] 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
   [65]http://www.w3.org/2011/07/26-fx-irc]

     [65] 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
   [66]http://www.w3.org/2011/07/26-fx-irc]

     [66] 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 [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 - 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 [68]http://www.w3.org/2011/07/26-fx-irc]

     [68] 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>
   [69]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.ht
   ml

     [69] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html

   <ed>
   [70]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters
   .html#feCustomElement

     [70] 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:
   [71]http://wiki.csswg.org/planning/seattle-2011#tuesday but don't
   see any other items (nor links to agendas in other locations)

     [71] 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
   [72]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda

     [72] 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
   [73]http://www.w3.org/2011/07/26-fx-irc]

     [73] 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
   [74]http://www.w3.org/2011/07/26-fx-irc]

     [74] 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>
   [75]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.ht
   ml

     [75] 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:
   [76]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/F
   ilterEffects

     [76] 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> [77]http://www.w3.org/Graphics/fx/track/issues/5

     [77] 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> [78]http://www.w3.org/TR/SVGCompositing/

     [78] 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?
   [79]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
   html

     [79] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html

   <anne> [80]http://www.w3.org/TR/SVGCompositing/

     [80] 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,
   [81]http://dev.w3.org/SVG/modules/compositing/publish/SVGCompositing
   .html

     [81] 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> [82]http://dev.w3.org/SVG/modules/compositing/publish/

     [82] 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
   [83]http://www.w3.org/2011/07/26-fx-irc]

     [83] 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> [84]https://www.w3.org/2005/06/tracker/users/my

     [84] 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
   [85]http://www.w3.org/2011/07/26-fx-irc]

     [85] 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 [86]http://www.w3.org/2011/07/26-fx-irc]

     [86] 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
   [87]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.

     [87] 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 [88]http://www.w3.org/2011/07/26-fx-irc]

     [88] 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
   [89]http://www.w3.org/2011/07/26-fx-irc]

     [89] 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>
   [90]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/A
   nimations/Harmonisation

     [90] 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> [91]http://www.downforeveryoneorjustme.com/w3.org

     [91] http://www.downforeveryoneorjustme.com/w3.org

   <tantek> [92]http://www.downforeveryoneorjustme.com/web5.w3.org

     [92] http://www.downforeveryoneorjustme.com/web5.w3.org

   <birtles> [93]http://dl.dropbox.com/u/11894343/Harmonisation.htm

     [93] 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>
   [94]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
   on_improvements#Wanted_feature:_re-use_animations

     [94] 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>
   [95]http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CS
   S_Animation#Promoting_attributes_to_properties

     [95] 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
   [96]http://www.w3.org/2011/07/26-fx-irc]

     [96] 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
   [97]http://www.w3.org/2009/11/03-CSS-minutes.html (I don't think
   it's been discussed since)

     [97] http://www.w3.org/2009/11/03-CSS-minutes.html

color correction

   <dbaron> [98]http://dev.w3.org/csswg/css-color-correction/

     [98] 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 [99]http://www.w3.org/2011/07/26-fx-irc]

     [99] 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>
   [100]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/
   SVGParamsUrlSyntax

    [100] 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>
   [101]http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html

    [101] 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 [102]http://www.w3.org/2011/07/26-fx-irc]

    [102] 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>
   [103]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/
   FXTransforms

    [103] 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> [104]https://bugzilla.mozilla.org/show_bug.cgi?id=505115

    [104] 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 [105]http://www.w3.org/2011/07/26-fx-irc]

    [105] 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.

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
   [106]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
   [107]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
   [108]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 [109]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
   [110]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
   [111]http://www.w3.org/2011/07/26-fx-irc]
   [NEW] ACTION: dino add shorthand property for shadow. [recorded in
   [112]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
   [113]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
   [114]http://www.w3.org/2011/07/26-fx-irc]
   [NEW] ACTION: dino update the filter spec to produce the new image
   type. recorded in [115]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
   [116]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
   [117]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
   [118]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 [119]http://www.w3.org/2011/07/26-fx-irc]
   [NEW] ACTION: RRSAgent - learn how to reference people by URL not
   just alias. recorded in [120]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
   [121]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 [122]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
   [123]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
   [124]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 [125]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
   [126]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
   [127]http://www.w3.org/2011/07/26-fx-irc]
   [NEW] ACTION: tantek to specify how opacity:0 impact hit testing.
   recorded in [128]http://www.w3.org/2011/07/26-fx-irc]
   [NEW] ACTION: trackbot - learn how to reference people by URL not
   just alias. recorded in [129]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
   [130]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
   [131]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
   [132]http://www.w3.org/2011/07/26-fx-irc]

    [106] http://www.w3.org/2011/07/26-fx-irc
    [107] http://www.w3.org/2011/07/26-fx-irc
    [108] http://www.w3.org/2011/07/26-fx-irc
    [109] http://www.w3.org/2011/07/26-fx-irc
    [110] http://www.w3.org/2011/07/26-fx-irc
    [111] http://www.w3.org/2011/07/26-fx-irc
    [112] http://www.w3.org/2011/07/26-fx-irc
    [113] http://www.w3.org/2011/07/26-fx-irc
    [114] http://www.w3.org/2011/07/26-fx-irc
    [115] 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

   [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 Wednesday, 27 July 2011 18:17:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 July 2011 18:17:39 GMT