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