RE: Minutes, 11 Oct 2010 FX telcon

I have been reading the update specification http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0000.html  (nice work!) 

I am extremely interested in following open issues identified in this conf call:

   Address if the properties are independent of transform attribute used in SVG (1.1, 1.2)
   Address if the transform properties are available as presentation attributes
   Investigate and address backwards incompatibilities (rotate, origin on which transform is applied)
   Address how to determine the difference between original   SVG attribute and new presentation attribute (example)

The reason I mention this is because I believe these (and some others) are bigger issues than transforms (as I have tried to communicate on the SVG calls).

Once we put a stake in the ground on them in what I believe to be priority order as:

	Backward Compatibility Approach
	Attributes that should be properties in SVG

We should break through more quickly on the open list of issues Anthony states above.

I know Erik had some proposals that were discussed last March.  Has any progress been made on these? (I cannot find it but if it has, please let me know)

Patrick Dengler

-----Original Message-----
From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Chris Lilley
Sent: Monday, October 11, 2010 2:07 PM
To: public-fx@w3.org
Subject: Minutes, 11 Oct 2010 FX telcon

Hello public-fx,

 http://www.w3.org/2010/10/11-fx-minutes.html

and below as text

                   CSS-SVG Task Force Teleconference

11 Oct 2010

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0008.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/10/11-fx-irc

Attendees

   Present
          +1.408.636.aaaa, smfr, ed, ChrisL, Shepazu, anthony

   Regrets
   Chair
          Erik

   Scribe
          ChrisL

Contents

     * [4]Topics
         1. [5]CSS SVG transforms update
         2. [6]Premultiplied gradients in CSS3
         3. [7]'writing-mode' values across CSS and SVG
     * [8]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 11 October 2010

   <scribe> scribenick: ChrisL

