See also: IRC log
<trackbot> Date: 10 December 2012
<scribe> Chair: Erik
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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: 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
<dsheets> a new format can always be compiled to the at-rule
<dsheets> XML -> CSS easy, CSS -> XML harder
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: 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
… 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
... 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?
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
smfr: that sounds ok
… 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
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
… 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()
… 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
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.
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.
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
… 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
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?
… 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.[End of scribe.perl diagnostic output]