<trackbot> Date: 10 December 2012

<scribe> Chair: Erik

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

filter effects, new syntax proposal for custom filter function

<krit> http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0070.html

krit: summary of the different proposals here

number 0 is in the working draft now

url inside the custom function

… the problem with that one is that it's not very future proof

… if you have new shader languages, the syntax won't work any more

… I think we should think about a new syntax for this

… proposal #1 is a custom filter at-rule

… different descriptors that match the particular shader language format

… proposal #2 is something similar to @font-face

… a generic @filter rule, with a url and format

… issues with #1 is that you need different descriptor definitions for different shader languages

… it's a bit of a burden in my opinion

… I prefer the generic src descriptor with url/format

… and the shader language would be described by a new format

… could be done with XML or whatever

… but it is something different, outside the style sheet

… on the mailing list it seems an at-rule would be ok, just a question of how it looks like

… I'd like to have more people involved in the proposal and get more feedback on that

… and get to a resolution soon

dino: I suggest putting something in the WD using an at-rule

… and then wait for comments

… 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

… I think we should start with the step of having the at-rule

… in the draft

krit: the editors have started some work on the at-rule proposal

… do we want to differ between fragment/vertex shaders?

… I agree it's harder to handle a new external format

… there'll be disagreement about the format

dino: I suggest we head towards #2 to start with

… without using terms like "fragment", "vertex", etc.

… at least initially

… I think we should publish something as a WD and see what happens

ed: I agree, proposal #2 is the one that feels more natural to me, most CSS-y

<dsheets> will Filter Effects 1.0 still define the mesh/blending operational model? why will these semantics be absent from CSS?

krit: would anyone say that we should never ever try to create an external shading language description language?

heycam: I think we should try to avoid it if we can

ed: it depends on what you want to put in the files

… if you just take a fragment shader, it's just a text string, that's what you feed to the implementation

… it depends how much structure you want to have in that external file

krit: the XML format we came up with as a first draft was quite simple

… you have a <fragment> and <vertex> element and it's cdata, that's all

<dsheets> and does not support many important use cases

… <parameter> elements would let you specify the params for the shading langauge

smfr: can you post a link to the example file?

<dsheets> and would be have CSS override analogs

<krit> http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0054.html

krit: I don't need a resolution now, but I'd encourage people to contribute to the discussion

heycam: I think it's less controversial to just stick it all in the at rule instead of coming up with a new format

<shepazu> +1

<dsheets> a new format can always be compiled to the at-rule

<dsheets> XML -> CSS easy, CSS -> XML harder

blending and compositing

<cabanier> links: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#box-shadow-mix-color

<cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#text-shadow-mix-color

cabanier: I've put placeholders in the spec right now

… most shadows, in our products, don't use the regular compositing when they are drawn

… people like to do multiply or other effects to make the shadows more pleasing

… right now those properties are in the compositing spec, but I think they would be better in the text/background/borders specs

… that would let you write them in the same shadow syntax

… but with the spec today you'd need two properties

krit: we have the same issue with filter effects and CSS masking, you might want to just target the background

… fantasai asked for a general solution extensible for the future

… but no proposal for that yet

<leaverou> http://lists.w3.org/Archives/Public/www-style/2012Dec/0005.html

leaverou: I posted to the CSS/FX lists

… I really disagree with the mix-color nam

… anything ending with -color looks like it takes a colour value

… I also think we're tring to keep modules decoupled

… we'd need to add properties in at least background/borders and text

… if we want different filters for these things, we'd need even more properties

… I think this is trying to accommodate a rare use case with a syntax that's not elegant

cabanier: which is the non elegant syntax?

leaverou: adding more css properties is inelegant

… from discussions with implementors, it sounded like more properties is worse for performance, takes more memory per element

… 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

… you couldn't have different effects applying to different parts of the box

… but I think that's a rare enough use case

… different effects for different background images on the one element

cabanier: I can only speak to how it's done in photoshop/illustrator

… you can overlay shadows and they don't use the default blend mode

… the stuff that adobe generates it's common

leaverou: I agree, but in photoshop you can only apply one shadow per layer, there's no other way to do it

… you can't use different shadows to the one layer with different effects

… you can actually do it, if you need different blending modes for different background images, you can split it up into separate elements

cabanier: WebKit has different compositing modes for different background images, even though it's not really documented

… there is quite a bit of content out there that uses it

… I'm not sure how useful it is, but it seems like some people would use it

… I think an at-rule would make it more confusing

smfr: I think that was added as a hack for dashboard

… I would be surprised if it's widely used on the web

… I don't think we should go by the usage of that particular property

cabanier: even though it's not well document, I think some people are using it

… but not advocating for it one way or the other

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

cabanier: I think it's reasonable, I agree

… so it might be useful for a text shadow, but to all the shadows at once

… the syntax I wrote doesn't allow for that

krit: how do we combine these in the future?

