See also: IRC log
<trackbot> Date: 17 May 2010
<smfr> http://qconsf.com/sf2008/speaker/Loretta+Guarino+Reid
<TabAtkins_> ScribeNick: TabAtkins
<TabAtkins_> ScribeNick: TabAtkins_
<ed> http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0053.html
ed: For transform-origin, we want
to be compatible with svg.
... I don't think we can defualt ot 50% 50%
smfr: Sounds like we may need an 'auto' value that does 0 0 for SVG and 50% 50% for other things.
ChrisL: That's a good way to split up automatic values.
dbaron: it's not clear what the
property does at all for SVG, particularly %ages.
... So maybe we should map all %s to 0
ChrisL: I think people would find that puzzling.
ed: I think it's fine if you
specify the transform-origin to something explicit, it should
apply to SVG.
... But it shouldn't counteract what is happening in SVG
today.
shepazu: Devil's advocate, is it okay to have diferent defaults for different languages?
smfr: We did that alreayd, with pointer-events in HTML and SVG.
shepazu: So if there's precedent, sure.
smfr: Are there any SVg elements for which % do make sense?
ed: %s are relative to the box in CSS, right? So we'd say it was relative to the bounding box in SVG?
shepazu: Or the origin, but I think it makes more sense to the bounding box.
smfr: It has to be related to the height and width somehow. For a path, I think it'd be weird to do the bounding box.
shepazu: SVG only has width and
height for one element, the rectangle.
... You could kinda say it has that for ellipse, but...
ChrisL: Any drawn element has a bounding box, though.
ed: It doesn't *always* make sense for paths, but I think it's intuitive enough for most cases.
shepazu: I think the bounding box is the closest analogue to the CSS idea, and that's what makes sense to me.
smfr: Should we resist using %s at all?
ChrisL: We have to do something about %s. Can it inherit from HTML into SVG?
shepazu: Regardless, we still have to say what happens if it's set explicitly.
smfr: No, does not inherit.
shepazu: I think if you can do it
in CSS, it makes sense to consider allowing it in SVG.
... I don't see what is inherently wrong with allowing %s in
SVG.
ed: Ok, so is anything suggested in the original email?
smfr: He makes a good point about
<g> elements containing animated stuff.
... It gets tricky.
ed: A <g> element would
always have a bounding box, even if it changes over time if
it's animated.
... The same is true for any animation in SVG in a group.
ChrisL: In some sense setting the transform-origin on the bounding box of a group makes more sense.
<ChrisL> setting origin based on the bounding box of a group could be handy. its the sum of the bbox of its childrten, so if some children are changing size it can be handy to add a (non visible) child
shepazu: It might be useful for us to jot down a bunch of use-cases for transform-origin, and think through some different applications.
<ChrisL> and then its bbox with be its parents bbox, if it is big enough
shepazu: Like what ChrisL
mentioned just now.
... And other things would conflict or reinforce that. smfr,
could you draw up some of those?
smfr: [lists some examples]
shepazu: I know that scaling has always been a pain for me; I usually want it to expand around the center point, not the origin.
ed: You can only specify one transform-origin, right?
smfr: yeah.
ed: So you can't use it for
really advanced things, but for simple cases it's really
handy.
... So if you want to transform and rotate with different
origins?
smfr: You'd have to either put
two elements with different origins, or build it into the
transitions.
... This also makes it easy to animate the transform-origin
itself.
shepazu: This is one of the things people are going to use for unexpected/unusual things, so it'll be hard to comprehensively list use-cases, but we can take a stab at thatm.
smfr: One thing you can do with
transform-origin, but not normal transforms...
... Are we talking about use-cases for %s, or...?
shepazu: %s as opposed to keywords, or opposed to absolute lengths?
smfr: Absolute lenghts.
shepazu: Say I had two icons,
60px wide and 45px wide. I want both to double their size
around their center point when I mouse over them.
... I don't want separate transformations, I'd rather just have
one that says "grow them from their center point".
smfr: That's a good use-case.
shepazu: If something happens at
50% 50%, that's of the current transformed value, not the
original "absolute" value, right?
... So if I rotated something and scaled it, the 50% would be
post-transformation?
smfr: [gives examples of what it means, to answer "yes" to the question]
shepazu: When transform-origin is
applied to multiple things, I think we need to lay out exactly
the way in which it is applied.
... And make good tests for it.
smfr: I'm slightly concerned
about using bounding-box, because in HTML it's relative to the
border-box. overflow doesn't change the border-box.
... Is the bounding-box affected by filters?
shepazu: No.
... In SVG2 we're adding different script methods to take into
account filters, strokes, etc.
... but getboundingBox() just returns the "core geometry" of
the shape.
smfr: Okay, that's all right then.
ed: So it sounds like we have
resolution then.
... To let SVG %s be relative to the bounding-box.
smfr: And to have an initial 'auto' value that has different behavior for SVg and HTML.
shepazu: Right.
ChrisL: I just saw an email form Anthony where he asked for editors, and Dean suggested Simon and Dean.
<scribe> ACTION: smfr, anthony to Add 'auto' value for transform origin, make %s be relative to bounding box in SVG. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action01]
<trackbot> Sorry, couldn't find user - smfr,
<scribe> ACTION: Simon, anthony to Add 'auto' value for transform origin, make %s be relative to bounding box in SVG. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action02]
<trackbot> Sorry, couldn't find user - Simon,
<ChrisL> trackbot, status?
<scribe> ACTION: Anthony , Simon to Add 'auto' value for transform origin, make %s be relative to bounding box in SVG. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action03]
<trackbot> Created ACTION-10 - , Simon: Add 'auto' value for transform origin, make %s be relative to bounding box in SVG. [on Anthony Grasso - due 2010-05-24].
ed: Also, add Simon and Dean to edit the spec.
<scribe> ACTION: Simon to Reply to Dr. Olaf's email. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action04]
<trackbot> Created ACTION-11 - Reply to Dr. Olaf's email. [on Simon Fraser - due 2010-05-24].
ed: [another email]
ChrisL: Seemed like a fine email, nothing contentious. We could go over it, certainly.
<ed> http://www.w3.org/mid/4BE8E7EE.2080600@cisra.canon.com.au
<ed> http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0057.html
ed: I think I agree with all the changes in here. It's just a question of who will make the changes.
smfr: I or Dean can do it.
<scribe> ACTION: Simon to Make changes suggested in Dean's email. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action05]
<trackbot> Created ACTION-12 - Make changes suggested in Dean's email. [on Simon Fraser - due 2010-05-24].
ed: Do we have a wiki or something for fx?
ChrisL: Yes.
... It was broken, and I'm not sure if it's been fixed yet.
<ChrisL> http://www.w3.org/Graphics/fx/wiki/Main_Page
<ed> http://www.w3.org/Graphics/fx/ (that's a broken link)
<shepazu> http://www.w3.org/Graphics/fx/wiki/Main_Page
ChrisL: There's nothing at fx, but fx/wiki works.
shepazu: So let's just redirect to /wiki
smfr: I still can't get in; I'm getting an incorrect password.
[various discussion over who can log in and who can't]
ed: Any updates on actions since last time?
smfr: I havne't had time to write on wiki anything about image transitions from last time.
<ChrisL> Open actions at http://www.w3.org/Graphics/fx/track/actions/open
ed: Anything else we need to discuss?
smfr: I'd like to talk about exposing SVg filters in HTML.
smfr: I'd like to have a way to
apply SVG filters from CSS with some syntax that references
filters from an SVG file.
... But in addition I'd like to see several very simple filters
as their own properties.
shepazu: In SVGWG we're calling those "canned effects".
ed: Where would you like to see that spec?
smfr: I think that much like this
transform stuff, this sits between SVG and CSS.
... It's going to be wrapping up SVG filters that exist in
CSS.
ed: So you'd prefer a separate spec?
smfr: yeah, like what we're doing with 2d transforms.
shepazu: Simon, are you saying that the filters spec should be in FXTF rather than SVG?
smfr: I don't mind the main
filters spec living in SVG, as long as as it evolves it is
applicable to HTML.
... And whatever we set up between that and CSS continues to
work.
ChrisL: I think on the Filters spec, it lists that explicitly as a design goal.
dbaron: Mozilla's been shipping
support for referencing an SVG filter from HTML for a
while.
... One thing I think would be very useful for filters in html
would be having support for "source graphic"/"source
alpha"/etc.
... Whatever those are called, we probably want to think about
extending those to work better with CSS.
... Things like separating the background from the border form
the content, etc.
... in the discussion for the box-shadow property, there's a
lot of discussion about what sort of effects people want to
shadow.
... And I think everyone has a different mental image about
what is being shadowed.
... And I think that once authors see that box-shadows shadows
X not Y, they'll want that choice.
TabAtkins_: BradK brought up that sort of idea in the last CSS ftf at TPAC.
<ChrisL> so we would want to get at the content, the background, the padding, and the border (or perhaps several of the eight sections of the border)
shepazu: Agreed that calling out
specific parts of the image would be useful, to be filtering
on.
... I think you can get a transluscency effect right now by
blurring something on top rather than below, like a reverse
drop-shadow. Like seeing through transluscent glass.
ed: Trying to find the part in the Filters spec where we say we expect other specs to extend the set of keywords.
<ed> http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html#FilterPrimitiveInAttribute
shepazu: The processing.js people have been doing some very cool things with applying SVG filters to html video, etc.
ed: Actually, I think the spec
currently doesn't say that we allow the to be extended, but it
does say that other specs need to define what the keywords
mean.
... But I don't disagree with extending the keywords.
smfr: What are our next steps in this area?
ed: I can take an action to add
that to the filters spec.
... I think we can start a wiki page for what CSS shorthand we
want for filters, and what primitives we want to expose in that
way.
smfr: I or David can contribute some thoughts on Moz's impl.
dbaron: We haven't extended it, we just have the CSS filter property that can be applied to any element.
ChrisL: So when you apply a filter, what is it applied to?
dbaron: The whole thing; the
border/background/etc.
... I think it works like opacity and creates a new stacking
context.
<dbaron> (but not sure about that)
shepazu: The processing.js people
want to apply multiple filters to the same content.
... I guess they would be sequential.
smfr: Chaining filters together?
shepazu: yes.
<fantasai> We discussed a list of things you'd want to apply filters to at a recent F2F
shepazu: Are we talking about just one spec? Filters, and canned filters are part of that? Or two different specs?
smfr: Is there any precedent for an SVg spec to describe CSS properties that can apply to HTML?
ChrisL: Not specifically to html.
<fantasai> http://www.w3.org/blog/CSS/2009/11/25/resolutions_84
shepazu: We can talk about CSS properties, but frex none of the border properties apply to CSS at the moment.
smfr: My feeling is that we should have a new spec under public-fx for the combined filters.
ed: Makes sense. I'd like to be one of the editors.
smfr: I could be an editor too.
<fantasai> makes sense to me too
<fantasai> but I would not like to be an editor too :)
<scribe> ACTION: eric to Start the spec for SVG filters in CSS. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action06]
<trackbot> Sorry, couldn't find user - eric
<scribe> ACTION: Eric to Start the spec for SVG filters in CSS. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action07]
<trackbot> Sorry, couldn't find user - Eric
<scribe> ACTION: Erik to Start the spec for SVG filters in CSS. [recorded in http://www.w3.org/2010/05/17-fx-minutes.html#action08]
<trackbot> Created ACTION-13 - Start the spec for SVG filters in CSS. [on Erik Dahlström - due 2010-05-24].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/can't/does not/ Succeeded: s/Me/I/ Succeeded: s/Chainging/Chaining/ Found ScribeNick: TabAtkins WARNING: No scribe lines found matching ScribeNick pattern: <TabAtkins> ... Found ScribeNick: TabAtkins_ Inferring Scribes: TabAtkins, TabAtkins_ Scribes: TabAtkins, TabAtkins_ ScribeNicks: TabAtkins, TabAtkins_ Default Present: Shepazu, David_Baron, ed, smfr, Tab_Atkins, ChrisL, anthony Present: Shepazu David_Baron ed smfr Tab_Atkins ChrisL anthony Regrets: Dino Agenda: http://lists.w3.org/Archives/Public/public-fx/2010AprJun/0056.html Found Date: 17 May 2010 Guessing minutes URL: http://www.w3.org/2010/05/17-fx-minutes.html People with action items: anthony eric erik simon smfr WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]