CSS-SVG Task Force Teleconference -- 17 May 2010

<trackbot> Date: 17 May 2010

<smfr> http://qconsf.com/sf2008/speaker/Loretta+Guarino+Reid

<TabAtkins_> ScribeNick: TabAtkins

<TabAtkins_> ScribeNick: TabAtkins_

transform-origin

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

merged css/svg transforms 2d spec

<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].

Wiki/Location for FX

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.

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].

- DRAFT -

CSS-SVG Task Force Teleconference

17 May 2010

Attendees

Contents

transform-origin

merged css/svg transforms 2d spec

Wiki/Location for FX

Exposing SVG Filters in HTML

Summary of Action Items

Scribe.perl diagnostic output