W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

RE: Transform specs

From: Cyril Concolato <Cyril.Concolato@cisra.canon.com.au>
Date: Wed, 1 Feb 2012 06:41:03 +0000
To: Dirk Schulze <dschulze@adobe.com>, Vincent Hardy <vhardy@adobe.com>
CC: "public-fx@w3.org" <public-fx@w3.org>, Simon Fraser <smfr@me.com>
Message-ID: <54EF1DA3171CEE48AD59D7FF0DE043C3567BF90B@exm02-wvp.cisra.canon.com.au>
Hi Dirk,

Thank you for the changes. It looks good to me. I've modified the wiki page (http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsToDoList) to indicate that it's no longer useful. I've added a few comments inline.

Regards,
Cyril

From: Dirk Schulze [mailto:dschulze@adobe.com]
Sent: Wednesday, 1 February 2012 5:41 AM
To: Vincent Hardy
Cc: Cyril Concolato; public-fx@w3.org; Simon Fraser
Subject: Re: Transform specs

Hi,

I looked at the last ToDo's on the list and added bugs on https://www.w3.org/Bugs/Public/:

  Add optional translation arguments for scale i.e. [Sxy] | [Sx Sy] | [Sxy Tx Ty] | [Sx Sy Tx Ty]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15801
[Cyril] I don't know exactly where this comes from, probably this is to allow scaling rectangles from their center instead of the top-left corner, without having to use two translations.
  Add "How to read" section to say whether this, or the CSS 2D transforms spec is the canonical reference for CSS Transforms. The role of the two specs is not really clear [SMFR_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0010.html>]
Done? The mail of Vincent says he added a reference into the old specs.
[Cyril] Yes, I think the notes added to the different specs satisfy that comment.
  Address the case when inline elements are broken into multiple boxes due to either bidi or line-breaking, if transforms apply to bounding box of the inline. Mark application of transforms to inlines as "at-risk" [CSSWG_1<http://lists.w3.org/Archives/Public/www-style/2010Nov/0243.html>]
Done. We disallow transformations to inline elements that are broken into multiple boxes.
[Cyril] Is this the meaning of "atomic inline-level element" in the definition of "transformable element"?
  Address how transform-origin is applied to elements
  (1) effects the transform list of an element OR (2) effects specific all roate and scale individually in the transform list.
  e.g. T rotate(...) translate(...) scale(...) T' OR T rotate(...) T' translate(...) T scale(...) T'
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15800

  Fix syntax in SVG examples to match actual output result
I am not sure which examples the comment is referencing.
[Cyril] I don't' know either.
  Add that the SVG transform attribute is a presentation property, thus removing the need to keep same behavior as in other presentation properties in SVG [ACTION-2891<http://www.w3.org/Graphics/SVG/WG/track/actions/2891>]
  Put wording in to say unlike previous versions of SVG it is now a presentation attribute
  Address if CSS transform property overrides the SVG transform property or alternatively the CSS transform property can add to the SVG attribute
  Perhaps have a single presentation property between CSS and SVG
Done. See also http://www.w3.org/Graphics/fx/wiki/Merged_Transforms for SVG specific issues.

  Address if the properties are independent of transform attribute used in SVG (1.1, 1.2) [DOH_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html>]
Done. Related to Action.

  Address if the transform properties are available as presentation attributes [DOH_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html>]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15716 (just 'transform-origin' at the moment)

  Address how to determine the difference between original SVG attribute and new presentation attribute (example) [DOH_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html>]
We have a difference with SVG DOM. A resolution solved most issues there. A second difference is on SVG/CSS syntax. I want to talk about that on the CSS WG meeting minutes.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15503
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15506
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15507
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15508
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15525

  Address fix issue regarding values that can be supplied to transfomation functions. Define that units required for elements using CSS Box Model and SVG elements that specify unitless values are considered pixel sizes in the user space [DOH_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html>]
This needs discussion with the CSS WG. Previous bug reports cover this already.

  Address if 'transform-origin' property has any influence on appearence of old SVG transform attribute [DOH_1<http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0001.html>]
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15505

  Address if units for values should be preserved in the DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15798

It would be great if you can review this Cyril.

Thanks a lot,
Dirk

On Jan 28, 2012, at 9:58 AM, Vincent Hardy wrote:


Hi Cyril,
On Jan 26, 2012, at 3:50 PM, Cyril Concolato wrote:


Hi all,

Looking at the main page of the task force (http://www.w3.org/Graphics/fx/) and at the transforms related pages, I found several problems:
*         Mainly, it is very confusing to have all the links out-dated. This is not new. During TPAC, we had two resolutions (http://www.w3.org/2011/11/03-fx-minutes.html#item03):
o   We will publish a merged SVG/CSS/2D/3D spec as WD, and republish CSS 2D and CSS 3D with a note about the merged spec
o   We will republish the SVG Transforms module to obsolete it.

Both the SVG Transforms spec (http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html) and the CSS 2D Transforms spec (http://dev.w3.org/csswg/css3-2d-transforms/) have been edited with the note. The CSS 3D spec has not been edited as far as I know. Vincent also had an ACTION-58 to "Make clear in the merged transforms spec that it hasn't yet replaced the separate specs" but I can't find the FX tracker and I don't know the status of the action. The spec has not been edited.



[vh] I just edited both the 3D transform spec. and the merged specification as per the following two actions:

- http://www.w3.org/2011/11/03-fx-minutes.html#action07
- http://www.w3.org/2012/01/23-fx-minutes.html#action06

Merged spec: http://dev.w3.org/cvsweb/~checkout~/csswg/css3-transforms/Overview.html?rev=1.11;content-type=text%2Fhtml
3D spec: http://dev.w3.org/cvsweb/~checkout~/csswg/css3-3d-transforms/Overview.html?rev=1.7;content-type=text%2Fhtml

so things should be in order now.


It would be good if we could update the drafts and publish quickly, or at least update the task force page and have 2 links per spec (published + editor's draft).

*         A link to the merged spec should be added.


*         The link to http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html should also be edited to point to the merged spec.

Finally, can someone tell me the status of this page: http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsToDoList ?
Is it also out dated? Which issues have been addressed? Which remain? Should the page be deleted and remaining issues integrated in the spec?

[vh] We (the editors) need to go over that list and make sure these issues have either been addressed or are captured in Bugzilla.

Thanks for making sure we are on track with these specs :-)
Cheers,
-v



The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Wednesday, 1 February 2012 06:41:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 February 2012 06:41:53 GMT