IRC log of fx on 2010-10-11

Timestamps are in UTC.

19:58:48 [RRSAgent]
RRSAgent has joined #fx
19:58:48 [RRSAgent]
logging to
19:58:50 [trackbot]
RRSAgent, make logs world
19:58:50 [Zakim]
Zakim has joined #fx
19:58:52 [trackbot]
Zakim, this will be 3983
19:58:52 [Zakim]
ok, trackbot; I see Styl_FXTF()4:00PM scheduled to start in 2 minutes
19:58:53 [trackbot]
Meeting: CSS-SVG Task Force Teleconference
19:58:53 [trackbot]
Date: 11 October 2010
19:59:35 [Zakim]
Styl_FXTF()4:00PM has now started
19:59:42 [Zakim]
+ +1.408.636.aaaa
20:00:02 [smfr]
Zakim, aaaa is me
20:00:02 [Zakim]
+smfr; got it
20:01:26 [Zakim]
20:01:37 [ed]
Zakim, ??P1 is me
20:01:37 [Zakim]
+ed; got it
20:05:32 [ChrisL]
ChrisL has joined #fx
20:06:16 [heycam]
heycam has joined #fx
20:06:24 [anthony]
anthony has joined #fx
20:06:43 [Zakim]
20:06:59 [ed]
20:07:12 [lstorset-opera]
lstorset-opera has joined #fx
20:07:46 [Zakim]
20:09:08 [ChrisL]
scribenick: ChrisL
20:09:16 [ChrisL]
Chair: Erik
20:09:21 [Zakim]
20:09:33 [ChrisL]
zakim, ??P3 is anthony
20:09:33 [Zakim]
+anthony; got it
20:09:48 [ChrisL]
topic: CSS SVG transforms update
20:09:50 [ed]
20:10:23 [ChrisL]
zakim, mute me
20:10:23 [Zakim]
ChrisL should now be muted
20:11:09 [ChrisL]
anthony: see
20:11:27 [ChrisL]
20:12:10 [ChrisL]
anthony: sumary at first url, spec at second one
20:12:56 [ChrisL]
anthony: some email from dr Olaf, pointed out some things
20:13:02 [anthony]
20:13:36 [ChrisL]
... mainly concerns related to changes from SVG
20:13:50 [ChrisL]
ds: wish there was a summary
20:13:56 [ChrisL]
anthony: I made one
20:14:16 [ChrisL]
anthony: changed todo list, added some items
20:14:27 [ChrisL]
... as follows
20:14:27 [anthony]
- Address any issues with transform-origin
20:14:33 [anthony]
20:14:38 [anthony]
- Address if the properties are independent of transform attribute used in SVG (1.1, 1.2)
20:14:43 [anthony]
- Address if the transform properties are available as presentation attributes
20:14:50 [anthony]
- Investigate and address backwards incompatibilities (rotate, origin on which transform is applied)
20:14:55 [anthony]
- Address who to determine the difference between original SVG attribute and new presentation attribute (example)
20:15:04 [anthony]
20:15:13 [anthony]
- Address if 'transform-origin' property has any influence on appearence of old SVG transform attribute
20:15:18 [anthony]
- Address issue for objects with no bounding box (e.g. line)
20:16:15 [ChrisL]
smfr: problem with assuming identity is the same as none
20:16:39 [ChrisL]
... in CSS identity doews something different, establishes a stacking context
20:17:15 [ChrisL]
... these need to be different values. initial value of none, bt identity as a defined value to start or end from
20:17:50 [ChrisL]
smfr: transform-origin initial value in SVG?
20:17:57 [ChrisL]
... 50% 50%?
20:18:25 [ChrisL]
anthony: odd for it to do differnt things in css and svg
20:18:31 [ChrisL]
smfr: how so?
20:18:57 [ChrisL]
... for pointer events we have a different initial value for svg and html
20:19:03 [ChrisL]
... could do the same here
20:19:20 [ChrisL]
shepazu: why have it different?
20:19:29 [ChrisL]
zakim, unmute me
20:19:29 [Zakim]
ChrisL should no longer be muted
20:19:45 [ChrisL]
smfr: fill and stroke dont translate to html
20:20:16 [ChrisL]
ChrisL: yes that is a perfectly reasonable for pointer-events
20:21:07 [ChrisL]
shepazu: do we have to have it different?
20:21:38 [ChrisL]
ChrisL: if svg already has them and css does not but has stacking contexts then the initial value needs to be different
20:22:01 [ChrisL]
ed: could see how many would brewak with a 50% 50% transform origin
20:22:05 [ChrisL]
... probably a lot
20:22:31 [ChrisL]
shepazu: can we make it so that both behaviors work in svg somehow
20:23:16 [ChrisL]
anthony: given that transform-origin is not previously part of svg, its new so should not be too much of an issue
20:23:29 [ChrisL]
... but for transform property it may break
20:24:22 [ChrisL]
ChrisL: if its a property then it always has a valie. even in older content that does not specify it explicitly
20:24:51 [ChrisL]
ed: would auto be ok as an initial value
20:25:56 [ChrisL]
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
20:26:10 [ChrisL]
20:26:22 [ChrisL]
ed: transform-oriin accepts coordinates?
20:26:30 [ChrisL]
smfr: well, it accepts lengths
20:27:24 [ChrisL]
smfr: percent is percent of the border box
20:27:36 [ChrisL]
shepazu: how to say 50% of the document?
20:27:42 [ChrisL]
smfr: you can't
20:29:15 [ChrisL]
ChrisL: so the initial value for svg is 0 0 which is relative to the local coordinate system
20:29:58 [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
20:30:22 [ChrisL]
smfr: in svg, bbox is pre-transform?
20:30:26 [ChrisL]
ChrisL: yes
20:30:38 [ChrisL]
shepazu: can you have an api to get the bbox?
20:31:06 [ChrisL]
smfr: yes there is one that gets the bbox of the transformed element. awkward when it maps to screen space
20:31:19 [ChrisL]
... existing apis use bbox
20:31:44 [ChrisL]
... have also had request for api to map local to global coordinate system
20:32:02 [ChrisL]
shepazu; dom3 has a request to hace such an api, jwatt made that request
20:32:16 [ChrisL]
... anticipate html/css will need that
20:32:22 [ChrisL]
shepazu (lloks for link)
20:32:40 [shepazu]
20:33:03 [ChrisL]
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
20:33:17 [ChrisL]
anthony: yes you would need a whole transform list
20:35:09 [ChrisL]
anthony: happy to go with the group. initial value for transform-origin, would be nice to be the center, and then somehow ...
20:35:41 [ChrisL]
ChrisL: that would change behaviour for existing content in new and old implementations. it would break all existing content that uses transforms
20:35:47 [ChrisL]
ed: resolution?
20:36:51 [ChrisL]
resolution: initial value is auto, which in svg means 0 0 and in html/css means 50% 50%
20:37:11 [ChrisL]
s/value/value of transform-origin/
20:37:57 [ChrisL]
smfr; so using css to apply this to svg does the right thing?
20:38:04 [ChrisL]
ChrisL: yes
20:39:15 [ChrisL]
action: anthony to add the new initial value of transform-origin to the spec
20:39:15 [trackbot]
Created ACTION-17 - Add the new initial value of transform-origin to the spec [on Anthony Grasso - due 2010-10-18].
20:39:24 [shepazu]
s/does the right thing/would have the traditional 0,0 origin point/
20:40:26 [ChrisL]
topic: Premultiplied gradients in CSS3
20:40:39 [ChrisL]
20:40:39 [ChrisL]
20:40:39 [ChrisL]
20:42:08 [ChrisL]
ed: css3 seems to want to have premultipied gradients, different from canvas and svg
20:43:07 [ChrisL]
smfr: otherwise gradient from red to transparent has grey in it
20:43:25 [ChrisL]
ChrisL; that is because transparent is rgba(0000) which is transparent black
20:43:47 [ChrisL]
... if you want a fade to red, fade to transparent red not transparent black
20:44:08 [ChrisL]
ed: people would want the css3 gradient systax with canvas and svg. they will be surprised
20:44:43 [ChrisL]
smfr: could we add a value to color interpolation to say its premultiplied
20:45:35 [ChrisL]
ChrisL: also in premultiplied, lower resolution for colors as the transparency goes up
20:45:58 [ChrisL]
smfr: so options are to pushback on premultiplied, or to add a value to allow controlling the interpolation
20:46:04 [ChrisL]
ed: not that difficult to add
20:46:10 [ChrisL]
shepazu: more properties
20:46:20 [ChrisL]
ed: no, existing property with one new value
20:47:20 [ChrisL]
ChrisL: concerned about hue shifts with fades of pastel colors
20:47:38 [ed]
20:47:52 [ChrisL]
smfr: we use premultipiied already for gradients in safari and firefox, certainly for transitions we use premultiplied
20:48:16 [ChrisL]
smfr: underlying lirary on mac does not give us a choice
20:48:35 [ChrisL]
smfr: chris, please post an example
20:48:54 [ChrisL]
action: chris post examples of reduced resolution with premultiplied colors
20:48:54 [trackbot]
Created ACTION-18 - Post examples of reduced resolution with premultiplied colors [on Chris Lilley - due 2010-10-18].
20:49:28 [ChrisL]
smfr: we use this for color transitions and for css3 gradients. that soec is not finished though
20:49:42 [anthony]
20:50:10 [ChrisL]
topic: 'writing-mode' values across CSS and SVG
20:50:26 [ChrisL]
ed: hoped to have elika here for this one
20:50:40 [ChrisL]
20:50:40 [ChrisL]
20:50:40 [ChrisL]
20:51:31 [ChrisL]
all implementations do different things with writing-mode. want to alighn with svg but there is inconsistet implementation behaviour
20:51:42 [ChrisL]
... wanted to see if spec defines correct behaviour
20:52:05 [ChrisL]
ChrisL: do we have a table of results for different implementations on that test?
20:52:17 [ChrisL]
ed: no. put this topic off until elika is here
20:52:56 [ChrisL]
ed: batik does 123 on second line in orange, in differnt way to opera. not well tested code in opera, not much used
20:54:36 [ChrisL]
ed: not that well defined in spec either.
20:54:53 [ChrisL]
ChrisL: good topic for tpac, needs a whiteboard
20:55:08 [ChrisL]
anthony: hope to be there
20:55:17 [ChrisL]
ed: will be there too
20:55:36 [ChrisL]
ed: good to define transforms more at tpac too
20:56:19 [ChrisL]
20:56:25 [ChrisL]
zakim, list attendees
20:56:25 [Zakim]
As of this point the attendees have been +1.408.636.aaaa, smfr, ed, ChrisL, Shepazu, anthony
20:56:32 [Zakim]
20:56:35 [Zakim]
20:56:37 [Zakim]
20:56:39 [Zakim]
20:56:47 [Zakim]
20:56:48 [Zakim]
Styl_FXTF()4:00PM has ended
20:56:50 [Zakim]
Attendees were +1.408.636.aaaa, smfr, ed, ChrisL, Shepazu, anthony
20:56:53 [ChrisL]
20:57:00 [ChrisL]
rrsagent, make logs public
20:57:06 [lstorset-opera]
lstorset-opera has left #fx
20:57:06 [ChrisL]
rrsagent, make logs minutes
20:57:17 [ChrisL]
rrsagent, make minutes
20:57:17 [RRSAgent]
I have made the request to generate ChrisL