W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2012

minutes, December 10 2012, FXTF telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 11 Dec 2012 09:05:03 +1100
Message-ID: <50C65C8F.5020902@mcc.id.au>
To: public-fx@w3.org
Please find the minutes from the FXTF telcon here:


and below as text.


       [1] http://www.w3.org/

                                - DRAFT -

                    CSS-SVG Task Force Teleconference

10 Dec 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/12/10-fx-irc


           Erik, Rik, Dirk, Cameron, Simon, Nikos, Lea, Peter, Doug




      * [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
          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: 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

    … 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

    … 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

    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

    … 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

    <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:




    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

    … but no proposal for that yet


      [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

    … 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

    … 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

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

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

    … 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

    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

    … 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

    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

    … 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

    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

    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

    … 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

    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

    <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

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

    leaverou: ok mix-blend-modes then

CSS Masking

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

    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

    … a list of real CSS3 Images


      [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

    … 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

    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

    <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

    … 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,

    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: this question came from elika

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

    … 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

    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

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

    … 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

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

    RRSAgent: make minutes

Summary of Action Items

    [NEW] ACTION: cabanier to update box shadow to apply to the
    whole shadow [recorded in
    [NEW] ACTION: Dirk to contact Jen about the SVG attribtues as
    CSS properties proposal [recorded in

    [End of minutes]
Received on Monday, 10 December 2012 22:05:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 December 2012 22:05:44 GMT