Minutes, January 23 2012 FXTF telcon

Minutes:


     http://www.w3.org/2012/01/23-fx-minutes.html


and as text:


    [1]W3C

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

                                - DRAFT -

                    CSS-SVG Task Force Teleconference

23 Jan 2012

    [2]Agenda

       [2]  
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0014.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/01/23-fx-irc

Attendees

    Present
           VH, ED, CM, SF

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           vhardy, dino

Contents

      * [4]Topics
          1. [5]Proposition for CSS Animations and Transitions on SVG
             attributes
          2. [6]CSS Transforms specification.
          3. [7]drop-shadow filter vs. a separate property
      * [8]Summary of Action Items
      _________________________________________________________

    <trackbot> Date: 23 January 2012

    <vhardy> ScribeNick: vhardy

Proposition for CSS Animations and Transitions on SVG attributes

    <ed>
    [9]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.htm
    l

       [9]  
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0168.html

    ed: this was discussed at the SVG F2F two weeks ago. We have a
    proposal from Microsoft.
    ... the outcome of the discussion is that the group believes the
    proposal is the best one so far and we would like to know if anybody
    has objections to the proposal.

    smfr: do we have a list of the property names?
    ... are we adding a list of properties to CSS through this
    promotion. I am concerned about properties like 'r', 'tx' or 'cx'.
    ... another concern is that we may be using names that CSS might
    want to use for other things in the future.

    vhardy: the list of property names is in the proposal.

    dino: I think the next step is to talk to the CSS wg. There are two
    options. Here are the properties we want to add to the CSS
    namespace. Do we need to prefix the properties or not. I do not
    think we can make much decision here.

    smfr: I agree.

    vhardy: I agree.

    dino: I agree too :-)

    ed: in that case, we need to summarize the properties that we plan
    to add and send it to the CSS WG.

    <scribe> ACTION: Patrick Dengler to send an email to the CSS WG
    asking for feedback on proposed list of additional properties to be
    added when promoting SVG attributes to properties. Ask if properties
    should be prefixed or not to deal with possible collisions.
    [recorded in
    [10]http://www.w3.org/2012/01/23-fx-minutes.html#action01]

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

    <scribe> ACTION: Erik Dahlstrohm (with Patrick Dengler) to send an
    email to the CSS WG asking for feedback on proposed list of
    additional properties to be added when promoting SVG attributes to
    properties. Ask if properties should be prefixed or not to deal with
    possible collisions. [recorded in
    [11]http://www.w3.org/2012/01/23-fx-minutes.html#action02]

    <trackbot> Created ACTION-65 - Dahlstrohm (with Patrick Dengler) to
    send an email to the CSS WG asking for feedback on proposed list of
    additional properties to be added when promoting SVG attributes to
    properties. Ask if properties should be prefixed or not to deal with
    possible collisions. [on Erik Dahlström - due 2012-01-30].

    <smfr> vhardy, don't forget to minute yourself!

    vhardy: how would we publish this new behavior for SVG presentation
    attributes? Will that be a stand-alone addendum to SVG 1.1 2nd
    edition, or will it be a 3rd edition of SVG 1.1

    dino: it sounds it should be a separate spec. if we want to have it
    alive in a reasonnable amount of time.

    vhardy: if a separate spec., that would be an addendum to SVG 1.1,
    right?

    ed: yes, this is adding properties for SVG 1.1, so the best would be
    to do an addendum to the SVG 1.1 spec. It should also be folded in
    SVG 2. It depends on what people feel is appropriate.

    <smfr> who's ichatting?

    heycam: normally, separate specs. add to the functionality instead
    of changing behavior, like here. I agree with Erik that it should be
    folded in SVG 2 anyway.
    ... I do not have a problem leaving it initially in a separate spec.

    vhardy: sounds good to me too: have a separate spec. for 1.1 and
    fold into SVG 2.

    <scribe> ACTION: Patrick to create an initial editor draft of the
    document that can be pointed to and discussed with the CSS WG.
    [recorded in
    [12]http://www.w3.org/2012/01/23-fx-minutes.html#action03]

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

    <dino> trackbot, reload

    <scribe> ACTION: Patrick to create an initial editor draft of the
    document that can be pointed to and discussed with the CSS WG.
    [recorded in
    [13]http://www.w3.org/2012/01/23-fx-minutes.html#action04]

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

    <scribe> ACTION: Erik to create an initial editor draft of the SVG
    with CSS Animations/Transitions document that can be pointed to and
    discussed with the CSS WG. [recorded in
    [14]http://www.w3.org/2012/01/23-fx-minutes.html#action05]

    <trackbot> Created ACTION-66 - Create an initial editor draft of the
    SVG with CSS Animations/Transitions document that can be pointed to
    and discussed with the CSS WG. [on Erik Dahlström - due 2012-01-30].

    ed: any other feedback on the proposal?

    (silence)

CSS Transforms specification.

    <dino> ScribeNick: dino

    vhardy: DirkS has joined Adobe and will be focusing on the merged
    transforms specification. He's captured the issues in bugzilla. He's
    started on a wiki page with the difficulties of the merge
    ... it would be better if he was an editor. I suggest we add Dirk as
    an editor.

    dino: I support this.

    smfr: me too

    ed: me too

    RESOLUTION: Dirk becomes an editor of the SVG+CSS Transforms
    specification

    RESOLUTION: Vincent also is an editor of the SVG+CSS Transforms
    specification

    vhardy: Dirk will bring some of the CSS OM issues to a telcon. After
    that he'll bring up the parsing issues (units, etc).
    ... do we think that should come here first? or go straight to CSS
    WG?
    ... risk is that people won't be at an FX call

    dino: I think we should go straight to CSS

    vhardy: ok
    ... I notice that the CSS 2D transform spec is now pointing at the
    merged spec. The CSS 3D spec hasn't. Should we do it?

    dino: I think so.

    (I didn't minute that because I think we just repeated the question)

    smfr: I think there are some outstanding edits that need to be
    included in the spec.
    ... I'm not sure if we want to update the 3d spec and publish, THEN
    move it to the combined spec.

    vhardy: when was the last major update to transforms?

    dino: Sept 11 I believe

    vhardy: in which case the merged spec has all the updates to 2d
    ... our resolution at the TPAC was to publish 3d, noting that it is
    now replaced by the merge spec

    <scribe> ACTION: Vincent to edit the CSS 3D spec to point to the
    merged spec [recorded in
    [15]http://www.w3.org/2012/01/23-fx-minutes.html#action06]

    <trackbot> Created ACTION-67 - Edit the CSS 3D spec to point to the
    merged spec [on Vincent Hardy - due 2012-01-30].

    smfr: so no changes other than the notification that this spec is
    now elsewhere?

    vhardy: correct

    <vhardy> ScribeNick: vhardy

    ed: there was more discussion on drop-shadow on the list.

    <ed>
    [16]http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0027.ht
    ml

      [16]  
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0027.html

    dino: Apple's position is that drop-shadow would be better as a
    separate property. We are talking about the shorthand functions.
    There would still be a way to do a drop shadow with an SVG filter.

drop-shadow filter vs. a separate property

    smfr: the CSS wg has talked about it multiple times in the past. It
    got some pushback because there were people who wanted to apply the
    drop shadow to some parts (e.g., just background or just border). I
    am not arguing against or for it, just relating what discussions
    happened in the past.

    ed: I am not sure I understand the advantage to keep it as a
    separate property. May be because it is somewhat easy to implement.

    dino: performance. It is a fairly complex filter. And, when it comes
    down to it, people will not put a drop shadow in the middle of their
    filter operation. They will likely apply a drop shadow and then
    filter the result.

    heycam: you still have to support the feDropShadow, so you'll have
    to worry about having it in the middle of the filter chain.

    dino: yes, but the shorthand will be easier and faster to implement.
    ... arbitrary filter chains could be very complex anyway. Authors
    will have to be aware of the complexity and that they might possibly
    be slow.

    heycam: it does not seem that it would be that hard to detect the
    position of the drop-shadow in the chain and optimize if in
    last/first position.

    dino: it is going to be slow in the filter chain.

    smfr: on the Mac we are relying on system framework for the
    shorthand filters which is faster than going through the whole
    filter chain. The method is super fast, they apply to everything. If
    we have to fall out of that to the filter chain, the performance
    impact is huge. There will be a lot of read-back from the GPU which
    is innefficient.
    ... drop-shadow does not fit nicely in our implementation
    constraints. In the way people use it, it makes sense to make it a
    separate property.
    ... people do not use it like a regular filter.

    dino: it would be interesting to see why people would use the drop
    shadow in a filter chain and why having it as a separate property
    would not work fine.

    smfr: we may get push back from the CSS working group like there was
    in the past. We can try again.
    ... there is text-shadow. May be this could extend text-shadow.

    <dino> vhardy: you probably want it to knock-out the content too

    <dino> vhardy: so you don't see through translucent pixels

    smfr: I think you may want to have both behaviors.

    dino: I think this is such a common request (drop-shadow) that it
    makes sense to make is a separate property.

    vhardy: why not optimize when detecting filter: drop-shadow(....)?

    smfr: we can do that. The tricky thing is that when we fall off the
    fast path, it is difficult to have a filter correctly applied to
    children elements like video or WebGL.

    dino: it would be good to know where people are with the
    implementation of this spec.
    ... the implementation is tricky when the content of the page is
    more complex.

    ed: I don't see how it is much harder to do it with the filter
    shorthand. I guess we can wait and see.

    heycam: it seems that you want to avoid any value on the shorthand
    property to go to the slow path.

    smfr: yes.

    dino: we can never guarantee that things will be fast, but we are
    trying to design this so that we can be fast in as many situations
    as possible. Right now, it is slow in too many cases. We are just
    talking about the shorthands.

    heycam: do you plan to make the markup filters fast in the future?

    dino: yes, we want to make everything fast. The issue of performance
    becomes complicated depending on the hw config.
    ... mobile, powerful hw...

    smfr: with markup filters, people can write their own custom
    filters. With the shorthand properties, we can do a lot of
    optimization. It is difficult with markup filters.

    dino: for the short term, custom filters may be faster than markup
    filters, even if our goal is to make everything fast.

    ed: it does not seem there is total agreement on what to do (keeping
    a separate property or not). I guess we can keep discussing it on
    the list.

    smfr: does anyone object to having a separate property.

    heycam: I do not object. It feels we are making decisions on current
    implementation performance.

    dino: that is true, but we could always add it back in.
    ... part of the spec. work is to get implementation feedback.
    ... this is the first release of the technology, we do not have to
    address everything upfront.

    vhardy: could we have both the drop-shadow property and the filter
    shorthand as well?

    dino: I would prefer to have the property. If it is a property, I do
    no see the use cases for having it in the middle of shorthand
    filters.

    ed: do you have any pointers for prior discussions on the css
    mailinglist(s) about this topic?

    <smfr>
    [17]http://lists.w3.org/Archives/Public/www-style/2009Sep/0131.html

      [17] http://lists.w3.org/Archives/Public/www-style/2009Sep/0131.html

    dino: We had previous discussions in the Seattle meeting. We were
    pointing these problems out and reluctantly agreed to adding
    drop-shadow filter shorthand

    smfr: the discussion is about drop-shadow interacts with
    border-image in CSS.

    ed: we should ask the CSS wg about splitting the drop-shadow filter
    in a separate property to get their feedback on that. I personally
    think it would be interesting to mix the drop-shadow in the middle
    of a chain.
    ... but if there are performance issues with doing that, then having
    a separate property may be the best way to deal with it.
    ... I don't want it to be difficult or to become a problem. I think
    having a filter keyword should still be an option.
    ... I think it is possible to keep it both ways. It depends on what
    other people think.

    vhardy: I think that if there are use cases where having the drop
    shadow in the middle of a filter chain is useful, I think we should
    keep it. Otherwise, I'd be ok keeping it.

    <scribe> ACTION: Dean to ask the CSS working group if we could add a
    drop-shadow property to CSS. [recorded in
    [18]http://www.w3.org/2012/01/23-fx-minutes.html#action07]

    <trackbot> Created ACTION-68 - Ask the CSS working group if we could
    add a drop-shadow property to CSS. [on Dean Jackson - due
    2012-01-30].

    ed: we are almost out of time. Anything else?

    (silence).

    ed: adjourned.

    <ed> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Dean to ask the CSS working group if we could add a
    drop-shadow property to CSS. [recorded in
    [19]http://www.w3.org/2012/01/23-fx-minutes.html#action07]
    [NEW] ACTION: Erik Dahlstrohm (with Patrick Dengler) to send an
    email to the CSS WG asking for feedback on proposed list of
    additional properties to be added when promoting SVG attributes to
    properties. Ask if properties should be prefixed or not to deal with
    possible collisions. [recorded in
    [20]http://www.w3.org/2012/01/23-fx-minutes.html#action02]
    [NEW] ACTION: Erik to create an initial editor draft of the SVG with
    CSS Animations/Transitions document that can be pointed to and
    discussed with the CSS WG. [recorded in
    [21]http://www.w3.org/2012/01/23-fx-minutes.html#action05]
    [NEW] ACTION: Patrick Dengler to send an email to the CSS WG asking
    for feedback on proposed list of additional properties to be added
    when promoting SVG attributes to properties. Ask if properties
    should be prefixed or not to deal with possible collisions.
    [recorded in
    [22]http://www.w3.org/2012/01/23-fx-minutes.html#action01]
    [NEW] ACTION: Patrick to create an initial editor draft of the
    document that can be pointed to and discussed with the CSS WG.
    [recorded in
    [23]http://www.w3.org/2012/01/23-fx-minutes.html#action03]
    [NEW] ACTION: Patrick to create an initial editor draft of the
    document that can be pointed to and discussed with the CSS WG.
    [recorded in
    [24]http://www.w3.org/2012/01/23-fx-minutes.html#action04]
    [NEW] ACTION: Vincent to edit the CSS 3D spec to point to the merged
    spec [recorded in
    [25]http://www.w3.org/2012/01/23-fx-minutes.html#action06]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [26]scribe.perl version 1.136
     ([27]CVS log)
     $Date: 2012/01/23 21:57:32 $
      _________________________________________________________

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

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [28]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/vhardy: don/vhardy, don/
Succeeded: s/filer/filter/
Succeeded: s/past/path/
Succeeded: s/discussions on this./discussions on the css mailinglist(s)
  about this topic?/
Succeeded: s/adjouned/adjourned/
Found ScribeNick: vhardy
Found ScribeNick: dino
Found ScribeNick: vhardy
Inferring Scribes: vhardy, dino
Scribes: vhardy, dino
ScribeNicks: vhardy, dino
Present: VH ED CM SF
Agenda: [29]http://lists.w3.org/Archives/Public/public-fx/2012JanMar/00
14.html

      [29]  
http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0014.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 23 Jan 2012
Guessing minutes URL: [30]http://www.w3.org/2012/01/23-fx-minutes.html
People with action items: dahlstrohm dean dengler erik patrick vincent
with

      [30] http://www.w3.org/2012/01/23-fx-minutes.html

WARNING: Possible internal error: join/leave lines remaining:
         <scribe> vhardy: DirkS has joined Adobe and will be focusing on
  the merged transforms specification. He's captured the issues in bugzi
lla. He's started on a wiki page with the difficulties of the merge



WARNING: Possible internal error: join/leave lines remaining:
         <scribe> vhardy: DirkS has joined Adobe and will be focusing on
  the merged transforms specification. He's captured the issues in bugzi
lla. He's started on a wiki page with the difficulties of the merge



    End of [31]scribe.perl diagnostic output]

      [31] 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 Monday, 23 January 2012 22:09:31 UTC