IRC log of fx on 2012-12-10

Timestamps are in UTC.

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