- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 25 Oct 2010 16:39:55 +0200
- To: public-fx@w3.org
- Cc: "Anthony Grasso" <anthony.grasso@cisra.canon.com.au>
So, I assume that Patrick meant this discussion:
http://www.w3.org/2010/03/11-fx-minutes.html#item02
From what I remember there was consensus around making 'transform' a
presentation attribute in SVG, and treating it exactly the same as any
other presentation attribute (the details of how to apply it then falls
out of the existing model). Perhaps this needs to be called out explicitly
in the spec (as an informative note)?
The transform property currently says it applies to "svg container
elements and graphics elements", the full list of elements in SVG 1.1
(according to the attributes appendix) that can have a transform attribute
is:
‘a’, ‘circle’, ‘clipPath’, ‘defs’, ‘ellipse’, ‘foreignObject’, ‘g’,
‘image’, ‘line’, ‘path’, ‘polygon’, ‘polyline’, ‘rect’, ‘switch’, ‘text’,
‘use’.
SVG 1.1 graphics elements are: ‘circle’, ‘ellipse’, ‘image’, ‘line’,
‘path’, ‘polygon’, ‘polyline’, ‘rect’, ‘text’ and ‘use’.
SVG 1.1 container elements are: ‘a’, ‘defs’, ‘glyph’, ‘g’, ‘marker’,
‘mask’, ‘missing-glyph’, ‘pattern’, ‘svg’, ‘switch’ and ‘symbol’.
The difference between the definitions in SVG 1.1 and in 2d transforms
are: 'glyph', 'marker', 'mask', 'missing-glyph', 'pattern', 'svg',
'symbol'. And note that <pattern> already has a 'patternTransform'
attribute. The difference needs to be described better since css 2d
transforms introduces new functionality on some svg elements where there
didn't use to be a transform attribute before.
As a status update, there are currently two open actions on the 2d
transforms spec:
http://www.w3.org/Graphics/fx/track/actions/8
http://www.w3.org/Graphics/fx/track/actions/12
Cheers
/Erik
On Wed, 13 Oct 2010 16:53:56 +0200, Patrick Dengler <patd@microsoft.com>
wrote:
> 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]
>
>
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 25 October 2010 14:40:39 UTC