- From: Chris Lilley <chris@w3.org>
- Date: Mon, 11 Oct 2010 23:06:41 +0200
- To: public-fx@w3.org
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 Monday, 11 October 2010 21:06:46 UTC