- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 05 Aug 2011 18:35:51 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Compositing/Filters
-------------------
- 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.
Miscellaneous
-------------
- 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
http://lists.w3.org/Archives/Public/www-style/2011Jul/0341.html
====== Full minutes below ======
Scribe: nimbu
Compositing
-----------
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
version
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
mode
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?
http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
<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
different.
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
filters.
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
well.
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
transformed
* 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
experimentation
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
prefix
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
together.
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
stuff.
<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
color-correction
----------------
<tantek> "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)
<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
mismatch?
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
transforms
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
something
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
deprecated.
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
workaround.
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
prefixes.
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
transforms.
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
engine
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