IRC log of fx on 2011-07-26

Timestamps are in UTC.

16:09:01 [RRSAgent]
RRSAgent has joined #fx
16:09:01 [RRSAgent]
logging to
16:09:11 [plinss_]
rrsagent, make logs public
16:09:29 [bradk]
bradk has joined #fx
16:11:53 [dbaron]
dbaron has joined #fx
16:11:58 [ed]
16:12:01 [anne]
anne has joined #fx
16:12:02 [sylvaing]
sylvaing has joined #fx
16:12:06 [smfr]
smfr has joined #fx
16:12:11 [stearns]
stearns has joined #fx
16:12:30 [arronei_]
arronei_ has joined #fx
16:12:43 [dino]
16:13:00 [TabAtkins_]
TabAtkins_ has joined #fx
16:13:10 [tpod]
tpod has joined #fx
16:13:21 [birtles]
birtles has joined #fx
16:13:28 [dino]
Scribe: dino
16:13:40 [dino]
Scribenick: dino
16:13:44 [tpod]
Hello dino
16:13:50 [dino]
is that all I have to do?
16:14:57 [tpod]
Is this channel archived?
16:15:00 [anne]
I am here
16:15:03 [fantasai]
16:15:10 [tpod]
16:15:13 [fantasai]
16:15:17 [miketaylr]
miketaylr has joined #fx
16:15:23 [dino]
Topic: SVG Pain and CSS Images
16:15:34 [krijnh]
krijnh has joined #fx
16:15:34 [Ms2ger]
Pain? :)
16:15:43 [dino]
s/SVG Pain/SVG Paint/
16:15:50 [smfr]
16:15:58 [hober]
sylvaing: could you skype bradk & me in?
16:16:10 [dino]
TabAtkins: There was a proposal a while ago about using SVG paint as CSS images.
16:16:17 [smfr]
16:16:20 [vhardy]
vhardy has joined #fx
16:16:33 [dino]
TabAtkins: That's one proposal. I plan to add it into CSS Image Values 4
16:16:52 [dino]
TabAtkins: The other way around is CSS into SVG paint servers
16:16:52 [heycam]
heycam has left #fx
16:17:14 [dino]
TabAtkins: e.g. <rect fill="linear-gradient(top blue)">
16:17:25 [dino]
TabAtkins: but there are other useful things like the element() function
16:17:30 [cabanier]
cabanier has joined #fx
16:17:30 [heycam]
heycam has joined #fx
16:17:41 [dino]
TabAtkins: question is where to specify using CSS images as paint servers?
16:17:57 [szilles]
szilles has joined #fx
16:17:59 [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
16:18:00 [dbaron]
tek Çelik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter Linss (HP)
16:18:00 [dholbert]
dholbert has joined #fx
16:18:04 [dino]
dino: what's the status of SVG specs
16:18:29 [shans]
shans has joined #fx
16:18:33 [dino]
heycam: SVG 2e was just published. We are starting on new specs now.
16:18:45 [tpod]
This is Tantek's iPod
16:19:08 [dino]
heycam: it would be ok to specify this in image values spec
16:19:15 [glazou]
glazou has joined #fx
16:19:36 [florian]
florian has joined #fx
16:20:29 [dino]
ed: many SVG implementations already support things like CSS colours even though it isn't supported in specs.
16:21:14 [dino]
dino: it seems weird for a CSS specification to define SVG behaviour
16:21:19 [tantek]
tantek has joined #fx
16:21:25 [dino]
heycam: we could do it in the SVG spec, it would take time
16:22:01 [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.
16:22:29 [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)/
16:22:31 [dino]
tantek: The problem then is that the CSS image values spec now requires an SVG implementation to exit CR
16:23:07 [dino]
dbaron: it's ok if there are two browser engines that implement it
16:23:15 [dino]
TabAtkins: Mozilla already have an implementation
16:23:21 [TabAtkins_]
16:23:34 [dino]
tantek: i am not formally opposing, but I think it is a potential serious issue.
16:24:11 [dino]
TabAtkins: all the CSS image values would be SVG paint servers in userSpaceOnUse
16:24:55 [dino]
heycam: uSoU percentages are relative to the viewport, not to the bounding box of the shape
16:25:25 [tantek]
<aside> Ms2ger - I created #fx-chat for off-topic conversations. :) </aside>
16:25:38 [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.
16:25:53 [dino]
TabAtkins: I don't want to create a new unit space just for this.
16:26:11 [dino]
heycam: are there other issues?
16:26:24 [dino]
TabAtkins: I think coordinate spaces are the only issues.
16:27:41 [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),
16:27:41 [dbaron]
Brian Birtles (Mozilla), Cameron McCormack (Mozilla), Tantek Çelik, Vincent Hardy (Adobe), Erik Dahlstrom (Opera), Peter Linss (HP)
16:27:48 [dino]
dino: what CSS image values have percentages?
16:27:53 [dino]
TabAtkins: only gradients
16:28:13 [dino]
vhardy: How about the keywords like top left etc? Would that be to the SVG bounding box?
16:28:38 [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.
16:28:50 [dino]
TabAtkins recaps yesterday's CSS discussion on gradients
16:29:46 [bradk]
I thought we were unresolved on whether or not to do away with corner-to-corner gradients for now. No concensus.
16:30:14 [dino]
bradk, i believe they were officially deferred from CSS IM 3
16:30:51 [dino]
ed: SVG 1.1 doesn't include the stoke and markers in the bounding box. That might be important for gradients also.
16:31:10 [dino]
TabAtkins: we may have to do some mode switching as you go from CSS to SVG.
16:31:45 [bradk]
dino, Are you sure? I don't recall seeing a resolution for that. I thought it was "no consensus, back to the list".
16:31:48 [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.
16:31:57 [dino]
bradk, no, I'm not sure.
16:32:11 [fantasai]
There was no consensus on removing anything from Gradients
16:32:11 [dino]
bradk, but Tab is speaking now as if it was a resolution :)
16:32:22 [fantasai]
Well, Tab's wrong then. :)
16:32:45 [bradk]
wouldn't be the first time. ;)
16:32:55 [dino]
heycam: CSS may have the same issue with calculating bounding boxes
16:33:36 [dino]
TabAtkins: yes, it's fairly well defined there. It defines the region of the canvas, such as content-box, border-box, etc.
16:34:08 [dino]
RESOLUTION: Tab to add wording to CSS Image Values 4 about how SVG Paint Servers apply to CSS
16:34:53 [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).
16:35:02 [stearns]
bradk - you're right, it's not in the minutes. But I believe it should have been
16:35:25 [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
16:35:38 [fantasai]
Dino: We're sending out massive images right now when we don't need to
16:35:49 [tantek]
dino, TabAtkins, re: 2nd Resolution - suggest making that a non-normative section.
16:36:04 [fantasai]
Dino: Add things for noise, checkboard, halo, etc. Not suggesting we add all those
16:36:06 [smfr]
16:36:23 [fantasai]
Cam: How does Compositing work?
16:36:37 [fantasai]
Dino; Becomes difficult in filters spec, bc sometimes you want the generated below, and other times above.
16:36:48 [fantasai]
Dino: e.g. ppl do a halo effect where a flash moves across the text.
16:36:53 [fantasai]
Dino: In that case you want it above.
16:37:02 [fantasai]
Dino: Tab said it would be better to allow an image anywhere in CSS
16:37:16 [fantasai]
Dino: e.g. say your background is blue with a faint noise texture above it
16:37:19 [cabanier]
16:37:24 [fantasai]
Cam: With bg now you can specify multiple things?
16:37:27 [fantasai]
smfr: multiple images, yes
16:37:44 [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...
16:37:50 [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
16:38:16 [fantasai]
Tab: Thing sin CSS spec that would move to being image values are :
16:38:24 [szilles]
szilles has joined #fx
16:38:29 [fantasai]
Tab: flood ...
16:38:48 [fantasai]
Tab: Unfortunately colors are not image types in CSS. Bg has special case of bg-color
16:38:51 [dino]
TabAtkins: flood would map to image() (eg. image(blue))
16:38:54 [fantasai]
Tab: But you can't have list-style-image: blue;
16:39:15 [fantasai]
Tab: If we don't get that otherwise, the image() function lets you smuggle that in
16:39:23 [dino]
TabAtkins: because image() has a fallback for a color
16:39:24 [fantasai]
Tab: Because it allows a fallback color
16:39:49 [dino]
TabAtkins: without an intrinsic size
16:40:03 [dino]
TabAtkins: turbulence could be an image value
16:40:31 [dino]
TabAtkins: the rest are filters so should stay as filters
16:40:42 [dino]
dino: I propose asking for examples on the list of generated images.
16:42:08 [dino]
RESOLUTION: The new image generator methods (eg. turbulence) to be added to CSS Image Values 4
16:42:13 [patrickdengler]
patrickdengler has joined #fx
16:43:04 [dino]
smfr: I am concerned about the syntax overhead of specifying some complex filters. eg. a checkerboard has colour, repeat, offset.
16:43:14 [dino]
TabAtkins: I agree. We'll have to balance that.
16:43:47 [dino]
fantasai: Once SVG Paint Servers are allowed, it may be better to reference an library of SVG images as a CSS paint.
16:44:24 [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.
16:45:06 [dino]
vhardy: are you suggesting changing the algorithm as is?
16:45:14 [dino]
ed: we can't remove what is there
16:45:33 [dino]
vhardy: it was hard to get the algorithm right, we shouldn't change it.
16:46:24 [dino]
vhardy: so which SVG filter primitives will become paint server?
16:47:19 [dino]
TabAtkins: It won't be the full set.
16:47:31 [dino]
dino: turbulence/noise is the only new one
16:48:13 [dino]
Topic: Pointer events an alpha-level hit testing
16:48:24 [ChrisL]
ChrisL has joined #fx
16:48:50 [ChrisL]
rrsagent, here
16:48:50 [RRSAgent]
16:48:57 [dino]
tantek: We have some degree of interop with the pointer-events property. Mozilla + IE support it. WebKit supports "none" and "auto" for HTML.
16:49:06 [dino]
tantek: so it has been added to CSS 3 UI
16:49:11 [tantek]
16:49:41 [dino]
dbaron: I believe Mozilla support is similar to WebKit - none and auto
16:49:46 [dino]
(for HTML content)
16:49:46 [smfr]
16:50:22 [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.
16:51:04 [dino]
smfr: We've had requests to support visiblePainted in HTML for image content.
16:51:32 [dino]
ed: SVG does ignore hit tests on fully alpha pixels in an image
16:52:02 [ed] (last paragraph, scroll down a bit)
16:52:07 [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."
16:52:10 [dino]
dbaron: we need translations of the purely SVG names. define what "stroke" means in HTML.
16:53:26 [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)
16:53:50 [dino]
heycam: would the CSS spec define what shapes, etc are for the SVG case? or should that be in the SVG spec?
16:54:33 [dino]
tantek: I'll redefine "auto" slightly. It currently references visiblePainted, but we're moving that out.
16:55:06 [dino]
tantek: I'll normatively reference the SVG spec for SVG content.
16:55:23 [bradk]
shouldn't there be a value for 'pointer-events' to determine clickability based on an opacity value?
16:55:27 [dino]
heycam: we should define a term in the SVG spec like "hit testable area" and have that as a reference target
16:56: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
16:56:35 [szilles]
szilles has joined #fx
16:56:50 [dino]
vhardy: what do you do for a stylesheet targeting both languages? SVG will allow more values.
16:57:29 [dino]
tantek: this is an old problem. some specifications allow different values.
16:58:03 [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.
16:58:40 [dino]
tantek: then maybe the specification should define "auto" and "none", then say that everything else is defined in the host language.
16:58:58 [dino]
tantek: this does mean that any new functionality will need new values
16:59:24 [dino]
TabAtkins: hopefully people are not using visiblePainted and expecting it to behave as "auto".
16:59:47 [dino]
TabAtkins: so we might be able to redefine visiblePainted
17:00:41 [dino]
TabAtkins: put the values in the spec and say that people should not use them outside of SVG.
17:01:14 [shepazu]
shepazu has joined #fx
17:01:25 [dino]
TabAtkins gave an example that the scribe missed
17:01:39 [dino]
tantek: that example is deprecated values. this is different.
17:01:40 [vhardy]
Example of precedent where SVG only uses a subset of the existing value set:
17:02:09 [dino]
szilles: the wording should be "these values only have defined meaning in sag"
17:02:14 [dino]
17:03:16 [dino]
RESOLUTION: List all the current values for pointer events, everything other than "none" is treated as "auto" unless applied to SVG content
17:03:57 [dino]
RESOLUTION: Add an author conformance criteria saying that they should not use the other values outside of SVG
17:04:08 [stearns__]
stearns__ has joined #fx
17:04:32 [tantek]
17:05:23 [dino]
tantek: Issue 4 is related to the computed value
17:05:29 [tantek]
@namespace svg "";
17:05:29 [tantek]
svg|svg { pointer-events: none }
17:05:30 [tantek]
svg|svg>* { pointer-events: visiblePainted }
17:06:15 [dino]
heycam: i don't think any content will be relying on seeing a computedStyle of 'visiblePainted'.
17:06:34 [dino]
heycam: so it would be ok to return 'auto' for SVG content
17:07:08 [dino]
tantek: the style rule was an attempt to address the difference in implementations.
17:07:27 [dino]
ed: I think it would be ok to make SVG content have 'auto' as the initial value
17:08:29 [tantek]
17:08:53 [dino]
vhardy: If 'auto' is added to CSS3 UI, we'll need to update/add the SVG specification.
17:09:02 [dino]
heycam: yes
17:09:36 [dino]
ACTION: Cameron to update the SVG specification, adding 'auto' the pointer-events specification.
17:09:36 [trackbot]
Created ACTION-35 - Update the SVG specification, adding 'auto' the pointer-events specification. [on Cameron McCormack - due 2011-08-02].
17:10:07 [ChrisL]
which svg specification is that,Cameron?
17:10:30 [dino]
tantek: moving on to issue 5
17:10:39 [heycam]
ChrisL, that'd be SVG 2
17:10:54 [heycam]
17:10:54 [trackbot]
ACTION-35 Update the SVG specification, adding 'auto' the pointer-events specification. notes added
17:11:34 [dino]
tantek: I believe the style rule I gave above gives the SVG behaviour to non-graphical elements.
17:11:46 [szilles]
szilles has joined #fx
17:13:07 [dino]
discussion about what elements in SVG should get pointer events
17:13:26 [tantek]
svg|svg { pointer-events: visiblePainted }
17:13:32 [dino]
dbaron: the SVG element doesn't paint anything, then it should be ok to have pointer-events applying to everything
17:13:36 [dino]
heycam: also <g>
17:13:50 [dino]
heycam: I think it should be auto everywhere
17:14:22 [dino]
tantek: SVG doesn't specify 'auto'. we're trying to ship an interoperable spec today.
17:15:39 [dino]
vhardy: the property value is saying what is generating events, not where you can place a listener.
17:15:52 [dino]
tantek: are SVG ok with accepting this change?
17:17:08 [dino]
Some discussion missed by scribe
17:17:19 [ChrisL]
wasn't it mentioned earlier thatsome html browsers accept visiblePainted?
17:17:32 [alexmog]
alexmog has joined #fx
17:17:34 [ChrisL]
if the goal is interop now, that it the most interoperable value
17:18:43 [dino]
heycam: SVG2 will be a while coming. We'll change the value there.
17:20:08 [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.
17:20:28 [smfr]
17:20:38 [dino]
tantek: this makes Issue 6 a non-issue now
17:21:15 [dino]
sylvaing: Question - is there a restriction on what elements the pointer-events apply to?
17:21:37 [dino]
tantek: do you have an example in markup?
17:22:16 [dino]
sylvaing: we're worried about click hijacking
17:22:45 [dino]
heycam: using elementFromPoint
17:23:00 [dino]
smfr: This is a valid point to bring up.
17:23:58 [dino]
sylvaing: MS is likely to add some restrictions on passing events down to iframes, or whatever.
17:25:02 [dino]
tantek: doesn't SVG define this with <foreignObject> ?
17:25:10 [dino]
shepazu: spec doesn't say anything
17:25:15 [dino]
tantek: what about implementations?
17:25:36 [dino]
No one responds to suggest that SVG implementations are doing anything to avoid click jacking at the moment
17:26:29 [dino]
sylvaing: It's likely that we will not propagate an event into an iframe
17:27:27 [dino]
tantek: There are two problems: what should implementations do? and now what should the specs say?
17:27:58 [tantek]
17:28:13 [dino]
tantek: I think the specification does have enough room to allow implementations to not propagate events across origin if necessary.
17:28:24 [dino]
tantek reads current CSS 3 UI spec language
17:28:34 [dino]
(can someone paste it in or link?)
17:29:12 [dino]
dbaron: i think that's more likely a bug in the spec rather than a loose reading. It should be defined.
17:29:28 [dino]
anne: agree. elementFromPoint only returns the iframe.
17:29:41 [dino]
----- break -----
17:47:30 [vhardy]
ScribeNick: vhardy
17:47:55 [vhardy]
ed: Let's continue on the CSS UI issues.
17:48:00 [tantek]
17:48:25 [vhardy]
tantek: we were discussing the click jacking scenario with pointer-events: none.
17:48:35 [vhardy]
tantek: sylvaing has a demo
17:49:26 [szilles]
szilles has joined #fx
17:49:46 [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.
17:49:55 [vhardy]
dbaron: you have the same issue with opacity.
17:50:18 [vhardy]
dbaron: the better protection is for web site to not allow being framed.
17:51:31 [vhardy]
sylvaing shows a demo where a frame hides and a 'play' button passes through and activates an 'add to cart button' without the user's knownledge.
17:52:26 [vhardy]
sylvaing: this is not a new issue, but it should be addressed.
17:53:27 [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.
17:53:43 [vhardy]
shepazu: I think the spec. should be more specific.
17:54:11 [vhardy]
dbaron: pointer-event's intent is to filter the targets of events and to let the evet target something lower in z order.
17:54:32 [vhardy]
shepazu illustrates the purpose of pointer-events: none.
17:55:02 [vhardy]
anne: even if we want to be vague for cross origin, we need to be specific for same origin.
17:55:24 [vhardy]
tantek: there is a missing reference here to the definition of hit testing.
17:55:36 [vhardy]
anne: it should be in the pointer-events specification.
17:55:46 [vhardy]
tantek: I do not agree.
17:56:00 [dbaron]
17:56:31 [vhardy]
tantek: does HTML5 define hit testing?
17:56:35 [vhardy]
anne: no
17:56:41 [anne]
17:56:47 [vhardy]
smfr: I thought it was defined.
17:56:47 [shepazu]
17:57:13 [vhardy]
anne: I think we had agreed that the definition of hit testing would be in CSS 3 UI.
17:57:17 [anne]
17:57:32 [vhardy]
tantek: this is just about the property.
17:57:51 [vhardy]
tantek: there is nothign about geometry, z-index, etc...
17:57:55 [alexmog]
alexmog has joined #fx
17:58:07 [anne]
17:58:08 [vhardy]
anne: the first reference I pasted has a portion that needs to be part of the spec.
17:58:13 [anne]
hixie's notes on hit testing ^^
17:58:17 [tantek]
17:58:43 [vhardy]
shepazu: The SVG 1.1 2nd edition has a definition of hit testing, which is new to SVG (was not in previous version).
17:59:31 [bradk]
No skype... is Sylvain out??
17:59:53 [vhardy]
anne: this was never in HTML5.
18:00:00 [vhardy]
anne: this should be in CSS.
18:00:05 [vhardy]
tantek: or DOM Events?
18:00:09 [vhardy]
several: CSS.
18:00:16 [vhardy]
shepazu: should be in CSS.
18:00:59 [vhardy]
tantek: should be split in CSS (geometry and opacity aspects) and then the definition of events should be in DOM Events.
18:01:15 [vhardy]
anne: sure.
18:01:40 [vhardy]
tantek: this is essentially what Hixie's note is doing.
18:02:06 [szilles]
szilles has joined #fx
18:02:26 [vhardy]
smfr: hit testing is the reverse of painting (order-wise). Where we talk about painting order, we could talk about hit testing.
18:02:37 [vhardy]
tantek: Hixie's note talks about painting order too.
18:02:45 [bradk]
standing by...
18:02:58 [vhardy]
tantek: are you saying that Hixie's note should be integrated in the spec.?
18:03:13 [vhardy]
anne: yes.
18:03:37 [vhardy]
tantek: hit testing should be defined in CSS, in CSS UI.
18:04:02 [vhardy]
anne: pointer-events is just about hit testing.
18:05:16 [vhardy]
(discussion about Hixie's proposal and comments that were made).
18:05:45 [vhardy]
shepazu: also needs to take into account SVG for hit-testing, so that the definition is not just HTML.
18:06:02 [vhardy]
dbaron: it is the opposite of z-order, so it should be fairly easy.
18:06:34 [vhardy]
tantek: there are only a few exception cases with elements like body, but the rest should apply for SVG.
18:06:40 [vhardy]
shepazu: we should coordinate on this.
18:07:30 [vhardy]
tantek: z-index and z-order should be in one place and hit testing should reference that.
18:08:01 [vhardy]
heycam: there are some SVG specificities that are different from HTML.
18:08:08 [ChrisL]
svg has a painting order, which is also relevant 9as z-index is for html/css)
18:08:36 [vhardy]
anne: it would be nice if the hit testing algorithm was generic, with possible arguments (like 'stop at the iframe')
18:08:57 [vhardy]
shepazu: I think we need to do some more work and re-coordinate on this later.
18:09:02 [ChrisL]
18:09:16 [smfr]
18:10:37 [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.
18:10:37 [trackbot]
Sorry, couldn't find user - Tantek
18:10:47 [tantek]
18:10:52 [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.
18:10:52 [trackbot]
Sorry, couldn't find user - tantek
18:10:57 [ChrisL]
trackbot, status
18:11:20 [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.
18:11:32 [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.
18:11:32 [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].
18:12:29 [vhardy]
tantek: this was the issue of security, partially. What do we need to say about the scenario sylvaing presented.
18:13:04 [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.
18:13:25 [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.
18:13:39 [vhardy]
dbaron: we should also talk to some people in the web security field.
18:14:08 [vhardy]
dbaron: some people at Mozilla would know about this.
18:15:22 [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.
18:15:22 [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].
18:15:43 [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.
18:15:43 [trackbot]
Sorry, couldn't find user - dbaron
18:15:48 [vhardy]
ed: is there anything more that we need to discuss here?
18:15:59 [vhardy]
shepazu: want to talk about transparency.
18:16:10 [vhardy]
shepazu: proposal for alpha-levels.
18:16:20 [vhardy]
shepazu: this came up from Zynga.
18:16:22 [dbaron]
trackbot, is user david David Baron or some other David?
18:16:22 [trackbot]
Sorry, dbaron, I don't understand 'trackbot, is user david David Baron or some other David?'. Please refer to for help
18:17:00 [ChrisL]
18:17:00 [trackbot]
ACTION-1 -- Doug Schepers to create an FX repository -- due 2010-03-18 -- CLOSED
18:17:00 [trackbot]
18:17:05 [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.
18:17:31 [ChrisL]
users list at
18:17:37 [ChrisL]
david id david dinger
18:17:38 [vhardy]
shepazu: they would like to say that if a pixel has a certain level of transparency, then the hist testing is not positive.
18:17:46 [ChrisL]
18:17:54 [vhardy]
shepazu: if opacity is less than x, then pass the even through
18:18:02 [vhardy]
tantek: do they want the hit testing mask?
18:18:11 [vhardy]
shepazu: they do not want to do their own hit testing.
18:18:54 [vhardy]
tantek: there are cases where there is a hole and you still want to hit positive for the hole.
18:19:08 [vhardy]
smfr: I have not heard Zynga asking for a separate image.
18:19:36 [vhardy]
tantek: where the opacity may address some of the use cases, it seems that a separate mask would cover more use cases.
18:20:06 [vhardy]
vhardy: and the image's opacity could be the default mask.
18:20:08 [vhardy]
tantek: yes.
18:20:17 [birtles]
birtles has joined #fx
18:20:21 [vhardy]
shepazu: this also solves some issues for SVG.
18:20:30 [vhardy]
shepazu: this is an issue we need to look into.
18:20:42 [vhardy]
smfr: it is not obvious that this needs to go into pointer-events.
18:20:46 [vhardy]
shepazu: right.
18:21:18 [vhardy]
shepazu: Paul Bakaus for Zynga mentioned he would rather not maitain two images.
18:21:37 [vhardy]
smfr: I think the threshold for pointer-events is simple enough that we could put it into pointer-events.
18:21:51 [vhardy]
.. a separate image is more complex and should be separate.
18:22:28 [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.
18:22:58 [tantek]
Hixie's notes refer to full transparency as allowing events to pass through
18:23:00 [vhardy]
tantek: currently, in Hixie's proposal, onlyt 100% translucent pixels let the event go through.
18:23:10 [vhardy]
We are talking about adding a threshold instead.
18:23:27 [tantek]
so we're talking about increasing that threshold from opacity:0 to opacity:x where 0≤x≤1
18:23:36 [sylvaing]
sylvaing has joined #fx
18:23:58 [vhardy]
dino: sometimes, you want the hit testing area to be larger than the element itself.
18:24:35 [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.
18:25:14 [vhardy]
shepazu: Alex Danilo said this is too difficult to implement because you might have to get the graphics back from the GPU.
18:25:25 [vhardy]
szilles: so you may have to precompute things.
18:25:45 [vhardy]
tantek: the mask solves that problem.
18:26:10 [heycam]
vhardy: having a mask, isn't that equivalent to just having the texture around?
18:26:24 [heycam]
vhardy: if you're keeping some data for hit testing, that's the same as keeping on the gpu and in memory
18:26:32 [heycam]
smfr: i think it might be expensive at run time
18:26:37 [heycam]
smfr: doable, but it may be slow
18:26:52 [szilles]
szilles has joined #fx
18:26:59 [vhardy]
tantek: if you go back to Paul's usecase, he is keeping his own mask in JS.
18:27:09 [vhardy]
tantek: that means the shapes are their masks.
18:27:17 [shepazu]
Alex's critique:
18:27:52 [vhardy]
tantek: so they have implemented masks as a work around. We could provide masks to resolve their issue.
18:28:38 [shepazu]
Paul,'s email
18:29:12 [vhardy]
ed: the email does not hint at their implementation method.
18:29:25 [vhardy]
shepazu: quoting the email..
18:29:35 [ed]
18:30:27 [vhardy]
heycam: it seems to be a good shorthand.
18:31:03 [vhardy]
tantek: if doing things in canvas and JS works, then shouldn't it be feasible in implementations?
18:31:21 [vhardy]
tab/shepazu: the point Alex Danillo made is valid.
18:32:10 [ChrisL]
there are some video codecs on gpu like for mpeg etc. those might be usablefor jpeg decoding
18:32:31 [ChrisL]
but in general the bandwidth of he back channel from gpu to cpu is not very good
18:32:59 [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.
18:33:29 [vhardy]
tab: box shadows do not impact hit testing.
18:33:42 [vhardy]
tab: round-borders affect hit testing.
18:33:51 [Zakim]
Zakim has left #fx
18:33:51 [vhardy]
tab: border-image does not affect hit testing.
18:34:35 [ChrisL]
bordser is a classic case for needing more values like visibleBorder for hit testing
18:34:35 [vhardy]
tab: I would be ok to say that things may slow down if you do hit testing on a filtered image, for example.
18:35:42 [vhardy]
discussion on various filter effects that may affect hit testing.
18:37:10 [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.
18:37:19 [vhardy]
tantek: we are talking about CSS UI 4 right?
18:37:23 [vhardy]
several: yes.
18:37:40 [vhardy]
shepazu: I think the threshold is enough for most cases.
18:38:26 [vhardy]
smfr: the GPU efficiency is an issue to consider.
18:38:43 [vhardy]
tantek: I would like to add this to CSS UI 4.
18:40:52 [dino]
ACTION: Dean to draft a proposal for specifying hit testing regions or masks for CSS 4 UI
18:40:53 [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].
18:42:03 [vhardy]
ACTION: tantek to specify how opacity:0 impact hit testing.
18:42:03 [trackbot]
Sorry, couldn't find user - tantek
18:42:45 [bradk]
opacity:0.001 should not be different from opacity:0 WRT hit testing
18:42:47 [tantek]
Issue 9:
18:43:13 [smfr]
bradk: opacity already has discontinuitues: 0.9999 creates stacking context, 1 does not
18:43:23 [ChrisL]
bradk, hit testing is like pregnancy. it is on/off not a sliding scale
18:43:25 [vhardy]
ACTION: Doug to propose that opacity of a pixel does not affect its pointer-event behavior for CSS 3 UI.
18:43:25 [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].
18:43:30 [szilles]
szilles has joined #fx
18:44:01 [vhardy]
18:44:01 [trackbot]
ACTION-39 Propose that opacity of a pixel does not affect its pointer-event behavior for CSS 3 UI. notes added
18:44:24 [shepazu]
action: shepazu to write up proposal for opacity threshold for pointer-events for CSS 4 UI
18:44:24 [trackbot]
Created ACTION-40 - Write up proposal for opacity threshold for pointer-events for CSS 4 UI [on Doug Schepers - due 2011-08-02].
18:44:29 [vhardy]
18:44:38 [vhardy]
tantek: I think we are ducking this.
18:44:52 [vhardy]
ed: the issue was for SVG.
18:45:49 [vhardy]
(discussion on filter effects and masks applying to HTML in SVG, through foreignObject)
18:46:19 [vhardy]
heycam: we would need to say that the mask actually impact hit testing.
18:46:34 [vhardy]
heycam: and clip-path as well.
18:46:56 [vhardy]
vhardy: this should go into the hit testing section.
18:46:56 [ed]
s/issue was for SVG./issue was mostly for SVG. /
18:48:58 [tantek]
18:49:12 [tantek]
18:49:19 [vhardy]
ACTION: Doug to propose wording for CSS 3 UI about how masks and clip-paths impact hit-testing.
18:49:19 [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].
18:49:38 [tantek]
18:49:57 [shepazu]
18:50:09 [birtles]
18:50:09 [vhardy]
tantek: we need a definition of these properties in a CSS spec.
18:50:23 [vhardy]
ed; we could put clipping and masking in the same spec.
18:50:38 [ed]
s/same spec/FXTF filter spec/
18:51:25 [ed]
18:53:43 [vhardy]
ACTION: ed to move clip-path and masks to the FX Filter specification draft.
18:53:43 [trackbot]
Created ACTION-42 - Move clip-path and masks to the FX Filter specification draft. [on Erik Dahlström - due 2011-08-02].
18:54:26 [vhardy]
tantek: I have no more issue on CSS 3 UI that requires CSS/SVG coordination. I have gone through the issues I had.
18:54:38 [vhardy]
ed: Next topic: filter effects.
18:54:46 [dino]
18:55:01 [vhardy]
dino: we have a lot of issues.
18:55:32 [vhardy]
dino: first issue is to come up with a name other than SVG filters.
18:55:43 [vhardy]
dino: there are pure css filters and then markup filters.
18:55:51 [ed]
Topic: filter effects
18:56:05 [vhardy]
chris: advanced filers? markup filters?
18:56:41 [vhardy]
dino: the whole spec. is CSS, there is a part that uses markup for advanced filters.
18:57:11 [vhardy]
(discussion on 'advanced filters' v.s. 'markup filters'
18:57:21 [vhardy]
18:57:33 [vhardy]
shepazu: I think markup filters is better
18:57:41 [vhardy]
smfr: declarative filters?
18:57:50 [ChrisL]
the filters previously known as SVG
18:58:00 [ChrisL]
custom filters
18:58:09 [vhardy]
dino: shorthand syntax and long-hand syntax?
18:58:18 [vhardy]
tantek: is this a CSS module?
18:58:28 [ChrisL]
its a jointly developed module
18:58:30 [vhardy]
dino: not currently. But it should be?
18:58:38 [vhardy]
dino: it should just be "Filters"
18:59:03 [vhardy]
tantek: I think we should call them 'CSS 3 Filters'
18:59:17 [vhardy]
fantasai: "CSS Filters"
18:59:20 [ChrisL]
can we please drop the 'levels' stuff
18:59:42 [vhardy]
shepazu: the spec. defines markup for filters.
18:59:57 [vhardy]
fantasai: we should call them "W3C filters"
19:00:01 [vhardy]
chrisL: agreed.
19:00:07 [Ms2ger]
HTML5 Filters?
19:00:57 [vhardy]
shepazu: markup filters is the most descriptive.
19:02:09 [fantasai]
XFilters :)
19:02:55 [ChrisL]
people are gradually being used to pointing to other media from css. images, svg, etc
19:03:25 [vhardy]
dino: the options we have heard:
19:03:30 [vhardy]
... element based filters
19:03:40 [vhardy]
... shorhand/longhand filters
19:03:43 [vhardy]
... markup filters
19:03:50 [vhardy]
... XML Filters
19:04:03 [ChrisL]
w3c filters
19:04:09 [vhardy]
... W3C Filters
19:04:15 [vhardy]
... XFilters
19:04:47 [ChrisL]
shorthand has an existing meaning in css,be careful to avoid confusion there
19:05:04 [ChrisL]
extesible filters
19:05:08 [ChrisL]
custom filters
19:05:09 [ed]
canned filters
19:05:09 [vhardy]
ACTION: Dino to make a naming proposal to distinguish between CSS and markup filters.
19:05:09 [trackbot]
Sorry, couldn't find user - Dino
19:05:30 [vhardy]
ACTION: dean to make a naming proposal to distinguish between CSS and markup filters.
19:05:30 [trackbot]
Created ACTION-43 - Make a naming proposal to distinguish between CSS and markup filters. [on Dean Jackson - due 2011-08-02].
19:05:45 [tantek]
ACTION: RRSAgent - learn how to reference people by URL not just alias.
19:05:45 [trackbot]
Sorry, couldn't find user - RRSAgent
19:05:52 [ChrisL]
I actually asked on sysreq about adding people to fx tracker , but no response
19:06:00 [tantek]
ACTION: trackbot - learn how to reference people by URL not just alias.
19:06:00 [trackbot]
Sorry, couldn't find user - trackbot
19:06:15 [vhardy]
dino: next issue is to have a custom filter using a particular language.
19:06:20 [smfr]
19:07:00 [ed]
19:07:48 [szilles]
szilles has joined #fx
19:08:05 [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.
19:08:11 [vhardy]
dino: what are the pros and cons?
19:08:21 [vhardy]
.. cons: security, not used often.
19:08:37 [vhardy]
... Adobe has a public repository of pixel bender filters and there are 20+ filters there.
19:08:59 [vhardy]
... pros: it is great for us as spec. developers because we do not have to define every effect.
19:09:06 [vhardy]
... cons: we need to define a filter.
19:09:25 [tantek]
ed - is there a URL for today's agenda? I added the CSS3-UI coordination to here: but don't see any other items (nor links to agendas in other locations)
19:09:41 [vhardy]
dino: sometimes, people also want to protect their shader code.
19:09:51 [ed]
patrick: inkscape has hundreds of defined filter effects that only use the existing svg filter functionality
19:09:58 [tantek]
ed - nm. thanks to smfr for
19:10:25 [ChrisL]
19:11:04 [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.
19:11:14 [vhardy]
dino: seems like there is a lot of cons.
19:11:17 [smfr]
ChrisL: or CUDA?
19:12:26 [vhardy]
vhardy: i think there are very nice effects that would could have with custom fitlers. We can come back later with more arguments.
19:12:49 [vhardy]
chrisl: if there was a DOM interface for custom filters, that may be easier.
19:13:29 [vhardy]
dino: one use case where Apple uses a custom filter is for video output to TV, or custom color correction.
19:14:26 [vhardy]
heycam: if we had custom filters, what if you do not have hardware accel.
19:14:34 [vhardy]
vhardy: then there is a sw path.
19:14:37 [szilles]
szilles has joined #fx
19:14:50 [vhardy]
ACTION: vhardy to come back with more arguments on custom filters and make a proposal.
19:14:50 [trackbot]
Sorry, couldn't find user - vhardy
19:15:17 [heycam]
trackbot, status?
19:15:38 [vhardy]
ACTION: vincent to come back with more arguments on custom filters and make a proposal.
19:15:38 [trackbot]
Sorry, couldn't find user - vincent
19:16:24 [vhardy]
dino: next is pointer-events on filter regions.
19:16:29 [ed]
19:18:30 [vhardy]
ed: we found that having filters impact hit testing is costly.
19:18:56 [vhardy]
smfr: and there are cases like blur where the hit becomes an area.
19:19:29 [vhardy]
dino: is that like shadows? Or should we deal with it with masking as well?
19:20:54 [heycam]
vhardy: in svg if oyu have text on a path, with hit testing and text selection, that kind of "distortion" works
19:21:04 [heycam]
vhardy: it doesn't if you go through a filter pipeline, pixels gets shifted around
19:21:11 [heycam]
... you're still operating on the original geometry you had
19:21:37 [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
19:21:44 [heycam]
fantasai: how would you determine that for a blur?
19:21:51 [heycam]
dino: there are multiple pixels
19:21:55 [heycam]
vhardy: it's not a 1-to-1 mapping
19:22:14 [arron]
arron has joined #fx
19:22:15 [heycam]
ChrisL: if you have a filter that displaces things, or if the visual result is quite different from the original, ...
19:22:23 [heycam]
fantasai: why not use transforms for shifting content?
19:22:34 [heycam]
vhardy: with filters you could use your source multiple times
19:22:51 [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
19:22:55 [heycam]
dino: the text might be in a different spot
19:23:09 [heycam]
vhardy: if you use SourceGraphic and feOffset, you could have a rectangle and make it a grid of four rectangles
19:23:12 [heycam]
... and that's the visual rendering
19:23:22 [heycam]
... in that case, it would be most natural to say if you click anything in there it hits positive
19:23:34 [heycam]
fantasai: if you want to multiply images, then that 's different from just mirroring
19:23:43 [heycam]
... nobody expects to click on a reflection of an icon and have that hit test
19:23:49 [ChrisL]
trackbot, status
19:23:58 [heycam]
... if you want something that's actually solid, there should be some other way of doing it that affects layout
19:24:04 [heycam]
shepazu: you should use a mask in this case
19:24:18 [heycam]
... nobody's asked for this either
19:24:24 [heycam]
fantasai: I think we haven't seen convincing use cases
19:24:47 [ChrisL]
trackbot, init
19:24:55 [heycam]
dino: if we have the mask image proposal, you would point to the filter image as the mask
19:25:00 [heycam]
vhardy: I think that covers most of what we need
19:25:06 [heycam]
... but I think still conceptually this is an important issue
19:25:14 [heycam]
ed: raise an issue for this?
19:25:23 [ChrisL]
trackbot, status
19:26:12 [vhardy]
dino: next one is enable-background.
19:26:28 [ChrisL]
tracker, init
19:26:35 [ChrisL]
trackbot, status
19:26:52 [vhardy]
dino: there is a general proposal to deprecate it.
19:27:26 [ChrisL]
trackbot, reload
19:27:41 [vhardy]
proposal at:
19:27:51 [ed]
I raised ISSUE-5 for the hit-testing
19:28:13 [ChrisL]
tracker, init
19:28:15 [ed]
19:28:24 [ChrisL]
tracker, init
19:28:31 [Ms2ger]
trackbot, init
19:28:39 [ChrisL]
trackbot, status
19:28:54 [vhardy]
cabanier: enable-background is defined for SVG and not for HTML. We need to define what that does for CSS/HTML.
19:29:24 [ChrisL]
adobe used to implement it
19:29:26 [vhardy]
dino: who implements enable-background.
19:29:49 [ChrisL]
but it seems under-implemented in current svg implementations
19:29:50 [vhardy]
Opera, Batik, Illustrator, Inkscape?
19:30:09 [ChrisL]
it would be good if adobe illustrator stopped writing it needlessly on svg exports
19:30:29 [vhardy]
ed: lunch break.
19:31:03 [dbaron]
lunch-break-after: always
19:33:05 [ted]
ted has joined #fx
19:33:07 [ChrisL]
trackbot, status
19:33:12 [ChrisL]
19:33:18 [ted]
ted has left #fx
19:34:55 [tpod]
tpod has joined #fx
19:41:38 [tpod_]
tpod_ has joined #fx
19:56:59 [Strengths]
Strengths has joined #fx
20:10:23 [patrickdengler]
patrickdengler has joined #fx
20:10:37 [stearns]
stearns has joined #fx
20:13:15 [pdengler]
pdengler has joined #fx
20:32:51 [birtles]
birtles has joined #fx
20:35:10 [szilles]
szilles has joined #fx
20:35:13 [nimbupani]
nimbupani has joined #fx
20:35:17 [anne]
anne has joined #fx
20:35:21 [tantek]
tantek has joined #fx
20:35:34 [dbaron]
ScribeNick: nimbupani
20:35:37 [dbaron]
ScribeNick: nimbu
20:35:46 [florian]
florian has joined #fx
20:36:17 [nimbu]
ed: we can do svg composting first and continue with filters
20:36:54 [ed]
20:37:01 [nimbu]
cabanier: there is a need for adobe to specify the blending into the css.
20:37:21 [vhardy]
vhardy has joined #fx
20:37:30 [smfr]
smfr has joined #fx
20:37:54 [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
20:38:05 [nimbu]
cabanier: the enable-backgrounds is necessary for compositing.
20:38:12 [TabAtkins_]
TabAtkins_ has joined #fx
20:38:23 [nimbu]
heycam: are we asking first if people are in favour of compositing for css at all?
20:38:35 [nimbu]
cabanier: there was a discussing in mailing list where people did not see the point of it. smfr
20:39:00 [nimbu]
cabanier: since we need it for filters anyway maybe its not a big deal
20:39:11 [nimbu]
smfr: webkit has a webkit property which lets you set compositing mode for an image
20:39:24 [nimbu]
heycam: can u do all compositing modes with existing svg filter primitives
20:39:27 [nimbu]
cabanier: i believe you can.
20:39:37 [nimbu]
cabanier: difficult as u need to do compositing urself.
20:39:51 [nimbu]
vhardy: svg compositing spec is more complete.
20:40:42 [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?
20:41:01 [nimbu]
heycam: if you have already implemented for svg it wont be much work to extend it
20:41:08 [nimbu]
cabanier: do u mean spec or implementation?
20:41:11 [nimbu]
heycam: implementation
20:41:33 [ChrisL]
ChrisL has joined #fx
20:43:04 [nimbu]
dbaron: how good is enable background is for authors to understand whats going on
20:43:11 [nimbu]
dbaron: whats the deal with x, y params in that?
20:43:17 [alexmog]
alexmog has joined #fx
20:43:17 [glazou]
glazou has joined #fx
20:43:22 [nimbu]
cabanier: those will go away. it is more confusing
20:43:54 [nimbu]
dbaron: with filters, the defaults meant things were meant to be clipped out.
20:44:02 [nimbu]
smfr: enable-bg is like opacity.
20:44:12 [nimbu]
cabanier: enable bg just generates stacking context.
20:45:07 [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
20:45:13 [nimbu]
cabanier: i agree the keyword is pretty confusing
20:45:23 [nimbu]
TabAtkins: i only understand it coz i have looked at it enough times
20:45:31 [nimbu]
TabAtkins: the svg compositing def
20:45:52 [nimbu]
szilles is your point editorial improvements will be appreciated dbaron
20:46:05 [nimbu]
dbaron: in compositing it sez new buffers are established for both of them. which seems wrong
20:46:33 [nimbu]
cabanier: that confusion comes from ported …
20:46:42 [nimbu]
cabanier: lets stick with regular blending modes
20:47:02 [nimbu]
dbaron: i am not sure i follow but i dont know if thats worth it
20:47:16 [nimbu]
ed: do we want to have this for css or html?
20:47:17 [dbaron]
s/thats worth it/it's worth explaining to me/
20:47:24 [ChrisL]
20:47:58 [nimbu]
vhardy: in the rendering model perspective, i dont see any harm done by making this generic
20:48:06 [nimbu]
anne: shouldnt all these things be generic
20:48:30 [nimbu]
cabanier: maybe we can get a better name if we put this in css
20:48:59 [nimbu]
anne: has anyone looked at how similar it is to canvas composite feature
20:49:10 [nimbu]
cabanier: canvas has porter-duff this is slightly different
20:49:35 [nimbu]
cabanier: we had a discussion on splitting it into porter-duff & blending modes. porter-duff is hard to specify.
20:49:51 [nimbu]
heycam: blend modes dont need u to keep it off on a separate buffer like enable bg?
20:49:54 [nimbu]
cabanier: they do.
20:49:54 [ChrisL]
why is porter-duff hard to specify?
20:50:03 [nimbu]
heycam: what ist he complexity for porter-duff
20:50:13 [nimbu]
anne: why is it "easy" for canvas but not for svg?
20:50:33 [nimbu]
vhardy: in svg or html u have multiple nodes and u need to define which to accumulate and what level.
20:50:46 [nimbu]
anne: and i guess u have to constantly run it if you change the underlying mode
20:50:53 [nimbu]
cabanier: canvas does not know about stacking context.
20:51:00 [nimbu]
vhardy: its also one drawing operation at a time
20:51:12 [nimbu]
vhardy: in tree model you can have whole trees or groups.
20:51:19 [nimbu]
cabanier: thats what enable bg does
20:51:34 [nimbu]
dbaron: is porter-duff trying to do smthing in cases other than where u have stacking context?
20:51:47 [smfr]
20:52:29 [nimbu]
dbaron: there are elements that are outside subtree and interleave with htem
20:52:54 [ChrisL]
dbaron,svg tries to avoid that interleave so we don't use the stacking conext
20:52:54 [nimbu]
shepazu: i dont understand what you mean by interleaving
20:53:23 [ChrisL]
shepazu, interleaved in z-order. in other words, not the painters algorithm used in svg
20:53:45 [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
20:53:59 [nimbu]
dbaron: css does not even define things in terms of drawing operations
20:54:17 [nimbu]
heycam: isnt there an appendix that sez paint the bg paint the border?
20:54:27 [ChrisL]
css defines the order of drawing border, background, and text
20:54:30 [nimbu]
dbaron: i am not sure if it was going to be interpreted that way.
20:54:54 [nimbu]
cabanier: u create two buffers the top one with desta top(?)
20:55:06 [nimbu]
dbaron: in css that sort of thing only makes sense in stacking context
20:55:10 [ChrisL]
s/desta top/dest atop/
20:55:19 [nimbu]
cabanier: enable background adds another stacking context.
20:55:38 [nimbu]
dbaron: if the stuff in here needs to apply to css it needs to say more about stacking contexts
20:55:59 [nimbu]
dbaron: the comp-op property has initial value that sorts over.
20:56:00 [heycam]
s/desta top(?)/dest-atop/
20:56:14 [dino]
is this the latest spec?
20:56:31 [anne]
20:56:33 [anne]
20:57:05 [nimbu]
ChrisL: u would still need stacking context in css and html. there is opacity or smthing that generates new stacking context
20:57:13 [nimbu]
vhardy: are u saying comp-op wont trigger new stacking context?
20:57:19 [ed]
dino: yes, that's the editor's draft version,
20:57:29 [nimbu]
ChrisL: it wont, even if it did the initial value would be smthing different.
20:57:46 [nimbu]
vhardy: should we make this work for html, css?
20:58:01 [anne]
ed, that's a 404
20:58:04 [ed]
20:58:07 [ed]
that one works
20:58:11 [szilles]
szilles has joined #fx
20:58:23 [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.
20:58:31 [anne]
ed, should update that to say editor's draft...
20:59:04 [nimbu]
ChrisL: it would be helpful if we have one for each host language, and say more clearly what happens.
21:00:28 [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.
21:00:28 [trackbot]
Sorry, couldn't find user - cabanier
21:01:16 [nimbu]
shepazu: add cabanier to this list :P
21:01:34 [nimbu]
dino: so u dont want to remove enable background.
21:01:43 [nimbu]
cabanier: no only the x, y.
21:02:50 [ChrisL]
trackbot, status
21:04:20 [dbaron]
21:04:37 [nimbu]
ChrisL: pls add cabanier too :P
21:06:29 [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.
21:06:30 [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].
21:07:08 [nimbu]
dino: proposal from tab for a new image generator
21:07:11 [ed]
topic: filter effects (continued)
21:07:21 [nimbu]
dino: any image generator, stream of filter property
21:07:26 [nimbu]
dino: does anyone disagree?
21:07:31 [nimbu]
dino: TabAtkins and i agree its a good idea
21:08:01 [nimbu]
dbaron: is this an extension to image vals
21:08:10 [nimbu]
TabAtkins: will just be in there but will be a new image type
21:08:27 [nimbu]
ChrisL: we need to find a separate way to bring it in.
21:08:39 [nimbu]
dino: this is the separate way. if u want to just filter the border.
21:08:51 [nimbu]
smfr: if u use border-image you will get sharp edges
21:09:00 [nimbu]
smfr: Chris suggests we get blur after we slice and stretch
21:09:22 [nimbu]
TabAtkins: @ santaclara tpac brad was talking about pulling sections of elements instead of entire element as filter input.
21:09:32 [nimbu]
dbaron: i think we need new filter input primitives for css stuff
21:09:39 [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)
21:09:50 [nimbu]
smfr: the border-image should be solved this other way.
21:09:54 [nimbu]
dino: other places can use this.
21:10:08 [nimbu]
dbaron: i can see using multi bg and wanting to filter one of em
21:10:28 [nimbu]
ACTION: dino update the filter spec to produce the new image type.
21:10:29 [trackbot]
Created ACTION-45 - Update the filter spec to produce the new image type. [on Dean Jackson - due 2011-08-02].
21:10:48 [bradk]
fitering borders should also filter border-images (since border-images are substitutes for borders)
21:11:28 [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
21:11:47 [nimbu]
cabanier: svg images is an example, so u want shadow around the shapes. it seems an overkill to apply filters to that
21:12:25 [nimbu]
??: does it not apply to blur and all that stuff. there would be a cross over.
21:12:41 [ed]
21:13:04 [nimbu]
heycam: we do want it for svg content
21:13:39 [nimbu]
heycam: if there was some short hand work in svg and not in css…
21:13:53 [nimbu]
dino: webkit has an extension -webkit-svg-shadow that will apply the shadow to the svg content
21:14:01 [nimbu]
dino: the reason this was added was canvas has it
21:14:23 [nimbu]
dino: the req was basically to draw a shape and give it a shadow.
21:14:36 [nimbu]
ChrisL: is the req to be a simple syntax?
21:14:41 [nimbu]
dino: whats the req for current one
21:14:50 [nimbu]
ChrisL: u have to do a lot of work to produce it.
21:15:16 [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?
21:16:00 [nimbu]
ChrisL: if u want to apply two filters on svg, you need to put second filter on group.
21:16:26 [nimbu]
pdengler: i was thinking in terms of text-shadow, box-shadow, drop-shadow
21:16:38 [nimbu]
pdengler: i think css authors dont think of them as filters
21:16:50 [nimbu]
pdengler: there are categories of effects that have nothing to do with filters.
21:17:24 [nimbu]
smfr: the issue is the order of ops
21:17:31 [nimbu]
pdengler: it goes with input types.
21:17:54 [nimbu]
smfr: if we have filter and box-shadow which do u do first
21:18:08 [nimbu]
dino: people consider shadow as part of object drawn
21:18:21 [nimbu]
dino: if you set opacity of text to 0 would you expect shadow to fade as well.
21:18:27 [nimbu]
smfr: i think we still render the shadow.
21:18:39 [nimbu]
dino: the shadow is really part of the object
21:19:05 [nimbu]
smfr: transforms and shadow.
21:19:17 [nimbu]
smfr: does the shadow move around, or stay same
21:19:23 [nimbu]
smfr: it depends on scenarios
21:19:42 [nimbu]
plinss: if i rotate smthing the shadow should stay and rotate.
21:20:06 [tantek]
ed: I'd like to spend 5 minutes discussing "color-correction" as mentioned/discussed here (I don't think it's been discussed since) - I think this is the right set of people to discuss it.
21:20:07 [ChrisL]
tha is why we added the 'ref' transform for svg so yo can use the local coordinate system of a higher element
21:20:09 [nimbu]
ChrisL: the shadow should be the last thing that comes after it is transformed
21:20:44 [bradk]
21:20:55 [nimbu]
dino: should we expose short hand for it?
21:21:12 [ChrisL]
s/ChrisL: the shadow/Bradk: the shadow
21:21:12 [nimbu]
ACTION: dino add shorthand property for shadow.
21:21:12 [trackbot]
Created ACTION-46 - Add shorthand property for shadow. [on Dean Jackson - due 2011-08-02].
21:21:27 [tantek]
ed: I have to depart by 4pm.
21:21:40 [nimbu]
dino: adding dropshadow keyword would become a long f()
21:21:58 [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.
21:22:13 [nimbu]
dbaron: is it a property or fn
21:22:53 [smfr]
like filter: dropshadow(10px, 10px, 20px, blue)
21:23:03 [bradk]
not sure if the ofset should scale.
21:23:11 [nimbu]
dbaron: what mechanism is it coming from, when the author is not specifying the order
21:23:23 [nimbu]
dbaron: when author lists in order then no problme
21:23:32 [nimbu]
smfr: issue when interacting with other css properties.
21:23:59 [nimbu]
dbaron: i see box-shadow as part of border drawing stuff. and it would happen before filters.
21:24:12 [nimbu]
dino: that was my point
21:24:27 [nimbu]
dino: not an effect like blur or warp
21:24:55 [nimbu]
bradk: can box-shadow be simulated with css?
21:25:07 [nimbu]
bradk: can box-shaow be simulated with filters?
21:25:23 [nimbu]
smfr: u could, but you have to generate mask the rounded border box which the shadow is applied to
21:25:40 [nimbu]
dino: u can do with markup filters by filter chain that floods black region, offsets it, composits
21:25:43 [ChrisL]
yes i assumed the question related to doing it with markup filters
21:25:44 [nimbu]
dino: not in short hand
21:26:02 [nimbu]
dino: proposal for a wave effect
21:26:07 [nimbu]
dino: ms has implemented
21:26:30 [nimbu]
dino: ed commented it might be interesting.
21:28:11 [bradk]
I've never personally had any need for a wave effect.
21:28:21 [tantek]
how about a new wave effect?
21:28:32 [nimbu]
dino: it seems like there is not much support
21:28:55 [nimbu]
dino: discussion about custom element to add any effect
21:29:03 [nimbu]
dino: some implementations have effects to add that are useful
21:29:17 [ChrisL]
as i mentioned earlier, a dom interface allws room for experimentation
21:29:24 [nimbu]
dino: some way it could be done as an extension and not how to prefix a fn name
21:29:36 [nimbu]
dino: the webGl community all agreed on same prefix
21:29:50 [nimbu]
dino: u get interoperability between browsers but no guarantee it would work forever
21:30:06 [nimbu]
dino: some effects that might be common the implementations would agree enough, it could possibly done in that manner
21:30:32 [nimbu]
heycam: we would need a reasonably complete desc of what that filter would be.
21:30:48 [nimbu]
dino: it is worthwhile getting feature pushed thro trackers as quickly as possible
21:31:08 [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
21:31:30 [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
21:31:36 [nimbu]
heycam: prefixing sounds like a good idea
21:31:44 [nimbu]
smfr: we have prefixed fn names for gradients so its not new
21:31:54 [nimbu]
dino: idea of shared prefx name has not been proposed before
21:32:03 [nimbu]
dino: it seems to work pretty well in webGL community
21:32:25 [nimbu]
szilles classic problem webkit community have webkit prefix
21:32:36 [nimbu]
szilles getting agreement doing the same thing or it breaks
21:32:45 [nimbu]
szilles: if it breaks come up with the new prefix.
21:33:08 [nimbu]
szilles: that was concern in csswg seemed safer for each implementation to have own prefix so it tried to be consistent to itself
21:33:27 [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
21:33:35 [nimbu]
cabanier: it would be nice to have one prefix.
21:33:40 [cyril]
cyril has joined #fx
21:33:41 [nimbu]
heycam: its diff from property names
21:33:45 [tantek_]
tantek_ has joined #fx
21:33:53 [nimbu]
dino: i guess u can still.
21:33:59 [nimbu]
smfr: people do that with bg image
21:34:07 [nimbu]
heycam: its an invalid value.
21:34:43 [nimbu]
dino: filter property in css om
21:35:00 [nimbu]
ed: thats come up before whether or not if it should be exposed to cssom
21:35:08 [nimbu]
anne: exposed or rename attr on interface to css filter
21:35:15 [nimbu]
anne: i dont think there is a middle ground
21:35:24 [nimbu]
anne: ecmascript guys hate the document.all as it is hidden
21:35:35 [nimbu]
anne: that is the pattern we dont want to follow
21:35:46 [nimbu]
anne: i dont know why we didnt go with that.
21:35:52 [nimbu]
anne: it is for attr exposed on css style decl
21:35:59 [nimbu]
anne: and style decl values
21:36:05 [nimbu]
smfr: is it coz ie claimed filter
21:36:07 [nimbu]
anne: yes
21:36:16 [nimbu]
dbaron: we have been shipping
21:36:19 [nimbu]
ed: also opera
21:36:27 [nimbu]
ed: its not a big problem
21:36:35 [nimbu]
ed: not many sites are broken
21:36:39 [nimbu]
dino: we should also ask ms
21:36:53 [nimbu]
pdengler: we see this coming anyway. i dont know what our avenues are to change.
21:37:00 [nimbu]
pdengler: i think we have some mitigations
21:37:08 [nimbu]
heycam: u can still support if the syntax is right
21:37:16 [nimbu]
pdengler: we are okay on this one if you want to keep style.filter
21:37:22 [nimbu]
pdengler: sylvaing?
21:39:47 [nimbu]
ed: see if we can publish smthing so people know where we are
21:40:11 [nimbu]
dino: we are happy to publish it
21:40:59 [nimbu]
ChrisL: there are sm people who are not rep here.
21:41:05 [nimbu]
dbaron: this is pretty much a full css meeting hre.
21:41:28 [dbaron]
We've been shipping since Firefox 4... so not all that long, but we have shipped it.
21:41:32 [nimbu]
RESOLVED: publish the drafts as soon as the edits are done.
21:42:24 [nimbu]
ACTION: ChrisL to check whether or not filters spec sounds as a new draft or not
21:42:24 [trackbot]
Created ACTION-47 - Check whether or not filters spec sounds as a new draft or not [on Chris Lilley - due 2011-08-02].
21:42:48 [nimbu]
21:43:07 [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./
21:43:36 [nimbu]
dino: moving to css / svg animations.
21:43:43 [nimbu]
ed: we have half an hour before break.
21:44:04 [ed]
Topic: CSS / SVG animations
21:44:11 [birtles]
21:44:49 [nimbu]
birtles: seems like there are diff ideas on where we are heading.
21:45:05 [nimbu]
birtles: check if we are on same page where we want to end up with animations in the long run
21:45:16 [szilles]
szilles has joined #fx
21:45:18 [nimbu]
birtles: see how feasible it is to merge them
21:46:24 [tantek]
21:46:51 [tantek]
21:46:56 [birtles]
21:47:57 [nimbu]
birtles: the target of animation is diff svg is 1 attr on an elm, css is more flex
21:48:11 [nimbu]
birtles: its smthing we need to fix in svg
21:48:51 [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
21:49:14 [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.
21:49:19 [nimbu]
smfr: we would like to be able to do
21:49:19 [ChrisL]
its a common use case to apply multiple animations
21:49:32 [nimbu]
smfr: we ahve talked about adding it to css for a while
21:50:00 [nimbu]
vhardy: having same model as smile would help.
21:50:00 [ChrisL]
yes, i think its needed and the sandwich model works well
21:50:18 [nimbu]
birtles: one complication is there are rules, and its a grey area
21:50:31 [szilles]
21:51:04 [ChrisL]
s/same model/same sandwich model/
21:51:18 [nimbu]
birtles: animation types how to do interpolation.
21:51:42 [nimbu]
birtles: interval timing is quite diff
21:52:03 [ChrisL]
lets get rid of wallclock, please
21:52:09 [nimbu]
birtles: css does not have complexity of svg
21:52:39 [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.
21:53:10 [nimbu]
birtles: multiple intervals, and syncbase
21:53:22 [nimbu]
ChrisL: do we find that syncbase stuff is getting used well?
21:53:46 [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
21:53:53 [nimbu]
birtles: i am concerned people are using it
21:54:36 [nimbu]
vhardy: what do you mean by you dont want syncbase?
21:54:53 [nimbu]
birtles: SMIL has 2 diff features for kicking off anims
21:55:06 [nimbu]
birtles: when an animation ends/starts, when I get an event
21:55:31 [nimbu]
birtles: basically maintain network of times and work out how to break that network
21:55:40 [nimbu]
birtles: u can hv -ve offsets
21:56:07 [nimbu]
birtles: event based is easier
21:56:16 [nimbu]
shepazu: to implement?
21:56:25 [nimbu]
birtles: yes for authors syncbase is better it is more predictable.
21:56:44 [nimbu]
ed: in most cases u dont want two sync anims to start slightly off, want it to same at same time
21:56:53 [nimbu]
heycam: u can fudge it.
21:57:07 [nimbu]
birtles: SMIL sez put event timestamp and use that.
21:57:25 [nimbu]
vhardy: syncbase can give u a way to get perfect sync
21:57:31 [ed]
s/same at same/start at same/
21:57:36 [nimbu]
birtles: time containers can give u that for most of use cases.
21:57:43 [nimbu]
dino: whats an e.g of time container?
21:58:06 [nimbu]
vhardy: difficulty is in spec hard to wrap head around, impl. is not that much code.
21:58:19 [nimbu]
vhardy: once u know what to do, its not that bad.
21:58:40 [nimbu]
birtles: i have test cases which werent working on other browsers. cycling dependencies SMIL has rules to break them but not impl. consistently.
21:58:48 [nimbu]
vhardy: it takes a couple of iterations to get right
21:58:55 [smfr]
21:59:01 [nimbu]
heycam: it is complex to understand as well.
21:59:14 [birtles]
22:00:04 [nimbu]
birtles: svg lacks some things for timing fns
22:00:17 [nimbu]
birtles: has timing mode mostly for motion on a path.
22:00:30 [nimbu]
birtles: svg does not hve reversing, smthing we should add.
22:00:36 [ChrisL]
adding reversing would be very helpful
22:00:36 [nimbu]
birtles: its not too different.
22:01:00 [nimbu]
birtles: its unfortunate the names are diff between css anims and svg.
22:01:26 [nimbu]
birtles: css takes a snapshot, svg everything is live
22:01:33 [nimbu]
shepazu: i dont understand what you mean
22:01:48 [ChrisL]
you mean for the actual animation atributes themselves via dom, right
22:01:56 [nimbu]
dino: if you change duration, transition during animation it does not change the animation itself
22:02:17 [nimbu]
dino: SMIL allows you to manipulate prop of animations while you animate.
22:02:27 [nimbu]
birtles: if you do try to merge these two, this needs to be resolved.
22:03:10 [nimbu]
birtles: svg makes everything declarative. css assumes you can use script to cancel anims
22:03:25 [nimbu]
birtles: we want to maintain decl. approach in svg
22:03:58 [nimbu]
vhardy: it is not obv what timing model is for css animations.
22:04:26 [nimbu]
birtles: svg has a notion of outermost element is a time container.
22:05:00 [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
22:05:11 [bradk]
speak up!
22:05:17 [nimbu]
birtles: do u want to be able to schedule multiple intervals.
22:06:33 [nimbu]
birtles: i suppose if we add time containers anyway we dont need to do that.
22:07:03 [nimbu]
smfr: time 0 is where load event fired?
22:07:17 [nimbu]
smfr: you might want to start animations when page is loading.
22:07:31 [nimbu]
ed: in tiny 1.2 we do it on start coz of same problem
22:07:40 [nimbu]
pdengler: there is more usage of css than svg
22:07:56 [nimbu]
pdengler: SMIL is more sophisticated and complex and causes problems in syntax and merging
22:08:10 [ed]
s/in tiny 1.2 we do it on start coz of same problem/in tiny 1.2 there is timelineBegin=onStart which solves that problem/
22:08:20 [nimbu]
pdengler: given css syntax is being more quickly adopted by webdevs, shouldnt that be…
22:08:57 [nimbu]
pdengler: anecdotal, i have seen more css anims than svg. the css syntax is better absorbed. coz there is complexity merging seems scary to me
22:09:08 [nimbu]
birtles: thats exact q i wanted to talk about
22:09:30 [nimbu]
pdengler: i think css anims is picking up.
22:09:33 [ChrisL]
questio for pat, if we end up still with two separate specs will IEnext implement only the css one?
22:10:21 [nimbu]
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.
22:10:33 [nimbu]
birtles: #2 seems difficult, and I am nots o sure its impossible.
22:10:56 [nimbu]
birtles: looking at 1 and 3. if we were to drop svg animations, we would need to add some features to achieve feature-parity.
22:12:05 [nimbu]
anne: are the missing features in wide use?
22:12:49 [nimbu]
florian: probably got a bunch of uis written in svg
22:12:59 [nimbu]
anne: at some point it will die out
22:15:28 [anne]
I so support Microsoft for once
22:15:42 [nimbu]
shepazu: we all agree we want one model
22:16:29 [nimbu]
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.
22:17:18 [nimbu]
vhardy: i would focus on what features we need. timing model. recommend we use SMIL as resource
22:17:40 [nimbu]
vhardy: i am okay with a new syntax.
22:17:51 [nimbu]
pdengler: i dont disagree with we need feature parity.
22:18:07 [nimbu]
shepazu: i prefer the element syntax to css syntax, but i dont remember my rationale.
22:18:13 [anne]
(With saying no to SVG Animation / SMIL)
22:18:34 [nimbu]
heycam: the syntax is the sticking point here.
22:20:46 [ChrisL]
doug is saying the stae chart stuff is one example where an element based syntax helps
22:21:00 [nimbu]
dino: is there a way to get to option 2 by changing the way SMIL currently is.
22:21:36 [nimbu]
smfr: when we talk about css animations we need css anims plus js.
22:21:43 [nimbu]
smfr: we cant put all of svg into decl. css
22:22:01 [nimbu]
dino: hope to come up with api that can be shared
22:22:09 [nimbu]
dino: can we map that api to SMIL
22:22:49 [nimbu]
vhardy: u need a decl way of animations.
22:23:37 [nimbu]
shepazu: wiling to see how far we can go with css syntax
22:23:56 [nimbu]
shepazu: just dont develop it further
22:24:39 [nimbu]
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.
22:24:51 [nimbu]
vhardy: we tried to work on exporting timings to animations, it is hacky stuff.
22:25:13 [ChrisL]
so we could end up paiting ourselves into a corner that can't for example animate things before the document completely loaded
22:25:13 [nimbu]
pdengler: css animations does not have the right stuff, then how is smil going to apply to html.
22:25:50 [szilles]
szilles has joined #fx
22:26:30 [bradk]
break time?
22:27:06 [bradk]
afternoon snacks must have arrived
22:27:10 [bradk]
22:28:57 [ed]
break 15min yes
22:43:31 [florian]
florian has left #fx
22:43:33 [szilles]
szilles has joined #fx
22:43:37 [florian]
florian has joined #fx
22:47:11 [nimbu]
ed: should we go thro the options, or do we have strong objections to #1.
22:47:28 [nimbu]
birtles: i am uncomfortable pushing all complexity to css
22:47:34 [nimbu]
birtles: okay dropping SMIL
22:47:48 [ed]
s/or do we have strong objections to #1./do we have strong objections to #1?/
22:48:51 [nimbu]
anne: why do u want angle bracket syntax
22:49:15 [nimbu]
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
22:49:33 [nimbu]
birtles: it can get complicated
22:49:59 [nimbu]
dino: if u think about a complex animations, you may have to put an id on every element and might have overhead on performance.
22:50:08 [nimbu]
tantek: would be great to see illustrative e.g.
22:50:41 [nimbu]
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
22:50:57 [nimbu]
anne: with xml u only get string manipulation by default which is not really right.
22:51:06 [nimbu]
birtles: how to change this attr, all apis already exist for that.
22:51:53 [nimbu]
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.
22:52:25 [nimbu]
heycam: it seems odd to me to have CSS anims affecting dom attr and not property values
22:52:38 [nimbu]
dino: i am not comfortable having css anims affect dom
22:52:50 [nimbu]
anne: what u mean by dom attr
22:53:02 [nimbu]
heycam: like x, y, attr on rect
22:53:16 [nimbu]
heycam: its not a big deal in html as u dont animate things that are not properties.
22:53:28 [nimbu]
heycam: many geometry things are attr and not properties
22:53:44 [nimbu]
heycam: i had a proposal to make attr properties, but it did not get traction.
22:53:56 [birtles]
22:54:10 [nimbu]
dino: pollution of property, potential classes, were arguments against
22:54:39 [szilles]
szilles has joined #fx
22:54:50 [nimbu]
heycam: if we used shape-left instead of x, would lose the fact that attr and property would have same name.
22:54:52 [dino]
22:55:00 [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)
22:55:04 [nimbu]
vhardy: we stopped short of that we did not bring it to csswg.
22:55:14 [nimbu]
heycam: i thought TabAtkins mailed www-style with diff options
22:55:18 [dino]
dholbert, he does mention it
22:55:20 [nimbu]
TabAtkins: i dont recall getting much of a response.
22:55:44 [dbaron]
Why not 'left' <=> @x, etc.
22:56:42 [nimbu]
vhardy: we should have prioritized list of req of what we need to put in.
22:57:16 [nimbu]
vhardy: set of animation feature sets that can work on svg, css, html
22:57:20 [heycam]
dbaron, there are a few properties that map ok like that, not all
22:57:26 [nimbu]
vhardy: and then see if we can push css animations to that or not.
22:57:28 [heycam]
dbaron, also suffers from the fact that it's a different name
22:58:07 [nimbu]
ACTION: dino to write up use-cases and priority list of features to be added to css animations
22:58:08 [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].
22:58:29 [nimbu]
dino: we can make a wikipage
22:59:21 [tantek]
"color-correction" as mentioned/discussed here (I don't think it's been discussed since)
22:59:33 [ed]
topic: color correction
23:00:12 [dbaron]
23:00:26 [nimbu]
tantek: has there been any update on this front?
23:00:56 [nimbu]
ChrisL: one of the versions of mac os x changed from gamma of 1.8 to 1.2 it means throwing stuff on current macs should be same as current PCs.
23:01:06 [nimbu]
ChrisL: it used to be that macs had diff gamma correction.
23:01:21 [nimbu]
smfr: its not just about gamma correction but finding ways to authors to map css colors to images
23:01:32 [nimbu]
ChrisL: the way we can do that, is to keep untagged images as sRGB
23:01:43 [nimbu]
dbaron: is there any browser where untagged images and css colors mismatch?
23:01:48 [ChrisL]
23:02:09 [nimbu]
dbaron: 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
23:02:09 [krijnh]
(Should I publicly log this channel as well?)
23:02:25 [nimbu]
smfr: webkit has a property for color correction.
23:02:34 [krijnh]
anne: ^^
23:02:41 [nimbu]
dbaron: i did put the stuff we discussed in a draft on didnt do anything in that draft.
23:02:45 [nimbu]
dbaron: it needs more work
23:02:45 [ChrisL]
rrsagent, here
23:02:45 [RRSAgent]
23:02:53 [ChrisL]
this is already logged btw
23:03:45 [nimbu]
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.
23:03:45 [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].
23:03:45 [ChrisL]
it would be good to knw if those pages are safari specific
23:03:51 [smfr]
23:04:25 [anne]
krijnh, yeah
23:04:25 [ChrisL]
the problem with this is that it removes sRGB as a baseline and replaces 'dio what you want' as the baseline
23:04:31 [krijnh]
And offline once in a while :)
23:04:36 [nimbu]
tantek: do u have doc of support somewhere?
23:04:39 [nimbu]
smfr: will check.
23:04:42 [anne]
krijnh, if you can handle that :)
23:04:47 [nimbu]
tantek: post url to doc if it exists.
23:04:52 [krijnh]
anne: fixing the auto cache refresh thing right now
23:05:28 [nimbu]
Topic: SVG parameters in CSS in relation to CSS Variables
23:05:29 [ChrisL]
s/throwing stuff/throwing stuff at the screen/
23:05:48 [shepazu]
23:07:15 [tpod]
tpod has joined #fx
23:07:45 [nimbu]
shepazu: we would like to consider csswg want to do smthing like this.
23:08:00 [nimbu]
TabAtkins: in ref to combining efforts, csswg is interested in pursuing vars.
23:08:35 [krijnh]
anne: done, every night around 00:10
23:08:38 [nimbu]
TabAtkins: params can work in with concept of vars such that you would put params and they would create vars.
23:08:48 [krijnh]
Windows Task Scheduler ftw :')
23:09:38 [tpod_]
tpod_ has joined #fx
23:09:39 [nimbu]
shepazu: i thought you would decl. canonical what is the var, and explicitly say this would be the param for that var
23:09:47 [nimbu]
TabAtkins: urs is probably a better idea.
23:10:16 [anne]
23:10:42 [krijnh]
anne, hober: logging this channel as well, will add them to my site somewhere this week
23:10:57 [nimbu]
shepazu: # syntax has been overloaded by media fragments.
23:11:19 [nimbu]
shepazu: 3rd syntax is x-pointer style function that enclose vars in would be best way forward.
23:11:43 [nimbu]
shepazu: imagine those are .css files. you are passing in a list of parameters within paranthesis
23:11:55 [smfr]
23:12:07 [shepazu]
fill="param(color) blue"
23:12:29 [nimbu]
shepazu: if param is not passed in, use this keyword
23:13:09 [shepazu]
23:13:31 [tpod]
Thanks everyone. I'll keel lurking as long as this connection holds.
23:13:42 [nimbu]
shepazu: is there any problem with this?
23:13:43 [tpod]
23:14:16 [nimbu]
heycam: for vars you know ahead of time.
23:15:36 [nimbu]
florian: csswg did not express interest in variables but only allow tab to work on his draft.
23:16:19 [nimbu]
florian: vars were global to the page, but params are stylesheet local and would make people who hate variables hate them more
23:17:32 [nimbu]
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
23:17:57 [nimbu]
TabAtkins: some of the qs raised against my proposal are valid here. are they changable by script?
23:17:59 [nimbu]
shepazu: yes
23:18:17 [nimbu]
shepazu: the HTML WG is not interested in changing the params thing
23:18:35 [nimbu]
TabAtkins: presumably there would some script based api to easily handle them rather than parse them urself
23:18:52 [nimbu]
shepazu: smone proposed a url parsing api.
23:18:57 [nimbu]
anne: adam barth is working on that.
23:19:05 [nimbu]
shepazu: maybe we just plug this into abarth's thing
23:19:10 [nimbu]
anne: is this not like param elms?
23:19:18 [nimbu]
shepazu: at one point it was, but they didnt like that.
23:19:27 [nimbu]
heycam: as in specify value of params in the url.
23:20:05 [nimbu]
shepazu: there are param elements. if only thing we can do is url syntax that is okay with me
23:20:18 [nimbu]
shepazu: this is a diff kind of param passing
23:20:35 [nimbu]
heycam: adam barth proposed to get query string, this is stuff embedded in frame.
23:20:46 [nimbu]
heycam: its going to hit the network every time.
23:21:21 [nimbu]
TabAtkins: i dont like the way u are defining right now to use a param with default val.
23:21:30 [nimbu]
TabAtkins: u cannot use the syntax if you use fill property in css.
23:23:24 [nimbu]
TabAtkins: if u want default values on params pre decl them
23:23:47 [nimbu]
shepazu: that was in org version of spec, but dropped as people didnt like
23:24:19 [nimbu]
shepazu: what would be better for css
23:24:42 [nimbu]
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
23:24:45 [ChrisL]
%20 is your freind
23:24:55 [ChrisL]
url escaped space
23:25:16 [nimbu]
ACTION: shepazu propose a couple of diff syntax and submit them for wider review and see what people think about them and ping csswg
23:25:16 [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].
23:25:28 [nimbu]
TabAtkins: nothing to do with spaces in param decl but in param use
23:26:12 [nimbu]
TabAtkins: param blue foo is ambiguous if you are specifying fallback or another value
23:26:31 [ChrisL]
syntactic spaces considered harmful. syntactic spaces as ancestor selectors, doubly so
23:26:38 [nimbu]
TabAtkins: if u use param in a path, it would be THE example.
23:27:01 [plinss_]
param(name, default)
23:28:37 [ed]
Topic: FX transforms
23:28:37 [ed]
23:29:09 [nimbu]
vhardy: agree on how we can go about doing this. I can help with editing the doc.
23:29:17 [nimbu]
heycam: who are editors of current doc?
23:29:27 [nimbu]
vhardy: dean chris simon and we also had anthony
23:29:40 [nimbu]
vhardy: what we want here is to understand what we need as next step.
23:30:04 [nimbu]
vhardy: i just want to know how we go about producing a new document.
23:30:21 [nimbu]
dino: you run into issue of how to combine with svg if u call it css transforms
23:31:00 [nimbu]
vhardy: soln is to say its css transform. there are only 2 ways to combine them.
23:31:24 [nimbu]
heycam: i seem to be the only one in fav of turning into a property
23:31:51 [nimbu]
heycam: the fact that transform dom attr does not translate to property names…
23:32:08 [nimbu]
heycam: arg against turn into property is what svg dom access to transform stuff means. i dont think its impossible to design smthing
23:32:46 [nimbu]
vhardy: if we agree on putting together a doc. we agree on intent to combine them.
23:32:58 [nimbu]
smfr: want a time frame as we already have implementations of css transforms
23:33:09 [nimbu]
vhardy: is it okay if we try to advance 2d first and then 3d
23:33:43 [nimbu]
smfr: it is simple to have 1 doc, but we have multiple impl. of 2d transforms.
23:33:55 [nimbu]
dbaron: we are getting a few pieces of 3d transforms in
23:34:08 [nimbu]
shepazu: by the time we finish this spec would we not have 2 impl.
23:34:13 [nimbu]
vhardy: is that not likely?
23:34:18 [dbaron]
23:34:29 [nimbu]
smfr: for 3d transforms the impl would be more widely varied.
23:34:59 [nimbu]
smfr: there are no obv conflicts in om.
23:35:04 [szilles]
szilles has joined #fx
23:35:16 [nimbu]
sylvaing: i wouldnt want to take risk of doing 3d if smthing changes in 2d.
23:35:32 [nimbu]
dino: that relies on css om. we removed that css values have still been deprecated.
23:35:43 [nimbu]
sylvaing: we need a better def for 3D anyway.
23:35:52 [nimbu]
vhardy: goes into direction of might as well have one spec.
23:36:23 [nimbu]
shepazu: is anyone not using 2d transforms coz its not standardized?
23:36:33 [nimbu]
dbaron: it is a pain for the authors coz of prefixes
23:36:39 [nimbu]
shepazu: bigger pain if we get it wrong
23:36:54 [nimbu]
sylvaing: do i prefix only 3d?
23:37:03 [nimbu]
smfr: fair point as you can mix 2d & 3d functions
23:37:15 [nimbu]
heycam: are there no more open issues on 2d?
23:37:24 [nimbu]
smfr: there are def issues w.r.t svg and css
23:37:43 [nimbu]
smfr: the issue with dropping prefix on 2d and not on 3d might have a workaround.
23:38:04 [nimbu]
smfr: it is possible to pass 3d transform functions, and throw away the z parts.
23:38:20 [nimbu]
dino: if they wanted to do 3d they can use prefix and the prefixed one beats the unprefixed one.
23:38:30 [nimbu]
smfr: you wouldnt want to do that.
23:38:41 [nimbu]
vhardy: my pref is to make it one doc and work out the issues we have and move forward.
23:38:52 [nimbu]
smfr: ideally that would be mine too, but i think it would take 2 years
23:39:17 [nimbu]
vhardy: it does not hurt to have one spec if its the hold up.
23:39:40 [nimbu]
dino: we say we want to know what it should be.
23:40:18 [nimbu]
anne: the thing with om you cant really pull transforms in front of designing the value api.
23:40:33 [nimbu]
smfr: transforms are a good test case for value api
23:40:45 [nimbu]
sylvaing: try to drop prefixes on the property but the om can have the prefixes.
23:41:02 [nimbu]
smfr: probably apply the same for gradients
23:41:24 [tpod]
tpod has joined #fx
23:41:32 [nimbu]
anne: webkit still has the old value api. all the new apis are designed around premise of keeping around that api.
23:41:42 [nimbu]
anne: that seems bad as we abandonded it around 2003 or 4
23:41:57 [nimbu]
shepazu: this does not resolve question of svg and css
23:42:05 [nimbu]
smfr: does resolve prefix droppping on 2d and not on 3d
23:42:26 [nimbu]
anne: why cant we drop for 3d.
23:42:47 [nimbu]
smfr: we dont have more than 1 impl and there will be lots of issues when there are more.
23:43:03 [nimbu]
dbaron: i would be interested in figuring out what you do wrong.
23:43:44 [nimbu]
dino: would property change even if impl is undefined.
23:44:00 [nimbu]
smfr: the values and property are fairly stable. svg might add a few things.
23:44:05 [nimbu]
smfr: there is an issue with units in matrix
23:44:23 [nimbu]
dbaron: issue of whether we want px as base unit, or get unit right in "some sense"
23:44:39 [nimbu]
dbaron: i am less confident in the stability of other properties in 3d transforms.
23:45:08 [nimbu]
smfr: we should start filing issues somewhere
23:45:28 [nimbu]
shepazu: it seems like people think this is priority. is that right?
23:45:31 [nimbu]
smfr: i think so.
23:45:49 [nimbu]
shepazu: we can make lot of progress if we start pushing this.
23:46:17 [nimbu]
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
23:46:46 [nimbu]
ChrisL: it is better that way to style if we multiply together
23:47:27 [nimbu]
dino: it becomes harder if you want to make all svg attr properties then you would have two properties
23:47:39 [nimbu]
heycam: convert to property and use css one.
23:47:42 [ChrisL]
"we dont need to keeparound SVG transforms" uh huh, make every single piece of svg non conformant at a stroke ....
23:48:19 [nimbu]
heycam: what do others think about turning svg transform attr into a property
23:48:24 [ChrisL]
turning it into a property makes it apply to all elements
23:48:48 [nimbu]
shepazu: deal with legacy transform attr deal with it as we did, going forward use css transforms
23:49:03 [nimbu]
heycam: i dont want to put transform inside style.
23:49:36 [nimbu]
shepazu: whats the downside
23:49:51 [nimbu]
heycam: we need to make sure the syntax is compat and make sure existing one would work
23:50:22 [nimbu]
heycam: needto define what access to SVG transform means
23:50:48 [nimbu]
heycam: i think we can come up with smthing reasonable.
23:50:58 [nimbu]
heycam: i was hoping we would resolve syntax comat problems anyway.
23:51:08 [nimbu]
??: would 3d apply to svg.
23:51:13 [nimbu]
heycam: there are plans to.
23:51:28 [nimbu]
vhardy: smfr u were talking about applying 3d transforms to svg right?
23:51:32 [nimbu]
smfr: yep
23:51:59 [stearns]
23:53:26 [smfr]
ChrisL: you're rustling
23:53:42 [nimbu]
ed: look at … in svg tiny
23:54:36 [ed]
s/look at … in svg tiny/look at TraitAccess in svg tiny 1.2, it allows fetching both baseVal and animVal for properties as well as for normal attributes/
23:56:26 [nimbu]
RESOLVED: Turn transform attribute into a CSS property and heycam to investigate and write a proposal to what SVG DOM does in this situation
23:56:44 [nimbu]
ACTION: heycam to investigate and write a proposal to what SVG DOM does when svg transform attribute becomes a css property
23:56:44 [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].
23:56:53 [nimbu]
dino: we still got the question on merging the spec.
23:57:34 [nimbu]
dino: the transforms spec requires units in translations.
23:57:40 [nimbu]
smfr: transform-origin changes
23:57:53 [nimbu]
heycam: u still worried about slight differences in svg and css.
23:57:55 [ChrisL]
yeah lets kill the units requirement
23:58:23 [nimbu]
dino: making one unified spec isnt just adding 3d stuff but also combining unitless and united transform fns and maybe differences in transform origin
23:59:34 [nimbu]
heycam: we should try to resolve any diff we can and put the restl as slight differences between presentation and property
23:59:56 [nimbu]
ed: some of the issues have been resolved in fx transforms draft e.g. transform-origin has been resolved.