… compositing, blending, filters...

cabanier: that was the original question

… do we split it up into multiple specs?

krit: I think it's a bad idea to split this up into the other specs

… if it's affecting background and borders, it should be in that spec

cabanier: and masking and filters?

krit: or we find one specification to define it for everything

cabanier: I think B&B could refer to another spec

… there are examples of that in there already, e.g. for box-shadow's syntax

… we can just say "see these specs" for what the compositing/filtering means

krit: so we are opposed to having new properties for all these features?

cabanier: looks like it

… so new arguments to the existing properties

krit: or new properties to take these arguments?

cabanier: the fewer properties the better

… if nobody has a strong opinion, we can leave it in the spec for now and continue on the mailing list?

smfr: I'm not sure I understand the behaviour of these properties

… background-mix-compositing

… does it describe how it composites with things behind it on the page?

cabanier: only on backgrounds compositing with each other

… I think that's how WebKit does it too

smfr: for the other ones, like box-shadow-mix-color?

cabanier: it would blend with everything in the same stacking context

smfr: some of these will be extremely hard to implement without a lot of memory

cabanier: the spec says the default has non-isolated groups

… but I think that's too memory intensive

… so I've made it blending only within a stacking context

smfr: authors don't necessarily know what stacking contexts are

… even implementing it relative to the stacking context, we might end up with a compositing layer between it and the stacking context

cabanier: there is a compositing layer that is not a stacking context?

smfr: yes, if you have overflow for example

cabanier: would that create problems with z-index?

smfr: it does for clipping

… but it's just an implementation bug

… it concerns me how we'll work out how these things work

… I'd be happy if they only affect compositing between bits of the same element

… borders compositing on top of the background, for example

cabanier: for box shadow? there's no background behind it

smfr: yes, so you can't easily change how that's composited

cabanier: we have an example implementation, I'd like to see how it would go wrong

… are you just generally worried about blending of shadows/boxes, not the element itself?

smfr: I'm worried about blending across elements, in such a way that the element itself uses different blending modes

cabanier: every blending mode creates a stacking context

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

… is that text shadow blending on top of the box shadow?

cabanier: yes it should be, they're not compounding operations

… you would draw the box shadow, then you'd draw the text shadow on top of that

smfr: maybe I need to understand these better
... I agree with Lea that these would be obscure use cases

… I could understand tools outputting them

cabanier: I think authors will want to multiply shadows

… it'll look much more pleasing than multiply

leaverou: right now authors don't any blending modes

… if the authors ask for more behaviour can't we give it to them alter?

cabanier: definitely

leaverou: it seems if you apply blending mode to the topmost image, not the others, and it blends only with the underneath images

… is that right?

cabanier: that is how it's currently defined

leaverou: I think that will be confusing

cabanier: I don't disagree

… there's also the point about whether it's implementable

… tools are less concerned about memory footprint and performance than browsers do

… we can ask for the more natural mode, but it requires a lot of work to implement

… but it probably won't get implemented in browsers

… we can definitely start with the simple stuff and add more things later

leaverou: I think that sounds reasonable

cabanier: do you believe people would expect to blend the background and not blend within the backgrounds?

leaverou: I think if people apply the blending modes to the top background layer, they would expect to blend with whatever is below it

… authors don't understand the implementation restrictions

… they would expect it to blend with whatever is below the element

cabanier: I think it could be done, but it'd be yet another property to define

… if you believe it's more common, I can update the spec for that as well

leaverou: I don't have statistics to back it up, but it's my impression as an author

cabanier: there was another question about mix-color

… people didn't like the name