CSS SVG transforms update

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

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

   anthony: see
   [10]http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0000.ht
   ml

     [10] http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0000.html

   and
   [11]http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTrans
   forms.html

     [11] http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

   anthony: sumary at first url, spec at second one
   ... some email from dr Olaf, pointed out some things

   <anthony>
   [12]http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.ht
   ml

     [12] http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html

   anthony: mainly concerns related to changes from SVG

   ds: wish there was a summary

   anthony: I made one
   ... changed todo list, added some items
   ... as follows

   <anthony> - Address any issues with transform-origin

   <anthony> - IDL

   <anthony> - Address if the properties are independent of transform
   attribute used in SVG (1.1, 1.2)

   <anthony> - Address if the transform properties are available as
   presentation attributes

   <anthony> - Investigate and address backwards incompatibilities
   (rotate, origin on which transform is applied)

   <anthony> - Address how to determine the difference between original
   SVG attribute and new presentation attribute (example)

   <anthony> - Address if 'transform-origin' property has any influence
   on appearence of old SVG transform attribute

   <anthony> - Address issue for objects with no bounding box (e.g.
   line)

   smfr: problem with assuming identity is the same as none
   ... in CSS identity doews something different, establishes a
   stacking context
   ... these need to be different values. initial value of none, bt
   identity as a defined value to start or end from
   ... transform-origin initial value in SVG?
   ... 50% 50%?

   anthony: odd for it to do differnt things in css and svg

   smfr: how so?
   ... for pointer events we have a different initial value for svg and
   html
   ... could do the same here

   shepazu: why have it different?

   smfr: fill and stroke dont translate to html

   ChrisL: yes that is a perfectly reasonable for pointer-events

   shepazu: do we have to have it different?

   ChrisL: if svg already has them and css does not but has stacking
   contexts then the initial value needs to be different

   ed: could see how many would brewak with a 50% 50% transform origin
   ... probably a lot

   shepazu: can we make it so that both behaviors work in svg somehow

   anthony: given that transform-origin is not previously part of svg,
   its new so should not be too much of an issue
   ... but for transform property it may break

   ChrisL: if its a property then it always has a value. even in older
   content that does not specify it explicitly

   ed: would auto be ok as an initial value

   ChrisL: our initial value is 0 0 in the local coordinate system.
   that can't be expressed with percent syntax which is relative to the
   bbox

   ed: transform-oriin accepts coordinates?

   smfr: well, it accepts lengths
   ... percent is percent of the border box

   shepazu: how to say 50% of the document?

   smfr: you can't

   ChrisL: so the initial value for svg is 0 0 which is relative to the
   local coordinate system

   <ed> ED: so if we go for "0 0" as the initial value for svg, you
   would just have to specify transform-origin:center to get the
   50%,50% behaviour, not that much work really

   smfr: in svg, bbox is pre-transform?

   ChrisL: yes

   shepazu: can you have an api to get the bbox?

   smfr: yes there is one that gets the bbox of the transformed
   element. awkward when it maps to screen space
   ... existing apis use bbox
   ... have also had request for api to map local to global coordinate
   system

   shepazu; dom3 has a request to hace such an api, jwatt made that
   request

   scribe: anticipate html/css will need that

   shepazu (lloks for link)

   <shepazu>
   [13]http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0013.html

     [13] http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0013.html

   smfr: resisted giving the cuulative transform, because with 3d
   transforms flattening can occur, to put a plane in another 3d space
   so its hard to describe the whole thing

   anthony: yes you would need a whole transform list
   ... happy to go with the group. initial value for transform-origin,
   would be nice to be the center, and then somehow ...

   ChrisL: that would change behaviour for existing content in new and
   old implementations. it would break all existing content that uses
   transforms

   ed: resolution?

   resolution: initial value of transform-origin is auto, which in svg
   means 0 0 and in html/css means 50% 50%

   smfr; so using css to apply this to svg would have the traditional
   0,0 origin point?

   ChrisL: yes

   <scribe> ACTION: anthony to add the new initial value of
   transform-origin to the spec [recorded in
   [14]http://www.w3.org/2010/10/11-fx-minutes.html#action01]

   <trackbot> Created ACTION-17 - Add the new initial value of
   transform-origin to the spec [on Anthony Grasso - due 2010-10-18].

Premultiplied gradients in CSS3

   [15]http://www.w3.org/mid/B53F84D2-D549-4472-A7AE-CCDE9563E1D3@me.co
   m

     [15] http://www.w3.org/mid/B53F84D2-D549-4472-A7AE-CCDE9563E1D3@me.com

   [16]http://lists.w3.org/Archives/Public/www-svg/2006Jan/0342.html

     [16] http://lists.w3.org/Archives/Public/www-svg/2006Jan/0342.html

   [17]http://lists.w3.org/Archives/Public/www-svg/2006Jul/0050.html

     [17] http://lists.w3.org/Archives/Public/www-svg/2006Jul/0050.html

   ed: css3 seems to want to have premultipied gradients, different
   from canvas and svg

   smfr: otherwise gradient from red to transparent has grey in it

   ChrisL; that is because transparent is rgba(0000) which is
   transparent black

   scribe: if you want a fade to red, fade to transparent red not
   transparent black

   ed: people would want the css3 gradient systax with canvas and svg.
   they will be surprised

   smfr: could we add a value to color interpolation to say its
   premultiplied

   ChrisL: also in premultiplied, lower resolution for colors as the
   transparency goes up

   smfr: so options are to pushback on premultiplied, or to add a value
   to allow controlling the interpolation

   ed: not that difficult to add

   shepazu: more properties

   ed: no, existing property with one new value

   ChrisL: concerned about hue shifts with fades of pastel colors

   <ed>
   [18]http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationPrope
   rty

     [18] http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty

   smfr: we use premultipiied already for gradients in safari and
   firefox, certainly for transitions we use premultiplied
   ... underlying lirary on mac does not give us a choice
   ... chris, please post an example

   <scribe> ACTION: chris post examples of reduced resolution with
   premultiplied colors [recorded in
   [19]http://www.w3.org/2010/10/11-fx-minutes.html#action02]

   <trackbot> Created ACTION-18 - Post examples of reduced resolution
   with premultiplied colors [on Chris Lilley - due 2010-10-18].

   smfr: we use this for color transitions and for css3 gradients. that
   spec is not finished though

'writing-mode' values across CSS and SVG

   ed: hoped to have elika here for this one
   ... [20]http://www.w3.org/Graphics/fx/track/issues/3

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

   [21]http://www.w3.org/mid/4C2B18DD.6020209@w3.org

     [21] http://www.w3.org/mid/4C2B18DD.6020209@w3.org

   [22]http://dev.w3.org/csswg/css3-text-layout/test-writing-mode-direc
   tion.svg

     [22] http://dev.w3.org/csswg/css3-text-layout/test-writing-mode-direction.svg

   all implementations do different things with writing-mode. want to
   alighn with svg but there is inconsistet implementation behaviour

   scribe: wanted to see if spec defines correct behaviour

   ChrisL: do we have a table of results for different implementations
   on that test?

   ed: no. put this topic off until elika is here
   ... batik does 123 on second line in orange, in differnt way to
   opera. not well tested code in opera, not much used
   ... not that well defined in spec either.

   ChrisL: good topic for tpac, needs a whiteboard

   anthony: hope to be there

   ed: will be there too
   ... good to define transforms more at tpac too

   adjourned

   <scribe> agenda:
   [23]http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0008.ht
   ml

     [23] http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0008.html

Summary of Action Items

   [NEW] ACTION: anthony to add the new initial value of
   transform-origin to the spec [recorded in
   [24]http://www.w3.org/2010/10/11-fx-minutes.html#action01]
   [NEW] ACTION: chris post examples of reduced resolution with
   premultiplied colors [recorded in
   [25]http://www.w3.org/2010/10/11-fx-minutes.html#action02]

   [End of minutes]


-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead  Co-Chair, W3C Hypertext CG  Member, CSS, WebFonts, SVG Working Groups

Received on Wednesday, 13 October 2010 14:54:32 UTC