W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2010

Minutes public-fx telcon May 17, 2010

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 18 May 2010 09:35:49 +0200
To: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <op.vcv4pzlogeuyw5@localhost>
Hello public-fx,

here are the minutes from the May 17, 2010 public-fx telcon:


and the same in text format below:


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

                                - DRAFT -

                    CSS-SVG Task Force Teleconference

17 May 2010



    See also: [3]IRC log

       [3] http://www.w3.org/2010/05/17-fx-irc


           Shepazu, David_Baron, ed, smfr, Tab_Atkins, ChrisL, anthony



           TabAtkins, TabAtkins_


      * [4]Topics
          1. [5]transform-origin
          2. [6]merged css/svg transforms 2d spec
          3. [7]Wiki/Location for FX
          4. [8]Exposing SVG Filters in HTML
      * [9]Summary of Action Items

    <trackbot> Date: 17 May 2010

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

      [10] http://qconsf.com/sf2008/speaker/Loretta+Guarino+Reid

    <TabAtkins_> ScribeNick: TabAtkins

    <TabAtkins_> ScribeNick: TabAtkins_




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

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

    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

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

    smfr: [gives examples of what it means, to answer "yes" to the

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

    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

    <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

    <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

    <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

    <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> [16]http://www.w3.org/mid/4BE8E7EE.2080600@cisra.canon.com.au

      [16] http://www.w3.org/mid/4BE8E7EE.2080600@cisra.canon.com.au



    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

    <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> [19]http://www.w3.org/Graphics/fx/wiki/Main_Page

      [19] http://www.w3.org/Graphics/fx/wiki/Main_Page

    <ed> [20]http://www.w3.org/Graphics/fx/ (that's a broken link)

      [20] http://www.w3.org/Graphics/fx/

    <shepazu> [21]http://www.w3.org/Graphics/fx/wiki/Main_Page

      [21] 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

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



    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

    <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> [24]http://www.w3.org/blog/CSS/2009/11/25/resolutions_84

      [24] 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

    <trackbot> Sorry, couldn't find user - eric

    <scribe> ACTION: Eric to Start the spec for SVG filters in CSS.
    [recorded in

    <trackbot> Sorry, couldn't find user - Eric

    <scribe> ACTION: Erik to Start the spec for SVG filters in CSS.
    [recorded in

    <trackbot> Created ACTION-13 - Start the spec for SVG filters in
    CSS. [on Erik Dahlström - due 2010-05-24].

Summary of Action Items

    [NEW] ACTION: Anthony , Simon to Add 'auto' value for transform
    origin, make %s be relative to bounding box in SVG. [recorded in
    [NEW] ACTION: eric to Start the spec for SVG filters in CSS.
    [recorded in
    [NEW] ACTION: Eric to Start the spec for SVG filters in CSS.
    [recorded in
    [NEW] ACTION: Erik to Start the spec for SVG filters in CSS.
    [recorded in
    [NEW] ACTION: Simon to Make changes suggested in Dean's email.
    [recorded in
    [NEW] ACTION: Simon to Reply to Dr. Olaf's email. [recorded in
    [NEW] ACTION: Simon, anthony to Add 'auto' value for transform
    origin, make %s be relative to bounding box in SVG. [recorded in
    [NEW] ACTION: smfr, anthony to Add 'auto' value for transform
    origin, make %s be relative to bounding box in SVG. [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [36]scribe.perl version 1.135
     ([37]CVS log)
     $Date: 2010/05/17 21:02:21 $

      [36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [37] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [38]http://dev.w3.org/cvsweb/~checkout~/2002

      [38] 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, an
Present: Shepazu David_Baron ed smfr Tab_Atkins ChrisL anthony
Regrets: Dino
Agenda: [39]http://lists.w3.org/Archives/Public/public-fx/2010AprJun/00
Found Date: 17 May 2010
Guessing minutes URL: [40]http://www.w3.org/2010/05/17-fx-minutes.html
People with action items: anthony eric erik simon smfr

      [40] http://www.w3.org/2010/05/17-fx-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

    End of [41]scribe.perl diagnostic output]

      [41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 18 May 2010 07:36:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:36 UTC