20:57:32 <RRSAgent> RRSAgent has joined #fx
20:57:32 <RRSAgent> logging to http://www.w3.org/2012/12/10-fx-irc
20:57:34 <trackbot> RRSAgent, make logs world
20:57:34 <Zakim> Zakim has joined #fx
20:57:36 <trackbot> Zakim, this will be 3983
20:57:36 <Zakim> ok, trackbot; I see GA_FXTF()4:00PM scheduled to start in 3 minutes
20:57:37 <trackbot> Meeting: CSS-SVG Task Force Teleconference
20:57:37 <trackbot> Date: 10 December 2012
20:58:19 <Zakim> GA_FXTF()4:00PM has now started
20:58:26 <Zakim> + +1.415.832.aaaa
20:58:45 <krit> zakim, aaaa is me
20:58:45 <Zakim> +krit; got it
20:58:51 <Zakim> +Doug_Schepers
20:59:14 <Zakim> +Lea
20:59:21 <Zakim> +plinss
20:59:51 <smfr> smfr has joined #fx
21:00:04 <Zakim> + +1.408.636.aabb
21:00:11 <smfr> Zakim, aabb is me
21:00:11 <Zakim> +smfr; got it
21:00:25 <Zakim> +cabanier
21:00:35 <Zakim> +??P13
21:00:40 <cabanier> cabanier has joined #fx
21:00:53 <ed> Zakim, ??P13 is me
21:00:53 <Zakim> +ed; got it
21:01:12 <ed> chair: ed
21:01:18 <Zakim> +nikos
21:01:20 <ed> Agenda: http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0071.html
21:01:50 <smfr> smfr has changed the topic to: http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0071.html
21:02:01 <Zakim> +??P15
21:02:27 <heycam|away> heycam|away has joined #fx
21:02:27 <dino> dino has joined #fx
21:03:45 <Zakim> +??P19
21:03:47 <heycam|away> Zakim, ??P19 is me
21:03:47 <Zakim> +heycam|away; got it
21:04:10 <heycam> Chair: Erik
21:04:13 <heycam> Scribe: Cameron
21:04:15 <heycam> ScribeNick: heycam
21:04:34 <heycam> Topic: filter effects, new syntax proposal for custom filter function
21:04:36 <krit> http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0070.html
21:04:49 <heycam> krit: summary of the different proposals here
21:04:54 <heycam> number 0 is in the working draft now
21:04:58 <heycam> url inside the custom function
21:05:06 <heycam> … the problem with that one is that it's not very future proof
21:05:21 <heycam> … if you have new shader languages, the syntax won't work any more
21:05:30 <heycam> … I think we should think about a new syntax for this
21:05:40 <heycam> … proposal #1 is a custom filter at-rule
21:05:51 <heycam> … different descriptors that match the particular shader language format
21:06:13 <heycam> … proposal #2 is something similar to @font-face
21:06:22 <heycam> … a generic @filter rule, with a url and format
21:06:51 <heycam> … issues with #1 is that you need different descriptor definitions for different shader types
21:06:55 <heycam> s/types/languages/
21:07:09 <heycam> … it's a bit of a burden in my opinion
21:07:15 <heycam> … I prefer the generic src descriptor with url/format
21:07:27 <heycam> … and the shader language would be described by a new format
21:07:33 <heycam> … could be done with XML or whatever
21:07:43 <heycam> … but it is something different, outside the style sheet
21:07:54 <hober> hober has joined #fx
21:07:58 <heycam> … on the mailing list it seems an at-rule would be ok, just a question of how it looks like
21:08:00 <krit> krit has joined #fx
21:08:00 <cabanier> cabanier has joined #fx
21:08:06 <heycam> … I'd like to have more people involved in the proposal and get more feedback on that
21:08:13 <heycam> … and get to a resolution soon
21:08:22 <heycam> dino: I suggest putting something in the WD using an at-rule
21:08:25 <heycam> … and then wait for comments
21:08:48 <heycam> … I think ultimately the idea of a separate format to describe a shader package is a good one, except we run into the problem of it being really hard to adopt tnew formats on the web
21:08:59 <heycam> … I think we should start with the step of having the at-rule
21:09:02 <heycam> … in the draft
21:09:12 <heycam> krit: the editors have started some work on the at-rule proposal
21:09:20 <heycam> … do we want to differ between fragment/vertex shaders?
21:09:27 <paul___irish> paul___irish has joined #fx
21:09:33 <heycam> … I agree it's harder to handle a new external format
21:09:39 <heycam> … there'll be disagreement about the format
21:09:46 <heycam> dino: I suggest we head towards #2 to start with
21:10:09 <heycam> … without using terms like "fragment", "vertex", etc.
21:10:14 <heycam> … at least initially
21:10:23 <heycam> … I think we should publish something as a WD and see what happens
21:10:36 <heycam> ed: I agree, proposal #2 is the one that feels more natural to me, most CSS-y
21:11:00 <dsheets> will Filter Effects 1.0 still define the mesh/blending operational model? why will these semantics be absent from CSS?
21:11:05 <heycam> krit: would anyone say that we should never ever try to create an external shading language description language?
21:11:32 <heycam> heycam: I think we should try to avoid it if we can
21:11:55 <heycam> ed: it depends on what you want to put in the files
21:12:07 <heycam> … if you just take a fragment shader, it's just a text string, that's what you feed to the implementation
21:12:20 <heycam> … it depends how much structure you want to have in that external file
21:12:32 <heycam> krit: the XML format we came up with as a first draft was quite simple
21:12:40 <heycam> … you have a <fragment> and <vertex> element and it's cdata, that's all
21:12:46 <dsheets> and does not support many important use cases
21:12:50 <heycam> … <parameter> elements would let you specify the params for the shading langauge
21:13:04 <heycam> smfr: can you post a link to the example file?
21:13:05 <dsheets> and would be have CSS override analogs
21:13:22 <krit> http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0054.html
21:14:07 <heycam> krit: I don't need a resolution now, but I'd encourage people to contribute to the discussion
21:15:15 <heycam> heycam: I think it's less controversial to just stick it all in the at rule instead of coming up with a new format
21:15:24 <shepazu> +1
21:15:30 <dsheets> a new format can always be compiled to the at-rule
21:15:44 <dsheets> XML -> CSS easy, CSS -> XML harder
21:15:51 <heycam> Topic: blending and compositing
21:16:19 <cabanier> links: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#box-shadow-mix-color
21:16:26 <cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#text-shadow-mix-color
21:16:34 <leaverou> q+
21:16:35 <heycam> cabanier: I've put placeholders in the spec right now
21:16:46 <heycam> … most shadows, in our products, don't use the regular compositing when they are drawn
21:16:56 <heycam> … people like to do multiply or other effects to make the shadows more pleasing
21:17:11 <heycam> … right now those properties are in the compositing spec, but I think they would be better in the text/background/borders specs
21:17:23 <heycam> … that would let you write them in the same shadow syntax
21:17:32 <heycam> … but with the spec today you'd need two properties
21:17:46 <heycam> krit: we have the same issue with filter effects and CSS masking, you might want to just target the background
21:17:54 <heycam> … fantasai asked for a general solution extensible for the future
21:17:58 <heycam> … but no proposal for that yet
21:18:16 <leaverou> http://lists.w3.org/Archives/Public/www-style/2012Dec/0005.html
21:18:18 <heycam> leaverou: I posted to the CSS/FX lists
21:18:30 <heycam> … I really disagree with the mix-color nam
21:18:40 <heycam> … anything ending with -color looks like it takes a colour value
21:18:53 <heycam> … I also think we're tring to keep modules decoupled
21:19:08 <heycam> … we'd need to add properties in at least background/borders and text
21:19:17 <heycam> … if we want different filters for these things, we'd need even more properties
21:19:35 <heycam> … I think this is trying to accommodate a rare use case with a syntax that's not elegant
21:19:45 <heycam> cabanier: which is the non elegant syntax?
21:19:51 <heycam> leaverou: adding more css properties is inelegant
21:20:13 <heycam> … from discussions with implementors, it sounded like more properties is worse for performance, takes more memory per element
21:20:32 <heycam> … I think it would be better to have a property like transition, that takes a comma separated list, saying which part the effect applies to
21:20:50 <heycam> … you couldn't have different effects applying to different parts of the box
21:20:55 <heycam> … but I think that's a rare enough use case
21:21:12 <heycam> … different effects for different background images on the one element
21:21:18 <heycam> cabanier: I can only speak to how it's done in photoshop/illustrator
21:21:28 <heycam> … you can overlay shadows and they don't use the default blend mode
21:21:35 <heycam> … the stuff that adobe generates it's common
21:21:51 <heycam> leaverou: I agree, but in photoshop you can only apply one shadow per layer, there's no other way to do it
21:22:03 <heycam> … you can't use different shadows to the one layer with different effects
21:22:18 <heycam> … you can actually do it, if you need different blending modes for different background images, you can split it up into separate elements
21:22:30 <heycam> cabanier: WebKit has different compositing modes for different background images, even though it's not really documented
21:22:38 <heycam> … there is quite a bit of content out there that uses it
21:22:49 <heycam> … I'm not sure how useful it is, but it seems like some people would use it
21:23:03 <heycam> … I think an at-rule would make it more confusing
21:23:31 <heycam> smfr: I think that was added as a hack for dashboard
21:23:38 <heycam> … I would be surprised if it's widely used on the web
21:23:46 <heycam> … I don't think we should go by the usage of that particular property
21:23:54 <heycam> cabanier: even though it's not well document, I think some people are using it
21:24:00 <heycam> … but not advocating for it one way or the other
21:24:20 <heycam> leaverou: as an author, I think I'd use a multiply on a shadow for the entire thing, not different modes to different layers of shadows
21:24:25 <heycam> cabanier: I think it's reasonable, I agree
21:24:45 <heycam> … so it might be useful for a text shadow, but to all the shadows at once
21:24:55 <heycam> … the syntax I wrote doesn't allow for that
21:25:02 <heycam> krit: how do we combine these in the future?
21:25:06 <heycam> … compositing, blending, filters...
21:25:13 <heycam> cabanier: that was the original question
21:25:18 <heycam> … do we split it up into multiple specs?
21:25:44 <heycam> krit: I think it's a bad idea to split this up into the other specs
21:25:54 <heycam> … if it's affecting background and borders, it should be in that spec
21:26:00 <heycam> cabanier: and masking and filters?
21:26:11 <heycam> krit: or we find one specification to define it for everything
21:26:16 <heycam> cabanier: I think B&B could refer to another spec
21:26:26 <heycam> … there are examples of that in there already, e.g. for box-shadow's syntax
21:26:37 <heycam> … we can just say "see these specs" for what the compositing/filtering means
21:27:02 <heycam> krit: so we are opposed to having new properties for all these features?
21:27:05 <heycam> cabanier: looks like it
21:27:13 <heycam> … so new arguments to the existing properties
21:27:19 <heycam> krit: or new properties to take these arguments?
21:27:23 <heycam> cabanier: the fewer properties the better
21:27:45 <heycam> … if nobody has a strong opinion, we can leave it in the spec for now and continue on the mailing list?
21:28:08 <heycam> smfr: I'm not sure I understand the behaviour of these properties
21:28:13 <heycam> … background-mix-compositing
21:28:22 <heycam> … does it describe how it composites with things behind it on the page?
21:28:30 <heycam> cabanier: only on backgrounds compositing with each other
21:28:37 <heycam> … I think that's how WebKit does it too
21:28:48 <heycam> smfr: for the other ones, like box-shadow-mix-color?
21:28:55 <heycam> cabanier: it would blend with everything in the same stacking context
21:29:07 <heycam> smfr: some of these will be extremely hard to implement without a lot of memory
21:29:15 <leaverou> q+
21:29:18 <heycam> cabanier: the spec says the default has non-isolated groups
21:29:23 <heycam> … but I think that's too memory intensive
21:29:32 <heycam> … so I've made it blending only within a stacking context
21:29:40 <heycam> smfr: authors don't necessarily know what stacking contexts are
21:29:58 <heycam> … even implementing it relative to the stacking context, we might end up with a compositing layer between it and the stacking context
21:30:05 <heycam> cabanier: there is a compositing layer that is not a stacking context?
21:30:09 <heycam> smfr: yes, if you have overflow for example
21:30:21 <heycam> cabanier: would that create problems with z-index?
21:30:30 <heycam> smfr: it does for clipping
21:30:41 <heycam> … but it's just an implementation bug
21:30:54 <heycam> … it concerns me how we'll work out how these things work
21:31:06 <heycam> … I'd be happy if they only affect compositing between bits of the same element
21:31:15 <heycam> … borders compositing on top of the background, for example
21:31:23 <heycam> cabanier: for box shadow? there's no background behind it
21:31:36 <heycam> smfr: yes, so you can't easily change how that's composited
21:31:45 <heycam> cabanier: we have an example implementation, I'd like to see how it would go wrong
21:32:02 <heycam> … are you just generally worried about blending of shadows/boxes, not the element itself?
21:32:20 <heycam> smfr: I'm worried about blending across elements, in such a way that the element itself uses different blending modes
21:32:26 <heycam> cabanier: every blending mode creates a stacking context
21:32:44 <heycam> smfr: but for a given element, you have box shadow blending with color-dodge, then text shadow in the same element blending with color-burn say
21:32:53 <heycam> … is that text shadow blending on top of the box shadow?
21:33:01 <heycam> cabanier: yes it should be, they're not compounding operations
21:33:16 <heycam> … you would draw the box shadow, then you'd draw the text shadow on top of that
21:33:24 <heycam> smfr: maybe I need to understand these better
21:33:27 <leaverou> q-
21:33:43 <heycam> smfr: I agree with Lea that these would be obscure use cases
21:33:48 <heycam> … I could understand tools outputting them
21:33:55 <heycam> cabanier: I think authors will want to multiply shadows
21:34:04 <heycam> … it'll look much more pleasing than multiply
21:34:19 <heycam> leaverou: right now authors don't any blending modes
21:34:33 <heycam> … if the authors ask for more behaviour can't we give it to them alter?
21:34:35 <heycam> cabanier: definitely
21:34:52 <heycam> leaverou: it seems if you apply blending mode to the topmost image, not the others, and it blends only with the underneath images
21:34:55 <heycam> … is that right?
21:35:01 <heycam> cabanier: that is how it's currently defined
21:35:05 <heycam> leaverou: I think that will be confusing
21:35:07 <heycam> cabanier: I don't disagree
21:35:13 <heycam> … there's also the point about whether it's implementable
21:35:25 <heycam> … tools are less concerned about memory footprint and performance than browsers do
21:35:39 <heycam> … we can ask for the more natural mode, but it requires a lot of work to implement
21:35:44 <heycam> … but it probably won't get implemented in browsers
21:35:51 <heycam> … we can definitely start with the simple stuff and add more things later
21:35:54 <heycam> leaverou: I think that sounds reasonable
21:36:05 <heycam> cabanier: do you believe people would expect to blend the background and not blend within the backgrounds?
21:36:21 <heycam> leaverou: I think if people apply the blending modes to the top background layer, they would expect to blend with whatever is below it
21:36:28 <heycam> … authors don't understand the implementation restrictions
21:36:37 <heycam> … they would expect it to blend with whatever is below the element
21:36:46 <heycam> cabanier: I think it could be done, but it'd be yet another property to define
21:36:53 <heycam> … if you believe it's more common, I can update the spec for that as well
21:37:03 <heycam> leaverou: I don't have statistics to back it up, but it's my impression as an author
21:37:19 <heycam> cabanier: there was another question about mix-color
21:37:23 <heycam> … people didn't like the name
21:37:32 <heycam> ACTION: cabanier to update box shadow to apply to the whole shadow
21:37:32 <trackbot> Created ACTION-84 - Update box shadow to apply to the whole shadow [on Rik Cabanier - due 2012-12-17].
21:37:42 <heycam> smfr: is there a reason mix-color isn't called blend mode?
21:37:49 <heycam> cabanier: there is a shorthand "mix"
21:38:04 <heycam> … and I think Tab Atkins suggested to break it up into mix-color, mix-composite
21:38:16 <heycam> … Dirk suggested mix-blend, but I think those words mean the same thing
21:38:31 <heycam> krit: I agree with Lea that the prefix/suffix color is normally used for color values
21:38:39 <heycam> … I would expect mix-color takes a color
21:38:52 <heycam> cabanier: it used to be called blend-mode
21:39:06 <heycam> krit: I don't have a problem with mix-blend
21:39:09 <heycam> cabanier: mix-blend-modes?
21:39:12 <heycam> smfr: that sounds ok
21:39:13 <heycam> leaverou: yeah
21:39:29 <heycam> … maybe mix-blending? I think all those suggested ones are better
21:39:44 <heycam> cabanier: I think Tab said that "-ing" isn't used in property names
21:39:48 <heycam> leaverou: ok mix-blend-modes then
21:39:55 <heycam> Topic: CSS Masking
21:40:04 <heycam> ed: first question, trying to resolve mask images on url functions
21:40:13 <heycam> krit: the problem is we have the mask property already
21:40:23 <heycam> … it will be a shorthand for SVG masking and for the WebKit-style masking
21:40:31 <heycam> … WebKit masking is like the background-image, but now mask-image
21:40:34 <heycam> … a list of real CSS3 Images
21:40:36 <ed> http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
21:40:40 <heycam> … that's in conflict with the mask property from SVG
21:40:43 <heycam> … both can take url()
21:40:56 <heycam> … but just from that url(), you don't know if its' a CSS Image value or an SVG mask element reference
21:41:02 <heycam> … we had some discussions on how to fix this issue
21:41:09 <heycam> … we came up with ways to distinguish them
21:41:25 <heycam> … if there is a fragment, then treat it as a reference to an SVG mask element, if you don't then treat it as a CSS Image value
21:41:42 <heycam> … I think the question is, do we want to have the same rule for all things that take url()s?
21:42:03 <heycam> … we have this issue not only for mask, but fill/stroke in SVG, and it could be used for border/background-image in the future
21:42:12 <heycam> … if they can in the future reference an SVG paint server element
21:42:17 <heycam> smfr: I think that's a good long term goal
21:42:24 <heycam> … you risk changing behaviour of existing content
21:42:34 <heycam> … I think it's unlikely people will have used fragments in a CSS SVG image
21:42:51 <heycam> krit: there is this SVG Stacks
21:43:05 <heycam> ed: a technique where you reference a subpart of an SVG, like a sprite sheet
21:43:11 <heycam> … using IDs to select elements inside the SVG
21:43:15 <heycam> krit: this is similar to media fragments
21:43:25 <heycam> … if we use this technique, we can't use media fragments with url()
21:43:45 <krit> http://www.w3.org/TR/css3-images/#image-notation
21:43:45 <heycam> … but CSS Images 3 already suggests to use image() if you want to use media fragments
21:44:02 <heycam> … because all the browser might not be able to use media fragments on the url() function
21:44:16 <heycam> … I don't think that's an issue at the moment, no browser supports media fragments on images anyway
21:44:29 <heycam> … but we'd need to make sure this rule about distinguishing by fragment goes into the Images spec
21:44:45 <heycam> smfr: isn't there a risk for server-side image generation using the fragments as parameters?
21:45:18 <heycam> heycam: shouldn't they be using query parameters?
21:45:25 <heycam> … not sure the fragments are sent in the request
21:45:38 <heycam> ed: personally I'm fine if there is a way to reference parts of an SVG like this
21:46:14 <heycam> krit: I prefer this proposal that just looks at the fragment
21:46:23 <heycam> smfr: initially this was a proposal to just apply to the mask property?
21:46:31 <heycam> … if that were a general approach I think I'm happy with it
21:46:44 <heycam> krit: people on the mailing list seem to be fine with this as a general approach
21:46:58 <heycam> smfr: is the intrinsic size of an image well documented/understood when it's a reference like this?'
21:47:02 <heycam> s/'//
21:47:26 <heycam> krit: we use the object bounding box of the element
21:47:36 <heycam> … if you apply mask-image on an element, it uses the bounding box of the image
21:47:41 <heycam> … that's in the spec already
21:47:45 <heycam> smfr: do you have a size? or an intrinsic ratio
21:47:55 <heycam> … the SVG document itself isn't laid out in a known size, right?
21:47:58 <heycam> krit: we have two ways
21:48:11 <heycam> … there's the viewport size relative or object bounding box
21:48:18 <heycam> … both can be applied in an HTML context as well
21:48:24 <heycam> … I don't see an issue with HTML content at the moment
21:48:27 <heycam> smfr: ok
21:48:48 <heycam> ed: sounds like this proposal is not meeting any resistance
21:50:44 <heycam> RESOLUTION: We will use fragments in url()s to distinguish between SVG resource element references and CSS Image values as general approach.
21:51:19 <heycam> Topic: renaming none to no-clip on the mask-clip property
21:51:20 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-clip
21:51:32 <heycam> krit: this question came from elika
21:51:39 <heycam> … we decided to have none for when you don't want to clip the mask
21:51:46 <heycam> … none is already used for mask-image
21:51:53 <heycam> … so it causes problems with the shorthand
21:52:02 <heycam> … for this reason I suggest renaming none to no-clip
21:52:12 <heycam> … suggestion from Elika
21:52:17 <heycam> smfr: sounds fine to me
21:52:48 <heycam> heycam: you would normally leave that value out of the shorthand, it's the default?
21:52:52 <heycam> smfr: no the default is border-box
21:53:14 <heycam> RESOLUTION: Renmae none to no-clip in the mask-clip property.
21:53:17 <heycam> s/Renmae/Rename/
21:53:49 <heycam> Topic: new keyword for mask-origin
21:53:52 <ed> Topic: New keyword for 'mask-origin' to move mask out of the border-box on the left and top when 'no-clip' was specified
21:54:11 <heycam> krit: at the moment you have border-box, padding-box, etc.
21:54:16 <heycam> … you can't go more left/top than border-box
21:54:20 <heycam> … do we want a way to make this possible?
21:54:40 <heycam> smfr: seems reasonable, but wonder if you could have an auto value that does that?
21:54:55 <heycam> … that'd be the bounding client rect
21:55:05 <heycam> … it's a little fuzzy, I don't think bounding client rect is defined for SVG
21:55:07 <heycam> krit: yeah
21:55:17 <heycam> … there is some text that suggests what to happen for SVG
21:55:28 <heycam> smfr: it's a bit ugly too since as your children lay out and potentially move around, the position of your mask might change
21:55:35 <heycam> krit: there's also mask-position
21:55:40 <heycam> … so it's more just where you put the origin
21:55:48 <heycam> … it might be fine to just have these three keywords
21:55:56 <heycam> … you can still move it around with mask-position
21:56:04 <heycam> … it's allowed to have negative values
21:56:09 <heycam> smfr: ok sounds find
21:56:12 <heycam> s/find/fine/
21:56:58 <heycam> Topic: new name for paint-order from SVG 2
21:57:22 <heycam> krit: CSS WG decided that we can have this feature, but don't use paint-order, it could be misleading
21:57:45 <heycam> … "paint order" is already used as a term
21:58:26 <heycam> heycam: so paint-order is to change the rendering order of fill/stroke/markers on a single SVG element
21:58:37 <heycam> krit: but it could be used in the future for CSS boxes if we wanted
21:58:53 <heycam> ed: were there any suggestions for different names?
21:58:55 <heycam> krit: no
21:59:08 <heycam> … maybe just discuss on the list
22:00:56 <heycam> krit: how do we move forward with the Attributes as Properties proposal?
22:01:11 <Zakim> -dino
22:01:19 <heycam> heycam: I think the last time we discussed it, having sensible looking CSS properties was the preferred approach from the CSS WG
22:01:28 <heycam> … I was meant to create a repo for Jen to write something up
22:01:32 <heycam> … but didn't get to do that
22:01:47 <heycam> ACTION: Dirk to contact Jen about the SVG attribtues as CSS properties proposal
22:01:47 <trackbot> Created ACTION-85 - Contact Jen about the SVG attribtues as CSS properties proposal [on Dirk Schulze - due 2012-12-17].
22:02:03 <Zakim> -ed
22:02:04 <Zakim> -cabanier
22:02:04 <Zakim> -krit
22:02:05 <Zakim> -heycamaway
22:02:05 <Zakim> -smfr
22:02:07 <Zakim> -nikos
22:02:09 <Zakim> -Lea
22:02:17 <Zakim> -plinss
22:02:46 <Zakim> -Doug_Schepers
22:02:48 <Zakim> GA_FXTF()4:00PM has ended
22:02:48 <Zakim> Attendees were +1.415.832.aaaa, krit, Doug_Schepers, Lea, plinss, +1.408.636.aabb, smfr, cabanier, ed, nikos, dino, heycam|away
22:02:55 <heycam> Present: Erik, Rik, Dirk, Cameron, Simon, Nikos, Lea, Peter, Doug
22:03:02 <heycam> RRSAgent: make minutes
22:03:02 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/10-fx-minutes.html heycam
22:04:32 <krit> krit has joined #fx
22:12:46 <fantasai> fantasai has joined #fx
23:09:05 <dbaron> dbaron has joined #fx