[CSSWG] Minutes and Resolutions Seattle F2F 2011-07-26 PM: Compositing, Filters, Animations, Transforms, SVG Params


   - Discussion of enable-backgrounds and interaction with CSS stacking contexts
   - Discussion of filter inputs from CSS model
   - Discussion of interaction of box-shadow, text-shadow and filters
   - Discussion of filter OM API
   - RESOLVED: publish the FXTF Filter Effects draft as soon as the edits
               discussed in this meeting are done.

CSS / SVG Model Cordination

   Discussion of syncing CSS and SVG animation models.
   Discussion of syncing CSS and SVG transform models.


   - Discussion of 'color-correction' property
   - Discussion of SVG Parameters and relation to CSS and CSS Variables
   - Reviewed CSS test harness for use with SVG test suites
   - Discussed 'background-print' proposal from Tab

====== Full minutes below ======

Scribe: nimbu


   ed: we can do svg composting first and continue with filters
   <ed> http://www.w3.org/TR/SVGCompositing/
   cabanier: there is a need for adobe to specify the blending into the css.
   cabanier: it can be done through filters and not easy as specifying keywords.
             should we adopt what svg is doing in css or having a more limited
   cabanier: the enable-backgrounds is necessary for compositing.
   heycam: are we asking first if people are in favour of compositing for
           css at all?
   cabanier: there was a discussion in the mailing list where people did not
             see the point of it. smfr
   cabanier: since we need it for filters anyway maybe its not a big deal
   smfr: webkit has a webkit property which lets you set compositing mode
         for an image
   heycam: can you do all compositing modes with existing svg filter primitives?
   cabanier: I believe you can.
   cabanier: difficult as you need to do compositing urself.
   vhardy: svg compositing spec is more complete.
   vhardy: if we are going to go about defining how things should render it
           would be a general issue. it would be applicable to anything you
           render. Do we want to do something that works for css in general?
   heycam: if you have already implemented for SVG it won't be much work to
           extend it
   cabanier: do you mean spec or implementation?
   heycam: implementation
   dbaron: how good is enable-background for authors to understand what's
           going on?
   dbaron: what's the deal with x, y params in that?
   cabanier: those will go away. it is more confusing
   dbaron: with filters, the defaults meant things were meant to be clipped out.
   smfr: enable-bg is like opacity.
   cabanier: enable bg just generates stacking context.
   cabanier: the 1st elm with enable bg new will create a new stacking context,
             the first descendant that has a blend mode will create a second
             one and those two will be put together
   cabanier: I agree the keyword is pretty confusing
   TabAtkins: I only understand it coz I have looked at it enough times
   TabAtkins: the svg compositing def
   szilles is your point editorial improvements will be appreciated dbaron
   dbaron: in compositing it says new buffers are established for both of them.
           which seems wrong
   cabanier: that confusion comes from Porter-Duff …
   cabanier: lets stick with regular blending modes
   dbaron: I am not sure I follow but I don't know if it's worth explaining
           it to me
   ed: do we want to have this for css or html?
   vhardy: in the rendering model perspective, I don't see any harm done by
           making this generic
   anne: shouldn't all these things be generic
   cabanier: maybe we can get a better name if we put this in css
   anne: has anyone looked at how similar it is to canvas composite feature
   cabanier: canvas has porter-duff. this is slightly different
   cabanier: we had a discussion on splitting it into porter-duff & blending
             modes. porter-duff is hard to specify.
   heycam: blend modes don't need you to keep it off on a separate buffer
           like enable bg?
   cabanier: they do.
   <ChrisL> why is porter-duff hard to specify?
   heycam: what is the complexity for porter-duff?
   anne: why is it "easy" for canvas but not for svg?
   vhardy: in svg or html you have multiple nodes and you need to define which
           to accumulate and what level.
   anne: and I guess you have to constantly run it if you change the underlying
   cabanier: canvas does not know about stacking contexts
   vhardy: it's also one drawing operation at a time
   vhardy: in a tree model you can have whole trees or groups.
   cabanier: that's what enable-bg does
   dbaron: is porter-duff trying to do something in cases other than where
           you have stacking context?
   <smfr> url?
   dbaron: there are elements that are outside subtree and interleave with them
   <ChrisL> dbaron, svg tries to avoid that interleave so we don't use the
            stacking conext
   shepazu: I don't understand what you mean by interleaving
   <ChrisL> shepazu, interleaved in z-order. in other words, not the painting
            algorithm used in svg
   dbaron: if there is A in subtree, B is outside, C is in subtree. and if
           B is on top of A and C. a sub tree is not a single atomic thing
   dbaron: css does not even define things in terms of drawing operations
   heycam: isn't there an appendix that says paint the bg, paint the border?
   <ChrisL> css defines the order of drawing border, background, and text
   dbaron: I am not sure if it was going to be interpreted that way.
   cabanier: you create two buffers the top one with dest-atop(?)
   dbaron: in css that sort of thing only makes sense in stacking context
   cabanier: enable background adds another stacking context.
   dbaron: if the stuff in here needs to apply to css it needs to say more
           about stacking contexts
   dbaron: the comp-op property has initial value that sorts over.
   <dino> is this the latest spec?
   <anne> http://www.w3.org/TR/SVGCompositing/
   <anne> oh
   * heycam the TR copy is newer than the one on dev.w3.org? :)
   * ChrisL heycam maybe the newest copy is in hg repo not the dev.w3.org cvs repo
   <ed> http://dev.w3.org/SVG/modules/compositing/publish/
   <anne> ed, should update that to say editor's draft...

   ChrisL: you would still need stacking context in css and html. there is
           opacity or something that generates new stacking context
   vhardy: are you saying comp-op won't trigger new stacking context?
   ChrisL: it won't, even if it did the initial value would be something
   vhardy: should we make this work for html, css?
   cabanier: the big drawback was we didn't want to blend two images together
             but if we are doing with filters anyway the drawback goes away.
   ChrisL: it would be helpful if we have one for each host language, and say
           more clearly what happens.
   ACTION: cabanier produce a new draft of compositing which should probably
           called CSS Compositing with appendices on how compositing works in
           css, html box model and svg model.
   <trackbot> Created ACTION-44
   shepazu: add cabanier to this list :P
   dino: so you don't want to remove enable background.
   cabanier: no only the x, y.