<scribe> ACTION: cabanier to update box shadow to apply to the whole shadow [recorded in http://www.w3.org/2012/12/10-fx-minutes.html#action01]

<trackbot> Created ACTION-84 - Update box shadow to apply to the whole shadow [on Rik Cabanier - due 2012-12-17].

smfr: is there a reason mix-color isn't called blend mode?

cabanier: there is a shorthand "mix"

… and I think Tab Atkins suggested to break it up into mix-color, mix-composite

… Dirk suggested mix-blend, but I think those words mean the same thing

krit: I agree with Lea that the prefix/suffix color is normally used for color values

… I would expect mix-color takes a color

cabanier: it used to be called blend-mode

krit: I don't have a problem with mix-blend

cabanier: mix-blend-modes?

smfr: that sounds ok

leaverou: yeah

… maybe mix-blending? I think all those suggested ones are better

cabanier: I think Tab said that "-ing" isn't used in property names

leaverou: ok mix-blend-modes then

CSS Masking

ed: first question, trying to resolve mask images on url functions

krit: the problem is we have the mask property already

… it will be a shorthand for SVG masking and for the WebKit-style masking

… WebKit masking is like the background-image, but now mask-image

… a list of real CSS3 Images

<ed> http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html

… that's in conflict with the mask property from SVG

… both can take url()

… but just from that url(), you don't know if its' a CSS Image value or an SVG mask element reference

… we had some discussions on how to fix this issue

… we came up with ways to distinguish them

… 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

… I think the question is, do we want to have the same rule for all things that take url()s?

… 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

… if they can in the future reference an SVG paint server element

smfr: I think that's a good long term goal

… you risk changing behaviour of existing content

… I think it's unlikely people will have used fragments in a CSS SVG image

krit: there is this SVG Stacks

ed: a technique where you reference a subpart of an SVG, like a sprite sheet

… using IDs to select elements inside the SVG

krit: this is similar to media fragments

… if we use this technique, we can't use media fragments with url()

<krit> http://www.w3.org/TR/css3-images/#image-notation

… but CSS Images 3 already suggests to use image() if you want to use media fragments

… because all the browser might not be able to use media fragments on the url() function

… I don't think that's an issue at the moment, no browser supports media fragments on images anyway

… but we'd need to make sure this rule about distinguishing by fragment goes into the Images spec

smfr: isn't there a risk for server-side image generation using the fragments as parameters?

heycam: shouldn't they be using query parameters?

… not sure the fragments are sent in the request

ed: personally I'm fine if there is a way to reference parts of an SVG like this

krit: I prefer this proposal that just looks at the fragment

smfr: initially this was a proposal to just apply to the mask property?

… if that were a general approach I think I'm happy with it

krit: people on the mailing list seem to be fine with this as a general approach

smfr: is the intrinsic size of an image well documented/understood when it's a reference like this?

krit: we use the object bounding box of the element

… if you apply mask-image on an element, it uses the bounding box of the image

… that's in the spec already

smfr: do you have a size? or an intrinsic ratio

… the SVG document itself isn't laid out in a known size, right?

krit: we have two ways

… there's the viewport size relative or object bounding box

… both can be applied in an HTML context as well

… I don't see an issue with HTML content at the moment

smfr: ok

ed: sounds like this proposal is not meeting any resistance

RESOLUTION: We will use fragments in url()s to distinguish between SVG resource element references and CSS Image values as general approach.

renaming none to no-clip on the mask-clip property

<krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-clip

krit: this question came from elika

… we decided to have none for when you don't want to clip the mask

… none is already used for mask-image

… so it causes problems with the shorthand

… for this reason I suggest renaming none to no-clip

… suggestion from Elika

smfr: sounds fine to me

heycam: you would normally leave that value out of the shorthand, it's the default?

smfr: no the default is border-box

RESOLUTION: Rename none to no-clip in the mask-clip property.

new keyword for mask-origin

New keyword for 'mask-origin' to move mask out of the border-box on the left and top when 'no-clip' was specified

krit: at the moment you have border-box, padding-box, etc.

… you can't go more left/top than border-box

… do we want a way to make this possible?

smfr: seems reasonable, but wonder if you could have an auto value that does that?

… that'd be the bounding client rect

… it's a little fuzzy, I don't think bounding client rect is defined for SVG

krit: yeah

… there is some text that suggests what to happen for SVG

smfr: it's a bit ugly too since as your children lay out and potentially move around, the position of your mask might change

krit: there's also mask-position

… so it's more just where you put the origin

… it might be fine to just have these three keywords

… you can still move it around with mask-position

… it's allowed to have negative values

smfr: ok sounds fine

new name for paint-order from SVG 2

krit: CSS WG decided that we can have this feature, but don't use paint-order, it could be misleading

… "paint order" is already used as a term

heycam: so paint-order is to change the rendering order of fill/stroke/markers on a single SVG element

krit: but it could be used in the future for CSS boxes if we wanted

ed: were there any suggestions for different names?

krit: no

… maybe just discuss on the list

krit: how do we move forward with the Attributes as Properties proposal?

heycam: I think the last time we discussed it, having sensible looking CSS properties was the preferred approach from the CSS WG

… I was meant to create a repo for Jen to write something up

… but didn't get to do that

<scribe> ACTION: Dirk to contact Jen about the SVG attribtues as CSS properties proposal [recorded in http://www.w3.org/2012/12/10-fx-minutes.html#action02]

<trackbot> Created ACTION-85 - Contact Jen about the SVG attribtues as CSS properties proposal [on Dirk Schulze - due 2012-12-17].

RRSAgent: make minutes

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.99)

Succeeded: s/types/languages/
Succeeded: s/'//
Succeeded: s/Renmae/Rename/
Succeeded: s/find/fine/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: +1.415.832.aaaa, krit, Doug_Schepers, Lea, plinss, +1.408.636.aabb, smfr, cabanier, ed, nikos, dino, heycam|away
Present: Erik Rik Dirk Cameron Simon Nikos Lea Peter Doug
Agenda: http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0071.html
Found Date: 10 Dec 2012
Guessing minutes URL: http://www.w3.org/2012/12/10-fx-minutes.html
People with action items: cabanier dirk

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.