/irc-logs / w3c / #fx / 2011-07-26 / end

Options:

# Session Start: Tue Jul 26 18:20:09 2011
# Session Ident: #fx
# 03[18:20] * Now talking in #fx
# [18:20] <Ms2ger> Pain? :)
# [18:20] <dino> s/SVG Pain/SVG Paint/
# [18:20] <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0111.html
# [18:20] <hober> sylvaing: could you skype bradk & me in?
# 06[18:20] * plinss_ tpod: and at http://logs.csswg.org/irc.w3.org/fx/?date=2011-07-26
# [18:20] <dino> TabAtkins: There was a proposal a while ago about using SVG paint as CSS images.
# [18:20] <smfr> http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
# 03[18:20] * Joins: vhardy (vhardy@72.254.89.196)
# 06[18:21] * hober sylvaing: thanks :)
# 06[18:21] * sylvaing If you want to listen to the meeting on Skype, ping sgalineau
# [18:21] <dino> TabAtkins: That's one proposal. I plan to add it into CSS Image Values 4
# 06[18:21] * heycam test
# [18:21] <dino> TabAtkins: The other way around is CSS into SVG paint servers
# 03[18:21] * Parts: heycam (cam@203.98.73.35) (Leaving)
# [18:21] <dino> TabAtkins: e.g. <rect fill="linear-gradient(top blue)">
# [18:22] <dino> TabAtkins: but there are other useful things like the element() function
# 03[18:22] * Joins: cabanier (cabanier@192.150.22.150)
# 03[18:22] * Joins: heycam (cam@203.98.73.35)
# [18:22] <dino> TabAtkins: question is where to specify using CSS images as paint servers?
# 03[18:22] * Joins: szilles (chatzilla@72.254.90.148)
# [18:22] <dbaron> 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), Simon Fraser (Apple), Dean Jackson (Apple), Brian Birtles (Mozilla), Cameron McCormack (Mozilla), Tan
# [18:22] <dbaron> tek Çelik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter Linss (HP)
# 03[18:22] * Joins: dholbert (dholbert@76.102.13.41)
# [18:22] <dino> dino: what's the status of SVG specs
# 03[18:23] * Joins: shans (qw3birc@128.30.52.28)
# [18:23] <dino> heycam: SVG 2e was just published. We are starting on new specs now.
# [18:23] <tpod> This is Tantek's iPod
# [18:23] <dino> heycam: it would be ok to specify this in image values spec
# 03[18:23] * Joins: glazou (glazou@72.254.57.180)
# 06[18:24] * Ms2ger is surprised Tantek would have such a locked down device :)
# 03[18:24] * Joins: florian (florianr@72.254.59.60)
# [18:25] <dino> ed: many SVG implementations already support things like CSS colours even though it isn't supported in specs.
# [18:25] <dino> dino: it seems weird for a CSS specification to define SVG behaviour
# 03[18:25] * Joins: tantek (tantek@72.254.91.192)
# [18:26] <dino> heycam: we could do it in the SVG spec, it would take time
# [18:26] <dino> 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.
# [18:27] <ed> s/CSS colours even though it isn't supported in specs./CSS3 colours anywhere you can use a <color> in svg even though that isn't supported in the SVG spec(s)/
# [18:27] <dino> tantek: The problem then is that the CSS image values spec now requires an SVG implementation to exit CR
# [18:27] <dino> dbaron: it's ok if there are two browser engines that implement it
# [18:27] <dino> TabAtkins: Mozilla already have an implementation
# [18:27] <TabAtkins_> http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
# [18:28] <dino> tantek: i am not formally opposing, but I think it is a potential serious issue.
# [18:28] <dino> TabAtkins: all the CSS image values would be SVG paint servers in userSpaceOnUse
# [18:29] <dino> heycam: uSoU percentages are relative to the viewport, not to the bounding box of the shape
# [18:30] <tantek> <aside> Ms2ger - I created #fx-chat for off-topic conversations. :) </aside>
# [18:30] <dino> 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.
# [18:30] <dino> TabAtkins: I don't want to create a new unit space just for this.
# [18:30] <dino> heycam: are there other issues?
# [18:30] <dino> TabAtkins: I think coordinate spaces are the only issues.
# [18:32] <dbaron> 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),
# [18:32] <dbaron> Brian Birtles (Mozilla), Cameron McCormack (Mozilla), Tantek Çelik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter Linss (HP)
# [18:32] <dino> dino: what CSS image values have percentages?
# [18:32] <dino> TabAtkins: only gradients
# [18:32] <dino> vhardy: How about the keywords like top left etc? Would that be to the SVG bounding box?
# [18:33] <dino> 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.
# [18:33] <dino> TabAtkins recaps yesterday's CSS discussion on gradients
# [18:34] <bradk> I thought we were unresolved on whether or not to do away with corner-to-corner gradients for now. No concensus.
# 02[18:34] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [18:34] <dino> bradk, i believe they were officially deferred from CSS IM 3
# [18:35] <dino> ed: SVG 1.1 doesn't include the stoke and markers in the bounding box. That might be important for gradients also.
# [18:35] <dino> TabAtkins: we may have to do some mode switching as you go from CSS to SVG.
# [18:36] <bradk> dino, Are you sure? I don't recall seeing a resolution for that. I thought it was "no consensus, back to the list".
# [18:36] <dino> 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.
# [18:36] <dino> bradk, no, I'm not sure.
# [18:36] <fantasai> There was no consensus on removing anything from Gradients
# [18:36] <dino> bradk, but Tab is speaking now as if it was a resolution :)
# [18:36] <fantasai> Well, Tab's wrong then. :)
# [18:37] <bradk> wouldn't be the first time. ;)
# [18:37] <dino> heycam: CSS may have the same issue with calculating bounding boxes
# [18:38] <dino> TabAtkins: yes, it's fairly well defined there. It defines the region of the canvas, such as content-box, border-box, etc.
# [18:38] <dino> RESOLUTION: Tab to add wording to CSS Image Values 4 about how SVG Paint Servers apply to CSS
# [18:39] <dino> RESOLUTION: 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).
# [18:39] <stearns> bradk - you're right, it's not in the minutes. But I believe it should have been
# [18:40] <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
# [18:40] <fantasai> Dino: We're sending out massive images right now when we don't need to
# [18:40] <tantek> dino, TabAtkins, re: 2nd Resolution - suggest making that a non-normative section.
# [18:40] <fantasai> Dino: Add things for noise, checkboard, halo, etc. Not suggesting we add all those
# [18:40] <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
# [18:40] <fantasai> Cam: How does Compositing work?
# [18:41] <fantasai> Dino; Becomes difficult in filters spec, bc sometimes you want the generated below, and other times above.
# [18:41] <fantasai> Dino: e.g. ppl do a halo effect where a flash moves across the text.
# [18:41] <fantasai> Dino: In that case you want it above.
# [18:41] <fantasai> Dino: Tab said it would be better to allow an image anywhere in CSS
# [18:41] <fantasai> Dino: e.g. say your background is blue with a faint noise texture above it
# [18:41] <cabanier> discussion: http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
# [18:41] <fantasai> Cam: With bg now you can specify multiple things?
# [18:42] <fantasai> smfr: multiple images, yes
# 02[18:42] * Quits: tpod (tpod@66.87.2.135) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# [18:42] <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...
# [18:42] <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
# 06[18:42] * heycam wonders where shepazu is
# 06[18:42] * dino thanks fantasai for stepping in
# [18:42] <fantasai> Tab: Thing sin CSS spec that would move to being image values are :
# 03[18:43] * Joins: szilles (chatzilla@72.254.90.148)
# [18:43] <fantasai> Tab: flood ...
# [18:43] <fantasai> Tab: Unfortunately colors are not image types in CSS. Bg has special case of bg-color
# [18:43] <dino> TabAtkins: flood would map to image() (eg. image(blue))
# [18:43] <fantasai> Tab: But you can't have list-style-image: blue;
# [18:43] <fantasai> Tab: If we don't get that otherwise, the image() function lets you smuggle that in
# [18:43] <dino> TabAtkins: because image() has a fallback for a color
# [18:43] <fantasai> Tab: Because it allows a fallback color
# [18:44] <dino> TabAtkins: without an intrinsic size
# [18:44] <dino> TabAtkins: turbulence could be an image value
# [18:45] <dino> TabAtkins: the rest are filters so should stay as filters
# [18:45] <dino> dino: I propose asking for examples on the list of generated images.
# 02[18:46] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [18:46] <dino> RESOLUTION: The new image generator methods (eg. turbulence) to be added to CSS Image Values 4
# 03[18:46] * Joins: patrickdengler (pdengler@72.254.92.227)
# [18:47] <dino> smfr: I am concerned about the syntax overhead of specifying some complex filters. eg. a checkerboard has colour, repeat, offset.
# [18:47] <dino> TabAtkins: I agree. We'll have to balance that.
# [18:48] <dino> fantasai: Once SVG Paint Servers are allowed, it may be better to reference an library of SVG images as a CSS paint.
# [18:48] <dino> 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.
# [18:49] <dino> vhardy: are you suggesting changing the algorithm as is?
# [18:49] <dino> ed: we can't remove what is there
# [18:50] <dino> vhardy: it was hard to get the algorithm right, we shouldn't change it.
# [18:50] <dino> vhardy: so which SVG filter primitives will become paint server?
# [18:51] <dino> TabAtkins: It won't be the full set.
# [18:52] <dino> dino: turbulence/noise is the only new one
# [18:52] <dino> Topic: Pointer events an alpha-level hit testing
# 03[18:52] * Joins: ChrisL (ChrisL@128.30.52.169)
# [18:53] <ChrisL> rrsagent, here
# [18:53] <RRSAgent> See http://www.w3.org/2011/07/26-fx-irc#T16-48-50
# [18:53] <dino> tantek: We have some degree of interop with the pointer-events property. Mozilla + IE support it. WebKit supports "none" and "auto" for HTML.
# [18:53] <dino> tantek: so it has been added to CSS 3 UI
# [18:53] <tantek> https://developer.mozilla.org/en/css/pointer-events
# [18:54] <dino> dbaron: I believe Mozilla support is similar to WebKit - none and auto
# [18:54] <dino> (for HTML content)
# [18:54] <smfr> http://dev.w3.org/csswg/css3-ui/#pointer-events
# [18:54] <dino> 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.
# [18:55] <dino> smfr: We've had requests to support visiblePainted in HTML for image content.
# [18:56] <dino> ed: SVG does ignore hit tests on fully alpha pixels in an image
# [18:56] <ed> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty (last paragraph, scroll down a bit)
# [18:56] <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."
# [18:56] <dino> dbaron: we need translations of the purely SVG names. define what "stroke" means in HTML.
# [18:58] <dino> 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)
# [18:58] <dino> heycam: would the CSS spec define what shapes, etc are for the SVG case? or should that be in the SVG spec?
# [18:59] <dino> tantek: I'll redefine "auto" slightly. It currently references visiblePainted, but we're moving that out.
# [18:59] <dino> tantek: I'll normatively reference the SVG spec for SVG content.
# [18:59] <bradk> shouldn't there be a value for 'pointer-events' to determine clickability based on an opacity value?
# [19:00] <dino> heycam: we should define a term in the SVG spec like "hit testable area" and have that as a reference target
# [19:00] <dino> 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
# 03[19:01] * Joins: szilles (chatzilla@72.254.90.148)
# [19:01] <dino> vhardy: what do you do for a stylesheet targeting both languages? SVG will allow more values.
# [19:02] <dino> tantek: this is an old problem. some specifications allow different values.
# [19:02] <dino> dbaron: i suspect that the current implementations accept all the values that SVG supports, and treats the common value the same across both languages.
# [19:03] <dino> tantek: then maybe the specification should define "auto" and "none", then say that everything else is defined in the host language.
# [19:03] <dino> tantek: this does mean that any new functionality will need new values
# [19:03] <dino> TabAtkins: hopefully people are not using visiblePainted and expecting it to behave as "auto".
# [19:04] <dino> TabAtkins: so we might be able to redefine visiblePainted
# [19:05] <dino> TabAtkins: put the values in the spec and say that people should not use them outside of SVG.
# 03[19:05] * Joins: shepazu (schepers@128.30.52.169)
# [19:06] <dino> TabAtkins gave an example that the scribe missed
# [19:06] <dino> tantek: that example is deprecated values. this is different.
# [19:06] <vhardy> Example of precedent where SVG only uses a subset of the existing value set: http://www.w3.org/TR/SVG/painting.html#DisplayProperty
# [19:06] <dino> szilles: the wording should be "these values only have defined meaning in sag"
# [19:06] <dino> s/sag/SVG/
# 06[19:06] * dino curses OS X Lion autocomplete
# 06[19:07] * dino autocorrect
# 06[19:07] * anne case in point? :)
# [19:07] <dino> RESOLUTION: List all the current values for pointer events, everything other than "none" is treated as "auto" unless applied to SVG content
# [19:08] <dino> RESOLUTION: Add an author conformance criteria saying that they should not use the other values outside of SVG
# 02[19:08] * Quits: stearns (qw3birc@128.30.52.28) (Quit: Page closed)
# 03[19:08] * Joins: stearns__ (anonymous@72.254.63.25)
# [19:09] <tantek> http://wiki.csswg.org/spec/css3-ui#issue-4
# [19:09] <dino> tantek: Issue 4 is related to the computed value
# [19:10] <tantek> @namespace svg "http://www.w3.org/2000/svg";
# [19:10] <tantek> svg|svg { pointer-events: none }
# [19:10] <tantek> svg|svg>* { pointer-events: visiblePainted }
# [19:10] <dino> heycam: i don't think any content will be relying on seeing a computedStyle of 'visiblePainted'.
# [19:11] <dino> heycam: so it would be ok to return 'auto' for SVG content
# [19:11] <dino> tantek: the style rule was an attempt to address the difference in implementations.
# [19:12] <dino> ed: I think it would be ok to make SVG content have 'auto' as the initial value
# 02[19:12] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [19:13] <tantek> http://wiki.csswg.org/spec/css3-ui#issue-5
# [19:13] <dino> vhardy: If 'auto' is added to CSS3 UI, we'll need to update/add the SVG specification.
# [19:13] <dino> heycam: yes
# [19:14] <dino> ACTION: Cameron to update the SVG specification, adding 'auto' the pointer-events specification.
# 06[19:14] * trackbot noticed an ACTION. Trying to create it.
# 06[19:14] * RRSAgent records action 1
# [19:14] <trackbot> Created ACTION-35 - Update the SVG specification, adding 'auto' the pointer-events specification. [on Cameron McCormack - due 2011-08-02].
# [19:14] <ChrisL> which svg specification is that,Cameron?
# [19:15] <dino> tantek: moving on to issue 5
# [19:15] <heycam> ChrisL, that'd be SVG 2
# 06[19:15] * ChrisL ok
# [19:15] <heycam> ACTION-35: To SVG 2
# 06[19:15] * trackbot attempting to add comment notes to ACTION-35.
# [19:15] <trackbot> ACTION-35 Update the SVG specification, adding 'auto' the pointer-events specification. notes added
# [19:16] <dino> tantek: I believe the style rule I gave above gives the SVG behaviour to non-graphical elements.
# 03[19:16] * Joins: szilles (chatzilla@72.254.90.148)
# [19:17] <dino> discussion about what elements in SVG should get pointer events
# [19:18] <tantek> svg|svg { pointer-events: visiblePainted }
# [19:18] <dino> dbaron: the SVG element doesn't paint anything, then it should be ok to have pointer-events applying to everything
# [19:18] <dino> heycam: also <g>
# [19:18] <dino> heycam: I think it should be auto everywhere
# [19:18] <dino> tantek: SVG doesn't specify 'auto'. we're trying to ship an interoperable spec today.
# [19:20] <dino> vhardy: the property value is saying what is generating events, not where you can place a listener.
# [19:20] <dino> tantek: are SVG ok with accepting this change?
# [19:21] <dino> Some discussion missed by scribe
# [19:21] <ChrisL> wasn't it mentioned earlier thatsome html browsers accept visiblePainted?
# 03[19:22] * Joins: alexmog (alexmog@72.254.92.49)
# [19:22] <ChrisL> if the goal is interop now, that it the most interoperable value
# 06[19:22] * alexmog slaps anne around a bit with a large trout
# [19:23] <dino> heycam: SVG2 will be a while coming. We'll change the value there.
# 06[19:24] * anne wonders if alexmog found that in the lake while swimming
# 06[19:24] * shepazu suspects anne will be swimming with those fishes soon
# [19:24] <dino> 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.
# [19:25] <smfr> http://wiki.csswg.org/spec/css3-ui#issue-6
# [19:25] <dino> tantek: this makes Issue 6 a non-issue now
# [19:25] <dino> sylvaing: Question - is there a restriction on what elements the pointer-events apply to?
# [19:26] <dino> tantek: do you have an example in markup?
# 06[19:26] * alexmog found that spilled out of his phone with a bunch of dead angry birds
# 06[19:26] * shepazu wonders what shoe-size anne has... want to make sure that alexmog gets anne some comfortable concrete overshoes
# [19:26] <dino> sylvaing: we're worried about click hijacking
# [19:27] <dino> heycam: using elementFromPoint
# [19:27] <dino> smfr: This is a valid point to bring up.
# [19:28] <dino> sylvaing: MS is likely to add some restrictions on passing events down to iframes, or whatever.
# [19:29] <dino> tantek: doesn't SVG define this with <foreignObject> ?
# [19:29] <dino> shepazu: spec doesn't say anything
# [19:29] <dino> tantek: what about implementations?
# [19:30] <dino> No one responds to suggest that SVG implementations are doing anything to avoid click jacking at the moment
# 06[19:30] * bradk thinks shepazu means "cement overshoes", and wonders if he watched that episode of star trek. http://www.tvloop.com/star-trek/show/quotes/montgomery-scott-kracko-i-got-rights-scotty-you-90773
# [19:31] <dino> sylvaing: It's likely that we will not propagate an event into an iframe
# [19:32] <dino> tantek: There are two problems: what should implementations do? and now what should the specs say?
# [19:32] <tantek> http://dev.w3.org/csswg/css3-ui/#pointer-events0
# [19:32] <dino> tantek: I think the specification does have enough room to allow implementations to not propagate events across origin if necessary.
# [19:32] <dino> tantek reads current CSS 3 UI spec language
# [19:33] <dino> (can someone paste it in or link?)
# [19:33] <dino> dbaron: i think that's more likely a bug in the spec rather than a loose reading. It should be defined.
# [19:34] <dino> anne: agree. elementFromPoint only returns the iframe.
# [19:34] <dino> ----- break -----
# 02[19:35] * Quits: arronei_ (arronei@72.254.56.67) (Quit: arronei_)
# 02[19:43] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [19:52] <vhardy> ScribeNick: vhardy
# [19:52] <vhardy> ed: Let's continue on the CSS UI issues.
# [19:52] <tantek> http://dev.w3.org/csswg/css3-ui/#pointer-events0
# [19:53] <vhardy> tantek: we were discussing the click jacking scenario with pointer-events: none.
# [19:53] <vhardy> tantek: sylvaing has a demo
# 03[19:54] * Joins: szilles (chatzilla@72.254.90.148)
# [19:54] <vhardy> tantek: 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.
# [19:54] <vhardy> dbaron: you have the same issue with opacity.
# [19:54] <vhardy> dbaron: the better protection is for web site to not allow being framed.
# 06[19:55] * hober sylvaing: skype? (thanks)
# [19:56] <vhardy> 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.
# 02[19:56] * Quits: alexmog (alexmog@72.254.92.49) (Ping timeout)
# [19:57] <vhardy> sylvaing: this is not a new issue, but it should be addressed.
# [19:58] <vhardy> 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.
# [19:58] <vhardy> shepazu: I think the spec. should be more specific.
# [19:58] <vhardy> dbaron: pointer-event's intent is to filter the targets of events and to let the evet target something lower in z order.
# [19:59] <vhardy> shepazu illustrates the purpose of pointer-events: none.
# [19:59] <vhardy> anne: even if we want to be vague for cross origin, we need to be specific for same origin.
# [19:59] <vhardy> tantek: there is a missing reference here to the definition of hit testing.
# [20:00] <vhardy> anne: it should be in the pointer-events specification.
# [20:00] <vhardy> tantek: I do not agree.
# [20:00] <dbaron> http://www.webkit.org/specs/PointerEventsProperty.html
# 06[20:00] * sylvaing seems to have clickjacked the meeting...
# [20:01] <vhardy> tantek: does HTML5 define hit testing?
# [20:01] <vhardy> anne: no
# [20:01] <anne> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
# [20:01] <vhardy> smfr: I thought it was defined.
# [20:01] <shepazu> http://www.w3.org/TR/SVG/intro.html#TermHitTesting
# [20:01] <vhardy> anne: I think we had agreed that the definition of hit testing would be in CSS 3 UI.
# [20:01] <anne> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
# [20:02] <vhardy> tantek: this is just about the property.
# [20:02] <vhardy> tantek: there is nothign about geometry, z-index, etc...
# 03[20:02] * Joins: alexmog (alexmog@72.254.92.49)
# [20:02] <anne> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
# [20:02] <vhardy> anne: the first reference I pasted has a portion that needs to be part of the spec.
# [20:02] <anne> hixie's notes on hit testing ^^
# [20:02] <tantek> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
# [20:03] <vhardy> shepazu: The SVG 1.1 2nd edition has a definition of hit testing, which is new to SVG (was not in previous version).
# 02[20:03] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [20:04] <bradk> No skype... is Sylvain out??
# 06[20:04] * heycam sylvaing ^
# [20:04] <vhardy> anne: this was never in HTML5.
# [20:04] <vhardy> anne: this should be in CSS.
# [20:04] <vhardy> tantek: or DOM Events?
# [20:04] <vhardy> several: CSS.
# [20:04] <vhardy> shepazu: should be in CSS.
# 06[20:05] * sylvaing let me restart the call
# [20:05] <vhardy> tantek: should be split in CSS (geometry and opacity aspects) and then the definition of events should be in DOM Events.
# [20:05] <vhardy> anne: sure.
# [20:06] <vhardy> tantek: this is essentially what Hixie's note is doing.
# 03[20:06] * Joins: szilles (chatzilla@72.254.90.148)
# [20:07] <vhardy> smfr: hit testing is the reverse of painting (order-wise). Where we talk about painting order, we could talk about hit testing.
# 06[20:07] * sylvaing Skype sign-in difficulties...stand by
# [20:07] <vhardy> tantek: Hixie's note talks about painting order too.
# [20:07] <bradk> standing by...
# [20:07] <vhardy> tantek: are you saying that Hixie's note should be integrated in the spec.?
# [20:07] <vhardy> anne: yes.
# [20:08] <vhardy> tantek: hit testing should be defined in CSS, in CSS UI.
# [20:08] <vhardy> anne: pointer-events is just about hit testing.
# [20:09] <vhardy> (discussion about Hixie's proposal and comments that were made).
# 06[20:10] * Ms2ger remembers an opera draft for hit testing
# [20:10] <vhardy> shepazu: also needs to take into account SVG for hit-testing, so that the definition is not just HTML.
# 06[20:10] * ed ms2ger see the link pasted by anne above
# [20:10] <vhardy> dbaron: it is the opposite of z-order, so it should be fairly easy.
# 06[20:10] * Ms2ger ed, thanks, just saw it
# [20:11] <vhardy> tantek: there are only a few exception cases with elements like body, but the rest should apply for SVG.
# [20:11] <vhardy> shepazu: we should coordinate on this.
# [20:12] <vhardy> tantek: z-index and z-order should be in one place and hit testing should reference that.
# [20:12] <vhardy> heycam: there are some SVG specificities that are different from HTML.
# [20:12] <ChrisL> svg has a painting order, which is also relevant 9as z-index is for html/css)
# [20:13] <vhardy> anne: it would be nice if the hit testing algorithm was generic, with possible arguments (like 'stop at the iframe')
# [20:13] <vhardy> shepazu: I think we need to do some more work and re-coordinate on this later.
# [20:13] <ChrisL> s/9as/(as
# [20:13] <smfr> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
# [20:15] <vhardy> 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.
# 06[20:15] * trackbot noticed an ACTION. Trying to create it.
# [20:15] <trackbot> Sorry, couldn't find user - Tantek
# 06[20:15] * RRSAgent records action 2
# [20:15] <tantek> hello
# [20:15] <vhardy> 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.
# 06[20:15] * trackbot noticed an ACTION. Trying to create it.
# 06[20:15] * RRSAgent records action 3
# [20:15] <trackbot> Sorry, couldn't find user - tantek
# [20:15] <ChrisL> trackbot, status
# 06[20:15] * trackbot knows about the following 13 users: Anthony, Cameron, Chris, David, Jonathan, Doug, Elika, Erik, Dean, Robin, Simon, Peter, Daniel
# 06[20:15] * sylvaing Skype server down; will notify here when back up
# [20:15] <vhardy> 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.
# 06[20:16] * ChrisL wishes for a trackbot, add <user> command
# [20:16] <vhardy> 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.
# 06[20:16] * trackbot noticed an ACTION. Trying to create it.
# 06[20:16] * RRSAgent records action 4
# [20:16] <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].
# 02[20:16] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [20:17] <vhardy> tantek: this was the issue of security, partially. What do we need to say about the scenario sylvaing presented.
# [20:17] <vhardy> 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.
# [20:18] <vhardy> tantek: the alternate proposal is to make a note that sites that do not want to have this happen should not allow being framed.
# [20:18] <vhardy> dbaron: we should also talk to some people in the web security field.
# [20:18] <vhardy> dbaron: some people at Mozilla would know about this.
# [20:19] <vhardy> 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.
# 06[20:19] * RRSAgent records action 5
# 06[20:19] * trackbot noticed an ACTION. Trying to create it.
# [20:19] <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].
# 02[20:20] * Quits: sylvaing (sylvaing@72.254.56.201) (Quit: sylvaing)
# [20:20] <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.
# 06[20:20] * RRSAgent records action 6
# 06[20:20] * trackbot noticed an ACTION. Trying to create it.
# [20:20] <trackbot> Sorry, couldn't find user - dbaron
# [20:20] <vhardy> ed: is there anything more that we need to discuss here?
# [20:20] <vhardy> shepazu: want to talk about transparency.
# [20:20] <vhardy> shepazu: proposal for alpha-levels.
# [20:20] <vhardy> shepazu: this came up from Zynga.
# [20:20] <dbaron> trackbot, is user david David Baron or some other David?
# [20:20] <trackbot> Sorry, dbaron, I don't understand 'trackbot, is user david David Baron or some other David?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
# [20:21] <ChrisL> action-1?
# 06[20:21] * trackbot getting information on ACTION-1
# [20:21] <trackbot> ACTION-1 -- Doug Schepers to create an FX repository -- due 2010-03-18 -- CLOSED
# [20:21] <trackbot> http://www.w3.org/Graphics/fx/track/actions/1
# [20:21] <vhardy> 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.
# [20:22] <ChrisL> users list at http://www.w3.org/Graphics/fx/track/users
# [20:22] <ChrisL> david id david dinger
# [20:22] <vhardy> shepazu: they would like to say that if a pixel has a certain level of transparency, then the hist testing is not positive.
# [20:22] <ChrisL> s/dinger/singer/
# [20:22] <vhardy> shepazu: if opacity is less than x, then pass the even through
# [20:22] <vhardy> tantek: do they want the hit testing mask?
# [20:22] <vhardy> shepazu: they do not want to do their own hit testing.
# [20:23] <vhardy> tantek: there are cases where there is a hole and you still want to hit positive for the hole.
# [20:23] <vhardy> smfr: I have not heard Zynga asking for a separate image.
# [20:24] <vhardy> tantek: where the opacity may address some of the use cases, it seems that a separate mask would cover more use cases.
# 02[20:24] * Quits: birtles (chatzilla@72.254.87.44) (Quit: ChatZilla 0.9.87-rdmsoft [XULRunner 1.9.0.17/2009122204])
# [20:24] <vhardy> vhardy: and the image's opacity could be the default mask.
# [20:24] <vhardy> tantek: yes.
# 03[20:24] * Joins: birtles (chatzilla@72.254.87.44)
# [20:24] <vhardy> shepazu: this also solves some issues for SVG.
# [20:25] <vhardy> shepazu: this is an issue we need to look into.
# [20:25] <vhardy> smfr: it is not obvious that this needs to go into pointer-events.
# [20:25] <vhardy> shepazu: right.
# [20:25] <vhardy> shepazu: Paul Bakaus for Zynga mentioned he would rather not maitain two images.
# [20:26] <vhardy> smfr: I think the threshold for pointer-events is simple enough that we could put it into pointer-events.
# [20:26] <vhardy> .. a separate image is more complex and should be separate.
# [20:27] <vhardy> 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.
# [20:27] <tantek> Hixie's notes http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html refer to full transparency as allowing events to pass through
# [20:27] <vhardy> tantek: currently, in Hixie's proposal, onlyt 100% translucent pixels let the event go through.
# [20:27] <vhardy> We are talking about adding a threshold instead.
# [20:28] <tantek> so we're talking about increasing that threshold from opacity:0 to opacity:x where 0≤x≤1
# 03[20:28] * Joins: sylvaing (sylvaing@72.254.56.201)
# [20:28] <vhardy> dino: sometimes, you want the hit testing area to be larger than the element itself.
# 06[20:28] * sylvaing Skype connection is back on; call sgalineau
# [20:29] <vhardy> 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.
# [20:29] <vhardy> shepazu: Alex Danilo said this is too difficult to implement because you might have to get the graphics back from the GPU.
# [20:30] <vhardy> szilles: so you may have to precompute things.
# [20:30] <vhardy> tantek: the mask solves that problem.
# [20:30] <heycam> vhardy: having a mask, isn't that equivalent to just having the texture around?
# [20:30] <heycam> vhardy: if you're keeping some data for hit testing, that's the same as keeping on the gpu and in memory
# [20:31] <heycam> smfr: i think it might be expensive at run time
# [20:31] <heycam> smfr: doable, but it may be slow
# 03[20:31] * Joins: szilles (chatzilla@72.254.90.148)
# [20:31] <vhardy> tantek: if you go back to Paul's usecase, he is keeping his own mask in JS.
# [20:31] <vhardy> tantek: that means the shapes are their masks.
# [20:31] <shepazu> Alex's critique: http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html
# [20:32] <vhardy> tantek: so they have implemented masks as a work around. We could provide masks to resolve their issue.
# [20:33] <shepazu> Paul,'s email http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html
# [20:33] <vhardy> ed: the email does not hint at their implementation method.
# [20:34] <vhardy> shepazu: quoting the email..
# [20:34] <ed> s/ed:/heycam:/
# [20:35] <vhardy> heycam: it seems to be a good shorthand.
# [20:35] <vhardy> tantek: if doing things in canvas and JS works, then shouldn't it be feasible in implementations?
# [20:35] <vhardy> tab/shepazu: the point Alex Danillo made is valid.
# [20:36] <ChrisL> there are some video codecs on gpu like for mpeg etc. those might be usablefor jpeg decoding
# [20:37] <ChrisL> but in general the bandwidth of he back channel from gpu to cpu is not very good
# [20:37] <vhardy> 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.
# [20:38] <vhardy> tab: box shadows do not impact hit testing.
# [20:38] <vhardy> tab: round-borders affect hit testing.
# 06[20:38] * Zakim excuses himself; his presence no longer seems to be needed
# 03[20:38] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [20:38] <vhardy> tab: border-image does not affect hit testing.
# [20:39] <ChrisL> bordser is a classic case for needing more values like visibleBorder for hit testing
# [20:39] <vhardy> tab: I would be ok to say that things may slow down if you do hit testing on a filtered image, for example.
# [20:40] <vhardy> discussion on various filter effects that may affect hit testing.
# [20:41] <vhardy> 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.
# [20:41] <vhardy> tantek: we are talking about CSS UI 4 right?
# [20:41] <vhardy> several: yes.
# [20:42] <vhardy> shepazu: I think the threshold is enough for most cases.
# [20:43] <vhardy> smfr: the GPU efficiency is an issue to consider.
# [20:43] <vhardy> tantek: I would like to add this to CSS UI 4.
# 06[20:45] * heycam marvels at the quality of the skype speaker thingo
# [20:45] <dino> ACTION: Dean to draft a proposal for specifying hit testing regions or masks for CSS 4 UI
# 06[20:45] * RRSAgent records action 7
# 06[20:45] * trackbot noticed an ACTION. Trying to create it.
# [20:45] <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].
# [20:46] <vhardy> ACTION: tantek to specify how opacity:0 impact hit testing.
# 06[20:46] * RRSAgent records action 8
# 06[20:46] * trackbot noticed an ACTION. Trying to create it.
# [20:46] <trackbot> Sorry, couldn't find user - tantek
# 02[20:46] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [20:47] <bradk> opacity:0.001 should not be different from opacity:0 WRT hit testing
# [20:47] <tantek> Issue 9: http://wiki.csswg.org/spec/css3-ui#issue-9
# [20:47] <smfr> bradk: opacity already has discontinuitues: 0.9999 creates stacking context, 1 does not
# [20:47] <ChrisL> bradk, hit testing is like pregnancy. it is on/off not a sliding scale
# [20:48] <vhardy> ACTION: Doug to propose that opacity of a pixel does not affect its pointer-event behavior for CSS 3 UI.
# 06[20:48] * RRSAgent records action 9
# 06[20:48] * trackbot noticed an ACTION. Trying to create it.
# [20:48] <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].
# 03[20:48] * Joins: szilles (chatzilla@72.254.90.148)
# [20:48] <vhardy> ACTION-39: http://wiki.csswg.org/spec/css3-ui#issue-9
# 06[20:48] * trackbot attempting to add comment notes to ACTION-39.
# [20:48] <trackbot> ACTION-39 Propose that opacity of a pixel does not affect its pointer-event behavior for CSS 3 UI. notes added
# [20:48] <shepazu> action: shepazu to write up proposal for opacity threshold for pointer-events for CSS 4 UI
# 06[20:48] * RRSAgent records action 10
# 06[20:48] * trackbot noticed an ACTION. Trying to create it.
# [20:48] <trackbot> Created ACTION-40 - Write up proposal for opacity threshold for pointer-events for CSS 4 UI [on Doug Schepers - due 2011-08-02].
# [20:49] <vhardy> tantek: http://wiki.csswg.org/spec/css3-ui#issue-10
# [20:49] <vhardy> tantek: I think we are ducking this.
# [20:49] <vhardy> ed: the issue was for SVG.
# [20:50] <vhardy> (discussion on filter effects and masks applying to HTML in SVG, through foreignObject)
# [20:50] <vhardy> heycam: we would need to say that the mask actually impact hit testing.
# [20:51] <vhardy> heycam: and clip-path as well.
# [20:51] <vhardy> vhardy: this should go into the hit testing section.
# [20:51] <ed> s/issue was for SVG./issue was mostly for SVG. /
# 06[20:52] * ChrisL the discussion is getting hard to hear
# [20:53] <tantek> https://developer.mozilla.org/en/CSS/clip-path
# [20:53] <tantek> https://developer.mozilla.org/en/CSS/mask
# [20:53] <vhardy> ACTION: Doug to propose wording for CSS 3 UI about how masks and clip-paths impact hit-testing.
# 06[20:53] * trackbot noticed an ACTION. Trying to create it.
# 06[20:53] * RRSAgent records action 11
# [20:53] <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].
# [20:54] <tantek> https://developer.mozilla.org/en/CSS/-webkit-mask-box-image
# [20:54] <shepazu> http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
# [20:54] <birtles> https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_content
# [20:54] <vhardy> tantek: we need a definition of these properties in a CSS spec.
# [20:54] <vhardy> ed; we could put clipping and masking in the same spec.
# [20:55] <ed> s/same spec/FXTF filter spec/
# [20:56] <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
# 06[20:56] * Ms2ger wonders why that doc links to a 2008 HTML5 draft
# [20:58] <vhardy> ACTION: ed to move clip-path and masks to the FX Filter specification draft.
# 06[20:58] * RRSAgent records action 12
# 06[20:58] * trackbot noticed an ACTION. Trying to create it.
# [20:58] <trackbot> Created ACTION-42 - Move clip-path and masks to the FX Filter specification draft. [on Erik Dahlström - due 2011-08-02].
# 06[20:58] * ed ms2ger references will need to be updated there yes
# [20:59] <vhardy> tantek: I have no more issue on CSS 3 UI that requires CSS/SVG coordination. I have gone through the issues I had.
# [20:59] <vhardy> ed: Next topic: filter effects.
# [20:59] <dino> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
# [20:59] <vhardy> dino: we have a lot of issues.
# [21:00] <vhardy> dino: first issue is to come up with a name other than SVG filters.
# [21:00] <vhardy> dino: there are pure css filters and then markup filters.
# [21:00] <ed> Topic: filter effects
# [21:00] <vhardy> chris: advanced filers? markup filters?
# [21:01] <vhardy> dino: the whole spec. is CSS, there is a part that uses markup for advanced filters.
# [21:01] <vhardy> (discussion on 'advanced filters' v.s. 'markup filters'
# [21:01] <vhardy> s/filters'/filters')
# [21:02] <vhardy> shepazu: I think markup filters is better
# [21:02] <vhardy> smfr: declarative filters?
# [21:02] <ChrisL> the filters previously known as SVG
# [21:02] <ChrisL> custom filters
# [21:02] <vhardy> dino: shorthand syntax and long-hand syntax?
# [21:02] <vhardy> tantek: is this a CSS module?
# [21:03] <ChrisL> its a jointly developed module
# [21:03] <vhardy> dino: not currently. But it should be?
# [21:03] <vhardy> dino: it should just be "Filters"
# [21:03] <vhardy> tantek: I think we should call them 'CSS 3 Filters'
# [21:03] <vhardy> fantasai: "CSS Filters"
# [21:03] <ChrisL> can we please drop the 'levels' stuff
# [21:04] <vhardy> shepazu: the spec. defines markup for filters.
# [21:04] <vhardy> fantasai: we should call them "W3C filters"
# [21:04] <vhardy> chrisL: agreed.
# [21:04] <Ms2ger> HTML5 Filters?
# [21:05] <vhardy> shepazu: markup filters is the most descriptive.
# 06[21:06] * shepazu @Ms2ger, that joke already did the rounds
# [21:06] <fantasai> XFilters :)
# 06[21:06] * fantasai shepazu, Ms2ger was first
# 06[21:07] * shepazu sits corrected
# 06[21:07] * Ms2ger is finally first at something!
# [21:07] <ChrisL> people are gradually being used to pointing to other media from css. images, svg, etc
# [21:08] <vhardy> dino: the options we have heard:
# [21:08] <vhardy> ... element based filters
# [21:08] <vhardy> ... shorhand/longhand filters
# [21:08] <vhardy> ... markup filters
# [21:08] <vhardy> ... XML Filters
# [21:08] <ChrisL> w3c filters
# [21:08] <vhardy> ... W3C Filters
# [21:08] <vhardy> ... XFilters
# 06[21:09] * glazou lunch is ready in the restaurant, when we want...
# [21:09] <ChrisL> shorthand has an existing meaning in css,be careful to avoid confusion there
# [21:09] <ChrisL> extesible filters
# [21:09] <ChrisL> custom filters
# [21:09] <ed> canned filters
# [21:09] <vhardy> ACTION: Dino to make a naming proposal to distinguish between CSS and markup filters.
# 06[21:09] * trackbot noticed an ACTION. Trying to create it.
# [21:09] <trackbot> Sorry, couldn't find user - Dino
# 06[21:09] * RRSAgent records action 13
# [21:10] <vhardy> ACTION: dean to make a naming proposal to distinguish between CSS and markup filters.
# 06[21:10] * trackbot noticed an ACTION. Trying to create it.
# 06[21:10] * RRSAgent records action 14
# [21:10] <trackbot> Created ACTION-43 - Make a naming proposal to distinguish between CSS and markup filters. [on Dean Jackson - due 2011-08-02].
# [21:10] <tantek> ACTION: RRSAgent - learn how to reference people by URL not just alias.
# 06[21:10] * trackbot noticed an ACTION. Trying to create it.
# [21:10] <trackbot> Sorry, couldn't find user - RRSAgent
# 06[21:10] * RRSAgent records action 15
# [21:10] <ChrisL> I actually asked on sysreq about adding people to fx tracker , but no response
# [21:10] <tantek> ACTION: trackbot - learn how to reference people by URL not just alias.
# 06[21:10] * trackbot noticed an ACTION. Trying to create it.
# 06[21:10] * RRSAgent records action 16
# [21:10] <trackbot> Sorry, couldn't find user - trackbot
# 02[21:10] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [21:10] <vhardy> dino: next issue is to have a custom filter using a particular language.
# [21:10] <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
# [21:11] <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#feCustomElement
# 03[21:12] * Joins: szilles (chatzilla@72.254.90.148)
# [21:12] <vhardy> patrickdengler: there are lots of issues with custom filters (security). In IE, we did not see any use of the custom filters we provided.
# [21:12] <vhardy> dino: what are the pros and cons?
# [21:12] <vhardy> .. cons: security, not used often.
# [21:13] <vhardy> ... Adobe has a public repository of pixel bender filters and there are 20+ filters there.
# [21:13] <vhardy> ... pros: it is great for us as spec. developers because we do not have to define every effect.
# [21:13] <vhardy> ... cons: we need to define a filter.
# [21:14] <tantek> ed - is there a URL for today's agenda? I added the CSS3-UI coordination to here: http://wiki.csswg.org/planning/seattle-2011#tuesday but don't see any other items (nor links to agendas in other locations)
# [21:14] <vhardy> dino: sometimes, people also want to protect their shader code.
# [21:14] <ed> patrick: inkscape has hundreds of defined filter effects that only use the existing svg filter functionality
# [21:14] <tantek> ed - nm. thanks to smfr for http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
# [21:15] <ChrisL> orcuda
# [21:15] <vhardy> 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.
# [21:15] <vhardy> dino: seems like there is a lot of cons.
# [21:15] <smfr> ChrisL: or CUDA?
# [21:17] <vhardy> vhardy: i think there are very nice effects that would could have with custom fitlers. We can come back later with more arguments.
# [21:17] <vhardy> chrisl: if there was a DOM interface for custom filters, that may be easier.
# 02[21:18] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [21:18] <vhardy> dino: one use case where Apple uses a custom filter is for video output to TV, or custom color correction.
# [21:19] <vhardy> heycam: if we had custom filters, what if you do not have hardware accel.
# [21:19] <vhardy> vhardy: then there is a sw path.
# 03[21:19] * Joins: szilles (chatzilla@72.254.90.148)
# [21:19] <vhardy> ACTION: vhardy to come back with more arguments on custom filters and make a proposal.
# 06[21:19] * trackbot noticed an ACTION. Trying to create it.
# [21:19] <trackbot> Sorry, couldn't find user - vhardy
# 06[21:19] * RRSAgent records action 17
# [21:19] <heycam> trackbot, status?
# 06[21:19] * trackbot knows about the following 13 users: Anthony, Cameron, Chris, David, Jonathan, Doug, Elika, Erik, Dean, Robin, Simon, Peter, Daniel
# [21:20] <vhardy> ACTION: vincent to come back with more arguments on custom filters and make a proposal.
# 06[21:20] * trackbot noticed an ACTION. Trying to create it.
# [21:20] <trackbot> Sorry, couldn't find user - vincent
# 06[21:20] * RRSAgent records action 18
# [21:20] <vhardy> dino: next is pointer-events on filter regions.
# [21:21] <ed> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
# [21:23] <vhardy> ed: we found that having filters impact hit testing is costly.
# [21:23] <vhardy> smfr: and there are cases like blur where the hit becomes an area.
# [21:24] <vhardy> dino: is that like shadows? Or should we deal with it with masking as well?
# 02[21:24] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [21:25] <heycam> vhardy: in svg if oyu have text on a path, with hit testing and text selection, that kind of "distortion" works
# [21:25] <heycam> vhardy: it doesn't if you go through a filter pipeline, pixels gets shifted around
# [21:25] <heycam> ... you're still operating on the original geometry you had
# [21:26] <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
# [21:26] <heycam> fantasai: how would you determine that for a blur?
# [21:26] <heycam> dino: there are multiple pixels
# [21:26] <heycam> vhardy: it's not a 1-to-1 mapping
# 03[21:26] * Joins: arron (Arron@24.17.123.244)
# [21:26] <heycam> ChrisL: if you have a filter that displaces things, or if the visual result is quite different from the original, ...
# [21:26] <heycam> fantasai: why not use transforms for shifting content?
# [21:27] <heycam> vhardy: with filters you could use your source multiple times
# [21:27] <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
# [21:27] <heycam> dino: the text might be in a different spot
# [21:27] <heycam> vhardy: if you use SourceGraphic and feOffset, you could have a rectangle and make it a grid of four rectangles
# [21:27] <heycam> ... and that's the visual rendering
# [21:27] <heycam> ... in that case, it would be most natural to say if you click anything in there it hits positive
# [21:28] <heycam> fantasai: if you want to multiply images, then that 's different from just mirroring
# [21:28] <heycam> ... nobody expects to click on a reflection of an icon and have that hit test
# [21:28] <ChrisL> trackbot, status
# 06[21:28] * trackbot knows about the following 13 users: Anthony, Cameron, Chris, David, Jonathan, Doug, Elika, Erik, Dean, Robin, Simon, Peter, Daniel
# [21:28] <heycam> ... if you want something that's actually solid, there should be some other way of doing it that affects layout
# [21:28] <heycam> shepazu: you should use a mask in this case
# [21:28] <heycam> ... nobody's asked for this either
# [21:28] <heycam> fantasai: I think we haven't seen convincing use cases
# [21:29] <ChrisL> trackbot, init
# [21:29] <heycam> dino: if we have the mask image proposal, you would point to the filter image as the mask
# [21:29] <heycam> vhardy: I think that covers most of what we need
# [21:29] <heycam> ... but I think still conceptually this is an important issue
# [21:29] <heycam> ed: raise an issue for this?
# [21:29] <ChrisL> trackbot, status
# 06[21:29] * trackbot knows about the following 13 users: Anthony, Cameron, Chris, David, Jonathan, Doug, Elika, Erik, Dean, Robin, Simon, Peter, Daniel
# [21:30] <vhardy> dino: next one is enable-background.
# [21:31] <ChrisL> tracker, init
# [21:31] <ChrisL> trackbot, status
# 06[21:31] * trackbot knows about the following 13 users: Anthony, Cameron, Chris, David, Jonathan, Doug, Elika, Erik, Dean, Robin, Simon, Peter, Daniel
# [21:31] <vhardy> dino: there is a general proposal to deprecate it.
# [21:32] <ChrisL> trackbot, reload
# [21:32] <vhardy> proposal at: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
# [21:32] <ed> I raised ISSUE-5 for the hit-testing
# [21:32] <ChrisL> tracker, init
# [21:32] <ed> http://www.w3.org/Graphics/fx/track/issues/5
# [21:32] <ChrisL> tracker, init
# [21:33] <Ms2ger> trackbot, init
# [21:33] <ChrisL> trackbot, status
# [21:33] <vhardy> cabanier: enable-background is defined for SVG and not for HTML. We need to define what that does for CSS/HTML.
# [21:33] <ChrisL> adobe used to implement it
# [21:34] <vhardy> dino: who implements enable-background.
# 06[21:34] * trackbot knows about the following 20 users: Steve, Sylvain, Anthony, Tab, Cameron, Dean, Chris, David, Jonathan, Robin, Vincent, Doug, Elika, Erik, Simon, David, Tantek, Peter, Daniel, Brad
# [21:34] <ChrisL> but it seems under-implemented in current svg implementations
# [21:34] <vhardy> Opera, Batik, Illustrator, Inkscape?
# [21:34] <ChrisL> it would be good if adobe illustrator stopped writing it needlessly on svg exports
# [21:35] <vhardy> ed: lunch break.
# 02[21:35] * Quits: glazou (glazou@72.254.57.180) (Quit: glazou)
# 02[21:35] * Quits: stearns__ (anonymous@72.254.63.25) (Quit: stearns__)
# 06[21:35] * ChrisL will call back after lunch
# [21:35] <dbaron> lunch-break-after: always
# 02[21:37] * Quits: tantek (tantek@72.254.91.192) (Quit: tantek)
# 03[21:37] * Joins: ted (ted@128.30.52.169)
# [21:37] <ChrisL> trackbot, status
# 06[21:37] * trackbot knows about the following 20 users: Steve, Sylvain, Anthony, Tab, Cameron, Dean, Chris, David, Jonathan, Robin, Vincent, Doug, Elika, Erik, Simon, David, Tantek, Peter, Daniel, Brad
# 02[21:37] * Quits: smfr (smfr@72.254.63.223) (Quit: smfr)
# [21:37] <ChrisL> yay
# 02[21:37] * Quits: patrickdengler (pdengler@72.254.92.227) (Ping timeout)
# 03[21:37] * Parts: ted (ted@128.30.52.169) (cya)
# 02[21:38] * Quits: birtles (chatzilla@72.254.87.44) (Ping timeout)
# 02[21:38] * Quits: nimbu (Adium@72.254.63.50) (Client exited)
# 02[21:38] * Quits: florian (florianr@72.254.59.60) (Ping timeout)
# 02[21:39] * Quits: TabAtkins_ (tabatkins@72.254.90.143) (Ping timeout)
# 03[21:39] * Joins: tpod (tpod@72.254.63.33)
# 02[21:42] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
# 03[21:46] * Joins: tpod_ (tpod@66.87.7.154)
# 02[21:46] * Quits: tpod (tpod@72.254.63.33) (Ping timeout)
# 03[21:46] * tpod_ is now known as tpod
# 03[22:01] * Joins: Strengths (chroot@150.101.115.231)
# 02[22:07] * Quits: anne (annevk@72.254.83.34) (Ping timeout)
# 03[22:14] * Joins: patrickdengler (pdengler@72.254.92.227)
# 03[22:15] * Joins: stearns (anonymous@72.254.63.25)
# 02[22:16] * Quits: patrickdengler (pdengler@72.254.92.227) (Quit: Leaving)
# 03[22:17] * Joins: pdengler (pdengler@72.254.92.227)
# 02[22:19] * Quits: vhardy (vhardy@72.254.89.196) (Ping timeout)
# 02[22:31] * Quits: tpod (tpod@66.87.7.154) (Quit: Colloquy for iPod touch - http://colloquy.mobi)
# 03[22:37] * Joins: birtles (chatzilla@72.254.87.44)
# 02[22:38] * Quits: alexmog (alexmog@72.254.92.49) (Ping timeout)
# 02[22:39] * Quits: Ms2ger (Ms2ger@91.181.57.248) (Quit: nn)
# 03[22:39] * Joins: szilles (chatzilla@72.254.90.148)
# 03[22:39] * Joins: nimbupani (Adium@72.254.63.50)
# 03[22:39] * Joins: anne (annevk@72.254.83.34)
# 03[22:39] * Joins: tantek (tantek@66.87.7.154)
# 03[22:40] * nimbupani is now known as nimbu
# [22:40] <dbaron> ScribeNick: nimbupani
# [22:40] <dbaron> ScribeNick: nimbu
# 03[22:40] * Joins: florian (florianr@72.254.59.60)
# [22:40] <nimbu> ed: we can do svg composting first and continue with filters
# [22:41] <ed> http://www.w3.org/TR/SVGCompositing/
# [22:41] <nimbu> cabanier: there is a need for adobe to specify the blending into the css.
# 03[22:41] * Joins: vhardy (vhardy@72.254.89.196)
# 03[22:42] * Joins: smfr (smfr@72.254.59.80)
# [22:42] <nimbu> cabanier: 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
# [22:42] <nimbu> cabanier: the enable-backgrounds is necessary for compositing.
# 03[22:42] * Joins: TabAtkins_ (tabatkins@72.254.58.122)
# [22:42] <nimbu> heycam: are we asking first if people are in favour of compositing for css at all?
# [22:43] <nimbu> cabanier: there was a discussing in mailing list where people did not see the point of it. smfr
# 02[22:43] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# [22:43] <nimbu> cabanier: since we need it for filters anyway maybe its not a big deal
# [22:43] <nimbu> smfr: webkit has a webkit property which lets you set compositing mode for an image
# [22:43] <nimbu> heycam: can u do all compositing modes with existing svg filter primitives
# [22:44] <nimbu> cabanier: i believe you can.
# [22:44] <nimbu> cabanier: difficult as u need to do compositing urself.
# [22:44] <nimbu> vhardy: svg compositing spec is more complete.
# [22:45] <nimbu> vhardy: 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?
# [22:45] <nimbu> heycam: if you have already implemented for svg it wont be much work to extend it
# [22:45] <nimbu> cabanier: do u mean spec or implementation?
# [22:45] <nimbu> heycam: implementation
# 03[22:46] * Joins: ChrisL (ChrisL@128.30.52.169)
# 06[22:46] * nimbu [alexmog just presented anne with a "slut" t-shirt]
# 06[22:47] * stearns that's the "South Lake Union Trolley"
# 06[22:47] * nimbu clearly
# [22:47] <nimbu> dbaron: how good is enable background is for authors to understand whats going on
# [22:47] <nimbu> dbaron: whats the deal with x, y params in that?
# 06[22:47] * ChrisL pics or it didn't happen
# 03[22:47] * Joins: alexmog (alexmog@72.254.92.49)
# 03[22:47] * Joins: glazou (glazou@72.254.60.179)
# [22:47] <nimbu> cabanier: those will go away. it is more confusing
# [22:48] <nimbu> dbaron: with filters, the defaults meant things were meant to be clipped out.
# [22:48] <nimbu> smfr: enable-bg is like opacity.
# [22:48] <nimbu> cabanier: enable bg just generates stacking context.
# [22:49] <nimbu> cabanier: 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
# [22:49] <nimbu> cabanier: i agree the keyword is pretty confusing
# [22:49] <nimbu> TabAtkins: i only understand it coz i have looked at it enough times
# [22:50] <nimbu> TabAtkins: the svg compositing def
# [22:50] <nimbu> szilles is your point editorial improvements will be appreciated dbaron
# [22:50] <nimbu> dbaron: in compositing it sez new buffers are established for both of them. which seems wrong
# [22:51] <nimbu> cabanier: that confusion comes from ported …
# [22:51] <nimbu> cabanier: lets stick with regular blending modes
# [22:51] <nimbu> dbaron: i am not sure i follow but i dont know if thats worth it
# [22:51] <nimbu> ed: do we want to have this for css or html?
# [22:51] <dbaron> s/thats worth it/it's worth explaining to me/
# [22:51] <ChrisL> s/ported/Porter-Duff/
# [22:52] <nimbu> vhardy: in the rendering model perspective, i dont see any harm done by making this generic
# [22:52] <nimbu> anne: shouldnt all these things be generic
# [22:53] <nimbu> cabanier: maybe we can get a better name if we put this in css
# [22:53] <nimbu> anne: has anyone looked at how similar it is to canvas composite feature
# [22:53] <nimbu> cabanier: canvas has porter-duff this is slightly different
# [22:54] <nimbu> cabanier: we had a discussion on splitting it into porter-duff & blending modes. porter-duff is hard to specify.
# [22:54] <nimbu> heycam: blend modes dont need u to keep it off on a separate buffer like enable bg?
# [22:54] <nimbu> cabanier: they do.
# [22:54] <ChrisL> why is porter-duff hard to specify?
# [22:54] <nimbu> heycam: what ist he complexity for porter-duff
# [22:54] <nimbu> anne: why is it "easy" for canvas but not for svg?
# [22:55] <nimbu> vhardy: in svg or html u have multiple nodes and u need to define which to accumulate and what level.
# [22:55] <nimbu> anne: and i guess u have to constantly run it if you change the underlying mode
# [22:55] <nimbu> cabanier: canvas does not know about stacking context.
# [22:55] <nimbu> vhardy: its also one drawing operation at a time
# [22:55] <nimbu> vhardy: in tree model you can have whole trees or groups.
# [22:55] <nimbu> cabanier: thats what enable bg does
# [22:56] <nimbu> dbaron: is porter-duff trying to do smthing in cases other than where u have stacking context?
# [22:56] <smfr> url?
# [22:57] <nimbu> dbaron: there are elements that are outside subtree and interleave with htem
# [22:57] <ChrisL> dbaron,svg tries to avoid that interleave so we don't use the stacking conext
# [22:57] <nimbu> shepazu: i dont understand what you mean by interleaving
# [22:57] <ChrisL> shepazu, interleaved in z-order. in other words, not the painters algorithm used in svg
# [22:58] <nimbu> 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
# [22:58] <nimbu> dbaron: css does not even define things in terms of drawing operations
# [22:58] <nimbu> heycam: isnt there an appendix that sez paint the bg paint the border?
# [22:59] <ChrisL> css defines the order of drawing border, background, and text
# [22:59] <nimbu> dbaron: i am not sure if it was going to be interpreted that way.
# [22:59] <nimbu> cabanier: u create two buffers the top one with desta top(?)
# [22:59] <nimbu> dbaron: in css that sort of thing only makes sense in stacking context
# [22:59] <ChrisL> s/desta top/dest atop/
# [22:59] <nimbu> cabanier: enable background adds another stacking context.
# [23:00] <nimbu> dbaron: if the stuff in here needs to apply to css it needs to say more about stacking contexts
# [23:00] <nimbu> dbaron: the comp-op property has initial value that sorts over.
# [23:00] <heycam> s/desta top(?)/dest-atop/
# [23:00] <dino> is this the latest spec? http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
# [23:01] <anne> http://www.w3.org/TR/SVGCompositing/
# [23:01] <anne> oh
# [23:01] <nimbu> ChrisL: u would still need stacking context in css and html. there is opacity or smthing that generates new stacking context
# [23:01] <nimbu> vhardy: are u saying comp-op wont trigger new stacking context?
# 06[23:01] * heycam the TR copy is newer than the one on dev.w3.org? :)
# [23:01] <ed> dino: yes, that's the editor's draft version, http://dev.w3.org/SVG/modules/compositing/publish/SVGCompositing.html
# [23:02] <nimbu> ChrisL: it wont, even if it did the initial value would be smthing different.
# [23:02] <nimbu> vhardy: should we make this work for html, css?
# 06[23:02] * ChrisL heycam maybe the newest copy is in hg repo not the dev.w3.org cvs repo
# [23:02] <anne> ed, that's a 404
# [23:02] <ed> http://dev.w3.org/SVG/modules/compositing/publish/
# [23:02] <ed> that one works
# 03[23:02] * Joins: szilles (chatzilla@72.254.90.148)
# [23:02] <nimbu> cabanier: thebig drawback was we didnt want to blend two images together, but if we are doing with filters anyway the drawback goes away.
# [23:03] <anne> ed, should update that to say editor's draft...
# [23:03] <nimbu> ChrisL: it would be helpful if we have one for each host language, and say more clearly what happens.
# 06[23:04] * anne wonders if shepazu and ChrisL trolled the WG there
# 06[23:04] * ChrisL yeah a bit
# [23:05] <nimbu> 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.
# 06[23:05] * trackbot noticed an ACTION. Trying to create it.
# [23:05] <trackbot> Sorry, couldn't find user - cabanier
# 06[23:05] * RRSAgent records action 19
# 06[23:05] * ChrisL for more details, see this video http://www.youtube.com/RickRoll.mov
# [23:05] <nimbu> shepazu: add cabanier to this list :P
# 02[23:05] * Quits: szilles (chatzilla@72.254.90.148) (Ping timeout)
# 06[23:06] * anne ChrisL, dude 404, no fun
# [23:06] <nimbu> dino: so u dont want to remove enable background.
# [23:06] <nimbu> cabanier: no only the x, y.
# 06[23:06] * heycam RikRoll.flv
# 06[23:06] * dbaron trackbot, users?
# 06[23:06] * anne oh wow, YouTube took the original rick roll offline http://www.youtube.com/watch?v=oHg5SJYRHA0
# 06[23:06] * dbaron trackbot, status?
# [23:07] <ChrisL> trackbot, status
# 06[23:07] * trackbot knows about the following 20 users: Steve, Sylvain, Anthony, Tab, Cameron, Dean, Chris, David, Jonathan, Robin, Vincent, Doug, Elika, Erik, Simon, David, Tantek, Peter, Daniel, Brad
# 06[23:08] * hober is surprised to see I'm not in this list: http://www.w3.org/Graphics/fx/track/users
# 02[23:08] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
# 06[23:08] * ChrisL apologieses to chair for derailing technical discussion
# 06[23:08] * ChrisL hober I will add you
# [23:08] <dbaron> https://www.w3.org/2005/06/tracker/users/my
# 06[23:08] * ed thinks it helps if the bots just worked as they should ;)
# [23:09] <nimbu> ChrisL: pls add cabanier too :P
# 06[23:09] * shepazu added hober
# 06[23:09] * hober thanks shepazu
# 06[23:10] * tantek realizes he has yet another web identity he didn't know about :/ http://www.w3.org/Graphics/fx/track/users/1464
# 06[23:10] * ChrisL rick does not exist, apparently
# 06[23:10] * shepazu ChrisL, he is in SVG WG http://www.w3.org/2000/09/dbwg/details?group=19480&public=1&gs=1&order=org
# [23:11] <nimbu> 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.
# 06[23:11] * trackbot noticed an ACTION. Trying to create it.
# 06[23:11] * RRSAgent records action 20
# [23:11] <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].
# 06[23:11] * shepazu wonders if that FX member list was a snapshot, or what?
# [23:11] <nimbu> dino: proposal from tab for a new image generator
# [23:11] <ed> topic: filter effects (continued)
# [23:11] <nimbu> dino: any image generator, stream of filter property
# [23:12] <nimbu> dino: does anyone disagree?
# [23:12] <nimbu> dino: TabAtkins and i agree its a good idea
# [23:12] <nimbu> dbaron: is this an extension to image vals
# [23:12] <nimbu> TabAtkins: will just be in there but will be a new image type
# [23:13] <nimbu> ChrisL: we need to find a separate way to bring it in.
# [23:13] <nimbu> dino: this is the separate way. if u want to just filter the border.
# [23:13] <nimbu> smfr: if u use border-image you will get sharp edges
# [23:13] <nimbu> smfr: Chris suggests we get blur after we slice and stretch
# [23:13] <nimbu> TabAtkins: @ santaclara tpac brad was talking about pulling sections of elements instead of entire element as filter input.
# [23:14] <nimbu> dbaron: i think we need new filter input primitives for css stuff
# [23:14] <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)
# [23:14] <nimbu> smfr: the border-image should be solved this other way.
# [23:14] <nimbu> dino: other places can use this.
# [23:14] <nimbu> dbaron: i can see using multi bg and wanting to filter one of em
# [23:15] <nimbu> ACTION: dino update the filter spec to produce the new image type.
# 06[23:15] * RRSAgent records action 21
# 06[23:15] * trackbot noticed an ACTION. Trying to create it.
# [23:15] <trackbot> Created ACTION-45 - Update the filter spec to produce the new image type. [on Dean Jackson - due 2011-08-02].
# [23:15] <bradk> fitering borders should also filter border-images (since border-images are substitutes for borders)
# [23:16] <nimbu> dino: the next topic there is a dropshadow effect. if there is smway to do it at a higher level than within a filter
# [23:16] <nimbu> cabanier: svg images is an example, so u want shadow around the shapes. it seems an overkill to apply filters to that
# [23:17] <nimbu> ??: does it not apply to blur and all that stuff. there would be a cross over.
# [23:17] <ed> s/??/patrickdengler/
# [23:17] <nimbu> heycam: we do want it for svg content
# [23:18] <nimbu> heycam: if there was some short hand work in svg and not in css…
# [23:18] <nimbu> dino: webkit has an extension -webkit-svg-shadow that will apply the shadow to the svg content
# [23:18] <nimbu> dino: the reason this was added was canvas has it
# [23:18] <nimbu> dino: the req was basically to draw a shape and give it a shadow.
# [23:19] <nimbu> ChrisL: is the req to be a simple syntax?
# [23:19] <nimbu> dino: whats the req for current one
# [23:19] <nimbu> ChrisL: u have to do a lot of work to produce it.
# [23:19] <nimbu> 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?
# [23:20] <nimbu> ChrisL: if u want to apply two filters on svg, you need to put second filter on group.
# [23:21] <nimbu> pdengler: i was thinking in terms of text-shadow, box-shadow, drop-shadow
# [23:21] <nimbu> pdengler: i think css authors dont think of them as filters
# [23:21] <nimbu> pdengler: there are categories of effects that have nothing to do with filters.
# [23:21] <nimbu> smfr: the issue is the order of ops
# [23:22] <nimbu> pdengler: it goes with input types.
# [23:22] <nimbu> smfr: if we have filter and box-shadow which do u do first
# [23:22] <nimbu> dino: people consider shadow as part of object drawn
# [23:22] <nimbu> dino: if you set opacity of text to 0 would you expect shadow to fade as well.
# [23:23] <nimbu> smfr: i think we still render the shadow.
# [23:23] <nimbu> dino: the shadow is really part of the object
# [23:23] <nimbu> smfr: transforms and shadow.
# [23:23] <nimbu> smfr: does the shadow move around, or stay same
# [23:23] <nimbu> smfr: it depends on scenarios
# [23:24] <nimbu> plinss: if i rotate smthing the shadow should stay and rotate.
# [23:24] <tantek> ed: I'd like to spend 5 minutes discussing "color-correction" as mentioned/discussed here 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.
# [23:24] <ChrisL> tha is why we added the 'ref' transform for svg so yo can use the local coordinate system of a higher element
# [23:24] <nimbu> ChrisL: the shadow should be the last thing that comes after it is transformed
# 06[23:24] * ChrisL that was bradk, not me
# 06[23:25] * nimbu oops
# 06[23:25] * ChrisL especially as I disagree with what he said :)
# [23:25] <bradk> :)
# [23:25] <nimbu> dino: should we expose short hand for it?
# 06[23:25] * ed tantek sure, i'll add that to the afternoon session
# [23:25] <ChrisL> s/ChrisL: the shadow/Bradk: the shadow
# [23:25] <nimbu> ACTION: dino add shorthand property for shadow.
# 06[23:25] * trackbot noticed an ACTION. Trying to create it.
# 06[23:25] * RRSAgent records action 22
# [23:25] <trackbot> Created ACTION-46 - Add shorthand property for shadow. [on Dean Jackson - due 2011-08-02].
# [23:26] <tantek> ed: I have to depart by 4pm.
# [23:26] <nimbu> dino: adding dropshadow keyword would become a long f()
# [23:26] <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.
# [23:26] <nimbu> dbaron: is it a property or fn
# [23:27] <smfr> like filter: dropshadow(10px, 10px, 20px, blue)
# [23:27] <bradk> not sure if the ofset should scale.
# [23:27] <nimbu> dbaron: what mechanism is it coming from, when the author is not specifying the order
# [23:27] <nimbu> dbaron: when author lists in order then no problme
# 06[23:28] * ed tantek ok
# [23:28] <nimbu> smfr: issue when interacting with other css properties.
# [23:28] <nimbu> dbaron: i see box-shadow as part of border drawing stuff. and it would happen before filters.
# [23:28] <nimbu> dino: that was my point
# [23:29] <nimbu> dino: not an effect like blur or warp
# [23:29] <nimbu> bradk: can box-shadow be simulated with css?
# [23:29] <nimbu> bradk: can box-shaow be simulated with filters?
# [23:29] <nimbu> smfr: u could, but you have to generate mask the rounded border box which the shadow is applied to
# [23:30] <nimbu> dino: u can do with markup filters by filter chain that floods black region, offsets it, composits
# [23:30] <ChrisL> yes i assumed the question related to doing it with markup filters
# [23:30] <nimbu> dino: not in short hand
# [23:30] <nimbu> dino: proposal for a wave effect
# [23:30] <nimbu> dino: ms has implemented
# [23:31] <nimbu> dino: ed commented it might be interesting.
# [23:33] <bradk> I've never personally had any need for a wave effect.
# [23:33] <tantek> how about a new wave effect?
# [23:33] <nimbu> dino: it seems like there is not much support
# [23:33] <nimbu> dino: discussion about custom element to add any effect
# [23:33] <nimbu> dino: some implementations have effects to add that are useful
# [23:33] <ChrisL> as i mentioned earlier, a dom interface allws room for experimentation
# [23:33] <nimbu> dino: some way it could be done as an extension and not how to prefix a fn name
# [23:34] <nimbu> dino: the webGl community all agreed on same prefix
# [23:34] <nimbu> dino: u get interoperability between browsers but no guarantee it would work forever
# [23:34] <nimbu> dino: some effects that might be common the implementations would agree enough, it could possibly done in that manner
# [23:35] <nimbu> heycam: we would need a reasonably complete desc of what that filter would be.
# [23:35] <nimbu> dino: it is worthwhile getting feature pushed thro trackers as quickly as possible
# [23:35] <nimbu> dino: 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
# [23:36] <nimbu> dino: how should they do it? prefix fn names or if its standard enough, send proposal, wait for agreement and use an experimental prefix
# [23:36] <nimbu> heycam: prefixing sounds like a good idea
# [23:36] <nimbu> smfr: we have prefixed fn names for gradients so its not new
# [23:36] <nimbu> dino: idea of shared prefx name has not been proposed before
# [23:36] <nimbu> dino: it seems to work pretty well in webGL community
# [23:37] <nimbu> szilles classic problem webkit community have webkit prefix
# [23:37] <nimbu> szilles getting agreement doing the same thing or it breaks
# [23:37] <nimbu> szilles: if it breaks come up with the new prefix.
# [23:37] <nimbu> szilles: that was concern in csswg seemed safer for each implementation to have own prefix so it tried to be consistent to itself
# [23:38] <nimbu> dino: its not like its a big issue anyway. if and when people want to use these new effects we will see what happens
# [23:38] <nimbu> cabanier: it would be nice to have one prefix.
# 03[23:38] * Joins: cyril (qw3birc@128.30.52.28)
# [23:38] <nimbu> heycam: its diff from property names
# 03[23:38] * Joins: tantek_ (tantek@72.254.90.199)
# [23:38] <nimbu> dino: i guess u can still.
# [23:38] <nimbu> smfr: people do that with bg image
# [23:38] <nimbu> heycam: its an invalid value.
# [23:39] <nimbu> dino: filter property in css om
# [23:39] <nimbu> ed: thats come up before whether or not if it should be exposed to cssom
# [23:39] <nimbu> anne: exposed or rename attr on interface to css filter
# [23:39] <nimbu> anne: i dont think there is a middle ground
# [23:39] <nimbu> anne: ecmascript guys hate the document.all as it is hidden
# [23:40] <nimbu> anne: that is the pattern we dont want to follow
# [23:40] <nimbu> anne: i dont know why we didnt go with that.
# [23:40] <nimbu> anne: it is for attr exposed on css style decl
# [23:40] <nimbu> anne: and style decl values
# [23:40] <nimbu> smfr: is it coz ie claimed filter
# [23:40] <nimbu> anne: yes
# [23:40] <nimbu> dbaron: we have been shipping element.style.filter
# [23:40] <nimbu> ed: also opera
# 02[23:40] * Quits: tantek (tantek@66.87.7.154) (Ping timeout)
# 03[23:40] * tantek_ is now known as tantek
# [23:41] <nimbu> ed: its not a big problem
# [23:41] <nimbu> ed: not many sites are broken
# [23:41] <nimbu> dino: we should also ask ms
# [23:41] <nimbu> pdengler: we see this coming anyway. i dont know what our avenues are to change.
# [23:41] <nimbu> pdengler: i think we have some mitigations
# [23:41] <nimbu> heycam: u can still support if the syntax is right
# [23:41] <nimbu> pdengler: we are okay on this one if you want to keep style.filter
# [23:41] <nimbu> pdengler: sylvaing?
# 06[23:43] * heycam anyone else having trouble loading pages from w3.org?
# [23:44] <nimbu> ed: see if we can publish smthing so people know where we are
# [23:44] <nimbu> dino: we are happy to publish it
# [23:45] <nimbu> ChrisL: there are sm people who are not rep here.
# [23:45] <nimbu> dbaron: this is pretty much a full css meeting hre.
# [23:46] <dbaron> We've been shipping element.style.filter since Firefox 4... so not all that long, but we have shipped it.
# [23:46] <nimbu> RESOLVED: publish the drafts as soon as the edits are done.
# 06[23:46] * dbaron RRSAgent, pointer?
# 06[23:46] * RRSAgent See http://www.w3.org/2011/07/26-fx-irc#T21-41-32
# [23:46] <nimbu> ACTION: ChrisL to check whether or not filters spec sounds as a new draft or not
# 06[23:46] * trackbot noticed an ACTION. Trying to create it.
# 06[23:46] * RRSAgent records action 23
# [23:46] <trackbot> Created ACTION-47 - Check whether or not filters spec sounds as a new draft or not [on Chris Lilley - due 2011-08-02].
# [23:47] <nimbu> s/sounds/counts
# 06[23:47] * dbaron points ChrisL to the Present list at http://www.w3.org/2011/07/26-fx-irc#T16-27-41
# [23:47] <ed> s/publish the drafts as soon as the edits are done./publish the FXTF Filter Effects draft as soon as the edits discussed in this meeting are done./
# [23:48] <nimbu> dino: moving to css / svg animations.
# [23:48] <nimbu> ed: we have half an hour before break.
# [23:48] <ed> Topic: CSS / SVG animations
# [23:48] <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Animations/Harmonisation
# 06[23:48] * sylvaing ping sgalineau on Skype for conf call access
# [23:49] <nimbu> birtles: seems like there are diff ideas on where we are heading.
# [23:49] <nimbu> birtles: check if we are on same page where we want to end up with animations in the long run
# 03[23:49] * Joins: szilles (chatzilla@72.254.90.148)
# [23:49] <nimbu> birtles: see how feasible it is to merge them
# [23:50] <tantek> http://www.downforeveryoneorjustme.com/w3.org
# [23:51] <tantek> http://www.downforeveryoneorjustme.com/web5.w3.org
# [23:51] <birtles> http://dl.dropbox.com/u/11894343/Harmonisation.htm
# 06[23:51] * ChrisL w3.org works fine for me from france and did yesterday too
# [23:52] <nimbu> birtles: the target of animation is diff svg is 1 attr on an elm, css is more flex
# [23:52] <nimbu> birtles: its smthing we need to fix in svg
# [23:53] <nimbu> birtles: 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
# [23:53] <nimbu> birtles: more significant diff its been proposed to css anims be added to underlying styles. i dont think there is anything to add anims together.
# [23:53] <nimbu> smfr: we would like to be able to do
# [23:53] <ChrisL> its a common use case to apply multiple animations
# [23:54] <nimbu> smfr: we ahve talked about adding it to css for a while
# [23:54] <nimbu> vhardy: having same model as smile would help.
# [23:54] <ChrisL> yes, i think its needed and the sandwich model works well
# [23:54] <nimbu> birtles: one complication is there are rules, and its a grey area
# [23:55] <szilles> s/smile/SMIL/
# [23:55] <ChrisL> s/same model/same sandwich model/
# [23:55] <nimbu> birtles: animation types how to do interpolation.
# [23:56] <nimbu> birtles: interval timing is quite diff
# [23:56] <ChrisL> lets get rid of wallclock, please
# [23:56] <nimbu> birtles: css does not have complexity of svg
# [23:57] <nimbu> birtles: SMIL has all sorts of rules which is a big area of difference. which might be difficult to merge and be impossible to merge.
# [23:57] <nimbu> birtles: multiple intervals, and syncbase
# [23:57] <nimbu> ChrisL: do we find that syncbase stuff is getting used well?
# 06[23:58] * ChrisL can't hear what he is saying
# [23:58] <nimbu> 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
# [23:58] <nimbu> birtles: i am concerned people are using it
# [23:59] <nimbu> vhardy: what do you mean by you dont want syncbase?
# [23:59] <nimbu> birtles: SMIL has 2 diff features for kicking off anims
# [23:59] <nimbu> birtles: when an animation ends/starts, when I get an event
# Session Close: Wed Jul 27 00:00:00 2011

The end :)