Image Generators and Filter Inputs

   dino: proposal from tab for a new image generator
   dino: any image generator, stream of filter property
   dino: does anyone disagree?
   dino: TabAtkins and I agree it's a good idea
   dbaron: is this an extension to image vals?
   TabAtkins: will just be in there but will be a new image type
   ChrisL: we need to find a separate way to bring it in.
   dino: this is the separate way. if you want to just filter the border.
   smfr: if you use border-image you will get sharp edges
   smfr: Chris suggests we get blur after we slice and stretch
   TabAtkins: @ santaclara TPAC brad was talking about pulling sections of
              elements instead of entire element as filter input.
   dbaron: I think we need new filter input primitives for css stuff
   <ChrisL> you need both. one to filter random images and one to filter
            the border stuff (which may have been made from images or may not)
   smfr: the border-image should be solved this other way.
   dino: other places can use this.
   dbaron: I can see using multi bg and wanting to filter one of them
   ACTION: dino update the filter spec to produce the new image type.
   <trackbot> Created ACTION-45
   <bradk> fitering borders should also filter border-images (since
           border-images are substitutes for borders)

   dino: the next topic there is a dropshadow effect. if there is some way
         to do it at a higher level than within a filter
   cabanier: svg images is an example, so you want shadow around the shapes.
             it seems an overkill to apply filters to that
   patrickdengler: does it not apply to blur and all that stuff. there would
                   be a cross over.
   heycam: we do want it for svg content
   heycam: if there was some short hand work in svg and not in css…
   dino: webkit has an extension -webkit-svg-shadow that will apply the
         shadow to the svg content
   dino: the reason this was added was canvas has it
   dino: the req was basically to draw a shape and give it a shadow.
   ChrisL: is the req to be a simple syntax?
   dino: what's the req for current one?
   ChrisL: you have to do a lot of work to produce it.
   dino: another q to ask is, you can assume shadow is a popular thing,
         now if we add filters would they expect filters to apply to shadow?
   ChrisL: if you want to apply two filters on svg, you need to put second
           filter on group.
   pdengler: I was thinking in terms of text-shadow, box-shadow, drop-shadow
   pdengler: I think css authors don't think of them as filters
   pdengler: there are categories of effects that have nothing to do with
   smfr: the issue is the order of ops
   pdengler: it goes with input types.
   smfr: if we have filter and box-shadow which do you do first
   dino: people consider shadow as part of object drawn
   dino: if you set opacity of text to 0 would you expect shadow to fade as
   smfr: I think we still render the shadow.
   dino: the shadow is really part of the object
   smfr: transforms and shadow.
   smfr: does the shadow move around, or stay same
   smfr: it depends on scenarios
   plinss: if I rotate something the shadow should stay and rotate.
   <ChrisL> that is why we added the 'ref' transform for svg so yo can use
            the local coordinate system of a higher element
   BradK: the shadow should be the last thing that comes after it is
   * ChrisL disagrees with that
   dino: should we expose short hand for it?
   ACTION: dino add shorthand property for shadow.
   <trackbot> Created ACTION-46

   <tantek> ed: I'd like to spend 5 minutes discussing "color-correction"
            as mentioned/discussed here http://www.w3.org/2009/11/03-CSS-minutes.html
            (I don't think it's been discussed since) - I think this is the
            right set of people to discuss it.
   <ed> tantek sure, i'll add that to the afternoon session

    dino: adding dropshadow keyword would become a long f()
   <bradk> I imagine an object rotating, but still acting as if the light
           source is from the same direction. But scaling the object should
           scale the shadow.
   dbaron: is it a property or function
   <smfr> like filter: dropshadow(10px, 10px, 20px, blue)
   <bradk> not sure if the offset should scale.
   dbaron: what mechanism is it coming from, when the author is not specifying
           the order?
   dbaron: when author lists in order then no problme
   smfr: issue when interacting with other css properties.
   dbaron: I see box-shadow as part of border drawing stuff. and it would
           happen before filters.
   dino: that was my point
   dino: not an effect like blur or warp
   bradk: can box-shadow be simulated with filters?
   smfr: you could, but you have to generate mask the rounded border box
         which the shadow is applied to
   dino: you can do with markup filters by filter chain that floods black
         region, offsets it, composits
   <ChrisL> yes I assumed the question related to doing it with markup filters
   dino: not in short hand
   dino: proposal for a wave effect
   dino: ms has implemented
   dino: ed commented it might be interesting.
   <bradk> I've never personally had any need for a wave effect.
   <tantek> how about a new wave effect?
   dino: it seems like there is not much support
   dino: discussion about custom element to add any effect
   dino: some implementations have effects to add that are useful
   <ChrisL> as I mentioned earlier, a dom interface allows room for
   dino: some way it could be done as an extension and not how to
         prefix a function name
   dino: the webGL community all agreed on same prefix
   dino: you get interoperability between browsers but no guarantee it
         would work forever
   dino: some effects that might be common the implementations would
         agree enough, it could possibly done in that manner
   heycam: we would need a reasonably complete desc of what that filter
           would be.
   dino: it is worthwhile getting feature pushed through trackers as
         quickly as possible
   dino: there are some effects tht would be useful to authors. there
         can't be much debate on how it can be implemented. e.g motion blue
   dino: how should they do it? prefix function names or if it's standard
         enough, send proposal, wait for agreement and use an experimental
   heycam: prefixing sounds like a good idea
   smfr: we have prefixed function names for gradients so it's not new
   dino: idea of shared prefx name has not been proposed before
   dino: it seems to work pretty well in webGL community
   szilles: classic problem webkit community have webkit prefix
   szilles getting agreement doing the same thing or it breaks
   szilles: if it breaks come up with the new prefix.
   szilles: that was concern in csswg seemed safer for each implementation
            to have own prefix so it tried to be consistent to itself
   dino: it's not like its a big issue anyway. if and when people want to
         use these new effects we will see what happens
   cabanier: it would be nice to have one prefix.
   heycam: it's diff from property names
   dino: I guess you can still.
   smfr: people do that with bg image
   heycam: it's an invalid value.

   dino: filter property in css om
   ed: that's come up before whether or not if it should be exposed to cssom
   anne: exposed or rename attr on interface to css filter
   anne: I don't think there is a middle ground
   anne: ecmascript guys hate the document.all as it is hidden
   anne: that is the pattern we don't want to follow
   anne: I don't know why we didn't go with that.
   anne: it is for attr exposed on css style decl
   anne: and style decl values
   smfr: is it coz IE claimed filter
   anne: yes
   dbaron: we have been shipping element.style.filter
   ed: also opera
   ed: it's not a big problem
   ed: not many sites are broken
   dino: we should also ask ms
   pdengler: we see this coming anyway. I don't know what our avenues are
             to change.
   pdengler: I think we have some mitigations
   heycam: you can still support if the syntax is right
   pdengler: we are okay on this one if you want to keep style.filter
   pdengler: sylvaing?
   ed: see if we can publish something so people know where we are
   dino: we are happy to publish it
   ChrisL: there are some people who are not represented here.
   dbaron: this is pretty much a full css meeting hre.
   <dbaron> We've been shipping element.style.filter since Firefox 4...
            so not all that long, but we have shipped it.
   RESOLVED: publish the FXTF Filter Effects draft as soon as the edits
             discussed in this meeting are done.
   ACTION: ChrisL to check whether or not filters spec counts as a new draft
           or not
   <trackbot> Created ACTION-47

