/irc-logs / w3c / #fx / 2012-12-10 / end

Options:

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

The end :)