- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 11 Dec 2012 09:05:03 +1100
- To: public-fx@w3.org
Please find the minutes from the FXTF telcon here:
http://www.w3.org/2012/12/10-fx-minutes.html
and below as text.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
CSS-SVG Task Force Teleconference
10 Dec 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-fx/2012OctDec/0071.html
See also: [3]IRC log
[3] http://www.w3.org/2012/12/10-fx-irc
Attendees
Present
Erik, Rik, Dirk, Cameron, Simon, Nikos, Lea, Peter, Doug
Regrets
Chair
ed
Scribe
Cameron
Contents
* [4]Topics
1. [5]filter effects, new syntax proposal for custom
filter function
2. [6]blending and compositing
3. [7]CSS Masking
4. [8]renaming none to no-clip on the mask-clip property
5. [9]new keyword for mask-origin
6. [10]New keyword for 'mask-origin' to move mask out of
the border-box on the left and top when 'no-clip' was
specified
7. [11]new name for paint-order from SVG 2
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 10 December 2012
<scribe> Chair: Erik
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
filter effects, new syntax proposal for custom filter function
<krit>
[13]http://lists.w3.org/Archives/Public/public-fx/2012OctDec/00
70.html
[13]
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>
[14]http://lists.w3.org/Archives/Public/public-fx/2012OctDec/00
54.html
[14]
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:
[15]https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.h
tml#box-shadow-mix-color
[15]
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#box-shadow-mix-color
<cabanier>
[16]https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.h
tml#text-shadow-mix-color
[16]
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>
[17]http://lists.w3.org/Archives/Public/www-style/2012Dec/0005.
html
[17] 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
[18]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>
[19]http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.
html
[19] 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> [20]http://www.w3.org/TR/css3-images/#image-notation
[20] 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>
[21]http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#
the-mask-clip
[21]
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
[22]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
Summary of Action Items
[NEW] ACTION: cabanier to update box shadow to apply to the
whole shadow [recorded in
[23]http://www.w3.org/2012/12/10-fx-minutes.html#action01]
[NEW] ACTION: Dirk to contact Jen about the SVG attribtues as
CSS properties proposal [recorded in
[24]http://www.w3.org/2012/12/10-fx-minutes.html#action02]
[End of minutes]
Received on Monday, 10 December 2012 22:05:44 UTC