CSS / SVG Animations

   dino: moving to css / svg animations.
   ed: we have half an hour before break.
   <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/Animations/Harmonisation
   birtles: seems like there are diff ideas on where we are heading.
   birtles: check if we are on same page where we want to end up with
            animations in the long run
   birtles: see how feasible it is to merge them
   <birtles> http://dl.dropbox.com/u/11894343/Harmonisation.htm
   birtles: the target of animation is diff svg is 1 attr on an elm,
            css is more flex
   birtles: it's something we need to fix in svg
   birtles: bigger diff is the values, in svg you can have independent anims
            targetting one attr and control how they combine together. and
            have anims build on themselves
   birtles: more significant diff its been proposed to css anims be added to
            underlying styles. I don't think there is anything to add anims
   smfr: we would like to be able to do
   <ChrisL> its a common use case to apply multiple animations
   smfr: we have talked about adding it to css for a while
   vhardy: having same sandwich model as SMIL would help.
   <ChrisL> yes, I think its needed and the sandwich model works well

   birtles: one complication is there are rules, and its a grey area
   birtles: animation types how to do interpolation.
   birtles: interval timing is quite diff
   <ChrisL> lets get rid of wallclock, please
   birtles: css does not have complexity of svg
   birtles: SMIL has all sorts of rules which is a big area of difference.
            which might be difficult to merge and be impossible to merge.
   birtles: multiple intervals, and syncbase
   ChrisL: do we find that syncbase stuff is getting used well?
   birtles: my guess is it is. I have already proposed that we drop it and
            introduce timing groups instead which gives 80% of functionality
            with fraction of complexity
   birtles: I am concerned people are using it
   vhardy: what do you mean by you don't want syncbase?
   birtles: SMIL has 2 diff features for kicking off anims
   birtles: when an animation ends/starts, when I get an event
   birtles: basically maintain network of times and work out how to break
            that network
   birtles: you can have negative offsets
   birtles: event based is easier
   shepazu: to implement?
   birtles: yes for authors syncbase is better it is more predictable.
   ed: in most cases you don't want two sync anims to start slightly off,
       want them to start at the same time
   heycam: you can fudge it.
   birtles: SMIL says put event timestamp and use that.
   vhardy: syncbase can give you a way to get perfect sync
   birtles: time containers can give you that for most of use cases.
   dino: what's an example of time container?
   vhardy: difficulty is in spec hard to wrap head around, impl. is not
           that much code.
   vhardy: once you know what to do, it's not that bad.
   birtles: I have test cases which weren't working on other browsers.
            cyclic dependencies SMIL has rules to break them but not
            impl. consistently.
   vhardy: it takes a couple of iterations to get right
   heycam: it is complex to understand as well.
   <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_re-use_animations
   birtles: svg lacks some things for timing functions
   birtles: has timing mode mostly for motion on a path.
   birtles: svg does not hve reversing, something we should add.
   <ChrisL> adding reversing would be very helpful
   birtles: its not too different.
   birtles: its unfortunate the names are diff between css anims and svg.
   birtles: css takes a snapshot, svg everything is live
   shepazu: I don't understand what you mean
   <ChrisL> you mean for the actual animation atributes themselves via dom, right
   dino: if you change duration, transition during animation it does not
         change the animation itself
   dino: SMIL allows you to manipulate prop of animations while you animate.
   birtles: if you do try to merge these two, this needs to be resolved.
   birtles: svg makes everything declarative. css assumes you can use script
            to cancel anims
   birtles: we want to maintain declarative approach in svg
   vhardy: it is not obvious what timing model is for css animations.
   birtles: svg has a notion of outermost element is a time container.
   <ChrisL> in SVG Tiny 1.2 we made all svg elements be time containers. Also the
            media elements. that was a request from the accessibility folks
   birtles: do you want to be able to schedule multiple intervals.
   birtles: I suppose if we add time containers anyway we don't need to do that.
   smfr: time 0 is when load event fires?
   smfr: you might want to start animations when page is loading.
   ed: in tiny 1.2 there is timelineBegin=onStart which solves that problem
   <ChrisL> the "loading screen" flash use case
   pdengler: there is more usage of css than svg
   pdengler: SMIL is more sophisticated and complex and causes problems in
             syntax and merging
   pdengler: given css syntax is being more quickly adopted by webdevs,
             shouldn't that be…
   pdengler: anecdotal, I have seen more css anims than svg. the css syntax
             is better absorbed. Because there is complexity merging seems
             scary to me
   birtles: that's exact question I wanted to talk about
   pdengler: I think css anims is picking up.
   <ChrisL> question for pat, if we end up still with two separate specs will
            IEnext implement only the css one?
   * anne has been saying since end of 2005 that SMIL is a mess (based on
          somewhat different criteria, but still)
   birtles: have listed 3 possibilities.
            1. drop svg anims and use css
            2. merge them
            3. try to align and play together but comprable enough so web
               devs can switch if they need to.
   birtles: #2 seems difficult, and I am not so sure it's possible.
   birtles: looking at 1 and 3. if we were to drop svg animations, we would
            need to add some features to achieve feature-parity.
   anne: are there missing features in wide use?
   florian: probably got a bunch of UIs written in svg
   anne: at some point it will die out
   <anne> I so support Microsoft for once
   shepazu: we all agree we want one model
   vhardy: I agree with what ChrisL is saying. I don't have strong feelings
           for syntax.
   vhardy: Animation is like text: it seems simple at first, but as you get
           deeper you realise how complex it really is.
   vhardy: I would focus on what features we need. timing model. recommend
           we use SMIL as resource
   vhardy: I am okay with a new syntax.
   pdengler: I don't disagree with we need feature parity.
   shepazu: I prefer the element syntax to css syntax, but I don't remember
            my rationale.
   <anne> (With saying no to SVG Animation / SMIL)
   heycam: the syntax is the sticking point here.
   <ChrisL> doug is saying the stae chart stuff is one example where an
            element based syntax helps
   dino: is there a way to get to option 2 by changing the way SMIL currently is.
   <dholbert> Option 2: Merge the two into one master Web Animations spec
              with two syntaxes
   <dholbert> ( from http://dl.dropbox.com/u/11894343/Harmonisation.htm )
   smfr: when we talk about css animations we need css anims plus js.
   smfr: we can't put all of svg into decl. css
   dino: hope to come up with api that can be shared
   dino: can we map that api to SMIL
   vhardy: you need a declarative way of animations.
   shepazu: willing to see how far we can go with css syntax
   shepazu: just don't develop it further
   smfr: here is an issue that is specific to css: css applies properties at
         style resolution time and we don't define when style resolution is.
         The timing thing is ill-defined.
   vhardy: we tried to work on exporting timings to animations, it is hacky
   <ChrisL> so we could end up painting ourselves into a corner that can't
            for example animate things before the document completely loaded
   pdengler: css animations does not have the right stuff, then how is smil
             going to apply to html.
<br duration="15m"/>
   ed: should we go through the options, or do we have strong objections to #1?
   birtles: I am uncomfortable pushing all the complexity to css
   birtles: okay dropping SMIL
   anne: why do you want angle bracket syntax
   birtles: you can already manipulate angle bracket stuff easily. it would be
            out of place to chuck in a style block to animate while everything
            else is in XML
   birtles: it can get complicated
   dino: if you think about a complex animations, you may have to put an id
         on every element and might have overhead on performance.
   tantek: would be great to see illustrative examples
   birtles: if its xml you can already manipulate elements with DOM API.
            if its new css you would need to invent a new DOM API
   anne: with xml you only get string manipulation by default which is not
         really right.
   birtles: how to change this attr, all apis already exist for that.
   ed: if we decide to drop svg animations, then css should cover svg use
       cases and I am not sure that problem is small either.
   heycam: it seems odd to me to have CSS anims affecting dom attr and not
           property values
   dino: I am not comfortable having css anims affect dom
   anne: what you mean by dom attr
   heycam: like x, y, attr on rect
   heycam: it's not a big deal in html as you don't animate things that are
           not properties.
   heycam: many geometric things are attr in SVG and not properties
   heycam: I had a proposal to make attr properties, but it did not get traction.
   <birtles> http://www.w3.org/Graphics/SVG/WG/wiki/Talk:F2F/Auckland_2011/CSS_Animation#Promoting_attributes_to_properties
   dino: pollution of property, potential clashes, were arguments against
   heycam: if we used shape-left instead of x, would lose the fact that attr
           and property would have same name.
   <dholbert> (side point: <animateMotion path="whatever"> is pretty useful
               & isn't easy to convert to CSS, even with attr-property mappings)
              (as I think birtles mentions in his document)
   vhardy: we stopped short of that we did not bring it to csswg.
   heycam: I thought TabAtkins mailed www-style with diff options
   <dino> dholbert, he does mention it
   TabAtkins: I don't recall getting much of a response.
   <dbaron> Why not 'left' <=> @x, etc.
   <heycam> dbaron, there are a few properties that map ok like that, not all
   <heycam> dbaron, also suffers from the fact that it's a different name

   vhardy: we should have prioritized list of req of what we need to put in.
   vhardy: set of animation feature sets that can work on svg, css, html
   vhardy: and then see if we can push css animations to that or not.
   ACTION: dino to write up use-cases and priority list of features to be
           added to css animations
   <trackbot> Created ACTION-48
   dino: we can make a wikipage


   <tantek> "color-correction" as mentioned/discussed here
            (I don't think it's been discussed since)
   <dbaron> http://dev.w3.org/csswg/css-color-correction/
   tantek: has there been any update on this front?
   ChrisL: one of the versions of mac os x changed from gamma of 1.8 to
           1.2 it means throwing stuff at the screen on current macs
           should be same as current PCs.
   ChrisL: it used to be that macs had different gamma correction.
   smfr: it's not just about gamma correction but finding ways to authors
         to map css colors to images
   ChrisL: the way we can do that, is to treat untagged images as sRGB
   dbaron: is there any browser where untagged images and css colors
   dbaron: there are bunch of browsers that do good color matches for
           tagged images, but don't for untagged and we want authors
           to opt-in to color correction
   smfr: webkit has a property for color correction.
   dbaron: I did put the stuff we discussed in a draft on dev.w3.org
           didn't do anything in that draft.
   dbaron: it needs more work
   ACTION: smfr to look at dbaron's draft and see if it matches what
           they have implemented and determine if its an issue or not.
   <trackbot> Created ACTION-49
   <ChrisL> it would be good to know if those pages are safari specific
   <smfr> ok
   <ChrisL> the problem with this is that it removes sRGB as a baseline
            and replaces 'do what you want' as the baseline
   tantek: do you have doc of support somewhere?
   smfr: will check.
   tantek: post url to doc if it exists.

SVG Parameters in CSS

   Topic: SVG parameters in CSS in relation to CSS Variables
   <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/SVGParamsUrlSyntax
   shepazu: we would like to consider csswg want to do something like this.
   TabAtkins: in ref to combining efforts, csswg is interested in pursuing vars.
   TabAtkins: params can work in with concept of vars such that you would
              put params and they would create vars.
   shepazu: I thought you would decl. canonical what is the var, and
            explicitly say this would be the param for that var
   TabAtkins: yours is probably a better idea.
   shepazu: # syntax has been overloaded by media fragments.
   shepazu: 3rd syntax is x-pointer style function that enclose vars in
            would be best way forward.
   shepazu: imagine those are .css files. you are passing in a list of
            parameters within paranthesis
   <smfr> http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html
   <shepazu> fill="param(color) blue"
   shepazu: if param is not passed in, use this keyword
   <shepazu> x="calc(param(coordx)+10%)"
   shepazu: is there any problem with this?
   heycam: for vars you know ahead of time.
   florian: CSSWG did not express interest in variables but only allow
            tab to work on his draft.
   florian: vars were global to the page, but params are stylesheet local
            and would make people who hate variables hate them more
   shepazu: my q is given this is something we are interested in adding
            in svg. if you want to add this in the future in css, is
            this acceptable in broad terms
   TabAtkins: some of the qs raised against my proposal are valid here.
              are they changable by script?
   shepazu: yes
   shepazu: the HTML WG is not interested in changing the params thing
   TabAtkins: presumably there would some script based api to easily
              handle them rather than parse them yourself
   shepazu: someone proposed a url parsing api.
   anne: adam barth is working on that.
   shepazu: maybe we just plug this into abarth's thing
   anne: is this not like param elms?
   shepazu: at one point it was, but they didn't like that.
   heycam: as in specify value of params in the url.
   shepazu: there are param elements. if only thing we can do is url
            syntax that is okay with me
   shepazu: this is a diff kind of param passing
   heycam: adam barth proposed to get query string, this is stuff
          embedded in frame.
   heycam: it's going to hit the network every time.
   TabAtkins: I don't like the way you are defining right now to use a
              param with default val.
   TabAtkins: you cannot use the syntax if you use fill property in css.
   TabAtkins: if you want default values on params pre decl them
   shepazu: that was in org version of spec, but dropped as people didn't like
   shepazu: what would be better for css
   TabAtkins: anything where you have space separated value becomes ambiguous
              with what is there right now. this is problem in css and maybe
             for future svg things
   <ChrisL> %20 is your firend
   <ChrisL> url escaped space
   ACTION: shepazu propose a couple of diff syntax and submit them for wider
           review and see what people think about them and ping csswg
   <trackbot> Created ACTION-50
   TabAtkins: nothing to do with spaces in param decl but in param use
   TabAtkins: param blue foo is ambiguous if you are specifying fallback
              or another value
   <ChrisL> syntactic spaces considered harmful. syntactic spaces as ancestor
            selectors, doubly so
   TabAtkins: if you use param in a path, it would be THE example.
   <plinss> param(name, default)

FX transforms

   <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FXTransforms
   vhardy: agree on how we can go about doing this. I can help with editing
           the doc.
   heycam: who are editors of current doc?
   vhardy: dean chris simon and we also had anthony
   vhardy: what we want here is to understand what we need as next step.
   vhardy: I just want to know how we go about producing a new document.
   dino: you run into issue of how to combine with svg if you call it css
   vhardy: solution is to say it's css transform. there are only 2 ways to
           combine them.
   heycam: I seem to be the only one in favor of turning into a property
   heycam: the fact that transform dom attr does not translate to property names…
   heycam: argument against turning into a property is what svg dom access
           to transform stuff means. I don't think its impossible to design
   vhardy: if we agree on putting together a doc. we agree on intent to
           combine them.
   smfr: want a time frame as we already have implementations of css transforms
   vhardy: is it okay if we try to advance 2d first and then 3d
   smfr: it is simple to have 1 doc, but we have multiple impl. of 2d transforms.
   dbaron: we are getting a few pieces of 3d transforms in
   shepazu: by the time we finish this spec would we not have 2 impl.
   vhardy: is that not likely?
   <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=505115
   smfr: for 3d transforms the impl would be more widely varied.
   smfr: there are no obvious conflicts in OM.
   sylvaing: I wouldn't want to take risk of doing 3d if something changes in 2d.
   dino: that relies on css om. we removed that css values have still been
   sylvaing: we need a better def for 3D anyway.
   vhardy: goes into direction of might as well have one spec.
   shepazu: is anyone not using 2d transforms because it's not standardized?
   dbaron: it is a pain for the authors because of prefixes
   shepazu: bigger pain if we get it wrong
   sylvaing: do I prefix only 3d?
   smfr: fair point as you can mix 2d & 3d functions
   heycam: are there no more open issues on 2d?
   smfr: there are def issues w.r.t svg and css
   smfr: the issue with dropping prefix on 2d and not on 3d might have a
   smfr: it is possible to pass 3d transform functions, and throw away the
         z parts.
   dino: if they wanted to do 3d they can use prefix and the prefixed one
         beats the unprefixed one.
   smfr: you wouldn't want to do that.
   vhardy: my pref is to make it one doc and work out the issues we have
           and move forward.
   smfr: ideally that would be mine too, but I think it would take 2 years
   vhardy: it does not hurt to have one spec if it's the hold up.
   dino: we say we want to know what it should be.
   anne: the thing with om you can't really pull transforms in front of
         designing the value api.
   smfr: transforms are a good test case for value api
   sylvaing: try to drop prefixes on the property but the om can have the
   smfr: probably apply the same for gradients
   anne: webkit still has the old value api. all the new apis are designed
         around premise of keeping around that api.
   anne: that seems bad as we abandonded it around 2003 or 4
   shepazu: this does not resolve question of svg and css
   smfr: does resolve prefix droppping on 2d and not on 3d
   anne: why can't we drop for 3d.
   smfr: we don't have more than 1 impl and there will be lots of issues
         when there are more.
   dbaron: I would be interested in figuring out what you do wrong.
   dino: would property change even if impl is undefined.
   smfr: the values and property are fairly stable. svg might add a few things.
   smfr: there is an issue with units in matrix
   dbaron: issue of whether we want px as base unit, or get unit right in
           "some sense"
   dbaron: I am less confident in the stability of other properties in 3d
   smfr: we should start filing issues somewhere
   shepazu: it seems like people think this is priority. is that right?
   smfr: I think so.
   shepazu: we can make lot of progress if we start pushing this.
   dino: the progress is all being in stuff thats stable and existing,
         the work to be done to merge the two specs is how does svg become
         transform properties
   ChrisL: it is better that way to style if we multiply together
   dino: it becomes harder if you want to make all svg attr properties
         then you would have two properties
   heycam: convert to property and use css one.
   <ChrisL> "we don't need to keep around SVG transforms" uh huh, make
            every single piece of svg non conformant at a stroke ....
   heycam: what do others think about turning svg transform attr into a property
   <ChrisL> turning it into a property makes it apply to all elements
   shepazu: deal with legacy transform attr deal with it as we did,
            going forward use css transforms
   heycam: I don't want to put transform inside style.
   shepazu: what's the downside
   heycam: we need to make sure the syntax is compat and make sure existing
           one would work
   heycam: need to define what access to SVG transform means
   heycam: I think we can come up with something reasonable.
   heycam: I was hoping we would resolve syntax compat problems anyway.
   Jennifer: would 3d apply to svg.
   heycam: there are plans to.
   vhardy: smfr you were talking about applying 3d transforms to svg right?
   smfr: yep
   ed: look at TraitAccess in svg tiny 1.2, it allows fetching both baseVal
       and animVal for properties as well as for normal attributes
   RESOLVED: Turn transform attribute into a CSS property and heycam to
             investigate and write a proposal to what SVG DOM does in
             this situation
   ACTION: heycam to investigate and write a proposal to what SVG DOM
           does when svg transform attribute becomes a css property
   <trackbot> Created ACTION-51

   dino: we still got the question on merging the spec.
   dino: the transforms spec requires units in translations.
   smfr: transform-origin changes
   heycam: you still worried about slight differences in svg and css.
   <ChrisL> yeah lets kill the units requirement
   dino: making one unified spec isn't just adding 3d stuff but also
         combining unitless and united transform function and maybe
         differences in transform origin
   heycam: we should try to resolve any differences we can and put the
          rest as slight differences between presentation and property
   ed: some of the issues have been resolved in fx transforms draft
       e.g. transform-origin has been resolved.
   dino: the most dangerous difference is something like transform: scale(2)
         and expect it to apply to a bunch of elms some of which are svg
         and html.
   heycam: how's origin resolved?
   ed: I think svg elements it was moved to something else.
   anne: svg elms can have different origin specified
   heycam: are you saying it could be confusing?
   dino: yeah
   anne: svg has diff co-ordinate model than css anyway
   ed: you can specify transform-origin:50%,50% explicitly for svg to get
       the same origin as for other elements
   dino: next step is to find someone who wants to do it.
   heycam: I have to look at transforms stuff and look at impact to svg
   vhardy: I am willing to help.
   <dbaron> Sounds like there are at least some :hover editors :-)
   dino: I am okay if you (vhardy) took it over
   vhardy: heycam has a bunch of items that anthony had.
   smfr: I am willing to edit some of the 3d parts
   vhardy: I am not ready to do it just by myself.
   dino: the stuff that needs to be done is the difficult part.
   vhardy: I like someone to work with me on editing an wording the svg stuff
   smfr: I would like other implementors to start filing issues
   dbaron: what's the tracking mechanism?
   vhardy: we have a wiki page.
   <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FXTransforms
   smfr: wiki is fine.
   <ed> http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsToDoList
   vhardy: we agree to do one spec and call it 'css transforms'?
   smfr: there is confusion with xslt transform
   smfr: so we need a prefix
   RESOLVED: The CSS 2d, 3d, SVG 2d and 3d, FX transforms spec are going to
             be combined into one CSS Transforms spec.
   ACTION: vhardy to work with heycam dino smfr to work on the new spec for
           CSS Transforms.
   <trackbot> Created ACTION-52

   dbaron: I have mixed feelings, as 2d is more stable than 3d.
   dbaron: last TPAC we had a resolution to get css 2d get to CR more quickly
   dino: boris, dbaron and sylvaing had comments on css 2d
   vhardy: I will work with you smfr dino to figure out what would be the
           best base to start from.
   dbaron: we can still advance the current specification
   florian: so combined spec becomes css 4
   dbaron: I think we should keep the option open to advance 2-D, but I'm ok
           with going ahead with this approach.
   dino: it is just interesting that we have a spec that could possibly enter
         CR and we are not progressing it.
   shepazu: do we have tests for it?
   smfr: we have some test cases that are being worked on
   shepazu: if people want to push css2d before css2d and 3d go for it.
   heycam: I don't think its a problem
   heycam: it's only a problem if we need to make changes to css2d spec.
   heycam: I don't see how spec organization impacts 3d.
   smfr: how do you ship a browser that supports prefixed or unprefixed.
   heycam: thats a q regardless of whether they are in same spec or not
   smfr: if in same spec you can drop prefixes at once.
   heycam: is that the convention?
   smfr: yeah one module yeah.
   shepazu: having a 2d spec does not resolve the issue
   smfr: that's true.
   heycam: is the convention to drop prefix once we get to CR?
   dbaron: convention is to drop prefix once you go to CR and get the test suite
   shepazu: we have no problems with anyone pushing 2D stuff, even putting
            it into CR.
   smfr: I think thats fine. we will figure out how to deal with prefix
         issue when it comes up.
   smfr: the combined spec is a good thing in long term, if we decide we want
         to we can accelerate the 2d spec separately and we will figure out
         internally issues related to dropping the prefix somehow.

Publishing Schedule

   vhardy: we could have a draft by TPAC for transforms
   ed: for filters how long it would take?
   dino: I can have it done by the week.
   dino: everyone has agreed we can publish it as first WD
   vhardy: discuss on friday how much progress we can make w.r.t compositing
   cabanier: how 3d transforms work with compositing and filters. as compositing
             assumes 2D.
   dino: we do specify some form of flattening in the 3D spec. it is a bit of
         black magic at this moment.
   vhardy: can you discuss this sometime tomorrow?
   ed: that's all on the agenda I could squeeze a bit about the testing
   ed: plinss currently the svg test suite is not using the test harness,
       it could be useful.

Testing Harness Overview

   <plinss> test.csswg.org/harness
   plinss: it presents all the test in a test suite
   plinss: it computes what order …
   plinss: there are metadata embedded in the test which links back to the url.
   plinss: presents your test in an iframe, test can be multiple formats
           in a tabbed interface.
   plinss: upper right hand corner you have current results known by rendering
   plinss: it is doing manual testing visually
   plinss: it has a bunch of reporting system.
   plinss: shows detailed results gathered thro that particular tests, user agent.
   plinss: full flushed out test file.
           you can also see results by portions of the spec.
   <plinss_> http://test.csswg.org/annotations/css21/
   plinss: there is a spec annotation system
   plinss: tests show up for each section
   plinss: it injects that annotation mark.
   plinss: annotations link back to the harness
   plinss: the title for each annotation takes you to the test itself.
   shepazu: how do you put this into the spec?
   plinss: 1 line of script
   alan: how does it display if a section does not have tests? maybe it
         should display red.
   plinss: not every section needs tests
   plinss: there are some features that are exposed in the ui, you can enter
           another UA string.
   plinss: I run a cron that takes all the results and figures out where
           tests are needed most to get to CR
   plinss: there is an instance of this running on w3c server
   plinss: its all open source.

   shepazu: so in svg I can't tell can you do side by side comparisons?
   <plinss_> http://test.csswg.org/harness/test/CSS21_DEV/flag/reftest/
   plinss: you can do back and forth side by side.
   plinss: can specify it must look like this page, AND this page and NOT
           like this page.
   plinss: the reference can be plain reference file or another test.
   shepazu: can we resolve to move to this in SVG 2?
   ed: I am most interested is the ability to see the test+results in each
       spec sections
   shepazu: even if you don't do tests in this harness you can post reports.
   plinss: I believe mozilla and webkit have their own systems to run
           automated tests and they can export it to the harness.
   <plinss_> http://w3c-test.org/framework/

Printing Backgrounds

   TabAtkins: mainly for csswg, could people respond to thread of
              background-print property
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2011Jul/0341.html
   TabAtkins: solution suggested by glazou to have authors override default
              UA stylesheets is not feasible as browsers do not want authors
              to override UA styles
   plinss: I have no problem to override it, the default needs to be auto.
           we need something in css when user pref is auto.
   glazou: in your opinion auto is do not print bg until the author says
           print background
   plinss: there is no way to change default.
   TabAtkins: background-print is just an element property.
   * fantasai thinks an element property is overkill and a document property
              would do, except we don't have those

Meeting closed.

Received on Saturday, 6 August 2011 01:36:21 UTC